This is a good question. Since it affects security in the archive I'd like to have consensus and have Matthias' view.
Wed, Sep 22
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.
Mon, Sep 20
Sep 14 2021
Sep 13 2021
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.
Sep 11 2021
What would be the preferred way to get this done?
Sep 10 2021
Sep 8 2021
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).
Sep 7 2021
Sep 3 2021
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.
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.
Sep 1 2021
Aug 25 2021
Aug 20 2021
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.
Aug 19 2021
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 18 2021
Aug 13 2021
Aug 12 19:25:07 sigyn kernel: PM: suspend entry (deep)
Aug 12 19:25:07 sigyn systemd-sleep: Suspending system...
Aug 12 19:25:07 sigyn systemd: Starting Suspend...
Aug 12 19:25:07 sigyn systemd: 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: <info> [1628810707.6702] device (enp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
For completeness, you're referring to https://pureos.net/ ?
Aug 11 2021
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
~/.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?
Aug 10 2021
Aug 4 2021
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.]
Aug 2 2021
Aug 1 2021
Jul 27 2021
Jul 26 2021
Jul 17 2021
Jul 16 2021
Jul 11 2021
Jul 10 2021
Jul 7 2021
This issue should be solved by now.
Jul 6 2021
Jul 5 2021
maybe, thanks for the tip.
Jul 3 2021
is it perhaps possible to use the binary /usr/lib/grub/i386-coreboot/cbmemc.mod already provided in package grub-coreboot-bin?
Jul 1 2021
Jun 30 2021
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.