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

What I'm wondering is: why isn't the necessary data automatically generated at package build time and included as a file (perhaps named PACKAGE.contents) in the .deb file? Then to build the Contents file for a repo would just involve scanning through all the .deb files and extracting the .contents file from each and then concatenating them. I don't understand the Debian package build system well enough to know why it doesn't work this way.

[Update: I now see that this is T155. Possibly this should be marked as a duplicate of that? I don't yet know how to do that.]

This issue should be solved by now.

maybe, thanks for the tip.

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

@jonas.smedegaard is a package like the above: that is not a standalone project but an artifact generated in the build process of coreboot something that would normally be ok to package as a debian package.
Or is there any debian guideline against packaging something like this?
Considering that we do not package coreboot (the project that generates this binary in it's build process) as deb.

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!

@jonas.smedegaard yes it works now \o/. Thanks!

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.

After digging through the Debian bug logs, they have a bug already filed under a similar title whose fix would cover this as well.

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.

I'm not sure if it's still undergoing testing. I can tell you that Nitrokey is referencing it here:

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?

Understood that you're at the same commit level as Debian. I don't understand why they haven't applied that commit either. My thought was that I'd have better luck filing the request in PureOS's tracker rather than Debian's, because this materially affects the use of the Librem Key.

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/

https://github.com/gpg/poldi
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=poldi.git
https://tracker.debian.org/pkg/poldi

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.

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

I have now disabled repo keysafe: It has moved to https://git.joeyh.name/git/keysafe.git/ as officially announced at https://joeyh.name/code/keysafe/
I verified that the latest commit here is contained in the newer git repo.

I have now disabled these repos which are empty:

• gnome-pureos2.1
• purebrowser