Recently retested with the same Logitech headset and these package versions. It's working again!

There is an RSS bot that reposts Purism blog posts in the #community-general:talk.puri.sm room. I'm afraid I don't have any details, and the person that implemented it is away. But if you can generate RSS output that might be a start!

@jeremiah.foster Currently I manually trigger builds by running a command on the archive server. I could likely give you access to that with permission of the sysadmins. Since the automated builds might be very slow though and the system will override the previous image in case there is more than one image build on the same day, I think that you might be happier with a manual image build.

(Oh, I want that too but the page you linked is a high-level and textual status tracking document.)

@chris.lamb Ah, so you just want Git commit updates? That's a way easier thing to do, I assumed you wanted notifications about any archive changes and bugtracker changes.

I now put my own status-tracking document into the repository

In T701#13101, @EchedeyLR wrote:

The first error I read it was related with some kernel modules used for the touchpad but I was not sure. Please, run lshw again and dmesg.

The driver should be provided by the kernel like the old version.

The first error I read it was related with some kernel modules used for the touchpad but I was not sure. Please, run lshw again and dmesg.

That took awhile! But the whole process ran. I rebooted (the computer wouldn't shut down properly) and tried connecting via wifi. No luck. It wont even recognize available networks, which it has done in the past.
Incidentally, the error I've been getting from when I tried installing Linux mint definitely has something to do with the touchpad, but I've tried installing LM with the touchpad turned off and no dice.
So I can't install Mint, but I can install PureOS but can't get the driver for the wifi card.
Hmmmmm. I haven't given up yet.

It's upgrading right now...it's going to take awhile. I'll reboot and try the wifi when the upgrade is complete and I'll let you know.

I dont believe upgrade solve your problem but anyways you should maintain your system up-to-date for others reasons and make sure about both errors are not solved yet.

Okay, proceed to upgrade.

About both errors, I saw some posts and could be related with some kernel modules. We should wait for PureOS developers.

I have not hit Y yet...

Did not run sudo apt upgrade yet. Here is sudo apt update:

sudo apt update && sudo apt upgrade

OK...I checked for updates and it said the system was up to date. If you know how to manually update the kernel via the terminal, please let me know and I'll run the commands.
As far as the dmesg command, it returned an insanely long string where every line was the same:

It would be great if you test the wifi again before to exec dmesg

Please, upgrade your system first. Current available kernel version is about 4.19

I have no idea how to run as a superuser but it did give me a warning that the data may be incomplete unless I run the command as a superuser

Mmm on https://h-node.org/wifi/view/en/1941/Realtek-Semiconductor-Co---Ltd--RTL8821AE-802-11ac-PCIe-Wireless-Network-Adapter/1/1/undef/undef/undef/undef/wifi-works/RTL8821AE is reported as not run with free software but It was on Trisquel 8 (Ubuntu 16.04). Could you put lshw on your terminal and post here the *-network sections of the output?

Per your request.

lspci on your terminal

Please, make lspci on a terminal and post the output here.

Please, make lspci on a terminal and post the output here.

@chris.lamb For the Laniakea changes, I now put my own status-tracking document into the repository, so it is more obvious on why making such a change takes so long: https://github.com/lkorigin/laniakea/blob/master/docs/porting-status.md#status
I won't extend the existing codebase much (except for bugfixes) and instead just work on the new component versions for now, which unfortunately means very slow progress for a while.
As for the room itself, I can't comment on that, that's sysadmin business.

Great, thanks for the reply. What triggers the build? Is it possible for me to trigger a build? I'd like to test our PureOS ISO for reproducible builds so I'd like to build two images of PureOS twice and test with diffostat.

@jeremiah.foster There isn't a formal testing process. I check whether the system boots, installs and runs through the initial setup and the initial experience looks okay. Others do that as well on different hardware, and if nobody reports any major issues, the image is good to go.
If there was a particular change on the installer or initial setup that might have broken something, I will look at that change in more detail to see if really everything works as expected.
But that's about it, nothing fancy (or even structured) is currently happening.

So next in line to be tested in the February 2nd release, yes? If so what do we mean by "test", are we sanity testing i.e. it works in my machine kind of thing? I'd like to create a more formal QA process around this and would like to start from how we test today.

Thank you Jonas!

I recommended using 'tracker reset --hard' with GNOME photos, but it deleted some screenshots so caveat emptor; you may lose data.

Thanks for clarifying, @jeremiah.foster - I hope the current title is suitable.

Ehhh... What?
The latest release on https://downloads.pureos.net/ is the current one, and once it has been tested the released one (which should happen very quickly, ideally). If a release is considered broken, it is either removed or a more recent one is built.
Each and every image build is accompanied by a .packages files which lists the contained packages and their versions in details. See https://downloads.pureos.net/live/gnome/2019-02-10/pureos-8.0-gnome-live_20190210-amd64.packages for example.
There are also detailed file listings of stuff included in the installation images, as well as a build log and checksums (the former of which also contains all information on package versions).

flashrom 1.0 in PureOS and new Debian maintainer upstream.

So this issue seems to boil down to a wishlist item "bring in yacy to PureOS". PureBrowser has no leverage over what public search engines serve with regard to proprietary or non-proprietary javascript.

We should not mark the issue as "resolved" until it is no longer "broken" regardless of whether it is in the installer, green, or landing.

Well, I don't see how 'aggressive' fits here either way.

@jeremiah.foster please elaborate on your title change - is this issue not about _continuously_ updating at a faster _pace_ but only about getting some specific new version?!?

Users also have the option to install "unofficial" flatpak'd Firefox here if they feel comfortable with the possible lack of security: https://firefox-flatpak.mojefedora.cz/

The cryptsetup-initramfs package has a README on configuring gnupg-sc, but I've found it's not entirely accurate and is too focused on configuring a *new* and non-root disk.

Is there a documentation available to configure this, now that it's possible to do now?

Just confirming that we can close this ticket.

Restarted browser. Garbled text disappeared.

Ok, the workaround described in T486 helps!

This is NOT related to T431, but rather the workaround of that issue, I have described it in T486 and proposed a solution (workaround is also there) so I won't say anything more here as I simply do not have time to explain everything once again.

@jonas.smedegaard yes that does seem to be the case.

In T688#12739, @sean.obrien wrote:

it's worth questioning our assumptions in cases like this, and luckily I had just been in a discussion about this very thing with a PureOS user, looked up the policy, and can't find anything restricting us from doing that. I will contact Mozilla on Friday trademark-permissions@mozilla.com if there are no objections, but it's best to let this sit for a while.

How is this issue different from T11?

The ROM/files/etc might be but that would not completely explain why we can't at least have a solution matrix here. :)

The EC firmware needs to be replaced.
Maybe this is a license issue, because the ROM is non-free and distributing it freely would be problematic, but maybe @mladen.pejakovic will tell us more.

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?