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.

@Chris, can you look into this and see if it indeed has anything to do with purism-power-optimisations? (that's the only thing that would make sense to me, but it could also be a kernel issue in general. Encryption being the culprit seems highly unlikely to me though).

Your PureOS is tainted. The only versions of gnome-software that we include in PureOS are:

gnome-software | 3.28.0-1pureos1 | green      | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | landing    | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | purple     | source, amd64, arm64

The PureOS specific change includes exactly a difference to recognized things from the pureos-main archive as free.
Please reinstall your system to ensure that you actually only have stuff we ship in PureOS, and make sure that no non-PureOS sources exist in your sources.list.
The output of apt list suggests a manual installation of a foreign gnome-software package (highly likely from Debian), but it could also be that it was updated once and the source it came from has been removed meanwhile (if you know that you manually updated gnome-software that is fine, in this case you would need to reset the package and can maybe avoid a reinstallation).

I can't reproduce this issue - the software is shown as "Free" for me.
Which version of gnome-software do you have installed? (apt list gnome-software)

What is displayed if you click on the red "Proprietary" field?

Done, GIMP is at 2.10.6-3 in landing now.

This issue, as well as all reboot failures related to missing swap partitions are now addressed in the latest PureOS images.
In total, this issue and issues related to it consisted of 5 completely separate issues affecting various aspects:

I fixed this bug, which unfortunately brought us another (already known) bug of the swap partition not unlocking properly.

@mladen.pejakovic That's a different issue that was already fixed a while ago.
The one in this bug is actually even older and has been in PureOS forever (we just didn't see it because initramfs updates aren't triggered that often, and it is not that severe in its impact).

What should actually happen here is / being decrypted with a password, and swapfs being decrypted with a keyfile on /.
Or, as a second option, swapfs being reformatted at boot time.

You can fix this by changing the parameters of whetever is your swap partition to /dev/urandom swap,cipher=aes-xts-plain64,size=256,
e.g.:
luks-aaaaaaaa-a86a-469c-812f-92b36f70113e UUID=aaaaaaaa-a86a-469c-812f-92b36f70113e /dev/urandom swap,cipher=aes-xts-plain64,size=256

This /etc/crypttab is wrong, one line should have been set to auto-format swap.
Did you do manual partitioning, or did you select the default option?

Hmm, swap should not even be password-encrypted...
What's the content of your /etc/crypttab?

I was so sure that there already was a ticket, and I even wrote instructions there... But that either happened way back with our makeshift bugtracker, or I must have dreamed it.

Neat :-)
Since the error is triggered by archive metadata, there is no way to ensure people have upgraded their system prior to fetching new metadata. We just have to rely on people upgrading their system regularly.

@todd Just run the command I've shown above. Or update with GNOME Software, that should also do the trick.
apt update was actually successful (despite the appearance and exit code), you only need to update your packages with full-upgrade afterwards.

I've already fixed this in Debian days ago and ensured that the issue is resolved in PureOS yesterday.
If you upgrade PureOS fully (apt update ; apt full-upgrade) the issue should be gone.

Done, hashcat 4.2.1-1 is in PureOS now.

2018-08-26 10:28:51 - WARNING: clamav: Target version '0.100.1+dfsg-1pureos1' is newer/equal than source version '0.100.1+dfsg-1'.
This needs a manual dummy upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

Done.

Done.

I don't think re-purposing this old bug for a blacklist removal request is a good idea - I was actually a bit confused to me to see seeing the bug appear again with this title...

Done. It's nice that we apparently can get rid of these diversions now :-)

Is this still an issue? Cryptsetup has been upgraded multiple times since this issue was reported...

2018-08-25 19:33:54 - WARNING: xarchiver: Target version '1:0.5.4.13-1pureos1' is newer/equal than source version '1:0.5.4.13-1'.
This needs a manual dummy upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

WARNING: p7zip: Target version '16.02+dfsg-6pureos1' is newer/equal than source version '16.02+dfsg-6'
This needs a manual upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

Done.

This is resolved in the latest OEM and Live images, please test them! (for the oem image: https://downloads.puri.sm/oem/gnome/2018-08-25/, the live image is currently building)

Since I am quite out of ideas on this one now, I reported the issue with all information that I figured out so far against cryptsetup at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907201

As weird as it looks, this issue is the same bug as the OEM encryption issue.

This is supposed to be fixed in libvirt >= 4.6.0-2, which PureOS already has.
Can you please ensure the package is up to date and has at least that version, and then try again?
Feel free to reopen the bug in case the issue persists (it should really be gone though).

The archive generally doesn't support downgrades - versions can only ever go up, otherwise our users will not actually get the changes.
So, if we have a version 0.9.3.2-1+pureos1 in PureOS, I can not sync 0.9.3.2-1 from debian, because 0.9.3.2-1 << 0.9.3.2-1+pureos1.
The archive will also *never* override PureOS-specific changes.
So what I did just now make an 0.9.3.2-1+x1 upload[1], because 0.9.3.2-1+x1 >> 0.9.3.2-1+pureos1. Since there is no "pureos" in the version string anymore now, the next time Debian gets a higher version of this package, the archive will just override the package I uploaded and we will be fully in sync again.

Done, but @jonas.smedegaard if the version number in PureOS is *higher* than the one in Debian, I can't sync stuff. In that case, an upload without the "pureos" version suffix has to be made to PureOS, which is a thing you can easily do as well and which doesn't need me.

Redshift was never installed by default, so there is nothing to be done here.

Tracked the issue down to a ton of regressions in cryptsetup starting with 2:2.0.3-2 - so maybe a fix for this will just be rebuilding the image :-)