Thanks for the suggestions.
Please in future file one suggestion per issue report, to ease further tracking and discussion.

Thanks for the clarification!

@joao.azevedo did the outside World change, so that this is a regression, or is this a functionality which *never* worked on Stream and the patch is effectively a feature addition?

I assume this issue is targeted byzantium - tagging accordingly.

Systemd v248 reverted the software workaround: https://github.com/systemd/systemd/commit/ba2b8f9

I guess this is done now...

@joao.azevedo please note that bundling multiple issues makes them all harder to track - e.g. I would be uncomfortable assigning the issue report to myself if knowledgable about only a subset of involved issues, would only flag it as done when all parts were done, and would have a hard time noticing when all parts were done.

Assigning to you, @jeremiah.foster as you seem to be involved already and know at least some bits of it...

Sorry for the late reponse.
Unfortunately, PureOS does not support non-free environments like VMware. You are of course welcome to try use it in such environments, but we cannot help with issues you may encounter related to that.

Closing due to lack of info.

I guess Adrian isn't active on this any longer, so reassigning back you to, @jeremiah.foster

available since some time (entered Debian 2018-12-21)

available in Debian since 2018-12-21

Ah, I see it now: the older version mentioned by Carsten is the one currently in PureOS Byzantium.

which version of nuitka has such tight dependency on base-files, and why?

...or in this case, package repos (plural) as this issue affects both Amber and Byzantium.

thanks, @evangelos.tzaras - but you guessed correct: please only close when done from a user perspective, i.e. when fix has reached target repo.

Please (for future sake, if not this one) note that this issue tracker should be tracking user-visible targets, not staging targets like "landing".
I.e. not option e) but option g) at https://tracker.pureos.net/T553#18719

Feedback in the Debian derivatives list agrees with Carstens proposal, so I withdraw my alternative proposal.

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.

@carsten.schoenert Excellent!

@carsten.schoenert, will you have the honour?

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

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.

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

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.

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.

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

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

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