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.
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.
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.
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).
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> #1, <machine> #2, etc.).
every single report needs its own file … even repeated reports from the same person for the same machine (e.g. R4.0, R4.1 reports)
the HCL maintainer has to ensure correct numbering and not make any mistakes / duplicates
I think that would be a maintenance nightmare.
A technical solution could add the reporter name and the Qubes OS release into the slug and we’d have a unique URL. Alternatively a generated UID would do the trick too. But then we are back at a dev task.