Continuing the discussion from Short list of laptops/desktops that work well with Qubes OS:
I think it’s the other way around. It’s HCL links pointing to the forum. However, I was able to find none:
user@host:~/qubes-hcl$ grep -r "forum.qubes-os.org" | wc -l 104 user@host:~/qubes-hcl$ grep -r "qubes-os.discourse.group" | wc -l 0
@fsflover can you give a specific example?
So in this case the link was moved. And it’s not actually broken. Just points to the split post which is now the real post for that. Although not ideal.
@Sven here it has in fact been deleted. If you could @sven, please abstain from deleting topics as it sooner or later leads to confusions. There I can still see the deleted post has been moved to another conversation. Were it not deleted, users could still see it had been moved.
Or it could be when a full thread is moved, discourse automatically deletes the post and it makes it looks like the user who moved it also authored the post deletion?
Anyhow, we need to better handle these broken links. Either leaving reports always in their original URL and just quoting on the “device-meta page” or manually updating these links when things get moved around.
@Sven would this sound reasonable?
How is it not broken? The link is
interesting. It might be a bug. But whenever you send me a link to the HCL, the one you mean is actually the one bellow the link you sent me. Hence the confusion.
And yes. That one was deleted for the same reason as state here HCL links broken - #4 by deeplow. Thanks for bringing that to our attention.
I noticed it, too. The problem is, all four Librem 14 links to HCL are the same link. I just can’t link them separately. For this reason I had to write “4xR4.0” here. Same for some other laptops, including E570.
Ok. I’ll leave this for @sven.
Removed two linked reports that did not match the i7-7820HQ CPU on P51 page.
Removed one linked report that did not match the i7-8550U CPU on T480s page
Removed T480s from the R4.0 community-list due to lack of second HCL report and the one that was there listing issues. When originally seeing @quququbebebe’s report I overlooked the fact that it is for R4.1.
Removed one linked report that did not match the i5-2520M CPU on X220 page
Here are the changes made to the HCL. There is still work to do, as we now have the inconsistent state of some computers on the list having their HCLs listed, while others don’t. I’ll address that over time when we build the R4.1 version of the list.
I was forced to do this as an edit because “No more than 3 consecutive replies are allowed. Please edit your previous reply, or wait for someone to reply to you.” … I understand the intention but question the value. This way none of the mailing list receivers will see my post.
This is because the anchor links to specific HCL rows are automatically generated by slugifying the data in the first cell. Since all four of those rows have identical first cells, the slugs are all identical, hence all four anchor links are identical.
There’s probably some way to “fix” this, but I don’t know what it is. Would probably require a “help wanted” issue, followed by a community PR to fix it.
There are some laptops in HCL which have exactly the same specs but the first cell in the table differs in some random (?) characters, e.g.
X250 and X250
Shouldn’t it be done for all devices in order to give the possibiity to link separate reports?
IIRC, that code (e.g.
20CLS4AY00) the IBM/Lenovo hardware build configuration for the laptop.
In some cases it might matter, in that it specs a different processor, chipset/mainboard revision, etc. e.g. there was an era where some builds of a model would include an important virtualization feature, such as VT-d, and others would not.
I will make sure the broken links are fixed and if I move posts to a device page I will manually update the link. I think it is important that …
a) the link in the HCL always points to the original report post
b) that report post is moved onto the device thread in case we have one for that specific device
This will require some manual intervention every now and then by the maintainer, but seems manageable as going forward it will always happens at the time the report is added to the HCL (part of the flow).
I don’t see this as a bug, because by definition it’s the same machine then. In many cases it’s also one YML file, because I merge reports of identical machines into one file (as has been done by others before me).
Example case Librem 14:
--- layout: 'hcl' type: 'laptop' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'yes' remap: 'yes' brand: | Purism model: | Librem 14 v1 bios: | PureBoot-Release-18 cpu: | Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz cpu-short: | i7-10710U chipset: | Intel Corporation Device [8086:9b51] chipset-short: | Comet Lake gpu: | Intel Corporation Device [8086:9bca] (rev 04) (prog-if 00 [VGA controller]) gpu-short: | Integrated Graphics (UHD 620) network: | Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) memory: | 65410 scsi: | usb: | 1 versions: - works: 'yes' qubes: | R4.0 xen: | 4.8.5-34.fc25 kernel: | 5.4.129-1 remark: | credit: | @dallas87 link: | https://forum.qubes-os.org/t/short-list-of-laptops-desktops-that-work-well-with-qubes-os/5197/83 - works: 'yes' qubes: | R4.0 xen: | 4.8.5-34.fc25 kernel: | 5.4.125-1 remark: | credit: | @dom0 link: | https://forum.qubes-os.org/t/hcl-report-for-librem-14-v1/5585/1 - works: 'yes' qubes: | R4.0 xen: | 4.8.5-32.fc25 kernel: | 5.4.107-1 remark: | credit: | @hanabi link: | https://forum.qubes-os.org/t/hcl-librem-14-v1/4409/1 - works: 'yes' qubes: | R4.0 xen: | 4.8.5-30.fc25 kernel: | 5.4.98-1 remark: | credit: | MrChromebox link: | https://groups.google.com/d/msgid/qubes-users/300a400c536f64602908b8c2d14ba4fd0a8db7bf.camel%40puri.sm ---
Even though they’re the same model, I can understand why it seems like a bug that there’s no way to link directly to certain rows in the table. Ideally, either every row would naturally have a unique first cell (consistently merge all same-model reports), or we’d somehow make every first cell unique, perhaps by incrementing them (
<machine> #2, etc.).