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.

No, with the new installation there can't be a kernel mismatch anymore. The problem here is that Libreboot is run with an UEFI payload which boots into an (unsupported) EFI mode of the live-cd, which still offers a debian-installer install option.
See https://tracker.pureos.net/T460 for reference.

@chris.lamb No, if network-manager-openvpn-gnome is in the list it *will* be installed, unless there is something else pulled in that is mandatory and conflicts with the package.
It will not be explicitly seeded if it is pulled in by another package that is also seeded.

This was much trickier than usual to resolve, especially with the Britney dupe-pkg-on-arch:all bug being present as well, but it worked out in the end. lintian is updated in green now.

Right, because I uploaded a newer version to sid since I created this issue 4 or 5 days ago.

Heh, the reason for the arm64 issues is that our arm64 builder died, so nothing got built for that architecture for more than a week, No wonder issues exist with package migration.

@chris.lamb At the moment, lintian is simply too young, like the report says:

Package is 1 days old (needed 4)

@chris.lamb Gives me an error 404...

Done. Sorry for taking a bit longer with this, I was traveling yesterday.

I removed the repo, but you do have "Master" permission on the whole PureOS project - not sure why you couldn't remove the repo...

@chris.lamb The os-release thing already results in a neat "PureOS" string, and the logo is being worked on: https://salsa.debian.org/gnome-team/gnome-control-center/merge_requests/1/diffs

@chris.lamb Scroll to the very bottom in g-c-c, click "Details" -> "About"

@wellton To me it looks like you are installing PureOS on an UEFI payload. This has not been tested at all and is not really supported. Are you using an EFI Payload for Libreboot?
What you can try is to run the Live session, and install the system from there with the Live installer - that might work (but has not been tested by anybody yet).

@chris.lamb

Your remarks around upstream tarballs being ipso facto pristine is

also a little misleading in the general case, due to (at least)
Github's non- deterministic generatation of tarballs...

@chris.lamb I don't really recall why I did that back then, but this is debian/ directory only style packaging with Git. This is completely valid packaging, and gbp will happily use it. It's used inside Debian by a bunch of projects, most notably the KDE/Qt packaging team.

Does the *current* coreboot source package build a coreboot image?

The Tilix Git history, of course, But also the Debian package has no explicit patch (if it had, I should have noticed that as co-maintainer of the package ^^)
When I thought about this at first my intent was to only show the message if a feature requiring the VTE change was activated, but not immediately on startup.
As initial workaround, I added a gsettings change to PureOS default settings, but that only works if Tilix was installed first, which it isn't (so the gsettings override didn't really work, and I did not want to introduce a divergence of Tilix for PureOS).

Can you please point to the commit that fixed this? I fail to find it in the Git history. Thanks!

That was fixed three days ago already.
Thanks for reporting the issue.

Resolved in the 2018-05-30 image, currently building: http://master.pureos.net/jobs/c1202f83-6ecc-47d7-831a-77f72baa8d0b

At the moment, apt-file is pretty useless on PureOS, due to the archive not generating a Contents file (or rather, an empty one).
I am not sure though whether it's worth fixing at the current point in time, because the dinstall runs are already really slow, extracting file contents will slow the process down even further.
So this will likely only get fixed when my patches to speed up the process and break it into smaller bits have landed.
Generating Contents is easily one of the most expensive tasks to do (I was under the impression that we were building valid Contents files though and even thought about disabling it - but apparently, it's slow already, even without building them (the archive never created Contents files))

Simple reason for that being that the utils are part of the main coreboot sources, and we only really want the utilities right now (packaging the rest didn't make sense to me, but it might at some point, at which we can easily add the other pieces to the existing packaging)

I wouldn't mind if someone else updated the package, but I also could take the task of course.

Should we add any new users created on the system to the kvm group, or just the ones that were created by the installers?

@jonas.smedegaard That is because the package has binNMUs, and there is nothing we can do about this issue unless we rebuild all the packages for PureOS again and stop binary-syncing.
You can work around this by making a 1:2.12+dfsg-1+pureos1 upload.

Can be found at https://source.puri.sm/pureos/packages/pureos-gnome-settings now

Thank you for looking into that so quickly!
I had some mild panic that something seriously broke and the automatic migration let broken packages into green.

I can't reproduce this here... The pureos-desktop package is a transitional package to pureos-gnome, is the latter installable? Can you get a better error message from APT? Are there packages from 3rd-party repositories installed?

Fixed for a while already, I forgot to close the bug report.
Thank you for reporting the issue!

This should be fixed now (and ideally won't ever break again).

This has been resolved for ages now, thank you for reporting the issue!

Jup, we are in agreement - and you did say "academically", so I never though you actually wanted to make that change. But I wanted to make absolutely sure that I was just brainstorming here and had no actual intention of modifying user's group settings in a package - sorry for the confusion :-)

@chris.lamb Obviously IMO no package should do this, but purely academically: The seed packages are inadequate, because they are purely metapackages - their purpose is to pull in other packages that make the actual changes and can be removed individually. We would need a package that is on every system though, and one that actually already influences the behavior of users and groups.
The only package that fits this would be the base-files package, because that one already sets group and path defaults and also is on every system.
Alternatively, the gnome-boxes package could do this, but it would be very unexpected for users to see that the group configuration they have set changes for all users due to installing a package.

@chris.lamb Modifying the groups of existing users is evil(tm), and just like writing into $HOME, I don't think we should do that.
Instead, GNOME Boxes could maybe show a nicer error message, so users can add themselves to the group explicitly if they want to.
The groups in which users are is a choice of the administrator who might have intentionally left them out of the kvm group, and we shouldn't change that automatically for every user via a package.

@chris.lamb Ah, I missed the first highlight.
Does adding a user to the kvm group imply any "weaker" security? If not, we can add new users created in the installer to the kvm group, but we likely will have to do that globally, so not only users created by Calamares are in the kvm group by default, but also new user created by our OEM setup wizard.

Fixed in https://github.com/lkorigin/laniakea/commit/a1fd518405a05ad908a5cf4f5cbe5df688b66d6d

Done, the suites are now always ordered alphabetically.

I could have sworn I fixed that already...
Should be rather trivial to address, in any case :-)

@chris.lamb Jup, in fact, the arm64 package was already there when I looked at it. See http://software.pureos.net/builds/package/eb2f2109-0755-5fc0-b32f-ad5c5274a56c/1/ for its build logs.

@chris.lamb Be patient ;-) Migrating a completely new package taes at least two dinstall runs, so a few hours was just not enough time ^^
@d3vid The website takes a few minutes to update after a new package has been published, so you might have caight the new package immediately after it was migrated, but before it was actually registered in the database as being in green as well.