Thank you for the quick review & validation! :-)

This isn't actually a high priority issue, as it's only a visual/terminology thing. Will need input from the marketing team though, I think we canonically only call PureOS "PureOS" and not mention Linux (internally, GNU/Linux is used for PureOS though, so this may need to be changed).

This is resolved starting with the 2019-05-01 image builds.
Thanks for reporting this issue!
Since the installer changes are extensive this time, it would be awesome if you could test the new image and verify that the issue is gone. New images will become available on https://downloads.puri.sm/live/gnome/2019-05-01/ shortly.

Eww, I don't think I have addressed this yet. Thanks for the issue report!

emacs25 seems to only exist as a transitional binary package to emacs-gtk in PureOS:

emacs25    | 25.2+1-6+b2   | landing    | arm64
emacs25    | 25.2+1-6+b3   | landing    | amd64
emacs25    | 1:26.1+1-3.2  | green      | all
emacs25    | 1:26.1+1-3.2  | landing    | all
emacs25    | 1:26.1+1-3.2  | purple     | all

There appears to be some cruft in landing, but that has a lower version number so shouldn't be easily installable.
Are you sure this is still an issue?

I can reproduce this here. The timezone shouldn't actually cause any problems here, yet the Release file was apparently signed and piblished with a timestamp in the future to your system. Very strange. There is no unusual behavior going on in the archive as far as I can see.

The database connection got a bit messed up due to parts of the infrastructure rebooting.
Should all work again now (and soon even recover better from issues like this when the new software is in place).

librem5-devkit-tools_0.0.2_source.changes: misses mandatory field Binary
How was this source package built exactly? The Binary field needs to be present in .changes file in order to be processed.

This is not a bug in the archive. Source-only uploads are allowed, but the .changes file of this package apparently misses the mandatory Binary field and is therefore rejected. Not sure what caused this though, there might be an issue in the packages' build process somewhere.
See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-binary for more info on the missing field.

Attempting a sync, seeing it fail and then needing to do a manual rebuild is not efficient and can not be reliably automated. Attempting a sync which works but has a decent chance of introducing breakage which can be avoided by a rebuild is not wise.
By always rebuilding packages synced from foreign suites we get a 100% automatable process that saves human work and avoids the introduction of errors due to binaries being built in the wrong environment, even if they are rare.

@guido The package doesn't exist in our repositories anywhere, and I could fine no trace of it ever being uploaded. What's its source package name? Can you maybe just upload the package again?

Can you elaborate on what kind of "subtle incompatibilities" you consider rendering it "definitively not a smart idea" to let Debian unstable packages into PureOS?

Looks like I somehow always ignored those issues when processing bugs, sorry for that!

I can do it, unless you are faster with it - it's a really trivial upload anyway :-)

Can you check if this is still an issue? There have been lots of changes on the locale handling in the PureOS initial setup and installer.

FTR, this goes together with https://github.com/systemd/systemd/pull/9864 where I am still waiting on feedback.
The current situation with localed on Debian is really suboptimal.

FTR, the reason for blocking nvidia-settings was "References non-free NVIDIA driver".
Package is removed from blacklist now.

Yikes, looks like this issue fell through the cracks completely, sorry for that.

2019-03-24 07:27:13 - INFO: Imported 'mate-sensors-applet_1.20.3-1.dsc' to 'landing/main'.
2019-03-24 07:28:21 - INFO: Imported 'mate-sensors-applet-common_1.20.3-1_all.deb' to 'landing/main'.
2019-03-24 07:28:22 - INFO: Imported 'mate-sensors-applet_1.20.3-1_amd64.deb libmate-sensors-applet-plugin-dev_1.20.3-1_amd64.deb mate-sensors-applet-common_1.20.3-1_all.deb mate-sensors-applet-nvidia_1.20.3-1_amd64.deb libmate-sensors-applet-plugin0_1.20.3-1_amd64.deb' to 'landing/main'.
2019-03-24 07:28:24 - INFO: Imported 'libmate-sensors-applet-plugin-dev_1.20.3-1_arm64.deb mate-sensors-applet-common_1.20.3-1_all.deb libmate-sensors-applet-plugin0_1.20.3-1_arm64.deb mate-sensors-applet_1.20.3-1_arm64.deb' to 'landing/main'.

@jeremiah.foster The data on this URL lists which packages are in certain seeds and why. Some might be explicitly requested, while others are implicitly added via dependencies of packages that were not explicitly requested to be in the default set.
A "standard" PureOS installation consists of the "minimal", "standard" and a desktop seed (e.g. "gnome"), while the desktop seed is itself comprised of a common platform seed ("desktop-common") combined with a desktop specific one ("gnome" or "plasma").
So, if you want to know what is explicitly added to the GNOME flavor of PureOS, https://master.pureos.net/raw/germinate/pureos.green/gnome.seedtext could be interesting, while tables like https://master.pureos.net/raw/germinate/pureos.green/gnome also contain implicitly added stuff and sizes.

Needs a fake upload as the PureOS version is higher than the one in Debian.

Btw, gksu will not work at all on Wayland as wayland does not allow GUI apps to be run as root without some reconfiguration (which intentionally isn't done), and on Xorg I guess it's just broken because nobody looks at its code anymore.
So, I think we should just close this bug.

@jonas.smedegaard Apparently gksu wasn't auto-removed from PureOS because sbackup had a dependency on it. That package itself is cruft though, so I just dropped both from the archive.
Interestingly, sbackup was not considered for autoremoval in PureOS, I will have to take a closer look at why that happened later (my guess is that it has something to do with the package being NMU'ed and building only arch:all binary packages).

Syncing from unstable is just flipping a switch. But we need to know if we *want* to do that. Unstable won't get many package changes during the freeze period either.
Autosyncing with experimental is a terrible idea, because experimental packages may just get deleted without ever reaching unstable. There is also a lot of broken stuff in there which we really don't want in PureOS (experimental is really just a playground with zero QA happening).
So, stuff from experimental should only ever be synced manually and if there is a good reason for doing so.

Grrr, this means a distro patch to python-qpt got reverted in PureOS somehow.
I will have a look, thanks for the direct bug assignment!

@jeremiah.foster Kodi was added on request of your predecessor because the initial PureOS had it and PureOS was supposed to be "complete" (including a mediacenter).
IMHO we don't actually need it since people can easily install missing pieces via GNOME Software.

Just to elaborate on that: The pureos-*installer executables are either compatibility scripts or helper scripts that change installer configuration to the OEM settings. All of them eventually will launch 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

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

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

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

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

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

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.

Did you reboot after you upraded the system?

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

The package has migrated now.

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 [..]

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

See https://lists.puri.sm/pipermail/pureos-project/2019-January/000015.html for an explanation. The new image just needs to be tested and the download webpage updated in that case.

It's still on my todo list, but with a low priority, so it pretty much is at the bottom of the queue every time something else of higher importance is added.
Since we have AppStream and this feature isn't one of the most popular ones, its priority is low.
However, it is fixable and I intend to do so when the infrastructure redesign is applied.

Done. This was satisfying, not having to deal with the build of this beast it great!

Yeah, unfortunately the Librems are very often shipped with old software, Polywell didn't stay up-to-date with new releases. But issues like we had recently with the OEM setup of course also don't help with these issues.

Hmm yeah, then the PureOS version installed on that machine is likely very old.
In any case, after you update your system the issue will go away completely.

This is a task on my list, but it will take a lot of work and time to resolve properly. Dak isn't really designed for this, so some changes will be needed (just a normal dinstall run currently takes more than an hour alone).

I think this is an ancient bug - did you try a very old installation image of PureOS?

It's more tied to the fact that PureOS does not support UEFI in any way.
We should add support for it, but as of now this task is kind of low priority.

The helper script has now been split out into a new dbus-activated daemon. It's not the quality thing that I want yet, as the code needs some refactoring to work properly in an async way and the interface is quite crude, but it's good enough for a start.
See https://source.puri.sm/pureos/core/pureos-init-disk-crypto

This was actually pushed back too many times, and I should address this sooner - especially since there is other pending work on this module.

That doesn't help, the journal also contains the changes.
The good thing is that you'll only ever be able to read the password if you have root access on a drive that has already been unlocked using that password.

I am aware of this for a long time, it can only properly be fixed by making a proper service out of this tool, which I have not had the time to do yet due to piles upon piles of other critical tasks.
I might actually implement the service soon though, in the process of fixing swap-related boot issues.

Originally these choices were made because we were asked to remove the references on the FSF mailinglist to get PureOS endorsed. They also asked us to remove the "non-free" component reference from the APT manual pages.
However, nobody seems to insist on that anymore, and your reasoning makes sense to me, so I will gladly resynchronize this package with Debian.

It's on my todo list and will likely be added after the current refactoring is over. The tricky thing here is that Laniakea delegates most archive actions to dak, and I would need to hook into dak to make this feature work properly (which means without email parsing) and integrate it with the generic Laniakea messaging.
This feature will also require our sysadmins to allow bots in some way on our Matrix instance (at the moment, I have no way to actually register a Matrix bot).

Oh, neat!
Package synced with unstable.
2018-10-25 14:36:49 - INFO: Imported 'xscreensaver_5.40-1.dsc' to 'landing/main'.

@sean.obrien While that "Flatkill" (what a dumb name...) makes excellently valid points, there's nothing that is a fundamental flaw in Flatpak's design that won't be resolved with better maintenance and more development time. However, that's something that still needs to happen, and when creating something new, you need to start somewhere ;-)
But anyway, it's better to have this discussion at a different place, to not make the discussion on this (syncing) issue overly hard to follow.

@guido

For our CI we can (and will auto upload to purple/laboratory for some stuff but I'm really talking about things we want from other Debian suites not necessarily maintained by us.

You have me confused now. I thought the whole transitioning between landing -> and green is there to detect these inconsistencies?

The problem here is that we sync binaries and are based on Debian testing. We can't just selectively sync some stuff from unstable, because unstable packages might be built against other things that are only available in unstable (e.g. newer versions of libraries with soname bump). So doing that properly would always be a manual action.
I could change the code and implement something that allows syncing some packages only by source, but that will take a bit of time and might likewise cause trouble with packages synced from testing that would have to be rebuilt against the source-sync from unstable. That's why I did not implement this feature initially, in principle, to avoid having scenarios where the automation breaks things or causes unexpected sideeffects.

We don't automatically sync stuff with Debian unstable, and if I do a one-time sync the package will be out of date again rather soon.
So, maybe just uploading the latest version of libhandy to PureOS directly is a better option for you? It already is in the laboratory/purple suites afterall.

This was fixed a long time ago.
See https://tracker.pureos.net/T559#10667 for some instructions on how to resolve the configuration issue.

This looks like expected behavior to me: The first prompt is for the disk password, while the second one is for root permission to be actually able to mount the device.
However, there might still be an issue here, because apparently the disk is mounted twice, and also a local user should be able to mount disks directly without root permission, so the second authentication request might not be needed (it could be though that the system policy on what the user can do is different for encrypted disks compared to regular volumes).

@james.rufer GNOME Software will fetch an extension list when run under GNOME Shell. So, you'll need to run it in a GNOME Shell session and the GNOME site has to be reachable. Try refreshing the software index (refresh button in GNOME Software) in case information is missing.

I am not sure I understand the problem - what is the issue here? That extensions can be downloaded from GNOME?
Since we trust GNOME already, I don't think it makes sense to disallow that in GNOME software, especially because doing so means people will have trouble installing GNOME extensions.

Urgency bumped manually.

@jsbret Replace the
GRUB_CMDLINE_LINUX_DEFAULT=“quiet cryptdevice=UUID=708e0d88-4db9-4713-a5ac-aea1abe6e832:luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 root=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 resume=/dev/mapper/luks-708e0d88-4db9-4713-a5ac-aea1abe6e832 splash”
line with
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash”
ensure GRUB_ENABLE_CRYPTODISK is commented out and then run sudo update-grub and you should be fine.

@jsbret This very much sounds like a different issue that was solved a while ago. Check your /etc/default/grub for GRUB_ENABLE_CRYPTODISK, that option and associated settings should not be enabled (otherwise GRUB tries to decrypt /, which it shouldn't attempt to).

Hey Theo, can you maybe add a storage engine to our Phab instance?
Just having flatfile storage should actually be sufficient. I can not add this myself because I think I lack permission on the server itself (and that is needed to change this setting).

The issue here is that the tools (Calamares and gnome-initial-setup) use completely different technology.
One would have to implement a password quality checker for Calamares upstream as well.