Done.

This appears to work with the new kernel image and today's (8/26) update.

@vivia.nikolaidou Gentle ping :)

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.

Problem solved after upgrading to 4.6.0-2.
Many, many thanks!

A new image was built and I installed it (https://downloads.puri.sm/playground/2018-08-23/pureos-8.0-gnome-oem_20180823-amd64.hybrid.iso) in virt manager. After the install completed, I was prompted to reboot. Right after the reboot, I was prompted to enter the disk encryption password:

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.

Sorry, I don't follow.

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.

yagf does not fallback-depend on a non-free package, only a non-existent one.

hashcat does not fallback-depend on a non-free package, only a non-existent one.

Ah: Dropping the fork was done long ago in T330.

audex does not suggest a non-free package, only a non-existent one.

p7zip does not suggest a non-free package, only a non-existent one.

xarchiver does not suggest a non-free package, only a non-existent one.

foo2zjs does not suggest a non-free package, only a non-existent one.

engrampa does not suggest a non-free package, only a non-existent one.

doublecmd does not suggest a non-free package, only a non-existent one.

clamav does not suggest a non-free package, only a non-existent one.

When addressed, this issue should be flaged as "invalid" (not "resolved").

q4wine does not suggest a non-free package, only a non-existent one.

Also working on grpcio module packaging in the Python Modules team.

@vivia.nikolaidou What's the latest on this? Would love to get this settled up either way!

(Feel free to re-use this ticket if there is not already one.)

@mak sorry, you may have told me about making graphics for the installer but I lost track of that.

Chromium is blocked from entering PureOS.

This issue should be fixed by now (60.1.0esr-2pureos1 released to landing on August 17th).

This issue should be fixed by now (60.1.0esr-2pureos1 released to landing on August 17th).

This issue should (somewhat accidentally: See T550) be fixed by now (60.1.0esr-2pureos1 released to landing on August 17th).

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

This particular issue is resolved, I am currently working on getting the correct solution into upstream systemd as well.