Pinged Debian bug…

@mak you wrote this in a related discussion (in a non-public chat where you gave permission to quote in public):

Laniakea can sync a specific list of packages from any suite into landing, however this is definitely not a smart idea on PureOS as it currently is. We did that mistake on Tanglu in the past. Since PureOS doesn't rebuild all packages synced from Debian, there might be subtle incompatibilities, or synced packages would just flat out not work due to dependency issues. Or the synced experimental packages would break other stuff if not rebuilt against them, GLib is a primary candidate here (but we also had DBus interface incompatibilities occasionally).
So, if we sync stuff from random suites, I would also opt for rebuilding all Debian packages for PureOS, which in turn would require us to do transitions like Debian does (which would mean people would have to monitor and do those).

4.1.0+dfsg.1-1 is now in PureOS so the issue is gone.

I was commenting on a PureOS forum topic, and I discovered the same error when using Software->left application icon->Software Repositories. My system log file displayed the above stack.

Scope of this issue now relaxed to include source-identical but rebuilt packages.

Whoops, sorry: I totally misread this issue: Clearly not that PureOS is too unstable.

I generally find that it is easier to handle issues when framed by describing the "issue" (i.e. the thing broken or missing) as the topic - rather than an open-ended question.

Comments that were removed can be discussed in a separate issue: https://tracker.pureos.net/T722

Installed on L15 V3.

Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control

"cat: /etc/default/grub.cfg: No such file or directory"

Btw, gksu will not work at all on Wayland as wayland does not allow GUI apps to be run as root without some reconfiguration (which intentionally isn't done), and on Xorg I guess it's just broken because nobody looks at its code anymore.
So, I think we should just close this bug.

@jonas.smedegaard Apparently gksu wasn't auto-removed from PureOS because sbackup had a dependency on it. That package itself is cruft though, so I just dropped both from the archive.
Interestingly, sbackup was not considered for autoremoval in PureOS, I will have to take a closer look at why that happened later (my guess is that it has something to do with the package being NMU'ed and building only arch:all binary packages).

Why do PureOS distribute gksu at all? It was dropped from Debian a year ago: https://tracker.debian.org/pkg/gksu

What does

1. grub.cfg #
2. DO NOT EDIT THIS FILE #
3. It is automatically generated by grub-mkconfig using templates
4. from /etc/grub.d and settings from /etc/default/grub

#

Since you insist, @jeremiah.foster, on expanding/redefining the scope of this issue to be about switching *GENERALLY*, I cannot help and therefore unsubscribe from participation here:

Can you paste a copy of you grub.cfg file? Either here or in a pastebin somewhere? That might help debugging the issue. You grub.cfg file likely won't have any secret info, just things like the command line to boot your system as well as the UUID of your disks.

From the phone perspective we we'd like to pull a rather fixed set of packages from e.g. Debian experimental during the freeze automatically (assuming Debian's GNOME team ends up putting the packages there) but after all it's more of an example of a general pattern: grab packages a, b, c from repository x (ideally including required dependencies not present in the target distribution).

It's not, I installed the module and the same happens.

Nope. Installing libcanberra-gtk-module and libcanberra-gtk0 doesn't help.

I can reproduce this. I also get a message "Gtk-Message: 09:43:04.539: Failed to load module 'canberra-gtk-module'" when I run this so perhaps the error is there.

Also, could they provide more information, like actual log files or similar? Currently it is just port numbers and IP addresses which are no evidence of anything.

Yes, I updated grub before reboot.

@jeremiah.foster are you asking to *generally* switch from tracking testing to track unstable (or experimental), or are you - like this issue was initially intended to be about - asking about singling out packages to be tracked exceptionally from unstable (or experimental), where packages otherwise generally continue to track testing?

Syncing from unstable is just flipping a switch. But we need to know if we *want* to do that. Unstable won't get many package changes during the freeze period either.
Autosyncing with experimental is a terrible idea, because experimental packages may just get deleted without ever reaching unstable. There is also a lot of broken stuff in there which we really don't want in PureOS (experimental is really just a playground with zero QA happening).
So, stuff from experimental should only ever be synced manually and if there is a good reason for doing so.

I asked, user said he is not able to install OpenSnitch manually (by compiling from source).

I commented out "GRUB_ENABLE_CRYPTODISK=y" in/etc/default/grub then ran sudo update-grub. This stopped grub from asking me for a password.

Also, could they provide more information, like actual log files or similar? Currently it is just port numbers and IP addresses which are no evidence of anything.

Did you run

Grrr, this means a distro patch to python-qpt got reverted in PureOS somehow.
I will have a look, thanks for the direct bug assignment!

I believe this is the same problem as T660. In my case, this application does not launch. Fortunately, I do not use it very much.

Building my own PureOS ISO image?

Found the comment in /etc/default/grub and commented it out, then updated grub. Rebooted, but still the same startup sequence. Double checked to make sure the grub default file was saved with the enable_cryptodisk statement commented out.

Software and Updates starts, it just fails to find a distribution template for PureOS

In the grub package in Debian there was a configuration change that PureOS inherited. That change is the addition of an enabled display of the encryption password prompt. Can you check to see if there is a "GRUB_ENABLE_CRYPTODISK=y" line in/etc/default/grub ?

These are just warnings and do not affect boot.

@jeremiah.foster Packaging is here: https://source.puri.sm/Librem5/mfgtools/tree/pureos/purple

I agree @mak, folks can install via GNOME Software.

@jeremiah.foster Kodi was added on request of your predecessor because the initial PureOS had it and PureOS was supposed to be "complete" (including a mediacenter).
IMHO we don't actually need it since people can easily install missing pieces via GNOME Software.

I'll join you @guido. Let me poke around on this to see where I can contribute to packaging. In the meantime, I'm going to see if I can't get into the build tool we're using to see if I can't nudge a couple packages into showing up in the repos.

I think there are a number of extra packages in our default image. I hope to collect a list of those and winnow down our images to improve security by limiting surface area and to limit the amount of applications we have to support.

additional note: this doesn't appear to be a kernel issue, as I installed the Liquorix kernel and had the same result there - so must be one of the underlying packages libusb depends on

flashrom does not even display its version number via flashrom —version - it complains about being unknown on PureOS after being updated from 0.99 => 1.0.

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

As a user, I support this opinion. I think Kodi was the first thing I ripped off my Librem when I received it. I try to keep only what I need or may need.

@tbernard I suggest you repeat your question to ensure that the others tracking the original bug which this is a duplicate/mirror of hears it. You might also want to read the backlog, as they might have already answered your question ;-)

@sean.obrien @jonas.smedegaard so what's the situation with this now? Can we rename to Firefox or do we rename to a new generic name?

What are the security implications of adding users to the kvm group?