Re: How should Debian CI handle autopkgtests that require more than three hours

[Soren Stoutner]

On Thursday, May 8, 2025 11:31:41 PM Mountain Standard Time Paul Gevers wrote:
> An alternative that can be done now: the timeout of 2:47h is per test 
> stanza in d/t/control (see autopkgtest(1). For some test suites it's not 
> hard to split the test suite over multiple stanza. The overal timeout is 
> 8.5h (except on riscv64 where it's currently doubled).

Thank you for that information.  I did not know that there were separate 
timeouts for individual stanzas vs. the entire test suite.  I think I should 
be able to split my tests into separate stanzas and I expect the overall 
timeout of 8.5h should be sufficient for anything I am currently working on.

There might be other packages for which this is still not sufficient, but for 
me I don’t think any other adjustments are necessary.

-- 
Soren Stoutner
so...@debian.org

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

Trouble posting to debian-devel

[Antonio Russo]

Hello all,

I tried to post to this list two times yesterday morning.

Roughly, the content was about a security issue.  Neither post
was rejected, nor did I receive a bounce, but it did not show
up on the list.

I'm not repeating the content of that email, since I'm not sure
if the content is the reason that email was rejected.

I also contacted listermas...@lists.debian.org and have received
no response.

In the unlikely event that this email gets through, I'll try
posting the actual issue again, but there remains an issue
of the flakiness of the list and rejecting emails silently.

Best,
Antonio

Re: ITN procedure?

[Jonas Smedegaard]

Quoting Lucas Nussbaum (2025-05-09 09:40:38)
> On 09/05/25 at 06:10 +0200, Andreas Tille wrote:
> > Am Thu, May 08, 2025 at 09:56:47PM +0200 schrieb Lucas Nussbaum:
> > > > The point of this sentence is to define what is non-consensual in the
> > > > first place. Changing the packaging style means the NMU diff will be
> > > > difficult to review.
> > > 
> > > It don't think that it's about the ability to review the diff.
> > 
> > The goal of the Bug of the Day initiative--through which the mentioned
> > NMUs were prepared--is to reduce packaging smells[1], which are:
> > 
> >   1. Debhelper compatibility level: lower than 9 is a smell (we set 13)
> >   2. Build system: not using dh is a smell.
> >   3. Source format and patch system: not using 3.0 is a smell
> >   4. VCS: not using Git and Salsa is a smell (except if the package is 
> > using dgit).
> > 
> > > If a NMU involves changing the packaging style _and_ making other changes,
> > > it's also possible to publish the changes somewhere as a serie of patches
> > > rather than as a single patch.
> > 
> > Fixing item 4 provides a well-known and convenient way to publish all
> > patches, along with build logs automatically generated by Salsa CI.
> 
> I'm obviously a bit biaised since I authored trends.debian.net and thus
> arbitrarily decided of that list of « smells ». I agree with you that the
> first three items are things that it is reasonable to fix in an NMU
> (except in special cases, for example if the package is team-maintained,
> and the the team standardizes on using cdbs or source format 1.0).
> 
> However, I have doubts about (4), since there's still so many different
> workflows to use Git+Salsa.
> 
> Also, while (1-3) are things that can be worked on, sent to DELAYED/x,
> and cancelled if the maintainer disagrees, one cannot really do the same
> with switching to Git.

I find it smelly when a team-maintained package lacks individuals within
that team being responsible for the package, and worry if pushing smelly
lone-hero-maintained packages to be team-maintained just shifts the
flavor of smells.

@Lucas: Since you are apparently the judge on odours in Debian, would
you find it sensible to introduce tracking of team-maintained packages
where most recent uploads were done by non-Uploaders?

(yes, I am aware that some teams might disagree with that being a smell,
but that's already the case with current smells!)

 - 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

Re: Trouble posting to debian-devel

[Daniel Gröber]

Hi Antonio,

On Fri, May 09, 2025 at 08:31:22AM -0600, Antonio Russo wrote:
> I'd also like to confirm there is a policy (or at least agreement)
> that running code as root unnecessarily is a problem. 

Quoting https://release.debian.org/trixie/rc_policy.txt :

In addition to the issues listed in this document, an issue is release
critical if it:

* introduces a security hole on systems where you install the
  packages
  (these issues are "critical" severity)

5. General

  (b) Security

Programs must be setup to use the minimum privileges they can. (ie,
not setuid where setgid will suffice; not setuid root where setuid
some other user will suffice; setuid root for the minimum period
possible, etc)

> I bring that up because I'm concerned that the bug I filed may go
> ignored.

You need to tag security bugs as 'security' in reportbug. Then they get
CCed to the right people and won't be ignored.

You can do this after the fact by responding to the bug, adding
secur...@debian.org to CC and putting the following in the first lines of
your mail to add the tag:

Control: tags -1 + security

Ideally you should explain in your message what the security impact of this
bug is in your view.

Thanks,
--Daniel


signature.asc
Description: PGP signature

Re: FTBFS when /bin is before /usr/bin in PATH?

[Vincent Lefevre]

On 2025-05-08 03:08:17 +0200, Simon Josefsson wrote:
> I challenge that may be pre-mature optimization:
> 
> jas@kaka:~$ ls /usr/bin/|wc -l
> 4675
> jas@kaka:~$ ls /usr/games/|wc -l
> 21
> jas@kaka:~$ 

Indeed. I thought that there were a lot more in /usr/games.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Re: Intend To Orphan (ITO) procedure?

[Andreas Metzler]

On 2025-05-08 Andreas Tille  wrote:
> Hi,

> Am Thu, May 08, 2025 at 06:48:33PM +0200 schrieb Andreas Metzler:
> > It
> > just hides the fact that they are unmaintained and makes it therefore
> > harder to find stuff that should be orphaned and/or removed.

> Just a short comment: In the Bug of the Day effort the majority of
> packages will be moved into team maintenance using the ITS procedure or
> packages removed via (pre-)removal bugs.

Hello,

How do you go about that? Do you poll the respective team whether they
are committing to maintain it?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

/usr/games usage (Re: FTBFS when /bin is before /usr/bin in PATH?)

[Holger Levsen]

On Fri, May 09, 2025 at 07:15:03PM +0200, Vincent Lefevre wrote:
> > jas@kaka:~$ ls /usr/games/|wc -l
> > 21
> Indeed. I thought that there were a lot more in /usr/games.

$ apt-file search /usr/games|wc -l
1184


-- 
cheers,
Holger

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

No future.


signature.asc
Description: PGP signature

Re: FTBFS when /bin is before /usr/bin in PATH?

[The Wanderer]

On 2025-05-09 at 13:15, Vincent Lefevre wrote:

> On 2025-05-08 03:08:17 +0200, Simon Josefsson wrote:
>
>> I challenge that may be pre-mature optimization:
>> 
>> jas@kaka:~$ ls /usr/bin/|wc -l
>> 4675
>> jas@kaka:~$ ls /usr/games/|wc -l
>> 21
>> jas@kaka:~$ 
> 
> Indeed. I thought that there were a lot more in /usr/games.

It may depend on exactly what has and has not been installed.

$ apt-file search /usr/games/ | wc -l
1353

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

RFC for changes regarding NMU in developers reference (Was: ITN procedure?)

[Andreas Tille]

Hi Lucas,

Am Fri, May 09, 2025 at 09:40:38AM +0200 schrieb Lucas Nussbaum:
> > > If a NMU involves changing the packaging style _and_ making other changes,
> > > it's also possible to publish the changes somewhere as a serie of patches
> > > rather than as a single patch.
> > 
> > Fixing item 4 provides a well-known and convenient way to publish all
> > patches, along with build logs automatically generated by Salsa CI.
> 
> I'm obviously a bit biaised since I authored trends.debian.net and thus
> arbitrarily decided of that list of « smells ».

I confirm I'm sharing the same bias.

> I agree with you that the
> first three items are things that it is reasonable to fix in an NMU
> (except in special cases, for example if the package is team-maintained,
> and the the team standardizes on using cdbs or source format 1.0).

ACK for exceptions that would violate team policy.
 
> However, I have doubts about (4), since there's still so many different
> workflows to use Git+Salsa.

Which brings us back to DEP-14 as a baseline recommendation that can
help reduce friction. While individual workflows vary, having some
repository is a precondition for any collaboration--and DEP-14 provides a
neutral, widely accepted starting point.
 
> Also, while (1-3) are things that can be worked on, sent to DELAYED/x,
> and cancelled if the maintainer disagrees, one cannot really do the same
> with switching to Git.

Strictly speaking, there is nothing that prevents a maintainer from
reverting such a change post-NMU, for example by doing:

sed -i '/^Vcs.*salsa/d' debian/control
dch "Revert move to Salsa from latest NMU"

This wouldn't be the first time a change from an NMU is reverted--and
that's fine; the same applies to any patch in DELAYED/x. That said,
creating a repository and pushing history carries a higher level of
responsibility. If such a change is made, the NMUer should be expected
to adapt the repository layout to the maintainer's preferred workflow,
if known--just as they are already responsible for avoiding regressions.
And if the maintainer reverts the move to Salsa, the NMUer should ensure
that the unwanted repository is subsequently removed.

Moreover, we could explicitly recommend the repository be created using
minimal assumptions--i.e., DEP-14 layout, no forced CI setup, no changes
to packaging workflows--and clearly documented to ease handover or
rollback.


I followed Holger's suggestion and created a merge request[1],
splitting the changes into separate commits based on their level of
controversy so each can be discussed individually.

Kind regards
Andreas.

[1] https://salsa.debian.org/debian/developers-reference/-/merge_requests/68/

-- 
https://fam-tille.de

Re: Trouble posting to debian-devel

[Antonio Russo]

On 2025-05-09 08:20, Boyuan Yang wrote:


Just a reminder: if you are trying to report a sensitive security
issue: DO NOT post on debian-devel or other public mailing lists
to avoid disclosing it to the public in an unwanted way.
Please contact Debian Security Team via secur...@debian.org .

If it is about some generic technical discussion, using debian-devel
is suitable.


So, my mail is definitely being blocked based on the content.  I wont
name the specific package, but it involves running code as root that
does not need to be, because a systemd user unit is being started for
the root user.  I really don't think hiding the details (in this
specific case) protects anybody, and honestly I think it reduces
everyone's safety.

The reason I want to post this to debian-devel is because I'd like to
discuss a generic approach to ensuring that systemd user units that
are inappropriate for privileged users to start.

In particular, I'm advocating for some systemd target that would
Conflicts= with units that would have ConditionUser=!root so that
administrators could easily prevent things like drkonqi from starting
in sensitive user sessions.

I'd also like to confirm there is a policy (or at least agreement)
that running code as root unnecessarily is a problem.  I bring that
up because I'm concerned that the bug I filed may go ignored.

Best,
Antonio

Re: Trouble posting to debian-devel

[Boyuan Yang]

Hi,

在 5/9/2025 9:17 AM, Antonio Russo 写道:

Hello all,

I tried to post to this list two times yesterday morning.

Roughly, the content was about a security issue.  Neither post
was rejected, nor did I receive a bounce, but it did not show
up on the list.

I'm not repeating the content of that email, since I'm not sure
if the content is the reason that email was rejected.

I also contacted listermas...@lists.debian.org and have received
no response.

In the unlikely event that this email gets through, I'll try
posting the actual issue again, but there remains an issue
of the flakiness of the list and rejecting emails silently.


Just a reminder: if you are trying to report a sensitive security
issue: DO NOT post on debian-devel or other public mailing lists
to avoid disclosing it to the public in an unwanted way.
Please contact Debian Security Team via secur...@debian.org .

If it is about some generic technical discussion, using debian-devel
is suitable.

If you have some uncertainty about security in everyday usage, please
use https://lists.debian.org/debian-user/ .

Best,
Boyuan Yang


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFC for changes regarding NMU in developers reference (Was: ITN procedure?)

[Lucas Nussbaum]

On 09/05/25 at 10:27 +0200, Andreas Tille wrote:
> > However, I have doubts about (4), since there's still so many different
> > workflows to use Git+Salsa.
> 
> Which brings us back to DEP-14 as a baseline recommendation that can
> help reduce friction. While individual workflows vary, having some
> repository is a precondition for any collaboration--and DEP-14 provides a
> neutral, widely accepted starting point.

Err, the current state of things is that DEP-14 is still in CANDIDATE
state, and I read the last thread on this topic as unconclusive[0].

[0] https://lists.debian.org/debian-devel/2025/01/msg00080.html

So I wouldn't say that is "widely accepted".

I would love to see data about the actual acceptance of DEP-14 among
packages in the archive: my feeling is that it is currently being a bit
ignored by maintainers and teams (but maybe I'm wrong).

Lucas

Re: ITN procedure?

[Andreas Tille]

Am Fri, May 09, 2025 at 10:22:02AM +0200 schrieb Jonas Smedegaard:
> I find it smelly when a team-maintained package lacks individuals within
> that team being responsible for the package, and worry if pushing smelly
> lone-hero-maintained packages to be team-maintained just shifts the
> flavor of smells.

I agree that this is a problem in some teams.
 
> @Lucas: Since you are apparently the judge on odours in Debian, would
> you find it sensible to introduce tracking of team-maintained packages
> where most recent uploads were done by non-Uploaders?

As far as I understood the trends graphs are based on lintian-tags
and I'm not aware of an according tag tracking this.

Kind regards
Andreas. 

-- 
https://fam-tille.de

Re: ITN procedure?

[Lucas Nussbaum]

On 09/05/25 at 06:10 +0200, Andreas Tille wrote:
> Am Thu, May 08, 2025 at 09:56:47PM +0200 schrieb Lucas Nussbaum:
> > > The point of this sentence is to define what is non-consensual in the
> > > first place. Changing the packaging style means the NMU diff will be
> > > difficult to review.
> > 
> > It don't think that it's about the ability to review the diff.
> 
> The goal of the Bug of the Day initiative--through which the mentioned
> NMUs were prepared--is to reduce packaging smells[1], which are:
> 
>   1. Debhelper compatibility level: lower than 9 is a smell (we set 13)
>   2. Build system: not using dh is a smell.
>   3. Source format and patch system: not using 3.0 is a smell
>   4. VCS: not using Git and Salsa is a smell (except if the package is using 
> dgit).
> 
> > If a NMU involves changing the packaging style _and_ making other changes,
> > it's also possible to publish the changes somewhere as a serie of patches
> > rather than as a single patch.
> 
> Fixing item 4 provides a well-known and convenient way to publish all
> patches, along with build logs automatically generated by Salsa CI.

I'm obviously a bit biaised since I authored trends.debian.net and thus
arbitrarily decided of that list of « smells ». I agree with you that the
first three items are things that it is reasonable to fix in an NMU
(except in special cases, for example if the package is team-maintained,
and the the team standardizes on using cdbs or source format 1.0).

However, I have doubts about (4), since there's still so many different
workflows to use Git+Salsa.

Also, while (1-3) are things that can be worked on, sent to DELAYED/x,
and cancelled if the maintainer disagrees, one cannot really do the same
with switching to Git.

Lucas

Re: RFC for changes regarding NMU in developers reference (Was: ITN procedure?)

[Holger Levsen]

On Fri, May 09, 2025 at 12:43:54PM +0200, Lucas Nussbaum wrote:
> On 09/05/25 at 10:27 +0200, Andreas Tille wrote:
> > > However, I have doubts about (4), since there's still so many different
> > > workflows to use Git+Salsa.

same here.

> > Which brings us back to DEP-14 as a baseline recommendation that can
> > help reduce friction. While individual workflows vary, having some
> > repository is a precondition for any collaboration--and DEP-14 provides a
> > neutral, widely accepted starting point.
> Err, the current state of things is that DEP-14 is still in CANDIDATE
> state, and I read the last thread on this topic as unconclusive[0].

that, both, plus the fact that DEP-14 does not recommend one specific
workflow, but several.
 

-- 
cheers,
Holger

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

More and more people seem to forget that SARS-CoV-2 infection can cause
memory impairment.


signature.asc
Description: PGP signature