@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.

Texmaker is updated in PureOS now :-)

This was taking far too long on the Debian side for a new package to be uploaded, therefore I just did a dummy upload to reset the changes.
As soon as a newer package is published in Debian, it will automatically by synced to PureOS, removing the delta entirely.

@heather.ellsworth Jup, this feature would be rather straightforward to implement.
The tough bit implementation-wise would be to make Synchrotron selectively only sync source packages. At the moment, there is only a global switch for whether binary packages should be synced or not.

FWFIW In the current iteration the screens shield will still show up after a while, but the screen will not be locked anymore. So there should be no instances where someone would need to enter a password.

No, it is not always needed to recompile - Debian packages are *never* recompiled when moving from unstable to testing.

This is fixed as part of my live session and live-build rework.
I will publish some initial images for testing soonish.

This is fixed as part of my live session rework.
I will publish some initial images for testing soonish.

Deviations from Debian are - in a way - tracked at a global level at http://master.pureos.net/synchrotron/ - going to a per-patch level would be nicer, but this page already gives an overview of packages that have been modified in PureOS and where a newer version of them is available in Debian.
That way currently, changes in PureOS are reviewed regularly, any time we merge in a newer package from Debian.

Well, we can already sync packages with Debian unstable or experimental, but those have to be recompiled in PureOS - otherwise we can not ensure they actually work with the software that is in PureOS (that's based on testing).
Also, pulling packages from non-testing suites is an explicit task that is currently done manually.