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.

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

You make a good point. In this case it's a security tradeoff because suspend-to-disk creates a security vulnerability since secrets that were in RAM only (disk decryption keys, passwords) could be written to disk and potentially be recoverable.

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

The swap partition should be encrypted with a random LUKS key like in a standard Debian install instead of via a key file. It's a feature that encrypted swap is blown away each reboot.

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.

3 users reported another breakage today, this time GNOME session was broken after failed/incomplete upgrade process. Waiting for additional info.

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.

@I_have_issues wrote:

I have never got multitouch, or two finger click to work. I run Ubuntu 17.10.

can we get rid of this hack? There will be more people contributing to pureos in the future (phone team).