Re: Is it worth spending more time on adduser?

[Matthias Urlichs]

On 27.04.25 14:18, Marc Haber wrote:

At least not enouch space to waste any more life time on it.


Owch. That's one way to look at it, but it does seem that it's not 
really conductive to your emotional well-being.


Look at it another way. Quite a few admin scripts, both in 
/var/lib/dpkg/info and not, use adduser, presumably because it did 
something no other tool did at the time. Thus, IMHO you can safely 
assume that you spent much less time on it than your collective users 
saved, as they utilized adduser instead of re-inventing some wheels (or 
the bits and pieces of them that they needed).


I'd count that as a win in my book.

The work people did on CVS and SVN and HG and whatnot didn't go down the 
drain either, when git took over the world. People used them. They added 
value. Yes, in 2025 it's probably not a good idea to set up a new SVN 
repository, and there's probably not much point in working on improving 
its code *now*, but that's a different problem.


--
-- regards
--
-- Matthias Urlichs

BEGIN:VCARD
VERSION:4.0
N:Urlichs;Matthias;;;
NICKNAME:Smurf
EMAIL;PREF=1:matth...@urlichs.de
TEL;TYPE=work;VALUE=TEXT:+49 911 59818 0
URL;TYPE=home:https://matthias.urlichs.de
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Is it worth spending more time on adduser?

[Chris Hofstaedtler]

* Marc Haber  [250428 08:40]:

On Sun, 27 Apr 2025 15:13:00 +0200, Chris Hofstaedtler
 wrote:

As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?


As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.


I don't know about that. It probably helps.

Fedora is discussing what to do in a related context:
   https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Chris

Re: Is it worth spending more time on adduser?

[Chris Hofstaedtler]

* Marc Haber  [250428 08:52]:

This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning.


Yeah. There's always talk about some form of technical leadership 
group, but it's always unclear how that should look like, and what 
it powers should or even could be.


So we end up with informal SIGs (to not use "cabals"), and at best a 
post to d-devel.


Chris

Re: In the shadows (Was: Is it worth spending more time on adduser?)

[Andrey Rakhmatullin]

On Mon, Apr 28, 2025 at 01:50:19PM +0200, Daniel Gröber wrote:

Hi Marc,

On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:

I was just told off-the-records that [...]


Consider the motives of those staying out of the public limelight.

Does consensus need to be spoken quietly and in the shadows?

Are they afraid of something?


This is even more wtf than some of the previous messages here.


--
WBR, wRAR


signature.asc
Description: PGP signature

Re: In the shadows (Was: Is it worth spending more time on adduser?)

[Marc Haber]

On Mon, 28 Apr 2025 13:50:19 +0200, Daniel Gröber 
wrote:
>Hi Marc,
>
>On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:
>> I was just told off-the-records that [...]
>
>Consider the motives of those staying out of the public limelight.
>
>Does consensus need to be spoken quietly and in the shadows?
>
>Are they afraid of something?

Just for the record: All I see here is non-existent technical leadship
and bad communication. Not conspiracy.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Matthias Urlichs]

On 28.04.25 12:56, Marc Haber wrote:

Could somebody with an LWN subscription share a friends link?


Subscriptions to LWN are free for DDs, somebody (HP IIRC) sponsors them.

--
-- regards
--
-- Matthias Urlichs

BEGIN:VCARD
VERSION:4.0
N:Urlichs;Matthias;;;
NICKNAME:Smurf
EMAIL;PREF=1:matth...@urlichs.de
TEL;TYPE=work;VALUE=TEXT:+49 911 59818 0
URL;TYPE=home:https://matthias.urlichs.de
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Is it worth spending more time on adduser?

[Matthias Urlichs]

On 28.04.25 10:57, Marc Haber wrote:

That's different. git won because it was the superior program. Noone
every forbid using svn.


I don't think the reason *why* previous work isn't useful any more, 
today, matters much.


I mean, adduser isn't going to be somewhat-obsolete-for-some-usecases 
(not all of them!) because somebody decided that Marc is a horrible 
human being and/or his work is and has been completely useless, quite 
the opposite in fact, but because of externals that prima facie have 
nothing to do with you personally *or* the quality of your work.


--
-- mit freundlichen Grüßen
--
-- Matthias Urlichs

BEGIN:VCARD
VERSION:4.0
N:Urlichs;Matthias;;;
NICKNAME:Smurf
EMAIL;PREF=1:matth...@urlichs.de
TEL;TYPE=work;VALUE=TEXT:+49 911 59818 0
URL;TYPE=home:https://matthias.urlichs.de
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

In the shadows (Was: Is it worth spending more time on adduser?)

[Daniel Gröber]

Hi Marc,

On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:
> I was just told off-the-records that [...]

Consider the motives of those staying out of the public limelight.

Does consensus need to be spoken quietly and in the shadows?

Are they afraid of something?

--Daniel


signature.asc
Description: PGP signature

Bug#1104297: ITP: python-pyslurm -- Python Interface to Slurm

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pyslurm
  Version : 24.11.0
  Upstream Contact: Toni Harzendorf 
* URL : https://github.com/PySlurm/pyslurm
* License : GPL-2
  Programming Lang: Python
  Description : Python Interface to Slurm

pyslurm is the Python client library for the Slurm Workload Manager.

I intend to maintain this as part of DPT but I am open to join the HPC team
(maintainers of Slurm) and maintain it there.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmgPdqcbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqF1QH/RkzuIU9yFupOCGH/6/G
XIaxQxqCShFBq3mJ4YEY4C7Mt3wbv3v84xksBoFJk91NE0KVo1eADmrg9BlW4dIy
9ui6jkhcfBWSICHEvS9e4Q3bq1xOBDsvhcDj64sUq7iBsgia+6dQpOkmpqPQPxfQ
t5SO3Bsc6s5D8HKny/m0D6cWjuJ32jc4dkpOKnndHNAoA46EPrRv1dLQzxvYy3g+
qoN1vO7FeSdbEGknw60WHP6u7Ot3Bp5ycW9tP7hrEQvykvvzuHKih6OlxxNik86L
V6I9zie/7nwh4QFyVwRTJJ3qwgL4CzibY7gUuLlPnpFj4P4g9FV9ED2jOWdZ+4eX
uS8=
=+WE/
-END PGP SIGNATURE-

Re: Is it worth spending more time on adduser?

[Holger Levsen]

On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:
> Not that I know of. I was just told off-the-records that it does not
> make sense to spend any more time on adduser since it's going to be
> forbidden soon anyway.

don't believe everything they say?


and many thanks for maintaining adduser for so long from me too!! i'm sure
i'll be a happy user for years to come! (because I have it's usage scripted.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Der Spiegel: Herr Professor, vor zwei Wochen sah die Welt noch in Ordnung aus...
Adorno: HALT DIE FRESSE!


signature.asc
Description: PGP signature

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 11:34:18 +0200, Andreas Tille 
wrote:
>Am Mon, Apr 28, 2025 at 11:02:13AM +0200 schrieb Marc Haber:
>> That's my biggest gripe about Debian. It strongly influences the only
>> voice I have in that regard, the DPL vote.
>
>... speaking as DPL I was also not aware about the adduser issue and I
>did not realised that this was a topic in any platform or question on
>debian-vote.  Honestly, I'm happy that I do not need to decide on this
>kind of technical decisions and that we have some CTTE.  Is there an
>according bug documenting the problem?

Not that I know of. I was just told off-the-records that it does not
make sense to spend any more time on adduser since it's going to be
forbidden soon anyway.

Actually, as I said, this is not an adduser issue, it is a general
thing I have with Debian, and it might be misunderstanding on my side
n general. And I understand that this is not fixed without going into
the constitution and changing many of our processes and that this is
not going to happen any time soon.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler
 wrote:
>Fedora is discussing what to do in a related context:
>https://lwn.net/Articles/1018082/
>But sysusers might or might not actually help them.

Could somebody with an LWN subscription share a friends link?

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 10:36:54 +, Holger Levsen
 wrote:
>On Mon, Apr 28, 2025 at 12:31:24PM +0200, Marc Haber wrote:
>> Not that I know of. I was just told off-the-records that it does not
>> make sense to spend any more time on adduser since it's going to be
>> forbidden soon anyway.
>
>don't believe everything they say?

The technical reasoning was sound (persistent /etc/passwd is going
away, so packages who need their uid better declare it via sysusers so
that it is recreated automatically on system boot) and I immediately
understood that the advice was correct.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Proposal -- Interpretation of DFSG on Artificial Intelligence (AI) Models

[Matthew Vernon]

Russ Allbery  writes:

> 4. As you discovered, finding the training data, even when upstream has
>retained it (which I suspect will not always be the case, since I
>expect in at least some cases upstream would just start over if they
>wanted to retrain the model and therefore would view at least some of
>the training data as equivalent to ephemeral object files they would
>discard), is not going to be easy since almost no one cares. This is of
>course not a new problem in free software, and we have long experience
>with telling upstreams that no, we really do care about all of the
>source code, but it is incrementally more work of a type that most
>Debian packagers truly dislike doing.

This makes me wonder what "the preferred form for modification" is when
it comes to training data for gnubg (and the related examples discussed
here), if the answer is "if we needed to re-train the model for whatever
reason we'd start from scratch".

[in any case, I think I'd +1 the suggestion else-thread to hold off
applying any of this until after the trixie release]

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: Is it worth spending more time on adduser?

[Sune Vuorela]

On 2025-04-28, Marc Haber  wrote:
> The technical reasoning was sound (persistent /etc/passwd is going
> away, so packages who need their uid better declare it via sysusers so
> that it is recreated automatically on system boot) and I immediately
> understood that the advice was correct.

Though some improvements are still quite much needed

https://lwn.net/Articles/1018082/

/Sune

Re: Is it worth spending more time on adduser?

[Sune Vuorela]

On 2025-04-28, Marc Haber  wrote:
> On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler
> wrote:
>>Fedora is discussing what to do in a related context:
>>https://lwn.net/Articles/1018082/
>>But sysusers might or might not actually help them.
>
> Could somebody with an LWN subscription share a friends link?

https://lwn.net/SubscriberLink/1018082/c32532680eaebda6/

Re: Is it worth spending more time on adduser?

[Bastian Blank]

On Mon, Apr 28, 2025 at 12:56:18PM +0200, Marc Haber wrote:
> On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler
>  wrote:
> >Fedora is discussing what to do in a related context:
> >https://lwn.net/Articles/1018082/
> >But sysusers might or might not actually help them.
> Could somebody with an LWN subscription share a friends link?

https://lwn.net/SubscriberLink/1018082/9da60ec5de229c84/

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.

why is Perl Build-Essential: yes?

[Jonathan Dowland]

"apt-cache show perl" lists it as "Build-Essential: yes". But why? It's 
not in the transitive dependencies of build-essential, nor 
/usr/share/doc/build-essential/list, and I can't find that header 
verbatim in Perl's debian/control in the source, nor in the binary (I 
checked perl_5.40.1-3_amd64.deb with dpkg-deb -I)



Thanks,

--
Please do not CC me for listmail.

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

Re: Is it worth spending more time on adduser?

[Jakub Wilk]

* Matthias Urlichs , 2025-04-28 14:20:
Subscriptions to LWN are free for DDs, somebody (HP IIRC) sponsors 
them.


It hasn't been HP for a long time.

https://wiki.debian.org/MemberBenefits says:
"Thank you to Microsoft who is footing the LWN bill since 2020, Debian 
France who have topped up the amount requested by LWN for 2023 and HP 
who have sponsored in the past."


--
Jakub Wilk

Re: why is Perl Build-Essential: yes?

[Sven Joachim]

On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:

> "apt-cache show perl" lists it as "Build-Essential: yes". But why? It's 
> not in the transitive dependencies of build-essential,

It is, dpkg-dev depends on perl:any.

> nor /usr/share/doc/build-essential/list, and I can't find that header 
> verbatim in Perl's debian/control in the source, nor in the binary (I 
> checked perl_5.40.1-3_amd64.deb with dpkg-deb -I)

The tag is coming from an FTP Master override, see
http://ftp.debian.org/debian/indices/override.sid.extra.main.gz.

You could argue that perl should probably not really be build-essential,
but even if somebody comes along and rewrites dpkg-dev and debhelper in
a different language it might be difficult to remove perl from build
environments.

Cheers,
   Sven

Re: Is it worth spending more time on adduser?

[Andrew M.A. Cater]

On Mon, Apr 28, 2025 at 08:39:17AM +0200, Marc Haber wrote:
> On Sun, 27 Apr 2025 15:08:18 +0200, "Andrea Pappacoda"
>  wrote:
> >On Sun Apr 27, 2025 at 2:18 PM CEST, Marc Haber wrote:
> >> Useradd has grown most of that functionality in the last two decades.
> >> That leaves no space for adduser between useradd and sysusers. At 
> >> least not enouch space to waste any more life time on it.
> >

To be strictly local: there are probably far more machines in the world
running Debian, Ubuntu and Debian derivatives than current Red Hat or
SUSE if you think of Linux machines with a full OS: for containers,
who knows :)

> >I think I do not fully understand what you mean: are you saying that 
> >adduser is useless outside of maintainer scripts?
> 
> I am saying that adduser was written in a time when useradd had about
> a fifth of its current features, and that the local admin can use
> useradd to create local users as comfortably nowadays, and be portable
> between distributions. adduser has developed into a helper for
> maintainer scripts, and I was told a few weeks ago that the months of
> my life I spent improving adduser are going down the drain.
> 

I don't often add users, but when I do I use useradd to add the user and
than to add the user to a custom group. That's finger memory but it's
constant over 20+ years. It's a Debianism - but it works, and I'm grateful
to you for maintaining it.

> >In my opinion adduser has great value outside of maintainer scripts! 
> >But I'm sure you know better than me, so I'm ready to change my mind.
> 
> Take a look at current useradd and decide wehther adduser actually
> adds a value other than fitting your finger memory.
> 

Will do - but thanks for your hard work. For a userbase value of one: *I*
appreciate it.
 
With every good wish, as ever,

Andy Cater
(amaca...@debian.org)

> Greetings
> Marc
> -- 
> 
> Marc Haber |   " Questions are the | Mailadresse im Header
> Rhein-Neckar, DE   | Beginning of Wisdom " | 
> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
> 

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler
 wrote:
>Fedora is discussing what to do in a related context:
>https://lwn.net/Articles/1018082/
>But sysusers might or might not actually help them.

Yes, that is about the idea, putting more burden on the since they
either have to get along without owning files, apply for a static
assignment, or to go through tempfiles.d to have their files reowned.
The suggested semi-static assignment has become possible with adduser
recently as we finally were able to fix a bug from the 243K range,
from 20 years ago. I was very proud of that and would like to thank
the people contributing the code. Sad that it will live for like a
fifth of the time the bug was open.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 10:59:30 - (UTC), Sune Vuorela
 wrote:
>On 2025-04-28, Marc Haber  wrote:
>> The technical reasoning was sound (persistent /etc/passwd is going
>> away, so packages who need their uid better declare it via sysusers so
>> that it is recreated automatically on system boot) and I immediately
>> understood that the advice was correct.
>
>Though some improvements are still quite much needed
>
>https://lwn.net/Articles/1018082/

I totally hate that idea. But I need to accept that. Traditional Unix
is going away, traditional systems are going away. It's all
containers, and everything else has to adapt.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: why is Perl Build-Essential: yes?

[Jonathan Dowland]

On Mon Apr 28, 2025 at 4:46 PM BST, Sven Joachim wrote:

On 2025-04-28 15:57 +0100, Jonathan Dowland wrote:

"apt-cache show perl" lists it as "Build-Essential: yes". But why? It's 
not in the transitive dependencies of build-essential,


It is, dpkg-dev depends on perl:any.


Thanks! For reasons I cannot explain, installing build-essential (in a 
Salsa CI environment) did not pull in perl.



The tag is coming from an FTP Master override, see
http://ftp.debian.org/debian/indices/override.sid.extra.main.gz.


Double-Thanks! (This seems likely true for all packages with 
Build-Essential: yes)


--
Please do not CC me for listmail.

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

Re: Re: Proposal -- Interpretation of DFSG on Artificial Intelligence (AI) Models

[Aigars Mahinovs]

On Mon, 28 Apr 2025 at 17:46, Stephan Verbücheln 
wrote:

> > Is the change technical or legal/philosophical? You could call this
> > a Turing test for copyright.
> This is not a new issue at all. I remember that back in the day in
> order to legally reverse engineer a computer program, companies had to
> set up two separate teams of developers.
> One team reads the code and writes documentation. The second team reads
> the documentation and writes the new code. It was crucial that no
> member of the second team sees the original code in order to rule out
> any copyright issues.


But, does it? If we consider the product of trained knowledge to be a
derivative work of the training input, then the documentation produced by
the first team would also be tainted by the copyright of the original code.
So such interpretation also defeats the whole two-teams process.

And many modern LLMs are actually often trained in stages - there is a very
large model that is trained on the source data and then there are compact
models that are actually trained by the first model. It's called model
distillation.

And then there are other methods of getting new information into already
trained models at runtime via RAG technique - with that a LLM may only
contain fundamental information and then reach out to load additional data
sources, relevant to the specific query. Like an expert going online and
checking prices and availability of various products before advising you
what to choose for your planned build. At this point the LLM+RAG is just a
smart web browser.

(Sadly, I am *not* an expert on modern AI technologies)

-- 
Best regards,
Aigars Mahinovs

Bug#1104309: ITP: golang-github-a-h-parse -- Set of parsing tools for Go

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 

* Package name: golang-github-a-h-parse
  Version : 0.0~git20250122.74294ad-1
  Upstream Author : Adrian Hesketh
* URL : https://github.com/a-h/parse
* License : Expat
  Programming Lang: Go
  Description : Set of parsing tools for Go

 A set of parsing tools for Go inspired by Sprache
 (https://github.com/sprache/Sprache/).
 .
 Build up complex parsers from small, simple functions that chomp away at
 the input.

This is an indirect dependency of anubis (ITP #1102132). I plan to
maintain this under the Go team umbrella.

Bug#1104310: ITP: golang-github-a-h-htmlformat -- Tool used to format HTML

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 

* Package name: golang-github-a-h-htmlformat
  Version : 0.0~git20250209.c2a3d62-1
  Upstream Author : Adrian Hesketh
* URL : https://github.com/a-h/htmlformat
* License : Expat
  Programming Lang: Go
  Description : Tool used to format HTML

 htmlformat is a Go package and CLI tool used to format HTML.
 .
 It is forked and simplified from the https://github.com/ericchiang/pup
 (https://github.com/ericchiang/pup) package.
 .
 It does not aim to:
 .
  * Colorize output.
  * Modify the input HTML except for formatting (i.e. no HTML escaping
will be applied).
  * Provide any facilities to query the content.

This is an indirect dependency of anubis (ITP #1102132). I plan to
maintain this under the Go team umbrella.

Re: Is it worth spending more time on adduser?

[Russ Allbery]

Marc Haber  writes:

> This is one more example of Debian lacking technical leadership, with
> small groups taking technical decisions for the entire distribution
> without even mentioning. Most of those technical decisions are sound and
> supportable, but there are technical decisions that have impact on other
> packages, and it is bad that those packages learn about it after
> spending weeks or even months of spare time without knowing that this
> work is going to go down the drain.

I just want to make a plug here that my hope when I first started working
on Policy was that Policy could be used for this. That's part of why I
spent a lot of time working on process and trying to identify gaps where
major architectural decisions had gone undocumented in Policy.

I have had almost no time and (to be honest the more directly relevant
problem) emotional energy for Debian since at least last summer and
honestly for some years before that, and I haven't been able to push that
vision forward or even keep up with the existing work. Sean has been doing
a fantastic job stepping into the gap I rather messily left, but Policy is
in general underresourced, not so much on the Policy Editor side, but on
the side of people doing the concrete work of documenting stuff. We need
people to be proactively picking up technical decisions, figuring out a
consensus, and writing up the results so that they can be merged into the
Policy document if we want Policy to be a collection of these decisions
for the project.

I do think that would help, but I'm not sure if it's possible, at least
following the current process. It's a fair bit of work and a lot of email
back and forth. But I'm not sure what a better solution would be that
would work with how Debian is structured.

My experience is that the biggest obstacle is timeliness. We have to be
able to document a technical decision within a reasonable amount of time
or people will just go do things because they're blocked and need to move
forward. When consensus is clear, I think we can mostly manage that, but
often consensus is murky. My plan to address that had been to promptly
refer such cases to the Technical Committee so that we could keep up
momentum and make a real decision, but (a) I was never entirely sure the
TC was on board with making that many decisions (the TC often decides to
not decide), and (b) I only managed to do this once or twice and then
stopped again so we never got into a rhythm.

I pretty thoroughly dropped this ball along with a whole bunch of other
balls, and I'm not sure my idea was even sound. Sean will certainly have
his own opinions, and he's been doing most of the work recently and I
would put more weight on his views than mine at this point. But maybe this
will get people thinking about how they might be able to step into this
decision-making gap and help out with it.

I should probably say explicitly that my guess is that having a high-level
process discussion about how Debian should do this in the abstract will
probably not be helpful. We're good at having those discussions and then
never acting on them. We probably instead need people to step in and start
trying to resolve concrete technical issues and document the resolution,
and then see if we can scale that process by having them identify the
bottlenecks they encountered and the places they got stuck.

-- 
Russ Allbery (r...@debian.org)  

Re: Re: Proposal -- Interpretation of DFSG on Artificial Intelligence (AI) Models

[Stephan Verbücheln]

> Is the change technical or legal/philosophical? You could call this
> a Turing test for copyright.
This is not a new issue at all. I remember that back in the day in
order to legally reverse engineer a computer program, companies had to
set up two separate teams of developers.
One team reads the code and writes documentation. The second team reads
the documentation and writes the new code. It was crucial that no
member of the second team sees the original code in order to rule out
any copyright issues.

> Processing of experiences into expert opinion is IMHO not directly
> comparable with compilation of source to a binary.
DSFG does not only apply to programming languages and program binaries.
For all data blobs in Debian packages, it is preferred to include the
scripts that generate it, for images it is preferred to have the SVG
code over the generated pixel graphics, etc.

For a reason, the relevant licenses do not define “source code” by
being in a programming language readable by humans. They define it like
this (example from GPLv3):

> The “source code” for a work means the preferred form of the work
> for making modifications to it.

In that definition, training data is quite obviously relevant. No one
tweaks neural network model weights manually.

Compare this to the previously mentioned example of S-boxes in
cryptography. They are small and usually created manually.

Regards
Stephan


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

Re: Is it worth spending more time on adduser? (was: Bug#1104169: wish: adduser _radvd on new installs)

[Marco d'Itri]

On Apr 27, Marc Haber  wrote:


While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
persistent /etc/passwd and /etc/group and that it will soon be
officially forbidden to use adduser in packages?
I am (nominally) one of the systemd package maintainers and I am not 
aware of anybody having decided this.
At this point I would say that using DynamicUser if possible, and 
sysusers if not, is just a best practice.

As usual in policy matters, policy follows usage.

Like many others, I believe that adduser is generally useful outside of 
maintainer scripts.


--
ciao,
Marco


signature.asc
Description: PGP signature

Re: Is it worth spending more time on adduser?

[Johannes Schauer Marin Rodrigues]

Hi Marc,

Quoting Marc Haber (2025-04-28 08:39:17)
> On Sun, 27 Apr 2025 15:08:18 +0200, "Andrea Pappacoda"
>  wrote:
> >On Sun Apr 27, 2025 at 2:18 PM CEST, Marc Haber wrote:
> >> Useradd has grown most of that functionality in the last two decades.
> >> That leaves no space for adduser between useradd and sysusers. At 
> >> least not enouch space to waste any more life time on it.
> >
> >I think I do not fully understand what you mean: are you saying that 
> >adduser is useless outside of maintainer scripts?
> 
> I am saying that adduser was written in a time when useradd had about
> a fifth of its current features, and that the local admin can use
> useradd to create local users as comfortably nowadays, and be portable
> between distributions. adduser has developed into a helper for
> maintainer scripts, and I was told a few weeks ago that the months of my life
> I spent improving adduser are going down the drain.

I don't think that's true. Even if maintainer scripts are moving away from
adduser, maybe think about it this way:

 - adduser has served many thousands of users for two decades directly as well
   as indirectly via maintainer scripts or any program which relies on adduser.
   All of these thousands of people would not've been able to do what they did
   in these many years if you had not maintained adduser. Thousands of people
   should be grateful of your work (and so am I) for what adduser has done for
   them in the past. This is a fact and independent from wherever adduser is
   going in the future. Your life time was far from wasted I think.

 - useradd gained the features it did because adduser paved the way for them.
   Your software was and is part of a wider ecosystem and you inspired other
   software authors to improve their software. You are one of the giants that
   others are standing on top of when they wrote their software. This is also
   something that nobody can take away from you and which is independent of
   wherever adduser is going in the future.

I understand that it feels very good to be the author/maintainer of a popular
piece of software. I like the feeling I get when the popcon graph of my own
packages is going up. We can also be upset about our own mortality and just as
we will not be here one day anymore: what we did in our life will always be
part of what the world is like today. Maybe you can think about it that way.
Your software has been the cornerstone of the computing use for many, many,
many people throughout the years. Nobody can take that away from you. I think
you can be very proud. :)

Thank you!

cheers, josch

signature.asc
Description: signature

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 10:46:39 +0200, Johannes Schauer Marin Rodrigues
 wrote:
>Quoting Marc Haber (2025-04-28 08:39:17)
>> I am saying that adduser was written in a time when useradd had about
>> a fifth of its current features, and that the local admin can use
>> useradd to create local users as comfortably nowadays, and be portable
>> between distributions. adduser has developed into a helper for
>> maintainer scripts, and I was told a few weeks ago that the months of my life
>> I spent improving adduser are going down the drain.
>
>I don't think that's true. Even if maintainer scripts are moving away from
>adduser,

It is GOOD that maintainer scripts are moving away from adduser.
sysusers is for most cases the better way to do it. I absolute hate
the idea that this is being forced because somebody decided that we
should be moving away from persistent /etc/passwd.

> - useradd gained the features it did because adduser paved the way for them.

Most of those features were already there when Roland hander over the
package to me two decades ago. About 80 % of my work was improving the
tool for package maintainers without impacting its usefulness for
local admins.

>Thank you!

Your kind words are appreciated. My frustration about the way we take
decision remains.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Andrej Shadura]

Hi,

On Mon, 28 Apr 2025, at 10:57, Marc Haber wrote:
> On Mon, 28 Apr 2025 09:38:56 +0200, Matthias Urlichs
>>The work people did on CVS and SVN and HG and whatnot didn't go down the 
>>drain either, when git took over the world.

> That's different. git won because it was the superior program.

No. Git won because of the network effects. It was not, and still isn’t 
superior to Mercurial, not in terms of the internal design, data model nor in 
terms of the user interface.
I only use Git myself because everyone else uses Git, including my work 
colleagues. If I were to use Mercurial, I’d be using it on my own, or use 
hg-git.

-- 
Cheers,
  Andrej

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 09:38:56 +0200, Matthias Urlichs
 wrote:
>The work people did on CVS and SVN and HG and whatnot didn't go down the 
>drain either, when git took over the world.

That's different. git won because it was the superior program. Noone
every forbid using svn. Other people deciding in the secret that
Debian will stop using /etc/passwd are forbidding adduser. Using
adduser will be an RC bug.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 09:57:23 +0200, Chris Hofstaedtler
 wrote:
>* Marc Haber  [250428 08:52]:
>>This is one more example of Debian lacking technical leadership, with
>>small groups taking technical decisions for the entire distribution
>>without even mentioning.
>
>Yeah. There's always talk about some form of technical leadership 
>group, but it's always unclear how that should look like, and what 
>it powers should or even could be.

That's my biggest gripe about Debian. It strongly influences the only
voice I have in that regard, the DPL vote.

>So we end up with informal SIGs (to not use "cabals"), and at best a 
>post to d-devel.

And that's bad.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Simon Richter]

Hi,

On 28.04.2025 15:40, Marc Haber wrote:


As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.


FWIW, switching to sysusers would break most of my CI containers -- 
these are orchestrated by Jenkins, and use a shell script as the root 
process. Changing this would require a deep dive into Java code.


My containers use "useradd" instead of "adduser" for the most part 
though, because these are just generic "don't run this part as root" 
users that require no configuration.


The same goes, I expect, for most of the Docker containers out there -- 
both systemd-nspawn containers and Docker containers running a copy of 
systemd as pid 1 are fairly niche, and will remain so until they also 
implement a replacement for Docker-style image distribution, and 
k8s-style container orchestration, and provide a stable interface for 
creating users inside a container during image creation.


People running Debian inside containers also do not care about immutable 
/usr or empty /etc, because containers are immutable anyway, and the 
contents of /etc are copied in from version control and switching to a 
database style format that uses dedicated tools creates additional 
overhead, and, again would require a stable interface for creating 
registry entries inside a container during image creation.


Frankly, I don't see that happening any time soon now, and even if it 
were, there would be no clear benefit to users, as they already have 
working solutions that would be broken by such a change, and the path of 
least resistance for them would be to switch to another distribution as 
container base image.


To get back on the original topic: I (and everyone in the company I work 
for) uses "adduser" to create users on shared machines, because it 
works, and allows us to actually get on with our main goals. That is 
actual value.


   Simon

Re: Is it worth spending more time on adduser?

[Andreas Tille]

Am Mon, Apr 28, 2025 at 11:02:13AM +0200 schrieb Marc Haber:
> That's my biggest gripe about Debian. It strongly influences the only
> voice I have in that regard, the DPL vote.

... speaking as DPL I was also not aware about the adduser issue and I
did not realised that this was a topic in any platform or question on
debian-vote.  Honestly, I'm happy that I do not need to decide on this
kind of technical decisions and that we have some CTTE.  Is there an
according bug documenting the problem?
 
> >So we end up with informal SIGs (to not use "cabals"), and at best a 
> >post to d-devel.
> 
> And that's bad.

If this is really the normal case that would be really bad.  I have the
impression that there are other decisions that are better communicated.

Kind regards from a happy adduser user and thank you for spending so
much time into it
Andreas.

-- 
https://fam-tille.de

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 14:20:45 +0200, Matthias Urlichs
 wrote:
>On 28.04.25 12:56, Marc Haber wrote:
>> Could somebody with an LWN subscription share a friends link?
>
>Subscriptions to LWN are free for DDs, somebody (HP IIRC) sponsors them.

Yes, but it is suggested that the resources are limited, and since I
know that I don't have the round tuits to read LWN at least weekly, I
have decided to leave those resources to people who make better use of
it.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Marc Haber]

On Mon, 28 Apr 2025 14:17:18 +0200, Matthias Urlichs
 wrote:
>I mean, adduser isn't going to be somewhat-obsolete-for-some-usecases 
>(not all of them!) because somebody decided that Marc is a horrible 
>human being and/or his work is and has been completely useless, quite 
>the opposite in fact, but because of externals that prima facie have 
>nothing to do with you personally *or* the quality of your work.

It is still incredibly frustrating. I mean, I KNOW that the
declarative approach is superior for packages, but someone needs to
keep adduser usable for the three digit number of packages that are
sill using it.

And it's different to see the package slowly fade out but to get it
pulled away just because some other maintainer gets his pet feature
implemented and rolled out.

This has happened to me already once when volatile.debian.net went
official and ftpmaster decided that a package that I spent significant
time on wouldn't fit on the org label any more.

In both cases, it is incredibly frustrating to not having known a year
earlier. In the adduser case this is especially bad because I had two
volunteers, newcomers to Debian, contributing to adduser in the last
two years whose work could have made more impact in other parts of
Debian. So, it's not only my work going down the drain, but theirs as
well.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Is it worth spending more time on adduser?

[Aaron Rainbolt]

On Mon, Apr 28, 2025 at 1:43 AM Marc Haber  wrote:
>
> On Sun, 27 Apr 2025 09:49:17 -0500, Aaron Rainbolt
>  wrote:
> >adduser has one very useful piece of functionality useradd doesn't
> >have to my awareness, which my workplace absolutely depends on for
> >hardware we build and sell. That's the ability to execute a "hook
> >script" at user creation (/usr/local/sbin/adduser.local), which can
> >then do bits of user account specific setup that can't be done via the
> >skel mechanism. Yes, we could just write a script that calls useradd
> >and then runs our user setup stuff, but adduser is currently
> >integrated into KDE (the desktop environment our hardware uses), so
> >that when the end user creates a new user account in KDE's settings
> >UI, the hook script is automatically run.
>
> Are you actually sure that KDE uses adduser? adduser as we are talking
> about is a Debianism. The Red Hat World has its own adduser, which is
> totally independent (and also totally incompatible), so I'd advise all
> other programs which should be useful outside the Debian ecosystem to
> not invoke adduser but to resort to standardized tools.

I am very sure, yes. This is the behavior on Ubuntu at least, I assume
on Red Hat-ish systems it calls something different.

> Greetings
> Marc
> --
> 
> Marc Haber |   " Questions are the | Mailadresse im Header
> Rhein-Neckar, DE   | Beginning of Wisdom " |
> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
>

Re: Need advice on architecture exclusion when arch: all packages are involved.

[Simon McVittie]

On Mon, 28 Apr 2025 at 09:11:51 +0900, Charles Plessy wrote:

on my side I have added a --64 option to the `routine-update` script (from the
same-named package) that adds a build-dependency on architecture-is-64-bits,
and plan to do the same for little-endian architectures.


This seems like a sufficiently common situation to encounter that the 
ability to automate it is a useful thing, so thank you for doing this.



I wrote recently that I plan to restrict all the team-maintained r-cran-*
packages to 64-bit, little-endian.  I have delayed that because of worries of
delaying migration of some packages with a mass upload, but...


Please note that we are about halfway through the soft freeze period for 
trixie (2025-04-15 to 2024-05-15), and the release team writes:


new transitions, new versions of packages that are part of
(build-)essential or large/disruptive changes remain inappropriate
— https://release.debian.org/testing/freeze_policy.html#soft

I see from https://bugs.debian.org/release-critical/other/testing.html 
that some of the r-bioc-* and r-cran-* family have been unable to 
migrate to testing. How many of those bugs would be resolved by removing 
their relevant packages from 32-bit and BE architectures, and how many 
are orthogonal?


I am not a release team member, but I suspect that if removals are 
necessary, at the current stage in the release process the release team 
would likely prefer the R/CRAN team to remove only the packages that 
genuinely do not work on 32-bit or BE, plus any packages that depend on 
them and would be broken by their removal. For other removals that are not 
necessary to resolve RC bugs, if it was up to me, I would defer them 
until forky opens. (It is not up to me.)


I see that on #1099927, Rebecca already said some very similar things 
about targeted removals being lower-risk and more appropriate at this 
stage of the release process.


The usual way to research "what would happen if I removed..." is to log 
in to the developer-accessible archive mirror machine 
(coccia.debian.org, aka mirror.ftp-master.debian.org) and run commands 
like for example:


# Architecture: all
dak rm -R -n r-cran-survminer

# Architecture: any
dak rm -R -n r-cran-sparr

At the time of writing, the results of those are that r-cran-survminer 
could be removed without breaking anything else (it's a leaf package) 
but r-cran-sparr could not be removed unless/until r-cran-kernelheaping was 
also removed.


For your convenience, the r-bioc-* and r-cran-* RC bugs currently 
relevant to testing:


* #1103217: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103198: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103227: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103199: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103200: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102189: r-cran-argparser, autopkgtest regressions including 64-bit LE
* #1102589: r-cran-broom.helpers, see below, 32-bit autopkgtest already ignored
* #1102590: r-cran-fansi, see below
* #1100292: r-cran-fastcluster, build-time regressions including 64-bit LE
* #1104158: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104159: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104160: r-cran-testthat, seems i386 specific
* #1099927: r-cran-testthat, already has some useful analysis from Rebecca
* #1103228: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102956: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102345: seems fixed in sid, just needs migration
* #1103369: r-cran-webgestaltr, could be armhf specific
* #1102591: r-cran-units, seems arm{el,hf}-specific

#1104160 seems i386-specific and therefore could be helped by targeted 
32-bit removals.


In #1102591 r-cran-units migration is blocked by autopkgtest regressions 
on arm{el,hf}. At first glance this seems arm{el,hf}-specific and 
therefore could be helped by targeted 32-bit removals.


#1103369 seems possibly armhf-specific and therefore could be helped by 
targeted 32-bit removals, but I would suggest that a maintainer should 
see whether the FTBFS is reproducible on 64-bit LE first (it doesn't 
seem particularly 32-bit-specific).


In #1099927 in r-cran-testthat, migration is blocked by autopkgtest 
regressions on 32-bit architectures (for which architecture-specific 
removals might help) but also by an autopkgtest regression on riscv64 
(which is 64-bit LE, so will be unaffected by your proposed removals).


#1104158 in r-cran-testthat refers to autopkgtest regressions. It seems 
some of those might be fixed in 3.2.3-1? If this is the case, please 
close the bug as fixed in the version in which it is fixed, so that the 
release team can have some visibility into what it will take to get this 
fixed in testing. Migration of r-cran-testthat/3.2.3-1 is blocked by 
#1099927.


#1104159 in r-cran-testtha

Re: Re: Proposal -- Interpretation of DFSG on Artificial Intelligence (AI) Models

[Gunnar Wolf]

Stephan Verbücheln dijo [Mon, Apr 28, 2025 at 03:46:27PM +]:

(...)

The “source code” for a work means the preferred form of the work
for making modifications to it.


In that definition, training data is quite obviously relevant. No one
tweaks neural network model weights manually.

Compare this to the previously mentioned example of S-boxes in
cryptography. They are small and usually created manually.


I understand that, when you consider trained models as the "thing" to be
modified, the preferred form of modification is the model itself: What RAG
does is to have a base trained LLM (confering the "mastery" of language),
and training over it with the domain-specific knowledge.


signature.asc
Description: PGP signature