...and thanks for working towards solving this issue.

This issue tracker tracks development of packages, whereas https://source.puri.sm/ tracks development of code projects (often used as basis for packages).

@ezs777 thanks for confirming it works for you!

This was fixed when the latest update of nautilus, which I applied this morning.

Architecturally this should actually be implemented in such a way that a bugtracker change emits a new message on Laniakea's ZeroMQ-based message-bus, and that message is then picked up by the Matrix bot and relayed to the channel
that way, other consumers can pick up the messages as well and act on them for other purposes than showing a channel message (that's how automatic bug closing was implemented in the past, actually)
(but "in the past" means deep in the past where Trac was used for bugtracking)
The messages Laniakea sends are multipart-ZeroMQ messages with a header/subject in rDNS form, like _lk.archive.new-package and a JSON body with a few standardized fields and one freeform "data" part. The JSON part is signed with an Ed25519 signature from the messaging relay, so messages can be authenticated as correct
(message submission happens via a Curve25519-encrypted connection to a relay, from where they are distributed to interested parties)
and yes, this should absolutely be documented properly ;-)
Fortunately, the Laniakea Python module has helpers for this stuff so you don't have to touch it directly - in theory all this needs is a consumer of bug tracker events that submits them to the relay, and then the Matrix bot only needs to be told how to convert the messages into human-readable form

openvpn: 2.5.1-1
network-manager-openvpn: 1.8.12-2

https://github.com/lkhq/laniakea/tree/master/src/mirk is the tool we use to push to Matrix.

With which version of openvpn? Some of the links you provided indicated older versions of openvpn were the issue, we have a newer version in Byzantium now.

see https://source.puri.sm/Librem5/debs/nautilus/-/issues/3

@jeremiah.foster We already reproduced the issue with Librem Tunnel.

I guess the next step is to try to reproduce with Librem Tunnel.

In Byzantium, I see openvpn at version 2.5.1-1. I created a new Purist openvpn certificate, loaded that cert into Network Manager, and as expected received the tun0 interface. I then used the browser to determine my IP and the browser returned 'Your IP address is in Gunzenhausen, Bayern, Germany (91710)' which is the end point of the VPN apparently because normally my address is in Oakville, Connecticut, United States (06779).

As I mentioned before, I did update all my packages before testing it again, and I got the same error. I did find a StackOverflow post with a similar workaround, but I didn't want to do that, if a regular bugfix or update was going to resolve it.

Did you update system?

Glad to hear you got it up an running!

I've successfully been able to install PureOS 10, so this issue can be closed. It might be helpful to provide this information to new users of the Librem Mini (and possibly the Librem 14), so they don't run into the same issue.

I actually got it to run with Debian Bullseye, so I'm guessing that the kernel was the reason. I'll try with Byzantium, and report back, and if all goes well, this issue can be closed.

I still get this in Byzantium;

You'll need a recent kernel which is why Amber won't run - I'm using 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1 (2021-03-02) x86_64 GNU/Linux but I'm surprised the one from the OEM ISO didn't work for you. Did you use this to install: http://downloads.pureos.net/byzantium/gnome-oem/2020-11-20/?

I tested this in a Byzantium image in Boxes. It worked, I was able o change the disk encryption passphrase twice on the same VM.

\o/

Upstream bug fixed.

@jeremiah.foster I am running Plymouth version 0.9.5-2pureos1. This is on a Librem 13 v3 running Byzantium.

The (supported) way to install Kodi on PureOS is to use the package which is part of PureOS, *not* use external packages from Ubuntu or elsewhere.

This issue should be fixed since release 2:19.0+dfsg1-1pureos1 of kodi, which should appear in Debian Byzantium within a week.

Which hardware? Which version of plymouth? Amber or Byzantium?

Added to debian/control file, patch merged.

BTW. This also happens on amber-phone.

@jonas.smedegaard I don't think we're using rred in PureOS though?

Merge request holding Vcs fields here: https://source.puri.sm/Librem5/debs/squeekboard/-/merge_requests/3

I'll inquire with MLS to see how we get a key.

I think that's what we should do, see above

The Ubuntu issue referenced in that changelog section is this: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918112

apt 2.2.2 arrived in Debian testing now (so should soon enter PureOS landing) might fix this - judging from its changelog: https://tracker.debian.org/media/packages/a/apt/changelog-2.2.2

{F723349}This happened to me too. This is a copy of /var/lib/apt before it was cleared out.
I then moved these files and run updates without issue. I tested reverting back to the broken apt files and running updates, that came back with 0 to upgrade.
We would likely have to revert to the old packages that we don't host anymore to reproduce the error. One idea is to boot a live USB and try to copy over the broken apt files.

Are we trying to get an API key from Mozilla Location Services?

What are we trying to achieve?

@jeremiah.foster location services are off by default, this is for the case where the user enables it. Would you drive that process since it affects all devices running PureOS the same way??

I don't know if we have a formal policy around the Mozilla location services though I don't think we should be using Debian's. I think we need to create a policy or at least have a process to do so.

@jeremiah.foster any plans here? Should that go via the sys-team to manage all api keys?

wrong issue tracker - moved to https://source.puri.sm/Purism/docs.puri.sm/-/issues/38

pipx is a technical tool, not intended for regular users. It was packaged for Debian as it was requested for the _administration_ of Librem One services but explicitly *not* for general use.

Arch Linux discussion: https://bbs.archlinux.org/viewtopic.php?id=260567

as previously noted, this is a non-issue: no non-free package is suggested because the suggested package is not registered in apt so it is neither free nor non-free, it is instead nonexistent.

as previously noted, this is a non-issue: no non-free package is suggested because the suggested package is not registered in apt so it is neither free nor non-free, it is instead nonexistent.

as previously noted, this is a non-issue since the package cannot really suggest something that does not exist as a package registered with apt.

I have tested and can confirm that the use of suffix purge works to drop local fork:
https://lists.puri.sm/pipermail/pureos-changes/2021-March/001152.html shows the packages I uploaded, and https://software.pureos.net/search_pkg?term=zpb shows (at the time of writing this) that landing now contains the package from Debian.

Looks good.