Re: ITN procedure?

Hello, On Wed, 07 May 2025, Tiago Bortoletto Vaz wrote: > So whatever you call your intention here I guess we should see it with > welcoming eyes. But, if one feels ITN can be somewhat misleading, let's > just try something else: ITR (Intent to Revamp)? > > "to change or arrange something agai

Re: Unable to access to Yubikey after recent GPG changes

On Sat, May 10, 2025 at 10:47:51PM +0200, Yadd wrote: > Found: echo 'disable-ccid' >> ~/.gnupg/scdaemon.conf > > An entry in /usr/share/doc/gnupg/README.Debian could help here There's an entry in /usr/share/doc/gnupg/NEWS.Debian.gz documenting this, which should show up on upgrades: gnupg2 (2.4.

Re: Unable to access to Yubikey after recent GPG changes

Found: echo 'disable-ccid' >> ~/.gnupg/scdaemon.conf An entry in /usr/share/doc/gnupg/README.Debian could help here On 5/10/25 22:39, Yadd wrote: Hi, I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing suc

Re: Unable to access to Yubikey after recent GPG changes

* Yadd [250510 22:39]: I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing succeeded. I'm running a Debian testing. Did someone find a solution ? People on IRC said this yubikey support article helped the

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

Hi, Holger Levsen ezt írta (időpont: 2025. máj. 9., P, 12:56): > > 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+Sals

Re: ITN procedure?

that this is really about moving the package from a strong-maintainer model to a collective-maintainship model, and that is still somewhat controversial. Like Jonas I really don't think re-use of 'NMU' is appropriate here. I wouldn't put it quite as strongly as he did (that se

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

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

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

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

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

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|lay

Re: Intend To Orphan (ITO) procedure?

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

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

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:

Re: Trouble posting to debian-devel

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 t

Re: Trouble posting to debian-devel

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

Re: ITN procedure?

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

Re: Trouble posting to debian-devel

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 ema

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

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 recommenda

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

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

Re: ITN procedure?

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

Re: ITN procedure?

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

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

Hi, On 09-05-2025 03:28, Soren Stoutner wrote: On Thursday, May 8, 2025 4:41:16 PM Mountain Standard Time Antonio Terceiro wrote: We could allow longer timeouts on a per-package basis and on maintainer request, like we handle having packages tested with KVM instead of containers. This would ne

Re: ITN procedure?

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

Re: ITN procedure?

Hi, 在 2025/5/9 02:24, Lucas Nussbaum 写道: > On 08/05/25 at 16:56 +0200, Bálint Réczey wrote: >> I agree with using existing processes and I also appreciate Andreas' >> initiative to improve the state of long-neglected packages. >> >> I believe the ITN name is a bit redundant, since our NMU process

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

On Thursday, May 8, 2025 4:41:16 PM Mountain Standard Time Antonio Terceiro wrote: > We could allow longer timeouts on a per-package basis and on maintainer > request, like we handle having packages tested with KVM instead of > containers. > > This would need the code to actually support this to

Re: Broken in links in Debian History document - old news removed from www.debian.org

On Thu, May 08, 2025 at 10:33:55PM +0200, Holger Wansing wrote: > I think about removing myself from the debian-www team. > Better no longer be part of it, otherwise people might blame me for such > decisions ... Please don't. Breaking things is unavoidable in complex enough systems, and is OK i

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

On Thu, May 08, 2025 at 11:38:35AM -0700, Soren Stoutner wrote: > I have two questions. > > 1. Is there a way to override the 3 hour time limit for Debian CI for a > particular package? No. > 2. Would there be objections to reconsidering the 3 hour default time limit > for all packages? We

Re: ITN procedure?

Le Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum a écrit : > On 08/05/25 at 16:56 +0200, Bálint Réczey wrote: > > I agree with using existing processes and I also appreciate Andreas' > > initiative to improve the state of long-neglected packages. > > > > I believe the ITN name is a bit red

Re: ITN procedure?

On 08/05/25 at 18:50 +, Bill Allombert wrote: > Le Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum a écrit : > > On 08/05/25 at 16:56 +0200, Bálint Réczey wrote: > > > I agree with using existing processes and I also appreciate Andreas' > > > initiative to improve the state of long-neglec

Re: Categorially refusing to exercise DPL powers (was: ITN procedure?)

G. Branden Robinson dijo [Thu, May 08, 2025 at 03:49:08AM -0500]: > > this GR does happen (and I'm confident it will), someone else will be > > DPL. > > In future DPL campaigns, I encourage the electorate to insist that each > candidate disclose which powers of the office they categorically refus

Re: Intend To Orphan (ITO) procedure?

On Thu, May 08, 2025 at 09:01:54PM +0200, Andreas Tille wrote: > 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. fwiw, I think that's great. Thank you! -- chee

Re: ITN procedure?

On 08/05/25 at 16:56 +0200, Bálint Réczey wrote: > I agree with using existing processes and I also appreciate Andreas' > initiative to improve the state of long-neglected packages. > > I believe the ITN name is a bit redundant, since our NMU process with > an upload to a delayed queue already sig

Re: Intend To Orphan (ITO) procedure?

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 mov

Re: ITN procedure?

On Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum wrote: > The developers-reference has this sentence: > > Fixing cosmetic issues or changing the packaging style in NMUs is > > discouraged. > > Maybe it could be changed to: > > Using NMUs to make changes that are likely to be non-consensua

Re: Intend To Orphan (ITO) procedure?

On 2025-05-08 Jonas Smedegaard wrote: > Quoting Andreas Tille (2025-05-08 10:26:08) > > Would it feel more appropriate if I called it ITO (Intent to Orphan) > > instead of ITN and use the 21 days waiting period + upload to > > delayed=10? > Yes, that helps tremendously. > That makes is clear th

Re: Intend To Orphan (ITO) procedure?

Am Thu, May 08, 2025 at 09:35:35PM +0800 schrieb tho...@goirand.fr: > How about a BoF on strong package ownership in Brest? I have registered such a BoF and want to prepend it by a Sprint in DebCamp. See you there Andreas. -- https://fam-tille.de

Re: ITN procedure?

Hi, Holger Levsen ezt írta (időpont: 2025. máj. 8., Cs, 10:38): > > On Thu, May 08, 2025 at 10:26:08AM +0200, Andreas Tille wrote: > > > again, orphaning means doing a QA upload. a gentler path would be an NMU. > > > again, I don't why we need a new process here. > > Orphaning is something typica

Re: Dropping awk?

Le Sun, Apr 20, 2025 at 11:22:04PM +0500, Andrey Rakhmatullin a écrit : > On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote: > > What I'm suggesting here is that if every individual package that needs > > awk has a Depends on it (via a package that allows switching > > implementations),

Re: Intend To Orphan (ITO) procedure?

On May 8, 2025 20:25, Andreas Tille wrote: > > Hi Jonas, > > Am Thu, May 08, 2025 at 11:22:44AM +0200 schrieb Jonas Smedegaard: > > Quoting Andreas Tille (2025-05-08 10:26:08) > > > Orphaning is something typically done by the maintainer themselves[1]. > > > If someone else does it un

Re: Intend To Orphan (ITO) procedure?

Hi Jonas, Am Thu, May 08, 2025 at 11:22:44AM +0200 schrieb Jonas Smedegaard: > Quoting Andreas Tille (2025-05-08 10:26:08) > > Orphaning is something typically done by the maintainer themselves[1]. > > If someone else does it unilaterally, wouldn't that come closer to a > > hijack? There's precede

Re: ITN procedure?

On May 8, 2025 19:46, Jonas Smedegaard wrote: > > Yes, I am quite aware of the appreciation from some maintainers of the > contributions made by Andreas - my criticism is another which goes > beyond appreciative maintainers. I do believe that Andreas' > experiment *also* aims to go beyo

Re: DEP-14: Default branch name 'debian/latest' objections?

On Thu, Jan 23, 2025 at 05:06:04PM -0800, Otto Kekäläinen wrote: > Hi! > > Current https://dep-team.pages.debian.net/deps/dep14/ states that the > default Debian branch name is 'debian/latest': > > > In Debian this means that uploads to unstable and experimental should be > > prepared either in

Re: ITN procedure?

Quoting tho...@goirand.fr (2025-05-08 13:30:17) > > > On May 8, 2025 04:27, Jonas Smedegaard wrote: > > > What do you want those numbers to tell us? That there is nothing > > > invasive about your experimental method and therefore no need to invent > > > new acronyms because NMU is a perfectl

Re: ITN procedure?

On May 8, 2025 04:27, Jonas Smedegaard wrote: > What do you want those numbers to tell us? That there is nothing > invasive about your experimental method and therefore no need to invent > new acronyms because NMU is a perfectly fine descriptor, or that your > method has show efficiency or t

Re: ITN procedure?

fer a gentler path > > that allows space for maintainers to re-engage if they wish. > > again, orphaning means doing a QA upload. a gentler path would be an NMU. > again, I don't why we need a new process here. Orphaning is something typically done by the maintainer themselves[1]

Re: Intend To Orphan (ITO) procedure?

ser > > > in spirit to a QA upload, as Holger suggested. I prefer a gentler path > > > that allows space for maintainers to re-engage if they wish. > > > > again, orphaning means doing a QA upload. a gentler path would be an NMU. > > again, I don't why we ne

Re: ITN procedure?

On Thu, May 08, 2025 at 08:46:35AM +, Holger Levsen wrote: > > I think your reaction to this is a bit harsh. I see this ITN proposal as > > a way how to handle pacakges that are effectively unmaintained, but > > where one is not necessarily interested in becoming the maintainer. > we have a p

Re: ITN procedure?

On Thu, May 08, 2025 at 01:42:34PM +0500, Andrey Rakhmatullin wrote: > On Thu, May 08, 2025 at 08:06:03AM +, Holger Levsen wrote: > > > I think your reaction to this is a bit harsh. I see this ITN proposal as > > > a way how to handle pacakges that are effectively unmaintained, but > > > where

Re: ITN procedure?

On Thu, May 08, 2025 at 08:06:03AM +, Holger Levsen wrote: I think your reaction to this is a bit harsh. I see this ITN proposal as a way how to handle pacakges that are effectively unmaintained, but where one is not necessarily interested in becoming the maintainer. we have a procedure for

Re: ITN procedure?

t an ITO - intent to orphan? Or ITREAO - > > intent to reveal effectively an orphan? > > >From my point of view, orphaning would be a more forceful step--closer > in spirit to a QA upload, as Holger suggested. I prefer a gentler path > that allows space for maintainers

Re: Categorially refusing to exercise DPL powers (was: ITN procedure?)

[follow-ups should probably go to -project; this issue is non-technical] Hi Andreas, Thank you for your prompt follow-up. At 2025-05-08T10:14:57+0200, Andreas Tille wrote: > Am Thu, May 08, 2025 at 02:54:47AM -0500 schrieb G. Branden Robinson: > > At 2025-05-08T09:07:48+0200, Andreas Tille wrote

Re: ITN procedure?

Hi, On 08/05/2025 10:38, Holger Levsen wrote: IMO it would certainly feel appropriate to use*existing processes* instead of inventing new ones*and* excercising them on the archive immediatly prior to wider discussion. Thanks for expressing in three lines the things that are bothering me in th

Re: ITN procedure?

"The information for this listing was last updated on Wed, 22 May 2024." That makes sense because I see m2crypto on this list. Le jeu. 8 mai 2025, 10:38, Holger Levsen a écrit : > > https://qa.debian.org/orphaned.html > >

Re: ITN procedure?

On Thu, May 08, 2025 at 10:26:08AM +0200, Andreas Tille wrote: > > again, orphaning means doing a QA upload. a gentler path would be an NMU. > > again, I don't why we need a new process here. > Orphaning is something typically done by the maintainer themselves[1]. that is true and it's also true t

Re: Categorially refusing to exercise DPL powers (was: ITN procedure?)

Hi Branden, Am Thu, May 08, 2025 at 02:54:47AM -0500 schrieb G. Branden Robinson: > At 2025-05-08T09:07:48+0200, Andreas Tille wrote: > > I don't believe the DPL should initiate GRs. I also think that when ^ > > this GR does happen (and I'm confident it will), someone else will b

Re: ITN procedure?

On Thu, May 08, 2025 at 10:00:10AM +0200, Andreas Tille wrote: > >From my point of view, orphaning would be a more forceful step--closer > in spirit to a QA upload, as Holger suggested. I prefer a gentler path > that allows space for maintainers to re-engage if they wish. again, orp

Re: ITN procedure?

t; intent to reveal effectively an orphan? >From my point of view, orphaning would be a more forceful step--closer in spirit to a QA upload, as Holger suggested. I prefer a gentler path that allows space for maintainers to re-engage if they wish. > In any case, you are talking about invasi

Re: ITN procedure?

On Wed, May 07, 2025 at 07:34:17PM -0300, Antonio Terceiro wrote: > I think your reaction to this is a bit harsh. I see this ITN proposal as > a way how to handle pacakges that are effectively unmaintained, but > where one is not necessarily interested in becoming the maintainer. we have a procedu

Re: ITN procedure?

On Wed, 2025-05-07 at 23:17 -0700, Otto Kekäläinen wrote: > Hi! > > I think Soren and Antonio summarized what I am thinking as well. If > there are seemingly unmaintained packages and we have people who are > willing to take care of them and update/refresh them by doing > something between a small

Re: ITN procedure?

Hi Joost, Am Thu, May 08, 2025 at 05:49:41AM +0200 schrieb Joost van Baal-Ilić: > I'm with Jonas and h01ger here: I don't think the benefits of the current > ITM-prodedure are bigger than the bad side effects. And even more people > voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentor

Re: ITN procedure?

Quoting Otto Kekäläinen (2025-05-08 08:17:27) > I think Soren and Antonio summarized what I am thinking as well. If > there are seemingly unmaintained packages and we have people who are > willing to take care of them and update/refresh them by doing > something between a small NMU and a full-scale

Re: status of packages shipping sysv-init script without systemd unit

Am 7. Mai 2025 22:50:17 MESZ schrieb Vincent Lefevre : >> > Yes, but then, shouldn't the severity be raised (as without >> > a fix, they will no longer work in Trixie)? >> >> Trixie still ships the sysv-generator and we are pretty much in freeze right >> now. >> >> So while I can't speak for Luca

Re: ITN procedure?

Hi! I think Soren and Antonio summarized what I am thinking as well. If there are seemingly unmaintained packages and we have people who are willing to take care of them and update/refresh them by doing something between a small NMU and a full-scale adoption, then that is only positive. On Wed, 7

Re: ITN procedure?

Hi Andreas e.a., [Please Cc me on replies, I'm not subscribed.] I'm with Jonas and h01ger here: I don't think the benefits of the current ITM-prodedure are bigger than the bad side effects. And even more people voiced this opinion, e.g. @ https://wiki.debian.org/DebianMentorsFaq it says: Pleas

Re: ITN procedure?

Hi, On Wed, May 07, 2025 at 07:34:17PM -0300, Antonio Terceiro wrote: > On Wed, May 07, 2025 at 10:27:03PM +0200, Jonas Smedegaard wrote: > > What is your offer? To take over? No, you don't want to do an ITS. > > > > You want to do "help" the maintainer see the light in changing their way > > of

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

Vincent Lefevre writes: > On 2025-05-07 18:18:25 +0200, Simon Josefsson wrote: >> Vincent Lefevre writes: >> >> > On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: >> >> I think a reasonable conservative system policy is PATH=/usr/bin and >> >> anything beyond that is something the user or s

Re: ITN procedure?

Le Wed, May 07, 2025 at 07:34:17PM -0300, Antonio Terceiro a écrit : > Maybe just not calling it an NMU would be a compromise? Indeed there are the team uploads that bypass NMU restrictions under the assumption that the changes are welcome and done with team spirit. It does not require to have a

Re: ITN procedure?

On Wed, May 07, 2025 at 10:27:03PM +0200, Jonas Smedegaard wrote: > What is your offer? To take over? No, you don't want to do an ITS. > > You want to do "help" the maintainer see the light in changing their way > of working themselves, by doing a one-off non-mild "NMU" which is not an > NMU becau

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

On 2025-05-07 18:18:25 +0200, Simon Josefsson wrote: > Vincent Lefevre writes: > > > On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: > >> I think a reasonable conservative system policy is PATH=/usr/bin and > >> anything beyond that is something the user or system administrator have > >> to

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

El 7/5/25 a las 23:33, Simon Josefsson escribió: You could probably say that the "must" only applies to "normal systems", but by using both "should" and "normal" in your characterization of "consensus", you are already deviating two steps from what Policy says. If you think Policy does not really

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

Santiago Vila writes: > El 7/5/25 a las 21:44, Simon McVittie escribió: >> That's not clear. Different developers have different > interpretations of what "packages must build successfully from source" > means - as a minimum they need to be buildable on our official > buildds, but the more differ

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 17:45:51 +0200, Michael Biebl wrote: > Am 07.05.25 um 15:28 schrieb Vincent Lefevre: > > On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote: > > > * Vincent Lefevre [250507 11:06]: > > > > I can see in journalctl output: > > > > > > > > May 07 10:25:13 qaa systemd-sysv-generator

Re: ITN procedure?

On Wednesday, May 7, 2025 10:56:43 AM Mountain Standard Time Jonas Smedegaard wrote: > Quoting Holger Levsen (2025-05-07 18:59:27) > > > On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote: > > > Since you asked: I respectfully find ITN a very bad idea. > > > > +1 I personally thin

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 15:03:40 +, Holger Levsen wrote: > On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote: > > Yes, but then, shouldn't the severity be raised (as without > > a fix, they will no longer work in Trixie)? > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian

Re: ITN procedure?

On Wed, 07 May 2025 17:42:39 +0200, Jonas Smedegaard wrote: If I am mistaken and ITN is only mild one-off contributions same a NMUs then I fail to see a reason for simply doing a 21-day-delayed NMU. Side note: AFAIK, there are DELAYED queues only for 0 to 15 days currently. Cheers, gregor

Re: ITN procedure?

Quoting Andreas Tille (2025-05-07 21:09:36) > Hi Jonas, > > Am Wed, May 07, 2025 at 05:42:39PM +0200 schrieb Jonas Smedegaard: > > > > Since you asked: I respectfully find ITN a very bad idea. > > I intended to ask and thank you for your clearly expressed opinion. > > > ITS is a process where

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

El 7/5/25 a las 21:44, Simon McVittie escribió: That's not clear. Different developers have different interpretations of what "packages must build successfully from source" means - as a minimum they need to be buildable on our official buildds, but the more differences from that we're willing t

Re: status of packages shipping sysv-init script without systemd unit

On May 07, Santiago Vila wrote: Given that there are still 148 open bugs, I would hope systemd maintainers consider not breaking the automatically generated units at this point in the release cycle and do that after the release of trixie instead. Of course! It is clearly too late for this chan

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

On Wed, 07 May 2025 at 20:43:24 +0200, Simon Josefsson wrote: Simon McVittie writes: I hope that packages don't assume that /usr/games is in the PATH at build time in any case. Is it a bug if they do? Buildd's have /usr/games in the default PATH so I don't think we notice now. That's not c

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

On Wed, May 07, 2025 at 08:43:24PM +0200, Simon Josefsson wrote: I think we should give up on /usr/games and move those executables to /usr/bin, renaming any binaries that conflict. This seems somewhat off-topic for a discussion of FTBFS - I hope that packages don't assume that /usr/games is in

Re: ITN procedure?

Hi Jonas, Am Wed, May 07, 2025 at 05:42:39PM +0200 schrieb Jonas Smedegaard: > > Since you asked: I respectfully find ITN a very bad idea. I intended to ask and thank you for your clearly expressed opinion. > ITS is a process where you intend to take over responsibility. Yes. > ITN is a proc

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

Simon McVittie writes: > On Wed, 07 May 2025 at 14:40:01 +0200, Simon Josefsson wrote: >>I think we should give up on /usr/games and move those >>executables to /usr/bin, renaming any binaries that conflict. > > This seems somewhat off-topic for a discussion of FTBFS - I hope that > packages don'

Re: ITN procedure?

Quoting Holger Levsen (2025-05-07 18:59:27) > On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote: > > Since you asked: I respectfully find ITN a very bad idea. > > +1 > > > ITS is a process where you intend to take over responsibility. > > > > ITN is a process where you intend to

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

On Wed, 07 May 2025 at 14:40:01 +0200, Simon Josefsson wrote: I think we should give up on /usr/games and move those executables to /usr/bin, renaming any binaries that conflict. This seems somewhat off-topic for a discussion of FTBFS - I hope that packages don't assume that /usr/games is in t

Re: ITN procedure?

On Wed, May 07, 2025 at 05:42:39PM +0200, Jonas Smedegaard wrote: > Since you asked: I respectfully find ITN a very bad idea. +1 > ITS is a process where you intend to take over responsibility. > > ITN is a process where you intend to put pressure on the existing > maintainer for changing their

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

Vincent Lefevre writes: > On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: >> I think a reasonable conservative system policy is PATH=/usr/bin and >> anything beyond that is something the user or system administrator have >> to add. I think we should give up on /usr/games and move those >> e

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

Am 07.05.25 um 14:40 schrieb Simon Josefsson: Matthias Urlichs writes: On 07.05.25 12:00, Santiago Vila wrote: For example, some configure script might look in the PATH and decide that sh is in /usr/bin and ship shell scripts as #!/usr/bin/sh. That's not a problem, because today's default (

Re: status of packages shipping sysv-init script without systemd unit

Am 07.05.25 um 15:28 schrieb Vincent Lefevre: On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote: * Vincent Lefevre [250507 11:06]: I can see in journalctl output: May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service '/etc/init.d/dictd' lacks a native systemd unit file, auto

Re: ITN procedure?

Quoting Andreas Tille (2025-05-07 17:16:07) > I fully agree that any deviation from our established NMU practices > should be discussed and, ideally, based on shared understanding. I plan > to bring a concrete proposal to the relevant lists in the near future. > In the meantime, feedback and concer

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

On 07/05/2025 02:59, Simon Richter wrote: Hi, On 5/6/25 20:31, Ahmad Khalifa wrote: The problem seems that it is generating a relative path to its own command expanded via PATH, which doesn't work because there is no /share symlink but there is /usr/share/. Perfectly reasonable method to sup

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

Am 07.05.25 um 16:57 schrieb Andrea Pappacoda: Hi, On Wed May 7, 2025 at 12:00 PM CEST, Santiago Vila wrote: AFAIK, the usr-merge was not about moving everything to usr/bin (that's an implementation detail) but about making /bin and /usr/bin equivalent. I had the opposite impression. The goa

Re: status of packages shipping sysv-init script without systemd unit

On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote: > Yes, but then, shouldn't the severity be raised (as without > a fix, they will no longer work in Trixie)? https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service says they are already at pri

Re: ITN procedure?

Hi Phil, Am Wed, May 07, 2025 at 08:23:08AM +0100 schrieb Phil Wyett: > I have seen a number of bug reports over the last few days that detail an > Intent > To NMU (ITN) procedure. Should this not be getting proposed/discussed here? You're absolutely right--thank you for pointing this out. The "

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

Hi, On Wed May 7, 2025 at 12:00 PM CEST, Santiago Vila wrote: AFAIK, the usr-merge was not about moving everything to usr/bin (that's an implementation detail) but about making /bin and /usr/bin equivalent. I had the opposite impression. The goal *is* moving stuff to /usr, as a prerequisite

Re: status of packages shipping sysv-init script without systemd unit

El 7/5/25 a las 15:35, Santiago Vila escribió: If the transitional unit stops working in trixie, does this mean that I should better make an upload for bookworm-proposed-updates and tell the user that they should enable it before upgrading to trixie, so that the upgrade bookworm -> trixie does no

Re: status of packages shipping sysv-init script without systemd unit

El 7/5/25 a las 10:48, Vincent Lefevre escribió: What's the status of such packages? For completeness, they are tracked using this usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service Given that there are still 148 open bugs, I would hope s

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

On 2025-05-07 14:02:15 +0200, Matthias Urlichs wrote: > That's not a problem, because today's default (according to my > /etc/login.defs) is "/usr/local/bin:/usr/bin:/bin" (plus /sbin for root, > plus …/games for non-root), i.e. with the symlinks last. Note that commands may be run via other ways

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

On May 07, Simon McVittie wrote: My understanding is that the compatibility symlinks /bin, /lib* and /sbin in the root directory can never be deleted, and even the least conservative advocates of merged-/usr don't intend to delete them, because they are part of the platform ABI. Correct. --

Re: status of packages shipping sysv-init script without systemd unit

El 7/5/25 a las 12:37, Chris Hofstaedtler escribió: They have open bugs that need fixing. For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039171 Hi. While we are at it, I'd like to have some guidance on a package for which I received one of such bugs. Asked the question here bu

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

On Wed, 07 May 2025 at 15:21:43 +0200, Santiago Vila wrote: El 7/5/25 a las 13:40, Simon Josefsson escribió: I think we need to separate: ... 2) Removing the /bin symlink. ... (I don't think anybody is proposing 2) right now). My understanding is that the compatibility symlinks /bin, /lib*

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

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote: > I think a reasonable conservative system policy is PATH=/usr/bin and > anything beyond that is something the user or system administrator have > to add. I think we should give up on /usr/games and move those > executables to /usr/bin, renaming

Re: status of packages shipping sysv-init script without systemd unit

On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote: > * Vincent Lefevre [250507 11:06]: > > I can see in journalctl output: > > > > May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service > > '/etc/init.d/dictd' lacks a native systemd unit file, automatically > > generating a unit

  1   2   3   4   5   6   7   8   9   10   >