Ok, got a reply from a Gnome dev, to reset the tracker via this command: tracker reset --hard

Merged in https://gitlab.com/libosinfo/osinfo-db/commit/3570a3965b6ebce5b59b8b2e96f0730f4c3e1340 via https://gitlab.com/libosinfo/osinfo-db/merge_requests/4

@actualben Thanks for your comment, this helps me. I'll try and read up a bit to understand exactly what we're bringing in and see what is required.

As I believe kyle.rankin was suggesting, it would be nice to add EDID data sets to the pureos standard kernel for resolutions beyond what's already in there, especially the common "named" resolutions (like the one I need "WQXGA" aka 2560 × 1600). The named resolutions are described here: https://en.wikipedia.org/wiki/Graphics_display_resolution

makes sense to do at least some basic testing before throwing out an image

While I'm using a Librem, it is a 13v3 which is a version later than yours and don't have access to a v2 at the moment. I have no problem with higher resolutions however using GNOME Settings in the manner you specify;

@jonkri Is it possible that there is a typo in the file name that prevents your window manager from picking it up? I ask that because you posted the contents of '10-montors.conf' and if that is the actual name of the file perhaps that is not getting read properly?

At the moment we deliberately don't point the downloads page just to the "latest" image, because it makes sense to do at least some basic testing before throwing out an image as default download. And in that case, the page may just as well point at the latest image.

I really don't get why this can't be resolved publically. For everybody that reports this issue here I would guess there are at least 10 others who are just bad-mouthing the device without us even knowing. Please can we have a solution matrix?

@chris.lamb: this was not needed before because Purism's assembly partner flashed the keyboard EC firmware prior to shipping.

It's still not clear how (what steps have to be done exactly) I (or Purism) can fix this issue and we all can agree that this issue shouldn't be existing, right?

Ah, right… Well, see.. this is why I would looove a wiki page (or whatever overview) with a grid of the status, next steps and ticket number for each combination. Is this something @mladen.pejakovic could put together?

This particular ticket is about the German keyboard layout issue where the pipe key does work, but sends an incorrect signal, not about the unrelated UK keyboard issue where the key does not send a signal at all.

@kyle.rankin Alas, I feel you are unwary victim of the multitude of confusion and lack of clarity around this issue and the misleading tickets. A firmware update is definitely required for at least (!) LibremV3 with the UK physical layout - the key simply cannot be remapped in software as it is not generating the keycode/scancode whatsoever. ie. it is not a question of selecting the right layout in Gnome or similar - the key cannot work in Grub/the bios/boot, etc.

Hmmm. Maybe the problem you're describing is not the problem I have, because the mapping shown in Gnome Settings/Region and Language (see the screenshot) shows the pipe key at the correct position and nope, I didn't choose the US keyboard layout at installation or anytime else.
At the testscreen it even shows that the pound sign (german layout on the right, left from enter) is pressed instead of the pipe sign (right from shift).

It's not a firmware problem exactly. The keyboard is a *different* layout than the default US/UK/DE layout, it's a variant. In the US case it's a US alternate international layout. If you dig down into the keyboard options and set it to that, the pipe key works, however during an install everyone naturally picks the default US keyboard layout (or UK or DE, depending on the device) and almost every key works as expected except the pipe key.

Thanks @Jonathan. It looks like your link leads to a opensnitch deb, I'll test it out. Would be cool if this was submitted to Debian, is that planned?

I can't recall why but it was asked that I kept the details off the public bugtracker at the time but I certainly remember that it did not need any special hardware. I'll leave this to the others cc'd above as they handled it last time, but I guess this is still evidence and underlines my previous pleas for a proper grid outlining the issue and solution for all Librem 13/Librem15 vs v3/v4 vs de/us/uk, etc.

I'd prefer if it's fixed on the firmware level instead having a workaround installed, which only works PureOS.
Is it somehow possible to apply the firmware fix myself? (I'm dependent on it, I need it for work...)
Is the EC flashable on PureOS, or do I need an external programmer?

So, um, the Librem13v3 w/DE keyboards need a firmware fix too? eg. https://tracker.pureos.net/T439#7821

Jep, no change.

Did you reboot after you upraded the system?

Ok, it reports 240-5pureos1 as the current installed version after apt full-upgrade, but it still inputs the pound sign instead of pipe.

@chris.lamb Odd, I didn't get an email for your reply to this ticket...
Anyway, my message in the chat was just that I wouldn't be able to work on it before/at FOSDEM, if there was any noteworthy thing I would have updated the ticket.
On the good side though, the changes are in green since this Saturday/Sunday, so everyone affected: Please upgrade your PureOS installations and check whether the issue is actually solved!
(I'll mark this as fixed meanwhile, but feel free to reopen if the issue persists)

Sorry, that was a bit to early :)

Also included in

Gentle ping on this?

@mak Ping on this?

Hola si es difícil empaquetar opensnitch depende de librerías muy espesificas ,

Ah, so it's a CLI utility? That's why it wouldn't launch from Gnome's search!

I think flameshot launches, it is just waiting for input no? If you run $ flameshot gui what happens?

Refiled PR here:
https://gitlab.com/libosinfo/osinfo-db/merge_requests/4

Any news on how to get proper Hz rate on the Librem 13v2?

I never did get any support trying to get this to work. However, I did write about how I got it to install on my MBP after lots of work:

Assuming the same/similar tools are used to build PureOS as Debian, it shouldn't be that difficult to add I would think. And given that modern systems no longer ship with Legacy Boot/CSM, users who want to give PureOS a try are left without a viable option outside of a VM. I'd think that rates higher than a 'low' priority, but that's just me :)

The package has migrated now.

I'm glad to hear FTPS is working again. I'm going to close this issue for now.

Glad to hear that the update helped!

Latest update fixed the issue.

Looks like the migration is blocked because it would break some older localization packages.
I gave it some manual hints to make the package migrate.

Uploading to the download page [..]

I have not seen Thunderbird version 60 in green since it appeared in buster and PureOS main in November. My understanding was that green was the proper update repository.

@mak ISTR some update here in a different forum; can you briefly update this ticket on your plans/timeline? No rush on the action itself, but I just cannot recall the current status / hat / next steps

Alright thank you for your replies. In fact, there was an update of FileZilla today and it did fix this issue. I am able to connect again over FTPS.

How far away do you think we are with this? I'm sure it would be a total boon for implicit communications within the PureOS team, @jeremiah.foster :)

I've tested the image and seen that it works. Uploading to the download page is a separate discussion and should probably wait until we've tested the OEM image. We can close this bug however by stating that there are two locations for new images, one is a directory that just holds the output of the build system, the other is the official, tested download image.

Thanks for mentioning, @guido - I had missed T594 now linked here.

Tracking fast-changing packages in particular need strong monitoring e.g. by somthing like security-tracker.debian.org.

This is also related to https://tracker.pureos.net/T594

in a binary .deb package you don't want your source control tool cruft left inside

That was a bit cryptic, sorry. I mean that in a binary .deb package you don't want your source control tool cruft left inside since it is extraneous and doesn't keep the original upstream source pristine. But, at the same time, you do want a branch that contains the debian directory since that is where the control file and other debian files live which give instructions to the final binary. The consequences are that one has to jungle many branches and to make sure you're on the right branch when you call gpb. Or perhaps I haven't got the hang of it yet.

I can confirm that the suspend/resume fix works

@jonas.smedegaard sure, the new title makes sense to me.

I find that expressing tickets as what is wrong helps.