Re: Accepting DEP14?

Hi, A couple of years ago I was thinking about implementing DEP-14 support in gbp, and my idea was that it should be as automatic as possible, with gbp.conf settings adjusting the automagically detected config if necessary. E.g. if it sees master+upstream, it works as before. The presence of pr

Re: Accepting DEP14?

Hi Andrej, Quoting Andrej Shadura (2024-08-17 10:19:57) > A couple of years ago I was thinking about implementing DEP-14 support > in gbp, [...] Please note that you are posting to the d-devel thread about DEP-14 in general, not the debbugs issue about DEP-14 support in git-buildpackage. I sugge

Re: Accepting DEP14?

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > IMO, and from discussions in the Debian Perl Group, the blocker is > the conversion of existing repos, both on salsa (which should be > doable via the API as suggested in the sketches mentioned above) and > also locally for hundreds of de

Bug#1078859: ITP: python-py-vapid -- Simple VAPID header generation library

Package: wnpp Severity: wishlist Owner: Tianyu Chen X-Debbugs-Cc: debian-devel@lists.debian.org, billchenchina2...@gmail.com * Package name: python-py-vapid Version : 1.9.1 Upstream Contact: JR Conlin * URL : https://github.com/web-push-libs/vapid/ * License :

Re: Accepting DEP14?

Hi Chris, Quoting Chris Hofstaedtler (2024-08-17 10:17:19) > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > > IMO, and from discussions in the Debian Perl Group, the blocker is > > the conversion of existing repos, both on salsa (which should be > > doable via the API as suggested in

Re: Accepting DEP14?

Chris Hofstaedtler writes: > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: >> IMO, and from discussions in the Debian Perl Group, the blocker is >> the conversion of existing repos, both on salsa (which should be >> doable via the API as suggested in the sketches mentioned above) and

Re: Re: Accepting DEP14?

> That's correct but the teams I'm working in recommend something > like: > Add the following to the configuration file ~/.gbp.conf or > debian/gbp.conf: Putting per-repository relevant settings into a global config and not into the per-repo config seems to fly into the face of the DEP18

Re: Accepting DEP14?

Am Sat, Aug 17, 2024 at 10:17:19AM +0200 schrieb Chris Hofstaedtler: > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > > IMO, and from discussions in the Debian Perl Group, the blocker is > > the conversion of existing repos, both on salsa (which should be > > doable via the API as sug

Re: Accepting DEP14?

Hello, On Sat, 17 Aug 2024 at 10:52, Andreas Tille wrote: > Any ideas how we can come up with some suggestion that will finally > enable us with some common reopsitory layout that enables automated > conversion from any existing layout. IMHO we should move DEP-14 > forward since having it an op

Re: Accepting DEP14?

Hi On Sat, 17 Aug 2024 at 10:59, Hector Oron wrote: > Thanks for bringing up this topic, I just wanted to share 8-year old > notes, when it was discussed the same topic and kind of acknowledged > at DebConf16: > - https://gobby.debian.org/export/debconf16/bof/gbp (entry > https://gobby.debian.or

Re: Accepting DEP14?

Il 17/08/2024 10:47, Jonas Smedegaard ha scritto: Hi Chris, Quoting Chris Hofstaedtler (2024-08-17 10:17:19) On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: IMO, and from discussions in the Debian Perl Group, the blocker is the conversion of existing repos, both on salsa (which shou

Re: Accepting DEP14?

Quoting Fabio Fantoni (2024-08-17 11:20:01) > Il 17/08/2024 10:47, Jonas Smedegaard ha scritto: > > Hi Chris, > > > > Quoting Chris Hofstaedtler (2024-08-17 10:17:19) > >> On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > >>> IMO, and from discussions in the Debian Perl Group, the blocke

Re: Accepting DEP14?

Am Sat, Aug 17, 2024 at 10:33:58AM +0200 schrieb Chris Hofstaedtler: > > > Add the following to the configuration file ~/.gbp.conf or > > debian/gbp.conf: > > Putting per-repository relevant settings into a global config and > not into the per-repo config seems to fly into the face of the

Re: Accepting DEP14?

On Sat, 17 Aug 2024 10:47:36 +0200, Jonas Smedegaard wrote: > I have in the past found it confusing how to handle it, but now I find > it tolerable (and don't recognize the "better to start from scratch" > judgement), after I figured out (as also hinted at in one of the links > by gregor) that you

Re: Accepting DEP14?

On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote: > My personal preference would be if we make a pristine-tar branch default > since this is what I observed in the wide majority of cases. Note that there are different opionons whether pristine-tar is needed/viable/useful. There is at

Re: Accepting DEP14?

Andrey Rakhmatullin writes: > On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote: >> My personal preference would be if we make a pristine-tar branch default >> since this is what I observed in the wide majority of cases. > > Note that there are different opionons whether pristine-tar

Request for IkiWiki NMU (FTBFS #1074727)

Hi, intrigeri's patch at looks good to me (eyeball test only) I would be very grateful if someone would be prepared to Debian-ize it and NMU IkiWiki (due to be removed from testing this week); I am not able to do any Debian work at th

Re: Request for IkiWiki NMU (FTBFS #1074727)

On Sat, 17 Aug 2024 at 13:13:51 +0100, Jonathan Dowland wrote: > intrigeri's patch at > > looks good to me (eyeball test only) > > I would be very grateful if someone would be prepared to Debian-ize > it and NMU IkiWiki (due to be remo

Re: Strange armel build error

On 2024-08-16 17:46 +0200, Alec Leamas wrote: > > From another perspective: what is the right thing to do in a situation like > this? Trying to hunt down the problem, and thus causing all sorts of noise > like this message? This is what the policy says, but still... > > Or just exclude that arc

Bug#1078908: ITP: lomiri-calendar-app -- Calendar App for Lomiri Operating Environment

Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lomiri-calendar-app Version : 1.0.2 Upstream Contact: UBports Developers * URL : https://gitlab.com/ubports/development/apps/lomiri-calendar-app/ * Licens

Bug#1078910: ITP: golang-github-containous-alice -- Painless middleware chaining for Go

Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-containous-alice Version : 0.0~git20171023.03f45bd-1 Upstream Author : Containous * URL : https://github.com/containous/alice * License : Expat Programming Lang: Go Descripti

Re: Strange armel build error

On 17/08/2024 14:42, Wookey wrote: On 2024-08-16 17:46 +0200, Alec Leamas wrote: From another perspective: what is the right thing to do in a situation like this? Trying to hunt down the problem, and thus causing all sorts of noise like this message? This is what the policy says, but still

Re: Re: Accepting DEP14?

> > Additionally, in my opinion debian/latest is a mistake we should not > > recommend. > > Please elaborate why you consider it a mistake. That's not obvious to > me. "latest" is illnamed. What do you expect to find in a branch thats called debian/latest? Packaging for unstable? For experiment

Re: Accepting DEP14?

Chris Hofstaedtler writes: > "latest" is illnamed. What do you expect to find in a branch thats > called debian/latest? > Packaging for unstable? For experimental? What if both evolve in > parallel? Yes, some packages do that. We discussed this a lot during the drafting of DEP14, and the reason

Re: Re: Accepting DEP14?

Quoting Chris Hofstaedtler (2024-08-17 22:45:59) > > > Additionally, in my opinion debian/latest is a mistake we should > > > not recommend. > > > > Please elaborate why you consider it a mistake. That's not obvious > > to me. > > "latest" is illnamed. Thanks for that (small) elaboration. > W

Re: Re: Accepting DEP14?

On Sat, 17 Aug 2024 at 22:45:59 +0200, Chris Hofstaedtler wrote: > "latest" is illnamed. What do you expect to find in a branch thats > called debian/latest? > > Packaging for unstable? For experimental? For experimental if there's currently a version in experimental (or if there is about to be o

Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

Hello, Anyone not interested in ancient history can skip this mail. On Thu, Aug 15, 2024 at 11:20:47PM +0100, Colin Watson wrote: > On 2024-07-14 (five days before the iproute2 change was made), there was > this conversation on #debian-devel: > > 19:14 Is there a reason why iproute2 ships a s

Re: Strange armel build error

On 2024-08-17 17:58 +0200, Alec Leamas wrote: > > > Fair enough. But TBH, i just cannot wait "a couple of weeks" for a possible > reply; there are users waiting for the backports as I write. Fair enough. If you can't wait then you can't wait. > To make it more interesting, the simple -latomic