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

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

Contacts is included in the latest revision of PureOS defaults.

Done, PureOS includes Noto Emoji by default now.

This is fixed with the latest pureos-meta changes.

We are waiting on some updated art and text from @francois , this text was just a placeholder and I would never have thought it would stay there for longer than a week...
(Now we have it for *years*, which is quite sad...)

This should be resolved in the upcoming images with a small change in casper.

This is indeed resolved now :-)

Very odd... Potentially, your system is set up correctly, but gnome-control-center doesn't display information correctly.
So, I am quite sure now that this issue is actually a duplicate of T549

@mladen.pejakovic I've split this issue and created T549 so we can track the GNOME bug individually.
Thanks for the feedback!

Please check whether the following packages are installer: pureos-minimal, pureos-standard, plymouth.
Without the pureos-* packages, the system isn't considered valid PureOS. They usually only get removed when someone adds 3rd-party unsupported repositories.

Hmm, I can't update this in Debian unless I am NMUing the package of another maintainer, which I really don't want to do.
I could update this in PureOS, which would introduce a delta between Debian and PureOS.
The ideal solution would have been if the Debian maintainer had just updated the package...

@mladen.pejakovic

The installer should pick this up automatically.

@chris.lamb Can you please test if this issue is fixed in my test image from http://downloads.puri.sm/playground/2018-08-10/ ?
Please be aware that the playground image suffers from unrelated issue T542

Not a high priority because this only affects a playground OEM image. Needs to be fixed though before we update the image (which should happen soonish).

@francois Solving this issues is a *tremendous* task. AppStream supports the notion of language packs, but in order for that to be useful, we need to add localization component metadata to a lot of packages and also make adjustments on other GNOME components, and likely GNOME Software as well.
I had a chat with some people from Canonical about this, and we might be looking into this again together. But this will take quite a while to get resolved in PureOS, unless we suddenly get a lot more engineering manpower.

@francois How did you try to install PureOS? Via the live installer, or via the OEM installer?

To clarify: Does this issue appear in the live installer, or in the OEM installer on first run? (I suspect it's the latter)

Did you consider reporting this issue to GNOME as well?

Since this was just mentioned again, I need feedback here... Go, or no go?
/me is for dropping it (at least temporarily).

Can you please run gnome-software in verbose mode (killall gnome-software ; gnome-software --verbose) and see what GS says when you load the Blender page?
(paste the log somewhere, ideally)

This bug is exclusive to VirtualBox, for some reason VBox doesn't play nice with Wayland which leads to GDM having trouble.
It's on my todo list to look into this already.

@chris.lamb @francois Actually, I already resynchronized systemd with Debian, so this issue should actually be gone now.
Can someone else maybe verify that it's gone as well (a quick test in my VM didn't result in that issue).

@zlatan.todoric Sorry for the late reply. As I am about to depart for Debconf, I can't really comment on the issue, but I can provide pictures of the chip I got from ThinkPenguin, which pretty much was exactly the same type that was already built into my Librem device:

Problem is we can't "just" add every new user created on the system to the kvm group.

Not sure what you mean with "filename information", but support for adding a GPG signature is on my todo list already.

With "Emoji font" you mean fonts-noto-color-emoji in particular, right?
Since we already ship a great deal of the Noto fonts for language/script compatibility, adding the Emoji font too would make some sense.

Done :-)

@chris.lamb Not sure if I get the question.. /etc/adduser.conf would need to be adjusted, as adduser is used by accountsservice in Debian.
New users created by Calamares are added to the kvm group, but not ones created by adduser/the OEM setup.

This is now "fixed" in PureOS, or worked-around rather.
I hope to maybe be able to address the actual issue at Debconf.

I've uploaded a new revision of Tilix with my patch to Debian: https://tracker.debian.org/news/973587/accepted-tilix-181-1-source-all-amd64-into-unstable/
Let's see if this sticks. Regardless of the workaround, we should still work towards fixing the actual issue, because that will not only benefit Tilix, but also GNOME Terminal and any other VTE-using app.

@chris.lamb The only thing we would need to do is get https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008 fixed in some capacity, no policy change is required - unless we do end up sourcing /etc/profile.d/* for non-login shells like Fedora, in that case we need to change policy I guess.
If we want to establish a new directory for that purpose, we can also do so and add it to policy later. It ultimately all depends on that bug report.

So, the official bug report to watch is now this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008

This issue affects everything using VTE, gnome-terminal is only exempt due to reverting an upstream change permanently via https://salsa.debian.org/gnome-team/gnome-terminal/blob/debian/master/debian/patches/Provide-fallback-for-reading-current-directory-if-OS.patch

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706065 for the Debian discussion about this on gnome-terminal and https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 for the upstream change that broke this in the first place, which VTE upstream won't change.
Also, the PR discussion has some more information: https://github.com/gnunn1/tilix/pull/1456#issuecomment-403175621

It's fixed now.

Checksum validation of 'main/source/Sources.xz' failed (5eb9cc2ccdf1bf16351400d06ae35d16089874d996c1afeab5b94179974051c2 != 56c51a31d6cc797891e0fa0b3112b7ffc7461819903664beddefcf565c742c0f). - the issue still persists.