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

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

@mak then what about

Well, 2 months later Thunderbird is still 1:52.4.0 in PureOS :/

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.

@mak remove and block from re-entering the chromium package from archive as GNU-libre ML is pointing this out.

PureOS does not intend to add i386 at this point nor in future unless compelling reason is there as it takes engineering time to add an arch and maintain it. Someone could probably compile wine to use 64bit libs only (though I didn't test it and how limited usage would be).

:p

An extra thing that we can do is to make sure that new PureOS users are part of the kvm group?

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.

@mak should I create a separate task for the pipe issue?
The situation is very confusing to me. Pipe worked when I received my German Librem13V2 a few days ago, now it no longer works.
I'm wondering if this is a result of T328 (fixing US, breaking DE?), but I can't tell.
However, two other users previously reported that it stopped working: https://forums.puri.sm/t/librem-13-backslash-key-generates-less-than-symbol/2133
This makes me wonder if it could be a weird sideeffect of ME-disablement / hardware initialization.

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

I think you're mixing up hardware layout (or labeling) and software layout. If you select a German layout, Z will yield z.

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

(this relates to the original topic of recompiling packages not about having to rebuild because we carry patches)

(seems I forgot to actually post this yesterday)

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.

That's a good behavior. Thanks again.

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

Since recompiling unstable packages in PureOS is recommended, is it just as easy as adding a source site to a list and then that site is polled for updates? I am assuming that these packages are auto compiled by the build system?

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 issue seems to have been resolved for me in the latest PureOS update, version 8.0
Thank you for your work!

I just tried vagrant (using libvirt) and it works, but gnome-boxes does not.

Perfect. Thank you @mak !

Thank you @mak !

To clarify - and address the comments from @heather.ellsworth above:

I am aware that we can recompile.

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.