@mladen Feel free to direct people to enter more details of their issue here, I get notification quickly.

Reopened to collect other issues and hopefully other solutions.

On my amber instance here, running an upgrade just of ca-certificates would work but I've already done it and get an expected result;

$ apt upgrade ca-certificates
Reading package lists... Done
Building dependency tree       
Reading state information... Done
ca-certificates is already the newest version (20200601~deb10u2).
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Updating ca-certificates is the same as updating any other package, simply do

@lo0 You may be right. My original URL was tested and now fails. I'm having trouble connecting to the new URL however so cannot confirm.

Updating ca-certificates on Byzantium solves this issue.

Amber works now but Byzantium still fails.

My understanding was that in Debian they updated the buildd chroots. In any case, Stelios writes; "very likely an issue client side. a few days ago intermediate lets-encrypt certificates expired ,workaround on older debian systems was to drop the line DST from /etc/ca-certificates.conf and run update-ca-certificates its not a server side issue its a client side issue".

It looks like updating the certs for repo.puri.sm is the workaround. Asked systeam to do this and then we can test again.

More here: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481

On Debian 11 this works;

Same thing occurs in Byzantium and GnuTLS

It may have been upstream that made these changes, if so, the bug ought to go there.

We need more information. Perhaps the version of Plasma they're using and a screenshot if possible?

dpkg is now at version 1.20.9pureos2 thanks to uploads by Sebastian this July.

Oh I see. This means that d/control email address can be arbitrary but the uploading key must be in the keychain. Thanks for the clarification. In such case we ought to mark it as pedantic (or just info) in Lintian.

See https://forums.puri.sm/t/pureos-better-integration-with-pureboot/14765

Won't users have to sign the package with their email address? So won't the email address have to be in the keyring? Or is there a workaround?

This is a good question. Since it affects security in the archive I'd like to have consensus and have Matthias' view.

I think this is an issue with the runtime that Gitg uses.

The name "Hephaestus" is going to be deprecated and removed in favor of just the version number, e.g. PureOS 9 Amber, Pureos 10 Byzantium, etc.

Aug 12 19:25:07 sigyn kernel: PM: suspend entry (deep)
Aug 12 19:25:07 sigyn systemd-sleep[14674]: Suspending system...
Aug 12 19:25:07 sigyn systemd[1]: Starting Suspend...
Aug 12 19:25:07 sigyn systemd[1]: Reached target Sleep.
Aug 12 19:25:07 sigyn kernel: r8169 0000:02:00.0 enp2s0: Link is Down
Aug 12 19:25:07 sigyn NetworkManager[617]: <info> [1628810707.6702] device (enp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')

For completeness, you're referring to https://pureos.net/ ?

In general I feel it's better that we receive into PureOS Debian packages as maintained by our upstream, namely Debian. It gives me pause that in this case, the maintainer of libpam-poldi and the person doing a lot of commits in the GitHub mirror are the same person: https://github.com/gpg/poldi/commits/master I don't know what it means that the package hasn't been updated in Debian - does the maintainer not have enough time? Is the patch still undergoing testing?

PureOS 10 has

We should not use this tool (Phabricator) to host source code.

I've uninstalled diffusion. Apparently this is sufficient to remove it from the various menus and it says "uninstalled" here: https://tracker.pureos.net/applications/view/PhabricatorDifferentialApplication/

The link goes to Debian branded page with little or no useful content at the moment. Filed issue.

Yes, let's create a PureOS Policy document. To be clear, we base it on Debian Policy and we add the parts where PureOS deviates. The document is meant to be an authoritative requirements document so ought to use nomenclature to indicate requirement levels either identical to Debian's nomenclature or the IETF nomenclature: https://tools.ietf.org/html/rfc2119

Using pureos/byzantium or pureos/amber with or without -phone is somewhat easier for me since it clarifies which branch is destined for which target suite. In my mind, pureos/latest points to the branch that you work from to create pureos/*.

I reverted to an older document because the NEW Queue is 404'ing at the moment.

Let's keep in mind that we also implement, in the PureOS case, the tools that do package processing. This means we can mandate a set of git tags along with git (obviously) and gbp. I guess the issue with git tags is that some Debian packages do not use git tags, but we can add them for PureOS without much issue no?

@guido Yes, okay to update. I'll do it unless you get to it first.

Then let's go with g) until / unless we determine this is unsuitable. It may lead to tags like "fixed in Byzantium" or "fixed in Amber" but those ought to be easily managed and I think we already have a "fixed in Byzantium" tag.

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

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.

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

Glad to hear you got it up an running!

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

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

Added to debian/control file, patch merged.

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