Re: GnuPG 2.4 before Trixie freeze

[Jonathan McDowell]

On Mon, Jan 13, 2025 at 02:04:00PM +0100, Simon Josefsson wrote:
> Jonathan McDowell  writes:
> > On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote:
> >> Daniel Kahn Gillmor  writes:
> >> > I welcome review and critique of the packaging for this tricky package,
> >> > which is pretty deeply embedded in Debian (though getting less so, as
> >> > apt no longer requires it and we have many other OpenPGP implementations
> >> > available today).  I'd be even more delighted with offers of active
> >> > co-maintenance beyond the work that Andreas and i have been doing.
> >> 
> >> I've offered help, but my impression has been that it not giving up on
> >> the schism thing has been more important than getting Debian to ship
> >> upstream code to users and let people decide what they want to use.
> >> 
> >> Sometimes it is better to let other make decisions rather than to make
> >> decisions for others.
> >
> > I agree, but in this instance given the reliance we have upon GnuPG
> > throughout the Debian ecosystem I believe it's important we ensure that
> > the default configuration of what we ship is compatible with OpenPGP.
> > Power users can feel free to play with OpenPGP v6 / LibrePGP
> > enhancements, but for the vast majority of folk sticking to RFC
> > compliant v4 is going to make the most sense.
> 
> I understand this concern, but I believe there is a strong bias for
> Debian developers to care about our own use-cases a lot which may not be
> particulary relevant outside the scope of Debian-internal development.
> 
> I believe it would be perfectly fine to ship verbatim upstream unpatched
> GnuPG 2.4 and work out any Debian-specific quirks and requirements we
> have and put quirks into tools that are external to GnuPG itself.

I don't agree. For trixie I would like us to ship a GnuPG which _by
default_ does not emit LibrePGP packets. I'm fully in favour of that
ability being available to folk who chose to explicitly enable it, but I
don't think it's a responsible default for us to ship.

It's a simple fact that the OpenPGP ecosystem, including GnuPG, is
complicated for folk who are not devoting significant time to
understanding it all. We've seen that previously in terms of having to
write documentation about how to generate keys with secure settings, or
explain why we've made certain decisions that deviate from what an
out-of-the box config would give. We're not an outlier in patching GnuPG
to provide OpenPGP v4 defaults.

(This email written wearing no hats, but definitely informed by the fact
I'm part of keyring-maint.)

J.

-- 
"I'm a paranoid agnostic. I doubt the existence of God, but I'm sure
there is some force, somewhere, working against me." -- Marc Maron


signature.asc
Description: PGP signature

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

[Julien Plissonneau Duquène]

Le 2025-01-14 02:58, Ángel a écrit :

reading /proc/fs/ext4/*/options:


Thank you.

It appears that these options lack auto_da_alloc, which may (still 
hypothetical at this point) explain the much better performance of 
--force-unsafe-io in your case.


Cheers,

--
Julien Plissonneau Duquène

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

[Stephan Verbücheln]

This appears silly from an engineering perspective, but there is a
specific motivation behind it: Proton (the mail company) wants this to
simplify the implementation of PGP with Browser APIs.

As you said, too many optional ciphers are bad for compatibility. Note
that the key preferences do not help with this mess. Users usually have
one identity, but want to use it with different PGP implementations,
e.g. on their phone and their PC.

However, GnuPG's reaction to start their own standard is not helping
either. Bodies like IETF have to find a true consensus, not only
majorities, because there is no way to ensure proportional
representation of developers, users or other stakeholders.

The free software community is used to the problem that companies
intentionally send new people into standardization bodies just to tip
over the majority vote. We have seen this happen many times. In my
opinion, the OpenPGP schism has this smell, too.

Regards
Stephan

PS: I also criticized some features of the new OpenPGP standard
personally, e.g. unnecessarily making signatures non-deterministic. But
those are academic details not related to the schism.

https://mailarchive.ietf.org/arch/msg/openpgp/uGHlHjeqo7VEZ55JO_7IcV-Q1Nk/


signature.asc
Description: This is a digitally signed message part

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

[Simon Josefsson]

First a big thank you for all your efforts re OpenPGP!  It is hard to
navigate when there are conflicting requirements around.  We need more
boats attempting to navigate rather than less, increasing the chances to
reach fertile grounds.

Daniel Kahn Gillmor  writes:

> But the schism is, as far as i can tell, a disaster for both OpenPGP and
> for the GnuPG project.  The best outcome would be for GnuPG to be able
> to parse the updated OpenPGP standards (keys, certificates, signatures,
> encryption), and to limit itself to emitting data that can also be read
> by other implementations, including the new simplified formats.  I know
> that the GnuPG project has the cryptographic and software development
> expertise to do it, but the project doesn't seem to have interest in
> broad interoperability or demonstrating leadership within a pool of
> peers, and is instead imposing this schism on the larger ecosystem.

There is also the possibility for Seqoia and others to implement parsing
of what GnuPG and others are emitting.  I am confident doing so is
within the expertise of the relevant people too.

Fundamentally, I believe that forking upstream projects in this way is
bad for users of distributions like Debian.  Each project should own the
moral compass of its own destiny, and users can decide what to use if
they agree with that compass.  That's why I personally no longer install
Debian for example, because I prefer a 100% free software OS.  Right now
user decision is crippled because users cannot conveniently get to the
proper GnuPG package from Debian, and I believe that's bad for everyone;
users, Debian, and GnuPG.

/Simon


signature.asc
Description: PGP signature

Re: wiki.d.o on a git-backed engine

[Jonathan Dowland]

On Mon Jan 13, 2025 at 10:27 PM GMT, Ahmad Khalifa wrote:
Wikis have their own version control and they're meant for a much 
wider audience. I think general documentation definitely belongs on a 
wiki, not git. Edit, fix typo, done in 30 seconds :)


The two git-backed wikis I am familiar with (IkiWiki, and GitLab) have a 
full, traditional web UI for interacting with the wiki, and the Git 
back-end is effectively invisible from that perspective, but, power 
users have the ability to easily create a full backup of the full wiki 
history; perform large-scale or complex, machine-assisted edits on the 
local copy; use advanced merge-conflict resolution tools.


Having said all that, I believe any effort to revamp the Debian Wiki 
should start with determining the requirements and goals, rather than 
start picking solutions.


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Project-wide LLM budget for helping people (was: Re: Complete and unified documentation for new maintainers

[Andrey Rakhmatullin]

On Tue, Jan 14, 2025 at 08:52:39AM +0100, Philip Hands wrote:
> I'd really like to know how it is possible for one to use an LLM to make
> a contribution to a permissively licensed project (e.g. Expat) without
> in effect stealing the code from one's own tribe of Copyleft authors.
> 
> Can one even play with an LLM without somehow contaminating one's brain?

Is this the same with reading some GPL code directly instead of using an
LLM that have read it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

[Sune Vuorela]

On 2025-01-14, Stephan Verbücheln  wrote:
> This appears silly from an engineering perspective, but there is a
> specific motivation behind it: Proton (the mail company) wants this to
> simplify the implementation of PGP with Browser APIs.

But is this motivation more important than a coherent ecosystem? 

> However, GnuPG's reaction to start their own standard is not helping
> either.

I agree that it is not helping on a coherent ecosystem, but I'm also
having a bit hard time finding any other solution from the GnuPG side
for a way forward if they think than 3 different ways of doing aead 
is an absolute no-go. 

At least publishing a spec/standard is much better than the same thing
without a spec.

A difference between GnuPG and many other implementers is that GnuPG
(in libgcrypt) does most crypto by themselves where many others use
third party libraries for most crypto and thus might have stronger
feelings against many ciphers.

> Bodies like IETF have to find a true consensus, not only
> majorities, because there is no way to ensure proportional
> representation of developers, users or other stakeholders.

And it was quite clear a bit early on that the GnuPG people would be in
the very rough end of a rough consensus. 

> The free software community is used to the problem that companies
> intentionally send new people into standardization bodies just to tip
> over the majority vote. We have seen this happen many times. In my
> opinion, the OpenPGP schism has this smell, too.

ack.

/Sune

Re: Re: GnuPG 2.4 before Trixie freeze

[Andrew Gallagher]

Simon Joseffson mailto:si...@joseffson.org>> wrote:

> It seems there is push from the anti-GnuPG people to promote a fork called 
> FreePG instead of real GnuPG, will you package that?
>
> https://gitlab.com/freepg/gnupg

FreePG is not an anti-GnuPG project, if anything it’s trying to keep GnuPG on 
Linux alive as long as possible, so as not to force users into a disruptive 
sudden migration to other tools. It is also very deliberately not a fork, but 
rather a set of discrete patches that are already being applied by multiple 
downstreams, some dating back years.

> Who is behind FreePG?

Me, mostly. I wrote the CI tooling that runs FreePG, and dkg has been helping 
to review and de-lint the patches against upstream, in consultation with other 
downstreams.

> Or do we want to trust 'Hooty McOwlface' with no earlier publicly recorded 
> community contributions?

Some clarity about Hooty is overdue. It is a machine account controlled by a 
Docker container that currently runs on my laptop, primarily because there are 
some automation tasks (such as mangling branch histories) that are not 
currently easy to do in the GitLab CI. I have commented on tickets using 
Hooty’s name in the past, but I’m trying to avoid it these days to avoid giving 
the impression that Hooty has an opinion.

At some point I may decide to walk away from the project, in which case I can 
hand Hooty over to someone else as a functioning unit.

> This is even more true considering that the people who are patching GnuPG 
> seems to be the same people who are working on replacing GnuPG with Seqoia.

If you mean dkg, he’s been doing thankless work for years now trying to keep 
the OpenPGP ecosystem together, including by wrangling downstream packaging for 
*multiple* projects. The Sequoia project has never been involved in FreePG, and 
they most likely found out about it the same way everyone else here did. FreePG 
is an orthogonal project and is not intended to either help or impede adoption 
of Sequoia - the target userbase is people who can not, or do not wish to, 
migrate away from GnuPG (yet?), but also don’t wish to become incompatible with 
mainstream OpenPGP.

A



signature.asc
Description: Message signed with OpenPGP

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

[Steve McIntyre]

si...@josefsson.org wrote:
>
>Fundamentally, I believe that forking upstream projects in this way is
>bad for users of distributions like Debian.  Each project should own the
>moral compass of its own destiny, and users can decide what to use if
>they agree with that compass.  That's why I personally no longer install
>Debian for example, because I prefer a 100% free software OS.  Right now
>user decision is crippled because users cannot conveniently get to the
>proper GnuPG package from Debian, and I believe that's bad for everyone;
>users, Debian, and GnuPG.

There's a lot of loaded words in what you write there.

Debian has *always* added config, applied patches and adapted upstream
behaviour of upstream packages to make them fit our needs better. Why
should GnuPG be any different?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: wiki.d.o on a git-backed engine

[Jonas Smedegaard]

Quoting Steve McIntyre (2025-01-14 15:16:49)
> Jonas wrote:
> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
> >> 
> >> thank you for the offer but why not have the follow up in a publicly
> >> archived list? happy to switch to -www, if -devel is not ideal
> >
> >Then let's move to the tinker team mailinglist:
> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
> 
> Erm, WTF? How about keeping this on a main project list. And maybe
> even include the current people working on web and wiki admin?
> 
> Unimpressed...

WTF what? Should we stop work in smaller groups and discuss everything
here in one giant mailinglist for every detail of the project, or what
in particular makes this detail so F'ing global?

Offended...

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: wiki.d.o on a git-backed engine

[Steve McIntyre]

Jonas wrote:
>Quoting Steve McIntyre (2025-01-14 15:16:49)
>> Jonas wrote:
>> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
>> >> 
>> >> thank you for the offer but why not have the follow up in a publicly
>> >> archived list? happy to switch to -www, if -devel is not ideal
>> >
>> >Then let's move to the tinker team mailinglist:
>> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
>> 
>> Erm, WTF? How about keeping this on a main project list. And maybe
>> even include the current people working on web and wiki admin?
>> 
>> Unimpressed...
>
>WTF what? Should we stop work in smaller groups and discuss everything
>here in one giant mailinglist for every detail of the project, or what
>in particular makes this detail so F'ing global?

What on earth makes the blend-tinker-devel list a reasonable place to
discuss the Debian wiki and maybe working on replacing its software?
Serafeim suggested debian-www, which seems like a much more reasonable
place to me at least.

>Offended...

What, that people questioned this? That the people in the team
*running the service you're talking about* might care about
discussions about it?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Call for contributions to maintain existing documentation - Salsa makes it is easy!

[Steve McIntyre]

Jon Dowland wrote:
>
>I'm *fairly* sure that a more pressing issue is that MoinMoin requires
>Python 2, which has been abandoned.
>
>At least the stable and deployed versions: 2.0.0a1 is the first release 

*nod*

I think we have moin2 packages just about ready for use, but I have
worries: it's not simply a dropin replacement, and the first few
attempts I've made at migrating some test wikis didn't go very
well. And then lots of ENOTIME :-(

"We" are a small team running the wiki. Like a number of places in
Debian infrastructure, ongoing admin is a time commitment that it
seems very few people are ready to make.

-- 
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: GnuPG 2.4 before Trixie freeze

[andrewg]

Simon Joseffson  wrote:
If the justification for those modifications are disagreement with 
upstream about how GnuPG should behave with regard to the wire 
protocol, it becomes even more clear to me that we are talking about a 
fork.


The disagreements are not so much about which wire formats should be 
supported, just which ones should be generated by default. Patching over 
upstream defaults is common practice for most Linux distros.


What is GnuPG?  Upstreams GnuPG or Debian's GnuPG or Fedora's GnuPG or 
Hooty's GnuPG?  This situation is bad both for Debian and GnuPG, and to 
the wider PGP eco-system.


I’m sympathetic in principle, however the current status in practice is 
that we already have “Debian’s GnuPG, “Fedora’s GnuPG” etc, and the 
immediate goal of FreePG is to reduce this number, so that users who 
install one distribution’s GnuPG can be reasonably confident that it 
will behave the same as another distribution’s. If it was practical to 
ship unmodified, or barely modified, upstream then distributions would 
already be doing it, and FreePG would not exist.


I do realise that this sounds like a “now we have 14 competing 
standards” scenario, but there are enough distros seriously considering 
alignment with FreePG that I believe the effort is useful on balance.



If there is commitment to provide long-term support for FreePG, how
about uploading that as a separate package in Debian?


To be clear, FreePG requires no more support than the various distros 
are already providing for their existing patch sets, and FreePG has no 
support staff other than those downstream packagers who are already 
providing that support on a voluntary basis. However, we hope that 
having a single set of patches will allow distro packagers to share that 
support burden.


And also please upload verbatim upstream GnuPG separately.  This allows 
user choice.


I agree that users should be empowered, however providing multiple 
install packages may not be the most sustainable way of doing so. It may 
be that the same outcome can be achieved through configuration options 
rather than separate binaries.


—-
Andrew Gallagher

Re: wiki.d.o on a git-backed engine

[Jonas Smedegaard]

Quoting Steve McIntyre (2025-01-14 17:27:20)
> Jonas wrote:
> >Quoting Steve McIntyre (2025-01-14 15:16:49)
> >> Jonas wrote:
> >> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
> >> >> 
> >> >> thank you for the offer but why not have the follow up in a publicly
> >> >> archived list? happy to switch to -www, if -devel is not ideal
> >> >
> >> >Then let's move to the tinker team mailinglist:
> >> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
> >> 
> >> Erm, WTF? How about keeping this on a main project list. And maybe
> >> even include the current people working on web and wiki admin?
> >> 
> >> Unimpressed...
> >
> >WTF what? Should we stop work in smaller groups and discuss everything
> >here in one giant mailinglist for every detail of the project, or what
> >in particular makes this detail so F'ing global?
> 
> What on earth makes the blend-tinker-devel list a reasonable place to
> discuss the Debian wiki and maybe working on replacing its software?
> Serafeim suggested debian-www, which seems like a much more reasonable
> place to me at least.
> 
> >Offended...
> 
> What, that people questioned this? That the people in the team
> *running the service you're talking about* might care about
> discussions about it?

No, but that my proposal for discussion place was so out of this earth
that you felt the need to curse over it.

Obviously I am so fucking stupid that I didn't know that the wiki team
used same mailinglist as the www team.

I stand fucking corrected.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: GnuPG 2.4 before Trixie freeze

[Simon Josefsson]

Thank you for clarifying a bit about who is behind FreePG!

Andrew Gallagher  writes:

> Simon Joseffson mailto:si...@joseffson.org>> wrote:
>
>> It seems there is push from the anti-GnuPG people to promote a fork
>> called FreePG instead of real GnuPG, will you package that?
>>
>> https://gitlab.com/freepg/gnupg
>
> FreePG is not an anti-GnuPG project, if anything it’s trying to keep
> GnuPG on Linux alive as long as possible, so as not to force users
> into a disruptive sudden migration to other tools. It is also very
> deliberately not a fork, but rather a set of discrete patches that are
> already being applied by multiple downstreams, some dating back years.

So the FreePG set of patches results in a GnuPG fork by all meanings
except, apparently, by name.

If you take a piece of freely licensed software and make modifications
that goes beyond simple build fixes, I would call that a fork.

https://en.wikipedia.org/wiki/Fork_(software_development)

If the justification for those modifications are disagreement with
upstream about how GnuPG should behave with regard to the wire protocol,
it becomes even more clear to me that we are talking about a fork.

We've seen this before, like LibreSSL or OpenSSL, or EGCS vs GCC or
Iceweasel vs Firefox.  Each example is somewhat different, but they are
useful for comparison.

It is fine to disagree with a project, and chose to use or work on
something else.

I don't think it is a good idea to use the powers that comes by being a
package maintainer or distribution to force changes of how some piece of
software is supposed to work by patching it without changing its name.

Doing so mis-represent the upstream project, and confuses users.

What is GnuPG?  Upstreams GnuPG or Debian's GnuPG or Fedora's GnuPG or
Hooty's GnuPG?  This situation is bad both for Debian and GnuPG, and to
the wider PGP eco-system.

If there is commitment to provide long-term support for FreePG, how
about uploading that as a separate package in Debian?

And also please upload verbatim upstream GnuPG separately.  This allows
user choice.

Right now there are claims that we shouldn't use GnuPG 2.4.x because it
is EOL before trixie EOL and the two alternatives that are proposed
instead is to continue use GnuPG 2.2.x or the FreePG fork that also lack
long-term commitment EOL date for support.

/Simon


signature.asc
Description: PGP signature

Re: wiki.d.o on a git-backed engine

[Steve McIntyre]

Jonas wrote:
>Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
>> 
>> thank you for the offer but why not have the follow up in a publicly
>> archived list? happy to switch to -www, if -devel is not ideal
>
>Then let's move to the tinker team mailinglist:
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

Erm, WTF? How about keeping this on a main project list. And maybe
even include the current people working on web and wiki admin?

Unimpressed...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: GnuPG 2.4 before Trixie freeze

[Marco d'Itri]

On Jan 14, Simon Josefsson  wrote:

> I don't think it is a good idea to use the powers that comes by being a
> package maintainer or distribution to force changes of how some piece of
> software is supposed to work by patching it without changing its name.
We have been doing this since Debian exists, so I think that you will 
have to express a much more articulate argument than "I don't think it 
is a good idea".

> And also please upload verbatim upstream GnuPG separately.  This allows
> user choice.
Why don't YOU do it, if you really care so much?
As a project we have no moral or technical obligations to provide 
choices that we do not personally care about.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: GnuPG 2.4 before Trixie freeze

[Simon Josefsson]

Marco d'Itri  writes:

> On Jan 14, Simon Josefsson  wrote:
>
>> I don't think it is a good idea to use the powers that comes by being a
>> package maintainer or distribution to force changes of how some piece of
>> software is supposed to work by patching it without changing its name.
> We have been doing this since Debian exists, so I think that you will 
> have to express a much more articulate argument than "I don't think it 
> is a good idea".

Do you have earlier examples of Debian modifying upstream's desired wire
crypto-sensitive protocol in the way like what is being done for GnuPG?
Maybe there are some older OpenSSH or OpenSSL patches like that.

>> And also please upload verbatim upstream GnuPG separately.  This allows
>> user choice.
> Why don't YOU do it, if you really care so much?
> As a project we have no moral or technical obligations to provide 
> choices that we do not personally care about.

I am hoping that the 'gnupg2' package could be altered towards that
goal, and that some sort of compromise with the GnuPG Debian maintainers
can be reached that providing a LibrePGP-compliant GnuPG in Debian is
acceptable.  I still have hope that this could happen.  But you are
right, it helps to do homework first.

I've filed an ITP for a 'gnupg24' source package, to allow more
substantiated discussion to proceed.

https://bugs.debian.org/1093026

I've set up the following repository, forking gnupg2's current Salsa git
debian/experimental repository, with the intent of minimizing it into
shipping a LibrePGP-compatible set of 'gpg' tools.

https://salsa.debian.org/debian/gnupg-24

I would prefer if this was team-maintained with the existing GnuPG
maintainers since they are the experts on GnuPG in Debian.

/Simon


signature.asc
Description: PGP signature

Bug#1093026: ITP: gnupg24 -- GNU Privacy Guard, a LibrePGP implementation

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: gnupg24
  Version : 2.4.7
  Upstream Author : Werner Koch, et al
* URL : https://www.gnupg.org/
* License : GPL
  Programming Lang: C
  Description : GNU Privacy Guard, a LibrePGP implementation

The intent with this package is to provide a LibrePGP-compliant variant
of GnuPG in Debian.

Packaging is based on the 'gnupg2' source package from experimental, and
will be maintained here:

https://salsa.debian.org/debian/gnupg-24/

The idea is to minimize the existing packaging into the most minimal set
of binary packages required to support a more upstream-like GnuPG 2.4.x
experience in Debian.

Hopefully only two new binary packages called 'gpg24' and 'gpgv24' will
be needed.

I am hoping that most of the auxilliary packages like scdaemon does not
need to be provided by this source package, but can be shared with the
GnuPG/FreePG variant already packaged in Debian in the 'gnupg2' source
package.

/Simon


signature.asc
Description: PGP signature

Re: GnuPG 2.4 before Trixie freeze

[Marco d'Itri]

On Jan 14, Simon Josefsson  wrote:

> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.
Like the Kerberos patch for OpenSSH?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: GnuPG 2.4 before Trixie freeze

[Simon Josefsson]

Marco d'Itri  writes:

> On Jan 14, Simon Josefsson  wrote:
>
>> Do you have earlier examples of Debian modifying upstream's desired wire
>> crypto-sensitive protocol in the way like what is being done for GnuPG?
>> Maybe there are some older OpenSSH or OpenSSL patches like that.
> Like the Kerberos patch for OpenSSH?

Yes, that may be a good example of why doing distribution-specific
custom patching of crypto code is a bad idea.

/Simon


signature.asc
Description: PGP signature

Re: New Delegation: tag2upload delegates

[Thorsten Glaser]

On Tue, 14 Jan 2025, Andreas Tille wrote:

>Task description

There should be something in this that says that they need to do so
in a way that matches ftpmaster policies.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Re: Let's make 2025 a year when code reviews became common in Debian

[Andreas Tille]

Hi,

Am Tue, Jan 14, 2025 at 07:14:09PM -0800 schrieb Otto Kekäläinen:
> > I gave this, specifically reviewing MRs in the debian namespace, a
> > try after your last message on this topic. Unfortunately I have to
> > say, it feels like a huge waste of time and is mostly frustrating.
> 
> Thanks! Seems we are now down to 838 open MRs in the Debian namespace.

Nice.
 
> > I haven't noted down hard numbers, but my feeling is that 40%+ of the
> > MRs are from the janitor-bot, and mostly outdated. Anyone looking at
> > the list should immediately filter them out, because they are not
> > actionable in any way.
> 
> I would recommend to just skip the janitor ones for now and focus on
> providing feedback to humans to facilitate collaboration (among
> humans).
> 
> Eventually the person making an upload of a package would be the best
> person to merge/reject whatever janitor submitted ones are open.

Regarding Janitor: I admit I love these automated tools polishing
packages regarding so many issues reported by lintian and beyond.  Its
really great and I really appreciate what Jelmer did.  I use
lintian-brush (which is as far as I know the script behind janitor)
regularly (= a couple of times per day statistically).  A big thank you
to Jelmer!

However, in all teams I'm deeply involved we asked Jelmer to not run
Janitor automatically on the Git repositories.  The rationale is, that
if a package is not uploaded commits by the Janitor might become
outdated - well, finally what is described above is happening.  We
simply run either lintian-brush (mostly triggered by routine-update
which included lintian-brush) right when working / before uploading a
package.  This makes sure the package is polished *at the right time*.

I'm not sure if it is good that Janitor runs on Debian/ team packages if
it turns out that people do not care for those MRs created by Janitor.
Well, as far as I'm informed Janitor is not creating MRs any more but is
commiting directly so the non-human MRs will not be an issue any more
(Jelmer, please correct me if I'm wrong).  However, if we have somehow
structured teams the way Janitor behaves can be written inside the team
policy where team members either like those commits or are running the
tools manually.  For the Debian/ team I'm not really sure what might be
the best solution.

> I don't know exactly how Salsa is configured regarding notifications.
> I agree it should be optimized but don't know exactly how.
> 
> Meanwhile, you can configure your own notification at
> https://salsa.debian.org/-/profile/notifications and at least ensure
> you are "watching" the pacakges you maintain.

Thank you for the reminder.  For my taste its suboptimal that users need
to actively switch on notifications but I'm aware that we have lots of
different tastes and it might make sense to stick to rather less than
more notifications default to not bother volunteers with to much
information.  On the other hand this leads to the observed effect of
very many unattended MRs.
 
> > Another is MRs for packages that were removed from unstable a long
> > time ago. I've closed them when I encountered them, but did not file
> > a ticket to get the repo archived (*).
> 
> Thanks!

+1

Regarding archiving the repo:  In some teams this is done by moving the
repository to some folder named "attic" (or similar).  I'm not sure
whether removed packages might consume a severe amount of disk space on
Salsa.  IMHO having the repository around is rather a feature than a bug
so I'd tend to keep them even in case of removed packages.
 
> However, I would support the idea of bulk closing MRs and complete
> repositories *if* the package has been removed from Debian for the
> same reason we bulk close their bug reports.

I tend to keep the repository for several reasons:
  * Users might like to create their own local packages from the last
status of the repository.
  * Vcs fields are published on lots of places and would become broken
links for no good reason.
  * Someone might decided to re-introduce a package and likes to have
the history
  * Repositories might be a great resource for "software-history"

What advantages would you see in removing repositories of removed
packages except saving some disk space?
 
> > Frustrated,
> > Chris

Thank you for taking over frustrating work.  Its really appreciated.
 
Kind regards
Andreas. 

-- 
https://fam-tille.de

Re: Let's make 2025 a year when code reviews became common in Debian

[Julien Plissonneau Duquène]

Le 2025-01-15 00:37, Chris Hofstaedtler a écrit :

Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.


Given the "Debian time" scale, a much longer delay would be appropriate 
IMO. I would suggest 2 years with no activity on the MR before closing 
for "staleness", but ideally some data points should be extracted from 
Salsa before discussing this.


Cheers,

--
Julien Plissonneau Duquène

Re: Let's make 2025 a year when code reviews became common in Debian

[Andrey Rakhmatullin]

On Tue, Jan 14, 2025 at 07:14:09PM -0800, Otto Kekäläinen wrote:
> > The other big category of MRs in the debian namespace was and still
> > is: MRs where the maintainers don't get mails from salsa. If one is
> > active with the project, one can know who is currently around and
> > assign / ping them in the MR, and hope they'll respond after a few
> > days. The original submitter obviously is long gone, because these
> > MRs also sit there for years.
> 
> I don't know exactly how Salsa is configured regarding notifications.

Opt-in.
See also https://salsa.debian.org/dep-team/deps/-/merge_requests/8#note_512610



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1093050: ITP: acstore -- Attribute Container store access library

[Hilko Bengen]

Package: wnpp
Severity: wishlist
Owner: Hilko Bengen 

* Package name: acstore
  Version : 0~20240407
  Upstream Author : Joachim Metz et al.
* URL or Web page : https://github.com/log2timeline/acstore
* License : Apache 2.0
  Programming lang: Python
  Description : Attribute Container store access library

acstore is a dependency of the current of Plaso.

Let's make 2025 a year when code reviews became common in Debian

[Otto Kekäläinen]

Hi,

Numerous people are posting Merge Requests on Salsa. Please help review them!

There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
have open (and total count in parentheses):

938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
91 (3058) at https://salsa.debian.org/groups/go-team/-/merge_requests
78 (2336) https://salsa.debian.org/groups/python-team/-/merge_requests
32 (1686) https://salsa.debian.org/groups/kernel-team/-/merge_requests
84 (1491) https://salsa.debian.org/groups/gnome-team/-/merge_requests
619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests
93 (980) https://salsa.debian.org/groups/multimedia-team/-/merge_requests
29 (964) https://salsa.debian.org/groups/rust-team/-/merge_requests
15 (882) https://salsa.debian.org/groups/DebianOnMobile-team/-/merge_requests
137 (761) https://salsa.debian.org/groups/installer-team/-/merge_requests
31 (725) https://salsa.debian.org/groups/games-team/-/merge_requests
24 (605) https://salsa.debian.org/groups/Mobian-team/-/merge_requests
15 (444) https://salsa.debian.org/groups/js-team/-/merge_requests
14 (343) https://salsa.debian.org/groups/libvirt-team/-/merge_requests
3 (282) https://salsa.debian.org/groups/med-team/-/merge_requests

If you have some spare time for Debian today, please consider
collaborating with another maintainer by providing them
review/feedback on an open Merge Request.

Some of them might be stale for various reasons, but there are for
sure many that are genuinely pending review/feedback. You don't need
to be a subject-matter expert. Any feedback is surely appreciated by
the author.

I hope more people do code reviews as I believe it can have these
benefits for Debian:
- Better social dynamics, fewer lonely maintainers and more collaborative spirit
- Better documentation of changes as authors write commit messages
thinking about the reviewers who will read them
- Higher average quality of changes (assuming Linus' Law)
- Hopefully higher quality also via CI results that integrate into the MR review
- Faster spread of best practices as more maintainers read code
written by multiple people in multiple packages
- More opportunities for new contributors to become active in Debian
as Merge Requests offer a easily relatable workflow to most software
developers


I personally feel strongly that code reviews and discussing optimal
solutions with other people makes Debian packaging way more fun than
simply working solo.

- Otto

Debian/Linux's NPU support?

[M. Zhou]

Hi folks,

It seems that "AI PC" was everywhere in the CES 2025, which basically indicates
the presence of the NPU device. Both AMD and Intel have integrated the NPU 
device
into their own new CPUs -- in that sense I guess the NPU device will be more 
popular
than discrete GPUs in the future, in terms of availability on a random user's 
computer.

For instance, Intel's U9 285K has an NPU, based on its official Ark page:
  
https://www.intel.com/content/www/us/en/products/sku/241060/intel-core-ultra-9-processor-285k-36m-cache-up-to-5-70-ghz/specifications.html
AMD's AI Max 395 also has an NPU (called AMD Ryzen AI):
  
https://www.amd.com/en/products/processors/laptop/ryzen/ai-300-series/amd-ryzen-ai-max-plus-395.html

The NPU devices are still very new to me. I did a little bit of research, and 
they
seem to need some new drivers and libraries:
  * Intel: https://github.com/intel/linux-npu-driver
   https://github.com/intel/intel-npu-acceleration-library
  * AMD: https://github.com/amd/xdna-driver
Since they are still very new hardware, I think we have plenty time to prepare 
this for
the trixie+1 release. I just hope they are not as annoying as discrete GPUs 
from the green
compoany.

If anybody is interested in improving Debian's support on such new hardware, 
I'd suggest
direct the communications to Debian Deep Learning Team, and work with the team:
https://lists.debian.org/debian-ai/
The team's mailing list is targeted at machine learning and hardware 
acceleration at the
very beginning. And NPU was started from AI.

I'd like to learn if anybody here has experience working with those devices.
Do they run without non-free blobs? If they work well with just DFSG-compliant 
packages,
that would be great.

Re: Let's make 2025 a year when code reviews became common in Debian

[Otto Kekäläinen]

> > 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
> [..]
> > If you have some spare time for Debian today, please consider
> > collaborating with another maintainer by providing them
> > review/feedback on an open Merge Request.
>
> I gave this, specifically reviewing MRs in the debian namespace, a
> try after your last message on this topic. Unfortunately I have to
> say, it feels like a huge waste of time and is mostly frustrating.

Thanks! Seems we are now down to 838 open MRs in the Debian namespace.

> I haven't noted down hard numbers, but my feeling is that 40%+ of the
> MRs are from the janitor-bot, and mostly outdated. Anyone looking at
> the list should immediately filter them out, because they are not
> actionable in any way.

I would recommend to just skip the janitor ones for now and focus on
providing feedback to humans to facilitate collaboration (among
humans).

Eventually the person making an upload of a package would be the best
person to merge/reject whatever janitor submitted ones are open.

> The other big category of MRs in the debian namespace was and still
> is: MRs where the maintainers don't get mails from salsa. If one is
> active with the project, one can know who is currently around and
> assign / ping them in the MR, and hope they'll respond after a few
> days. The original submitter obviously is long gone, because these
> MRs also sit there for years.

I don't know exactly how Salsa is configured regarding notifications.
I agree it should be optimized but don't know exactly how.

Meanwhile, you can configure your own notification at
https://salsa.debian.org/-/profile/notifications and at least ensure
you are "watching" the pacakges you maintain.

> Another is MRs for packages that were removed from unstable a long
> time ago. I've closed them when I encountered them, but did not file
> a ticket to get the repo archived (*).

Thanks!

> Having said that, my actions did get some MRs merged and a few
> people were happy about that (thanks for the feedback!). But
> overall, I still think it was a waste of time. The numbers are just
> not in the favor of reviewers (and probably also not in favor of
> maintainers).

For sure, the first people going through the long list of pending MRs
will wade through a lot of accumulated cruft.

As a recurring MR review habit I'd expect people to only look at the
MRs that are recent and focus on them.

> Maybe a viable option for the debian namespace is to blanket close
> any MR that is older than 6 months. But I don't know how that will
> fare for the Janitor MRs.

I would not recommend doing any blanket close. I'd rather err on the
side of having some open in vain for a long time than throwing away
something useful. I think my personal record is a patch I sent to
Redis and it eventually got merged after being pending for 6 years.

However, I would support the idea of bulk closing MRs and complete
repositories *if* the package has been removed from Debian for the
same reason we bulk close their bug reports.

> Frustrated,
> Chris

Thanks for your efforts! I think you can now with a good conscience
ignore old MRs and just focus on new ones next time you have time to
review.

The more DDs help with common namespace MR reviews, the less
frustrating it will be to individual DDs.

Re: GnuPG 2.4 before Trixie freeze

[Andrew Gallagher]

On Tue, Jan 14, 2025 at 06:10:22PM +0100, Simon Josefsson wrote:
> 
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.

To reiterate, FreePG does not modify the cryptographic core of GnuPG, or its 
wire protocols, merely the preferences and defaults.

> I am hoping that the 'gnupg2' package could be altered towards that
> goal, and that some sort of compromise with the GnuPG Debian maintainers
> can be reached that providing a LibrePGP-compliant GnuPG in Debian is
> acceptable.

What is the criterion for LibrePGP compliance in your view? Is the ability to 
read and write LibrePGP wire formats not sufficient?

I would encourage readers to check the patch list at [1] and the discussion at 
[2].

-- 
Andrew Gallagherhttp://andrewg.com/ andr...@andrewg.com

[1] https://gitlab.com/freepg/gnupg/-/tree/main/STABLE-BRANCH-2-4-freepg
[2] https://gitlab.com/freepg/gnupg/-/issues/1

Re: wiki.d.o on a git-backed engine

[Kunal Mehta]

Hi,

On 1/13/25 17:27, Ahmad Khalifa wrote:
Wikis have their own version control and they're meant for a much wider 
audience. I think general documentation definitely belongs on a wiki, 
not git. Edit, fix typo, done in 30 seconds :)


Agreed 100%, the openness for editing is really what makes wikis shine. 
It can be hard to accept, with many of us firmly set in Git's 
pre-approval style PR/MR workflows, to allow anyone with an account, to 
just change anything, but that empowerment is what makes wikis work and 
really blossom.


As one of the maintainers of the MediaWiki package in Debian[1] and a 
wholehearted wiki enthusiast (longtime Wikipedia admin, etc.), I have a 
lot of thoughts on this that I'll save for later, but I want to 
cross-link the ongoing discussion at 
 that goes 
over a lot of the same topics.


One small point I want to highlight regarding software choices is that 
broadly speaking, the MediaWiki community loves Debian. MediaWiki not 
only supports running on Debian as its top priority (probably 
unsurprising given that Wikipedia runs solely on Debian), it wants the 
upstream Debian package to be successful, including changing its release 
schedule to better fit Debian's. When I file bugs about things not being 
compatible with Debian's practices/policies (usually JavaScript), the 
response I get is "ok, how do we fix this?" and not "ugh, why do we need 
to bend over for Debian again". I can't of course promise that upstream 
would implement all of Debian's feature requests, but I find this type 
of cooperation and relationship important to any wiki's success.


[1] the package is in not a great shape right now, so my main Debian 
priority is getting it all set for trixie


-- Kunal

Re: gettext 0.23.x

[Guillem Jover]

Hi!

On Mon, 2025-01-06 at 16:45:54 +0100, Simon Josefsson wrote:
> Santiago Vila  writes:
> > Note for Guillem: I've included your suggested fix in the bug template.

Great, thanks!

> I don't think we should patch upstream code for things that aren't clear
> upstream bugs.  Patching upstream code in Debian packaging has a
> maintainance cost and some risks.

I disagree. Regardless of this being an upstream bug or not, I think
patching should and has always been an option, if it improves our lives,
or gives better behavior when integrating with the packaging.

Integration into a distribution implies potentially making different
trade-offs, which are not necessarily upstream bugs.

> As far as I understand, the reason
> for the FTBFS's isn't due to upstream misuse of gettext, it is a symptom
> of how Debian packaging is (mis-)using autotools.

While an upstream would not usually see this particular issue, unless
running autoreconf on an already autoreconf'ed tree during development
(for example), the semantics for AM_GNU_GETTEXT_VERSION might seem to
give some sense of control, but at the same time these seem
counterproductive, in a similar way as if a project requested that it
needs an exact version of any other tool (when a minimum would work as
well and give users an easier time), notice how this behavior diverges
from for example autoconf's AC_PREREQ which only requires a specific
minimum version. This seems like a recipe to ship obsolete build system
infrastructure, so in that sense it still looks like something
worthwhile I'd still propose upstream.

> In this case, I don't think filing upstream bugs is a good idea: it
> seems more appropriate if we fix this via debian/rules instead of
> putting fixes to Debian-specific problems into upstream code
> (especially since the fix changes upstream semantics wrt gettext so
> isn't guarantee to be what upstream prefer).  Some of the packages
> seems to already do strange things in debian/rules related to gettext
> and autotools, so I think at least some of these are packaging bugs
> and not upstream bugs.

Personally I think using AM_GNU_GETTEXT_REQUIRE_VERSION is the better
fix (both for upstream and for our packages), as it gives better
semantics, and should reduce workarounds, hacks and hardcoding of
internal gettext details from debian/rules, and simplify packaging,
with the cost of a few lines patch. Potentially forcing a version
mismatch via debian/rules seems more error prone, and it also means
going against the wishes of the autotools upstream which added those
version consistency checks for a reason. :)

Of course upstream projects might reject the patch, but then I also
think it's perfectly fine to still use the simpler, more robust and
elegant solution at hand, regardless. And as long Debian considers
best practice to run autoreconf at build time (even if it's currently
imperfect, so that we can regen stuff if we need to modify the
autotooled build system source, or get new autotools changes
percolated into the whole archive with a mass rebuild), maintainers
should feel free to use the best tool at hand to support that.

Thanks,
Guillem

Bug#1093076: ITP: openvino -- open-source toolkit for optimizing and deploying AI inference

[M. Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: openvino
  Version : 2024.6.0
  Upstream Contact: Intel
* URL : https://github.com/openvinotoolkit/openvino
* License : Apache-2.0
  Programming Lang: Python, C++
  Description : open-source toolkit for optimizing and deploying AI 
inference

Seems to be a popular backend choice for AI inference on CPU.
It also has the NPU support. NPU is still new to me and let's see whether it 
works
for linux.

OpenVINO also have pytorch and onnxruntime integration, which might be useful 
as well.

Thank you for using reportbug

Re: Let's make 2025 a year when code reviews became common in Debian

[Chris Hofstaedtler]

* Otto Kekäläinen  [250114 23:14]:
> Numerous people are posting Merge Requests on Salsa. Please help review them!
> 
> There is no single dashboard to show all Merge Requests for all Debian
> packages, but here are the largest teams listed to show how many they
> have open (and total count in parentheses):
> 
> 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
[..]
> If you have some spare time for Debian today, please consider
> collaborating with another maintainer by providing them
> review/feedback on an open Merge Request.

I gave this, specifically reviewing MRs in the debian namespace, a
try after your last message on this topic. Unfortunately I have to
say, it feels like a huge waste of time and is mostly frustrating.

I haven't noted down hard numbers, but my feeling is that 40%+ of the
MRs are from the janitor-bot, and mostly outdated. Anyone looking at
the list should immediately filter them out, because they are not
actionable in any way.

Then a lot of the MRs I looked at were "cleary good idea", but were
being ignored for _years_. I'm guessing this is because the
maintainer of the respective package is just AWOL, and we don't
have a process for dealing with that. In that case one can opt to
make their own life more miserable by doing a review, apply, test
build, test and "team upload", and at some point one will see the MR
submitter didn't bother testing the change.

The other big category of MRs in the debian namespace was and still
is: MRs where the maintainers don't get mails from salsa. If one is
active with the project, one can know who is currently around and
assign / ping them in the MR, and hope they'll respond after a few
days. The original submitter obviously is long gone, because these
MRs also sit there for years.

Another is MRs for packages that were removed from unstable a long
time ago. I've closed them when I encountered them, but did not file
a ticket to get the repo archived (*).

Having said that, my actions did get some MRs merged and a few
people were happy about that (thanks for the feedback!). But
overall, I still think it was a waste of time. The numbers are just
not in the favor of reviewers (and probably also not in favor of
maintainers).

Maybe a viable option for the debian namespace is to blanket close
any MR that is older than 6 months. But I don't know how that will
fare for the Janitor MRs.

Frustrated,
Chris


(*) there's a limit to "boring but someone needs to do it" where
I'll step in.

Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?

[Salvo Tomaselli]

> On SSDs, it does not matter, both because modern media lasts longer than
> the rest of the computer now,

That has not been my experience.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

signature.asc
Description: This is a digitally signed message part.

Re: New Delegation: tag2upload delegates

[Andreas Tille]

Hi,

Am Wed, Jan 15, 2025 at 12:50:55AM +0100 schrieb Thorsten Glaser:
> >Task description
> 
> There should be something in this that says that they need to do so
> in a way that matches ftpmaster policies.

I gave the ftpmaster team about three weeks response time to the text of
the delegation.  Do you have any specific suggestion?

BTW, any volunteers to join ftpmaster team?  If yes, please contact the
team.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Let's make 2025 a year when code reviews became common in Debian

[Julien Plissonneau Duquène]

Hi,

Le 2025-01-14 23:14, Otto Kekäläinen a écrit :


619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests


FWIW I took a look at that and most of them are Janitor merge requests. 
Please just skip them as some are outdated, and I'm planning to take 
care of them later this year with some housekeeping tasks.


Identifying merge requests that are clearly outdated and posting a 
comment with a short explanation (e.g. "Obsolete MR: already fixed in 
current package version") will also help in getting the count down.


Cheers,

--
Julien Plissonneau Duquène