@guido If you were to outline the steps you took for creating the 'green' docker image, I could follow that and put them into a pureos.sh script to submit upstream. I'm also setting this up to be automated.

https://tracker.pureos.net/T298 May be useful here as well.

That URL looks good and has some good resources. It also fits with my understanding of EDID and KMS.

In T809#15183, @richard.kolla wrote:

PureOS defaults to Wayland and has for sometime as per my testing of old ISOs. Both the customer and myself are using Wayland. He tried X.org and got the same result he said.

There is a way at least find the capabilities of your graphics card to see if the card support's your screen's resolution;

reportbug is a debian-native package. This means its only meant to work with Debian. We'd have to do code refactoring for PureOS.

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

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

I submitted this to PureOS.

flashrom v1.1 updated in PureOS

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

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.

Why?

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.

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'?

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

I have this snippet you pasted here at the bottom of my /etc/pulse/default.pa file. It came in via the regular update process on June 4th (I didn't add it manually.)

May I ask that you try commenting out

I've not experienced any issues with recent updates, including update to cryptsetup packages.

I don't know for sure. I'm taking a look at them right now and have downloaded and updated here. I'll report my experience with the updates.

We saw this behavior again today (see internal chat system for more.) I cannot reproduce but am just noting here that others are reporting this issue.

I don't think I did do that @jonas.smedegaard - the details of the task description show something more nuanced than "bad". If you feel that there is no evidence for DDG tracking and fingerprinting users, and personally I deem the DDG statement as acceptable, then I think we can move forward. In other words, that caveat I added shouldn't be a blocker but rather something to keep in mind and as evidence that we've thought about the problem.

No, that doesn't help;

TASK DETAIL

http://tracker.pureos.net/T563

EMAIL PREFERENCES

http://tracker.pureos.net/settings/panel/emailpreferences/

We've recently done a phd restart so let's see if that helps . . .

Thanks for opening the discussion here.

Changing to 'incomplete' since we cannot recreate the original issue.

Plan is to remain on Buster for PureOS Green.

Alternatively you can build from source?

Do you have additional repos enabled in your sources.list and/or sources.list.d? I don't see libmysql++-dev in our repos: https://repo.pureos.net/pureos/pool/main/libm/

Works for me, at least so far. I will retry later perhaps with new content.

Some users claim that lack of cups-filters prevents them from printing: https://forums.puri.sm/t/cant-print-ghostscript-fails-with-unable-to-determine-number-of-pages/5698