This was fixed since firefox-esr 52.5.3esr-1pureos2, released to PureOS landing 2018-01-21.

should be fixed in landing by now. Will keep this issue open until either someone using landing confirms, or it trickles into green and noone screams.

This issue is about following requirements defined by the GNU DFSG. Bug description is now updated to include relevant quotes from GNU FSDG.

Thanks for the update; I'll get this done as soon as I can, and report on what I find.

Thanks for confirming, @francois.

I can confirm that it is not an issue anymore on my side.

I will fork apparmor with that change...

Ah, it seems AppAmor contains a hardcoded list of web browsers, and needs to be educated about the existence of PureBrowser in the file

/etc/apparmor.d/abstractions/ubuntu-browsers

That smells like a problem with AppArmor blocking too much for Document Viewer.

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?

Please drop our fork of torbrowser-launcher: It violates GNU FSDG in that we lack control over what code ends on our users' systems.

I believe this issue relates not to the OS we develop, but instead to the infrastructure we use for developing it - and therefore should instead be tracked at https://code.puri.sm/Purism/Systems-Tasks

This is somewhat a design choice of Wayland: One application should not be allowed to "spy" on the windows of other applications.

Calibre seems installable again now.

https://lists.puri.sm/pipermail/pureos-project/2018-April/000000.html

• Vcs-Git,
• Vcs-Browser
• Maintainer
• Uploaders
• +pureos\d in version string

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.

Hmmm it worked the second time around... on the VM. Going to test on bare metal now.

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.

By then I had initramfs-tools-core=0.130 0.130pureos1 installed. Then just after I've manually installed busybox-initramfs, initramfs-tools-core upgraded to 0.130pureos1 0.130pureos2.

Sorry, I mean the "Install PureOS" application that runs within the Gnome desktop crashed. By crash I mean the installer application disappeared. I will see how repeatable it all is.

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?

I've had this application crash for me both when testing in a VM (at that point at the disk encryption password section) and also when trying directly on bare metal Librem 13v2, when trying to connect to wifi.

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

You may want to subscribe to https://tracker.pureos.net/T373

Me and my big mouth :)

Is there tracking bug for gitlab migration? :)

An interesting problem! :) I have no idea how to do this but since there is a chance to migrate to gitlab, I think we should wait for things to clear out.

(Apologies. I misspoke when I said *un*-encrypted; what I meant was "whatever less-secure method which would re-enable S2D)

It would be possible after the fact to even go as far as to reformat the swap partition to be a non-LUKS volume and treat it as regular unencrypted swap, if you wanted, but as @mak mentioned, it would be better to keep it as encrypted, but as a different kind of persistent encryption.

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

Just out of curiousity, would it be possible to disable this feature post-installation? ie switch from encrypted to unencrypted?

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.

Or if the attacker happens to read the contents of swap while the system is running. Since it isn't overwritten at each boot, it's possible imaging swap while the system is running would reveal old secrets that weren't securely wiped.