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.

@d3vid That is a blocker, but I adjusted the code again to ignore the arm64 architecture - we don't have enough build power at time to ensure that we can build every single package on arm64 (although in this case, plymouth built without problems).

Done, if the package can migrate, it should migrate instantly.
Its status can be monitored at http://software.pureos.net/package/source/landing/fontconfig

Would that be because it is not yet in buster?

The system doesn't seem to know that revision yet, I'll bump the packages urgency in advance.

How did you get to the Debian installer in that version? Because that is no longer a supported option to installing PureOS.

You are using an old installer image, please use an up-to-date one like https://downloads.pureos.net/live/gnome/2018-04-26/ for installing PureOS.

This should be addressed in the latest images, I am not sure though if the solution covers all cases (I could only do limited testing).
So, please reopen the issue in case this happens again!

That's a weird one... Can you still reproduce the issue? Can you verify that the "packagekit" package is installed?

What exactly does "issues" mean? What did you try, what did you expect and what was the actual result and error message?

Likely some GNOME weirdness. Needs to be investigated, the image sets should be identical.

Calamares should never even show up in the software center. I marked it's .desktop files to be ignored from inclusion in the software catalog now (effective as of calamares >= 3.2~rc4-0pureos5)
Thanks for noticing!

Yeah, for us it is a change needed for consistency and ease of development, but for our users it doesn't matter at all and thereby is more of a cosmetic change (I should have been clearer on what I meant ^^).

Ok, in that case I claim this task again - this is really not blocking anything at all, in a way it's more a cosmetic/consistency change. I had it on my todo list anyway, so having this bug makes sense.

@todd Why did you reassign the task?
It is still valid, even if Chris can now commit to the repo (which I though he could...), but moving it will need quite a lot more changes to not break things - that's the reason why all infrastructure components are still on Github, especially since Gogs was very unreliable initially and we couldn't risk these repositories to go down.

At the moment, this is not easily possible without setting up some kind of merge with Github or redirection, as a couple of tools pull data from the repository and have it hardcoded.
I want to have the repository and everything else moved rather soon though, and at the same time split the "PureOS" group at Gogs into pureos-packages and pureos proper, so all the infrastructure pieces can live there as well and we have a separate place for packages (for easier permission control, clear scope and less potential for name conflicts).

You got the image from https://downloads.puri.sm/oem/gnome/2018-04-08/ ?

The priority on this is fine, this is a high-priority bug. After getting the debconf prompt once though, you will never see it again.
As for the config file prompt, that is a thing we can ignore for now (it's a minor annoyance regular users won't even see because PackageKit will do the right thing. It's also very tricky to resolve, we likely need to incorporate some changes in the Grub package itself).

The config file change is harmless (I wonder why it's even shown), but the Debconf prompt should never have happened - this means the installer hasn't configured debconf for the GRUB package for some reason.

Can you please try this again with the new OEM installer ISOs and report if that works successfully?

Hmm, popularity contest is not installed by default... Do you still see this issue?

Is this still an issue? I have never experienced this behavior on current PureOS.

At least in the past, we tracked all infrastructure stuff in public here as well (except for concrete machine requests), so I think having this issue here makes sense.

This should be resolved via T365 (doesn't fix the d-i problem, but still resolves the issue in PureOS since the install environment and regular PureOS environment are (almost) identical now, so touchpads work well).

Also, every one of these package managers will not download non-free stuff behind the user's back. Like APT itself or a webbrowser, it will download things only if the users has directly requested that.

This is impossible, as pretty much all of GNOME, systemd, Xorg depends on Meson, and no Rust code can be built without cargo properly at the moment.

@jonas.smedegaard We deliberately added TorBrowser this way when creating PureOS back in the day. I never liked this at all, so personally I would like to remove the package, but I am not sure if we should do that, because the decision to have it that way was done on purpose.
@zlatan.todoric should the Tor Browser package be dropped from PureOS?

I tested this on the devices I have, with no major issue, Everything is working quite well, and the remaining issues are UI things or relatively minor.
So, this task is complete now, and for all further issues with the live boot it makes sense to just have regular bugs (some already exist).
The new and final-ish image can be found at https://downloads.puri.sm/oem/gnome/2018-04-08/, the regular live images have also been rebuilt.

Hmm, Calamares doesn't set any DNS resolver, and resolv.conf is fully autogenerated on all PureOS systems. On my system, NetworkManager automatically configures a DNS server when I connect to a network.

The swap partition not-mounting issue is fixed now as well, but will a new image build (obviously) to take effect.
I will build a new image for testing next Sunday.

So, Calamares crashed? Please open a terminal, type pureos-installer-oem --debug and get it to the point where it crashes, then send me the terminal output.

What is "this application"? GNOME Initial Setup? What does crash mean, did it disappear? Can you send me your journal log (all of sudo journalctl > log.txt) in a private message?

FTR, the new OEM image for testing can be found here: https://downloads.puri.sm/playground/oem/2018-04-06/
New known issue:

• swap partition is not mounted correctly with the new boot-reencryption mechanism, will be fixed in a future build

There is no officially supported net installer, and this is actually not supposed to work (or even tested).
Please install PureOS via one of the ISO images we offer on pureos.net
(there are also no plans at the moment to make a net install image work)

Hmm, which version of initramfs-tools-core do you have? That one should have pulled in busybox-initramfs and is default-installed on every PureOS installation (should be >= 0.130pureos2).
Please reopen this issue if you encounter the problem again, or are still having it. Also ensure that you are not accidentally on the landing suite of PureOS, because that's where there was a short time where the necessary dependency on busybox-initramfs didn't exist.

@zlatan.todoric LibreOffice build-depends on chromium, so this will be quite annoying.
Package is removed from PureOS now, but we will need to find a solution for LO...

This is resolved in gnome-initial-setup >= 3.28.0-2pureos3

So, if there are no objections, I would make a change to always reencrypt swap on boot by default on OEM installations, mainly because that is what we have done in OEM setups so far, with the option to change that back in future.

This should be fixed now.

I temporarily allowed QA to break arm64 packages if it helps resolving issues on amd64.
That will make the arm64 PureOS flavor less stable, but amd64 bugs get fixed faster and packages should get installable there again.
This should fix this issue, please feel free to reopen it if you still can't install the respective package (but please include a new APT log in that case).

@chris.lamb You wouldn't switch to unencrypted but keyfile-encrypted, but yes, something like that would work. You'd need to swapoff, then reformat swap and encrypt it with the keyfile, and then rewrite crypttab and update the initramfs.

That does make sense... You could also argue though that as soon as the attacker has the opportunity to read the swap partition or other parts of the RAM, you've already lost.

@kyle.rankin That could only happen if the encryption of the first disk (which holds they keyfile to decrypt the swap partition) is broken. If that happens, the impact would of course be more severe, as there are potentially a lot more passwords stored in RAM.

@kyle.rankin In that case we will loose suspend-to-disk support entirely. I could make this happen, if we decide that our users should not be able to use suspend-to-disk on their systems.

While according to Mozilla the source code will be published, and according to news websites the code was in fact published on https://github.com/Pocket, I can't find the backend code anywhere at all.
So the service indeed is non-free at the moment.

There's a new experimental live image available now for testing.
This build is feature-complete now, which means that - at the current point in time - I don't plan to add more features and the only remaining things to work on are bugs.

We better solver this independently from PureBrowser, to provide the freedom of opt-out to _not_ installing the plugin.

What usually happens is that you debootstrap green and then just add the landing repository (either replacing green, or on top).
Oddly though, that's not mentioned in https://tracker.pureos.net/w/development/pbuilder_environment_quick_setup/ even, so I think the docs need some update to reflect the current state of things (even if we add a landing suite to debootstrap later).

Yeah, this looks like a sideeffect of the arm64 architecture addition (which shouldn't have happened).
This should fix itself soonish, I will monitor the issue though in case it doesn't.

That's intentional, because landing is/was not supposed to be bootstrapped. It's original intent was just a playground like experimental, while the real deal is green.

@ah_purism Have you selected a German keyboard layout in System Settings --> Region and Language --> Input Sources? (click the plus symbol, then the dots and search for the German keyboard layout you want)

This is a very weird glitch, as it seems like the package is present, but its override was not added as well (and therefore it doesn't show up in the output files).
I will take a look at this, hopefully this does not affect other packages as well.

For the impatient, there is now an initial experimental image to test, demoing the new changes.
I don't want to receive bug reports for that just yet, because I haven't tested it a lot myself yet and there are quite a bunch of issues that I am already aware of.

@guido Packages recompiled in different environments do produce different behavior though. A lot of packages have Ubuntu/Tanglu/PureOS specific configurations that get enabled when (re)built on a particular system.
Also, lots of software enables different codepaths depending on which version of a particular shared library it was compiled against. Additionally, unless there is a symbols file in a Debian package, the Debian package will always depend on at least the shared library version it was compiled against, meaning that you can not selectively pull a few package from a particular suite and expect the result to work.