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

@jeremiah.foster: No, this ticket is explicitly about the functionality, not branding of it!

package without .git and with debian/

Indeed. I used gbp to package flashrom for PureOS and will use it to package some other firmware. I still find the combination of git branching and Debian packaging confusing especially when one wants to package without .git and with debian/ :-|

ps. Worth learning git-gbp as, well, "most" of Debian uses it these days so you'll bump into it whether you like it not. :)

Nice work!

New Debian maintainer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919434

Well, as we discussed in https://tracker.pureos.net/T688, we want to get rid of the PureBrowser branding anyway.

flashrom 1.0 is in our repos but is not available yet. Will check on what the hold up is.

For clarity, you mean adding a stable Firefox with its own branding and without any changes to defaults, right? This shouldn't be an issue since PureBrowser would be the default and Firefox would require installation by the user.

I received an update from the coreboot team regarding this problem. It apparently is not a PureOS issue only, it affects other OSes too. The quick fix is to suspend and resume again (obviously not a permanent fix). The coreboot team suspects it could be related to some ACPI setting in coreboot, but they haven't been able to find anything conclusive.

It would be great to get some more information on the state of the laptop when it is hibernating. I'm setting up something called "tellerstats" with lm-sensors (which are both in PureOS) to gather more info so I can see if I can reproduce the problem.

Is there anything I can do to help find the cause (collect logs, etc.)?

Seems you are on the right track in that the error message indicates FileZilla is requesting a feature unavailable in GnuTLS. The exact cause for you may not be same as the one addressed in the bugreorts you found - they might just be for similar kinds of issues.

The build is still failing :(

So, the problem is a simple test failure on arm64: https://software.pureos.net/builds/job/2ea4dd9c-5685-46cb-bd0c-f0d747053990

Assertion 'r < 0' failed at ../src/journal/test-compress.c:235, function test_lz4_decompress_partial(). Aborting.

@chris.lamb I'll have a look