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.

@chris.lamb The proper fix would be to establish a new location for scripts to be sourced by shells even for non-login shells. At the moment, everything using VTE in Debian actually has to implement a workaround for this to work, gnome-terminal is carrying a patch for this for ages.

The past sync run was interrupted, apparently because of connectivity issues (hashsum mismatch). This issue should resolve itself within the next few hours automatically - I'll keep this issue open until it does though.

Since upstream doesn't want this patch, we have no good way to resolve this.
I will discuss whether and how to change the Debian policy for sourcing files on first load of shells at Debconf, and if everything failes apply this patch downstream at Debian.

This should be fixed - can you please verify that the issue is indeed resolved for you?

The issue is known to the system: https://master.pureos.net/depcheck/green/binary/amd64/details/libkf5filemetadata-bin/5.45.0-1

Patch created: https://github.com/gnunn1/tilix/pull/1456

This is definitely not fixed yet, I'll look into this again.

Done, I moved everything away from Github a while ago.

@d3vid Yes - although technically, you would also need to check the recommends of the whole dependency tree that pureos-gnome (or any other package) depends on.
If the package is in the Depends line, you will have it regardless of whether the installation is new, if it is just recommended it might only be present on new installations.

I just generated new images, network-manager-openvpn-gnome is preinstalled on all of them ([installed,automatic]).
I therefore think it's safe to close this issue.

@chris.lamb That it's in recommends just means that a user can remove the package.

This is resolved in debootstrap >= 1.0.104pureos1 now.
You are now able to bootstrap purple and landing based on a revised green script.

@guido Ubuntu's scripts have a less-generic name though - that's why debootstrap in Debian has "green" and the Tanglu distribution names ("chromodoris", etc.) but not "staging" (Tanglu's equivalent to "landing") - I assume the same will be true for the generic landing name.

Hmm, this is a tough problem to solve. We can not really make a purism-specific seed for default packages. We could enable Purism branding on specific installs though, in which case the existing seed would always need to install Purism branding though (even if it is not shown).

@chris.lamb I didn't misread the report, I just mistyped the package name (fixed). The statement in itself is still true.