This issue is now raised in Debian Derivatives team: https://lists.debian.org/debian-derivatives/2021/09/msg00006.html

I think it is wrong needless busywork to rename original Uploaders field: During the lifetime of a forked package it is sensible to know who maintains the non-forked package (the Maintainer field) but not really relevant to know who was responsible of uploading within the upstream distribution (the Uploader field).

Issue description updated to not mention experimental.

Just FTR, we can't binary-sync anything from experimental, ever. Packages there are built with other binaries from experimental, which would break any suite we sync them into. Source syncs can work though, but will need support implemented in Synchrontron in Laniakea.

To me, this Lintian check actually makes little sense. The one for Maintainer is important, so the maintenance status is reflected in the modified package, but Changed-by could be any address. When Zlatan and I created the project, the initial goal was explicitly to get the community involved and have people outside of Purism contribute. That didn't really work out, but by limiting change authors to people with an @puri.sm address we make this even less likely and also make the project look a lot more like a Purism inside job than is good for it ;-)

This was a bit tricky, as byzantium is still an in-development release and all changes should go through landing. Fortunately though, the synchrotron Laniakea module is flexible enough nowadays to accommodate for that.
I've implemented a solution which will fill up the -updates and -security suites directly for byzantium from the respective bullseye suites, while not allowing manual uploads from us which should still go through landing. That workflow should work well for byzantiums current odd in-between state between "released" and "in-development".

I've prepared a setup on https://source.puri.sm/carsten.schoenert/seahorse

@carsten.schoenert happy to help here, first good step would be a MR against the above repo with the necessary changes. I usually do

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.

@carsten.schoenert Excellent!

@jonas.smedegaard
Let's call it a first challenge. ;)

The linitan check is about the fields in d/control. I doesn't care who signs/uploads the package later on.

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.

Sorry for the open/close ping pong but the issue is still there (and not a dup, i'll clarify in the other issue).

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

@carsten.schoenert i've created https://source.puri.sm/pureos/packages/lollypop by mirroring https://salsa.debian.org/python-team/packages/lollypop.git (see https://source.puri.sm/Librem5/librem5-dev-tools/-/issues/1 for the steps) since i wasn't sure if you have all the permissions set up yet.

@carsten.schoenert, will you have the honour?

I was intructed on the pureos-project mailinglist that if the latest package in Debian is a clean backport and I haven't seen any regressions, then the simplest solution is to simply backport that from unstable to byzantium.

@jeremiah.foster Please share your opinion on this issue, as it seems @mak is too busy to work on it.

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?

It's not a rejection reason (afaik Laneakia doesn't reject based on linitan errors yet) so likely not security relevant or am i missing something?

Will have a look at this over the weekend, shouldn't be that difficult on the technical side.

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.

Morning @carsten.schoenert I was told that this ticket should be brought to your attention.

I can handle this low priority for the moment, i found ways to build geary for the moment but i expect this issue to become more urgent during the byznatium cycle again (if not for geary then for other packages using vala). Issue here is that this will likely involve a glib upgrade as well.

What would be the preferred way to get this done?

We could probably have debug symbols packages for our self-built packages with a bit more space (the dbgsym packages are *insanely* huge, they dwarf the size of the actual archive), but for the full archive, so syncing the debug symbols from Debian to make them available easily in PureOS, we'd need quite a lot of space (I need to look at Debian to actually give a - then very good - estimate).
At time, PureOS holds dbgsym packages for everything that we have built in the landing suite, but byzantium doesn't have own debug symbols. You can however use the ones from landing, which are either equal to the versions in byzantium, or newer.

This is probably a duplicate of https://tracker.pureos.net/T873 (see last comment by Guido).

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.

apparently done...

I am not intimately familiar with the ISO building process, but suspect that this is harmless, caused by post-processing of the ISO file to support UEFI or something similar.

A second user confirmed the first report.

Sorry, this is not a helpdesk.
In my understanding, the builtin default values are nowadays sensible for general use.

Hmm, okay - I've just checked my little local CentOS server and indeed, it doesn't have a gpg.conf (or any conf) under ~/.gnupg. My apologies.

When you enter a new $HOME then maybe (unusually!) it came with furniture preinstalled but if it comes with personal items like toothpaste preinstalled, then you should not trust it.

No, that is not the issue here. The issue here is:

So, if PureOS insists on being unusual, the question becomes - why is PureOS unusual in this particular way?

The gnupg package in PureOS is the exact same as the gnupg package in Debian.
If the issue here is that you find the PureOS initial configuration of gnupg inferior to that of Debian, then you are mistaken.

Phew, this file exists on the gnupg implementation in Debian, CentOS and Fedora, at least - those are all fairly standard implementations of gnu/linux (although arguable implementations of two standards).

Correct, no gpg.conf file exist after a fresh install.

man gpg says:

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

Right, I clearly misunderstood what is the issue you are reporting here.
Can you please help clarify what is broken about gnupg.
If nothing is broken about gnupg then what else is the issue?
I mean, this is an issue tracker (not e.g. a helpdesk or a chat forum).

I'm not sure I understand the relevance of the answer to the question?
The question was: why are the defaults not reflected here:

~/.gnupg/gpg.conf (as per man gpg) as I would expect and are on my Debian 10 install
Or;
~/.gnupg/dirmngr.conf (as suggested here)

Those aren't 'system-wide' locations.

Correct, gnupg by design has built-in defaults and no system-wide configuration.
What is the issue you have with that?