HCL links broken

[fsflover]

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?

[brendanhoar]

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.

B

[Sven]

@deeplow

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?

This

[Sven]

@deeplow

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?

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).

[Sven]

@adw

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.

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

---

[adw]

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.).

[dom0]

There is a small error in the HCL that I have just noticed.

All of the Librem 14 items in the table are listed as using PureBoot-Release-18 for BIOS. However, my Librem 14 BIOS is Coreboot/SeaBIOS.

Now that Qubes R4.1 is here, I understand that this minor detail is less relevant, but I thought that I should mention this here.

Thank you for your work maintaining the HCL.

[Sven]

I’ll look into it.

[Sven]

Fixed

[fsflover]

This problem is still there. How do I link to MrChromebox’s report on Librem 14?

[Sven]

The way it is implemented currently you can’t do this. You can link the Librem 14 v1 but not a specific report. @adw explained why that is.

I lack the web programming skills and the time / motivation to learn them to do anything about it. So if this is a real pain point, someone from the community needs to step up and fix it.

[adw]

I think non-technical fixes are possible, as explained above, but whether they’re desirable is more of an HCL design and usability question.

[Sven]

@adw

we’d somehow make every first cell unique, perhaps by incrementing them ( <machine> #1 , <machine> #2 , etc.).

@adw

non-technical fixes are possible, as explained above

Non-technical would mean:

• 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

@adw

whether they’re desirable is more of an HCL design and usability question

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.

[adw]

@Sven

@adw

we’d somehow make every first cell unique, perhaps by incrementing them ( <machine> #1 , <machine> #2 , etc.).

@adw

non-technical fixes are possible, as explained above

Non-technical would mean:

• 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

The full sentence was:

@adw

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.).

It sounds like you are considering the second idea (second half of the sentence) but not the first idea (first half of the sentence).

The first idea would involve merging all the reports that would result in identical first cells, with the result that every first cell is unique. This would mean that there are no longer any situations where multiple rows share the same slugified anchor link.

Perhaps this is also a bad idea, but if so, I haven’t heard why yet.

[Sven]

@adw

The first idea would involve merging all the reports that would result in identical first cells, with the result that every first cell is unique. This would mean that there are no longer any situations where multiple rows share the same slugified anchor link.

Perhaps this is also a bad idea, but if so, I haven’t heard why yet.

Just to make sure we are not talking past each other: by “non-technical” we are talking about solutions that do not involve any change of the code that generates the website, but merely manipulating the data stored in the YML files?

If that is the case please consider the structure of the YML files: we first have data like the OEM, model, bios, CPU, graphics, networking, USB etc. That is what I would call the “machine data” and that is also what is used to create the slug.

Followed by that we have a list of “versions”. Each “version” consists of Qubes OS version, Kernel version, Xen version, a remark, the name of the reporter and a URL.

We already do merge all reports that have identical “machine data” into a single YML file. That means there is one slug. However, multiple persons may have reported about that machine and for multiple versions.

This is what is actually causing the issue. Each “version” aka report gets it’s own row in the table on the website, but they all share the slug generated from the “machine data”.

[adw]

@Sven

If that is the case please consider the structure of the YML files: we first have data like the OEM, model, bios, CPU, graphics, networking, USB etc. That is what I would call the “machine data” and that is also what is used to create the slug.

Followed by that we have a list of “versions”. Each “version” consists of Qubes OS version, Kernel version, Xen version, a remark, the name of the reporter and a URL.

We already do merge all reports that have identical “machine data” into a single YML file. That means there is one slug. However, multiple persons may have reported about that machine and for multiple versions.

This is what is actually causing the issue. Each “version” aka report gets it’s own row in the table on the website, but they all share the slug generated from the “machine data”.

If I understand correctly, following this option to its logical conclusion would probably result in deleting (or otherwise “losing”) “version” data while retaining only “machine” data. Then we’d have the desired result of every row starting with a unique first cell, but at the cost of “forgetting” how many different reports there were, from whom, on which releases, and so on. Presumably, this would be too extreme of a cost to pay for the desired benefit. Is this understanding correct?

If so, I agree that such a cost would be too high. I just wanted to make sure we were genuinely considering the available options.

[Sven]

@adw

Then we’d have the desired result of every row starting with a unique first cell, but at the cost of “forgetting” how many different reports there were, from whom, on which releases, and so on. Presumably, this would be too extreme of a cost to pay for the desired benefit. Is this understanding correct?

Yes.

@adw

If so, I agree that such a cost would be too high. I just wanted to make sure we were genuinely considering the available options.

I appreciate that and are glad we explained it in this detail. Currently the slug is generated from:

brand + model + cpu-short + chipset-short + gpu-short

I suggest a unique slug could be generated from:

brand + model + credit + qubes

credit = the name/alias of the reporter
qubes = the version of the Qubes OS release

If there ever is a reporter having multiple versions of the same brand/model and is reporting those for the same Qubes OS version … like me … I will make sure the model contains an additional identifier as in ThinkPad T430 (23477C8) and ThinkPad T430 (23497W9).

You did send me some instructions on how to create a build/test environment for the website and I suppose if I can locate the code that generates the slug I will be able to change the variables going into it and test the result. So unless another volunteer steps forward in this thread, I will take a look at this when I find the time (might be a few weeks with everything else that is going on).

[adw]

Another possibility occurs to me: Merging all same-model reports without losing information could be achieved by grouping the “version” data into a list. For example, a single row could have “Credit: Sven, Deeplow, Simon” (multiple names in one “Credit” cell). But this gets messy when considering how to handle different Qubes OS releases, since those are different columns. Probably too much trouble.

@Sven

I appreciate that and are glad we explained it in this detail. Currently the slug is generated from:

brand + model + cpu-short + chipset-short + gpu-short

I suggest a unique slug could be generated from:

brand + model + credit + qubes

credit = the name/alias of the reporter
qubes = the version of the Qubes OS release

IIRC, the slug is just automatically generated from the contents of the first cell, but it might be possible to include more than that.

@Sven

You did send me some instructions on how to create a build/test environment for the website

That’s documented here, btw.

@Sven

I suppose if I can locate the code that generates the slug I will be able to change the variables going into it and test the result. So unless another volunteer steps forward in this thread, I will take a look at this when I find the time (might be a few weeks with everything else that is going on).

Sounds good. This seems like a fairly low-priority issue, so I agree with not letting it take precedence over more pressing matters.

[Sven]

I have now made the change and submitted PR #198. There is an important side effect of this change to discuss before merging it: while I can update the links in the list of community recommended computers, there will be hundreds of links in the forum and the mailing list archive broken forever

Is everyone OK with that?

[Sven]

There is a better solution now. Each HCL report file (YML file) represents a specific device. But there can be more than one report in such a file. These reports are called ‘versions’. A version includes the Qubes OS release, kernel version, Xen version, remark and name/link of the reporter.

Until now if there was more than one version, all versions had the same URL (because the slug was formed from device details). The previously discussed solution of changing how the slug is created would result in breaking existing links in the forum and mailing list archive. This new solution simply adds an underscore and the version index to the URL of every report that is not the first one.

Hence all existing links continue to work as before, but we are now able to link to a specific ‘version’.