PureOS does allow for various screen resolutions as shown by the screen shot above. I configured my 34" screen via GNOME Display. I am running x11.

I'm closing this issue since Lollypop is now packaged for PureOS. I'm going to work with others on the team to see about integrating into CI/CD for L5. If there are any issues with the PureOS version of Lollypop for the Librem laptops, please open another issue. Thanks!

I cannot reproduce here with lollypop 1.1.4.11

@user22492 Is this with the PureOS package?

getting this error when running it

@omar.aboulhosn , we decided to work upstream with GNOME and so we don't want to promote PureOS by trying to re-invent the wheel with the hope that PureOS will be installed on a few more Thinkpads.

@mladen I reproduced the bug again while booting in verbose mode. The system sometimes hangs at Loading Linux 4.19.0-5-amd64, sometimes at Loading initial ramdisk.... Then after a couple minutes, the following line is shown:

error: failure reading sector 0x802 from `hd0'

and then the stack trace described above.

https://lists.puri.sm/pipermail/pureos-changes/2019-August/000411.html
Package is making its way into PureOS

Thanks a lot gusnan! :D

I just really wish there is more than just theming in their secret sauce. :D

Good link Adrien. I read the links to Tobias's article and to Sam's blog! Valid argument but whatever our competitor is doing, it's working (ok, minus the theming :)

They also have broken many apps by doing so: https://stopthemingmy.app/.

I don't know, at the very least the background should relate to 'Privacy and Security', even if not branded. Other than the menu options that show the switches off, *any* Linux operating system will run on our hardware.

GNOME itself is not over-branded anyway so that is perfect for us.

@francois Ah good too read, and I agree. :) I think mostly replacing GNOME's branding by Purism's should be sufficient.

@adrien.plazas , these were old proposals from James but we decided not to go this way and keep the branding at its minimum, so we will keep the application menu and background unbranded.

@EchedeyLR https://packages.debian.org/source/testing/chromium

Please file a _new_ issue instead: It might make good sense to use other addons, but that does not mean that the currently used addons are not working and therefore this issue is wrong to have "open".

In T57#14719, @jonas.smedegaard wrote:

@mak Please stop block chromium - it does not contain non-free code and is no longer unclear about licensing.

I submitted this to PureOS.

flashrom v1.1 updated in PureOS

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