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?

This issue should be solved by now.

is it perhaps possible to use the binary /usr/lib/grub/i386-coreboot/cbmemc.mod already provided in package grub-coreboot-bin?

Debian requires freely licensed source.
An artifact of a build process is not source.
Some third-party simply redistributing the artifact does not make it source.
Some third-party forking the artifact as a new project may make it source (depending on whether it is treated as the preferred form for modification by that new upstream author).

hm. This isue seems solved now.

Just stumbled upon yet another meta search engine which might (or might not - e.g. it doesn't seem decentralized) be relevant to consider: https://search.lilo.org/

This is not a Freedom issue: Promoting a commercial service does not violate the GNU Free Distribution Guidelines.
Instead, it is arguably a privacy issue - i.e. the code does not in itself leak personal data but promotes the use of a service which does.

This is a meta-issue tracking a bundle of issues, and as such not a Freedom issue (that is identified for each individual unbundled issue).

This is a meta-issue tracking a bundle of issues, and as such is not in itself a Freedom issue (that it identified for each unblundled issue). Lowering priority accordingly.

This is an issue in Debian but not in PureOS, because PureOS offers no nonfree packages.

This is an issue in Debian but not in PureOS, because PureOS offers no nonfree packages.

This issue is bogus for PureOS, because PureOS provide no non-free packages.

this is a meta-issue tracking multiple issues, and as such is not in itself a Freedom issue (that is identified for each individual unbundled issue).

This issue is not in itself a Freedom issue, but a bundling of multiple issues seemingly all tracked on their own.
Lowering priority and closing accordingly.

This issue is not in itself a Freedom issue, but a meta-issue bundling several issues tracked on their own.
Lowering priority accordingly

This issue is considered solved in PureOS.
It is true that the solution used for PureOS is not ideal, but it is effective: Users cannot accidentally or sloppily make use of the EME implementation included with Firefox ESR as shipped with PureOS, because it requires manually editing plaintext files to enable that functionality.

Thanks for the confirmation!

Makes sense to keep it open, I guess - but I don't expect much will happen here except keeping an eye on progress of this issue in Debian.

I find it unlikely that the Debian maintainer will join discussions here, and they are most suitable to address this issue.
Therefore I urge you to please fike a bugreport in Debian and discuss it there.

There should currently be no git repos publicly accessible as part of our Phabricator instance at tracker.pureos.net.
(I say "should" because I distrust both PHP and my own ability to reliably web-navigate the many of options of Phabricator)

I have now disabled repo laniakea: It has apparently moved to https://source.puri.sm/pureos/infra/laniakea
I verified that the latest commit here is contained in the newer git repo.

I have now disabled repo pdak: It has apparently moved to https://source.puri.sm/pureos/infra/pdak
I verified that the latest commit here is contained in the newer git repo.