Re: Questions about hard freeze and autopkgtests

Hi, It works: https://tracker.debian.org/news/1646860/accepted-python-flask-seeder-120-6-source-into-unstable/ https://tracker.debian.org/pkg/python-flask-seeder So in this case the Release Team doesn't need manual work here and can spend time on something else. I bumped the bug now to av

Re: My personal recommendation on how to create Debian packages from upstream Git

Hi Holger, Holger Levsen writes: > On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote: >> If you suggest that using "debian/latest" should *not* be done by >> default, then it seems that requires reverting changes to DEP-14. > > yes. dep14 currently says "that uploads to unstable a

Re: My personal recommendation on how to create Debian packages from upstream Git

Hi, On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote: > > thanks for writing the two most comprehensive docs about packaging, git and > gbp I have read in the last years. > Impressive work. +1 ! > On Wed, May 28, 2025 at 06:36:00AM -0700, Otto Kekäläinen wrote: > > in > > particular

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On Wed, May 28, 2025 at 01:53:21PM +0200, Julien Plissonneau Duquène wrote: Le 2025-05-27 20:30, Ahmad Khalifa a écrit : they all have a Database data model (faster search/query) Having some experience with databases, I'm not convinced that a RDBMS (SQL) is a necessity here. Better indexing a

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On Wed, May 28, 2025 at 02:22:00PM +, Holger Levsen wrote: Most of these I also very much agree with, however I doubt that *we* want to hide e-mail addresses from public (unauthenticated) web browsing. In my book the open development model of Debian is tied to the fact that we the developers

Re: Questions about hard freeze and autopkgtests

On Wed, 28 May 2025 at 17:06:52 -0400, Richard Hansen wrote: * What does "autopkgtest bounty" mean in the table at ? When we aren't in a freeze, packages with successful non-superficial autopkgtests migrate sooner than packages w

Re: My personal recommendation on how to create Debian packages from upstream Git

On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote: > If you suggest that using "debian/latest" should *not* be done by > default, then it seems that requires reverting changes to DEP-14. yes. dep14 currently says "that uploads to unstable and experimental should be prepared either

Re: My personal recommendation on how to create Debian packages from upstream Git

On Wed, May 28, 2025 at 10:05:44PM +, Holger Levsen wrote: > I appreciate and applaus Otto's posts too, but can we please agree on > debian/unstable, debian/experimental, debian/trixie, ... as our *default*? > while still "allowing" debian/latest and and also debian/3.11 and > debian/3.12 and

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On Wed, 28 May 2025 16:08:56 +0100, Ahmad Khalifa wrote: Can you expand on why you think manipulating bugs by mail is a security flaw? Anyone can manipulate any bug without restriction and in bulk. Right, and that's a feature not a bug (and for sure not a "security flaw"). Maybe I'm exagg

Bug#1106739: ITP: emacs-wfnames -- A mode to edit filenames in Emacs

Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-wfnames Version : 1.2 Upstream Author : Thierry Volpiatto * URL or Web page : https://github.com/thierryvolpiatto/wfnames * License : GPL-3+ Programming lang: Emacs Lisp Description : A mode

Re: My personal recommendation on how to create Debian packages from upstream Git

Quoting Holger Levsen (2025-05-29 00:05:44) > On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote: > > does it make sense to work in debian/latest and only last before pushing for > > review create another branch next/debian/latest? I'd always intuitively work > > in next/debian/latest direc

Re: My personal recommendation on how to create Debian packages from upstream Git

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote: > does it make sense to work in debian/latest and only last before pushing for > review create another branch next/debian/latest? I'd always intuitively work > in next/debian/latest directly. I appreciate and applaus Otto's posts too, bu

Questions about hard freeze and autopkgtests

I have a couple of questions regarding the hard freeze and packages with and without autopkgtests: * What does "autopkgtest bounty" mean in the table at ? * If I add a non-superficial autopkgtest to a package that currently

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

Julien Plissonneau Duquène writes: > I'm considering getting my hands into that thing later this year, so > let me try to summarize the relevant parts of the previous threads > (with the intent of documenting this in a wiki page). this is awesome > We would like debbugs to: > 0. keep all the e-

Re: My personal recommendation on how to create Debian packages from upstream Git

Hi Otto, thanks for writing the two most comprehensive docs about packaging, git and gbp I have read in the last years. I even tried writing some. Will stop doing that now that your docs exist. Impressive work. I have some comments though. On Wed, May 28, 2025 at 06:36:00AM -0700, Otto Kekäl

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On May 28, Ahmad Khalifa wrote: Anyone can manipulate any bug without restriction and in bulk. Untag it as RC, email 0-9 with the -done suffix, spam it with links, target packages that echo to a mailing list. Security measures should be proportional to the specific threat, and we actually

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On 28/05/2025 12:53, Julien Plissonneau Duquène wrote: Le 2025-05-27 20:30, Ahmad Khalifa a écrit : On 27/05/2025 17:46, Julien Plissonneau Duquène wrote: 0. keep all the e-mail features it currently offers IMHO, this is a security flaw, not a feature. I hear that everyone loves it, so at l

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On 28/05/2025 12:11, Jonathan Dowland wrote: On Tue May 27, 2025 at 7:30 PM BST, Ahmad Khalifa wrote: 0. keep all the e-mail features it currently offers IMHO, this is a security flaw, not a feature. I hear that everyone loves it, so at least the emails should be authenticated somehow (@debi

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

Hi Julien, thanks and applause for this initiative of yours! I agree the bts could see several improvements..! On Tue, May 27, 2025 at 06:46:29PM +0200, Julien Plissonneau Duquène wrote: > We would like debbugs to: > 0. keep all the e-mail features it currently offers > 1. process new requests an

My personal recommendation on how to create Debian packages from upstream Git

Hi, In my experience many of the discussions about packaging workflows on this list have many misconceptions, which in turn I think stems from that our tools are a bit challenging to use, and the documentation is somewhat lacking. Many tend to struggle to figure out how to do something, and once t

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On 28/05/25 at 13:53 +0200, Julien Plissonneau Duquène wrote: > > they all have a Database data model (faster search/query) > > Having some experience with databases, I'm not convinced that a RDBMS (SQL) > is a necessity here. Better indexing and caching would definitely help > though. Even if I'

Re: Dependency merging in APT

On Wed, May 28, 2025 at 10:20:34AM +0100, Simon McVittie wrote: > On Wed, 28 May 2025 at 10:33:26 +0200, Julian Andres Klode wrote: > > gnupg Depends: gpg (>= 2.4.7-19) overlaps Depends: gpg (<< 2.4.7-19.1~) > > - solutions: ['gpg=2.4.7-19'] > > - eliminated: [] ['gpg-from-sq=0.13.1-3'] > > > >

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On Wed, May 28, 2025 at 01:53:21PM +0200, Julien Plissonneau Duquène wrote: 1. process new requests and give feedback instantly My opinion now is that debbugs runs pretty frequently, but emails get rejected randomly, leading to a 30min wait for mail queue reruns. This is probably a mail serve

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On 27/05/2025 21:59, Lucas Nussbaum wrote: - add a new field that allows pointing to a merge request (similar to the 'forwarded' field) My intuition is that there are cases where we would like to link several merge requests (possibly in different repositories) to a single bug. - have a b

Re: new contributor annoyances (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On 28/05/2025 00:25, tho...@goirand.fr wrote: Please do contribute this upstream, so we get it on our next upgrade ! Yes, that's also a possibility. Cheers, -- Julien Plissonneau Duquène

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

Le 2025-05-27 20:30, Ahmad Khalifa a écrit : On 27/05/2025 17:46, Julien Plissonneau Duquène wrote: 0. keep all the e-mail features it currently offers IMHO, this is a security flaw, not a feature. I hear that everyone loves it, so at least the emails should be authenticated somehow (@debia

Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)

On Tue May 27, 2025 at 7:30 PM BST, Ahmad Khalifa wrote: 0. keep all the e-mail features it currently offers IMHO, this is a security flaw, not a feature. I hear that everyone loves it, so at least the emails should be authenticated somehow (@debian only maybe? one-time register-confirm email

Re: Dependency merging in APT

On Wed, 28 May 2025 at 10:33:26 +0200, Julian Andres Klode wrote: gnupg Depends: gpg (>= 2.4.7-19) overlaps Depends: gpg (<< 2.4.7-19.1~) - solutions: ['gpg=2.4.7-19'] - eliminated: [] ['gpg-from-sq=0.13.1-3'] Where gpg-from-sq would be considered a valid solution for the << depends as it prov

Dependency merging in APT

Hi all, yesterday I enabled a new feature in APT's new solver, where it takes overlapping dependencies from a package and merges them to their intersection. In particular this addresses the problem with version ranges and versioned provides such as: gnupg Depends: gpg (>= 2.4.7-19) overlaps Depe