We only have one installer in PureOS and that is Calamares

4TB disks/partitions can not be supported, unless we switch from BIOS to UEFI with GPT support, or adding GPT support to the Librem's BIOS by other means.
See https://en.wikipedia.org/wiki/GUID_Partition_Table

I can't reproduce this. My laptop 'suspends' when the lid is closed.

With regard to installers, it is unclear to me which installer is the default. This is relevant because I'm trying to diagnose a situation where the installer fails on disks that are 4 TB large. It looks like, from the files that show which packages are included in the ISO, that we also have a 'pureos-installer' and a 'pureos-live-installer' along with 'calamares' which appears to be an installer as well. I assume that pureos-installer is the default (and pureos-live-installer is just for GNOME Live?

@jeremiah.foster I'm afraid I didn't make a note of which ISO I used :( I guess if the issue doesn't recur on the latest ISO we can close it.

Is there a link to the ISO? I'm planning on doing some testing of images so that we can measure 'reproducibility', knowing which image was used as the ISO for PureOS installation in this bug will serve as a good starting point. If this is no longer an issue, perhaps we close the issue?

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;