Furthermore it evades Facebook link shims, removes the referer headers and performes link unwrapping for Twitter: https://www.eff.org/deeplinks/2018/05/privacy-badger-rolls-out-new-ways-fight-facebook-tracking

We should have Privacy Badger in PureBrowser.

Or the logo should be depicted in some nice ways, like painted on a wall, or an abstract arrangement of rectangles, dunno…

• Replace "9-dot" Gnome "show applications" with Purism rectangle
• Consider using background logo extension

@adrien.plazas , sorry for the late answer, we are finalizing the first version of the branding guidelines.

The "root account is locked" is due to a 2015 Debian change to harden security to prevent the single user mode passwordless shell. Link to the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 IIRC it was meant more for publicly exposed systems, as the security benefits for an already fully encrypted system are very small, but it causes a lot of pain when trying to recover your system. I disabled it on mine with a workaround patch that's in the bug report.

This seems to have begun to occur more frequently to me lately. It happens after almost every suspend after a longer on time, having to resuspend and resume each time to fix it. I updated the firmware around a week ago (this is a Librem 15 v3).
Also I wouldn't call the resuspend/resume a "fix", but rather a workaround.

I think this is relevant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930696
IMO a keyscript is unnecessary.
I ran into it when migrating my unencrypted PureOS to a new disk and adding LUKS to it at the same time (I first tried a fresh install but the installer failed for which I already opened a separate bug). I wrote up a quick guide on how to do that on Pureos/Debian, by the way: https://github.com/jjakob/wiki/wiki/Migrating-an-unencrypted-PureOS-Debian-install-to-fully-encrypted
Also getting rid of the unencrypted /boot partition would largely improve the security, I would highly recommend it as the default for the encrypted install. There's no need to enter the passphrase twice if a keyfile is used, and it works flawlessly.

@jeremiah.foster I have now pushed another commit to salsa, containing a man-page. I'll provide it to upstream in a pull request too.

@jeremiah.foster I'll take care of it.

@gusnan I ran lintian over the lollypop build because I know that our ftpmaster will do that too. It produced a warning and a bit of info. I think the warning might be worth addressing;

https://pureos.net/download/ is the link I'm referring to.

@elliebuz Did you create the desktop file for the Tor Browser?

Thank you @gusnan! Tack sä hemskt mycket! I'm just going to clone your package from git and build it for PureOS (I'm in the keyring so it's easier for me.) I'll point to it when it's uploaded to PureOS.

I've gotten the script to lock the screen when run. There are problems using 'remove' however in the udev rule, I don't think that our Vendor ID is showing up. At lease when I run

udevadm monitor

the Vendor ID is not picked up and consequently the script is not run. I'll test via other means and other parameters.

And there you have it:

I have made an upload - I will push the git repo to the Debian Python Applications Packaging team on salsa when I can see that it is in the NEW queue.

When I run the command on the command line

/usr/bin/dbus-send --print-reply --type=method_call --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock

I get;

I added the debugging info and the file was not created when I removed the key, so I don't think the script is being run. I tested the script as root without the key and the script outputs info to /tmp correctly.

No need for apology - your concern is appreciated even if it turns to be unfounded.

Upon rechecking, flathub is not offered as a default source.

This sounds similar to issue T585.

This is most likely not a coreboot issue. I tested on a machine that has proprietary firmware and memtest did not work.

Hmm, now I found https://puri.sm/posts/music-player-lollypop-added-to-pureos-store-for-librem-5-phone-and-laptops/ .
It isn't already packaged, right?

@mladen I'm able to reproduce in case you need me to provide more details

I have started looking at packaging this - I can provide a packaging repo containing my work soon. I guess packaging in Debian is the preferred way, and not in pureos. I'll take ownership of that RFP.

Oops!

In T801#14990, @jeremiah.foster wrote:

Why?

Why?

I'm not sure whether the 2 issues are related or not. I should have authored a new task and cross-referenced.

Noticed the same reproducible sequence of events in:

Interesting. Might be related to Calamares.

My feeling is that we ought not permit packages or apps to download code from external sources, at least not at install time. This seems like security risk.

I'm also experiencing this problem. After showing the Purism logo, the screen remains black for a couple minutes, then displays the same kernel panic.
I have a Librem13v4 with the 128GB SATA SSD.

In the cases where the /etc/crypttab is pasted (in the original post in this issue) I can see that both crypttabs have /

We need to determine where the issue is. Can we get a copy of /etc/crypttab? Also, can the customer boot into recovery mode? Is there any other information on the situation like log messages or output from 'journalctl -xe'?

I'm not sure what tokens do, but I didn't mean to cycle like that :-)

@noe.nieto While you are at perfect liberty to install any flatpack you want, it is not in your best interest to install flatpacks that:

Am looking into this, but not simple due to upstream changes requiring additional Python libraries packaged.

@jeremiah.foster @mak not that update-initramfs did not fixed issues, but it made it worse: customer now cannot boot even the older kernel version.

In T788#14927, @mak wrote:

Thank you for the feature request, but unfortunately we'll definitely not have cdrtools in PureOS.
There has been an old fight about its license change which I really don't want to start again. Also, the legal situation didn't really change and Debian, the FSF and Red Hat all agree on this particular legal issue.
Plus, to put it frankly, Jörg Schilling is one of the least fun upstream developers one could ever deal with.
See https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy for some abbreviated summary of the licensing issue.
You can use cdrkit to burn optical media, or just switch to the much more modern libburnia which is used by many open source projects: https://en.wikipedia.org/wiki/Libburnia
GNOME's Brasero is using libburn anyway.

The user upgraded via sudo apt update && sudo apt full-upgrade and also did sudo update-initramfs -u -k all and here's the output:

Thank you for the feature request, but unfortunately we'll definitely not have cdrtools in PureOS.
There has been an old fight about its license change which I really don't want to start again. Also, the legal situation didn't really change and Debian, the FSF and Red Hat all agree on this particular legal issue.
Plus, to put it frankly, Jörg Schilling is one of the least fun upstream developers one could ever deal with.

@jonas.smedegaard Do you think it's worth packaging and if so who will be the maintainer?

@mak Can you make it happen?

In T792#14905, @gorgeous wrote:

I can do that, of course, but as I said already, this is happening for the 2nd time, after a new/clean installation from a USB flash drive with a PureOS8 ISO image. After installing some of the system updates, this issue appears. How can I be sure this would not happen again?

I can do that, of course, but as I said already, this is happening for the 2nd time, after a new/clean installation from a USB flash drive with a PureOS8 ISO image. After installing some of the system updates, this issue appears. How can I be sure this would not happen again?

@mladen Can we ask the user to do an apt-get update && apt-get upgrade? Otherwise we need to get more information.

A user recently upgraded via Software Center and had this issue. He can successfully boot *4.19.0-2* but the newer kernel (4.19.0-5):

@gorgeous I suggest you do a re-install, you will save yourself a lot of time. Your installation seems very broken.