Le 2025-05-14 20:52, Otto Kekäläinen a écrit :
The `gbp.conf` field `upstream-vcs-tag` (e.g. `upstream-vcs-tag =
v%(version%~%-)s`) could probably be added as a new upstream metadata
field if Jelmer and Guido agree on what to call it and how to roll it
out in a backwards compatible way.
(...)
T
On Fri, 16 May 2025 16:07:47 +0200, Julien Plissonneau Duquène wrote:
Le 2025-05-12 15:04, Lucas Nussbaum a écrit :
Regarding "I don't want a gbp.conf", I think that we should aim for
DRY,
and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or t
On May 14, PICCA Frederic-Emmanuel
wrote:
Despite this, it is good practice to
not push any upstream branch to the packaging repository so as to not
confuse anyone about the purpose of the Git repository.
This kind of personal opinions proposed as if they were the consensus
are the reason wh
Le 2025-05-12 15:04, Lucas Nussbaum a écrit :
Regarding "I don't want a gbp.conf", I think that we should aim for
DRY,
and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or thousands of packages...
Could having a way to manage "team defaults"
+Jelmer, who is the maintainer of the metadata specification
> https://wiki.debian.org/UpstreamMetadata
>
> That's pretty much where we are now. This was done in the pre-Salsa time, and
> if people get excited about the concept, I guess that Salsa offers new
> opportunities to play with the conce
Le Wed, May 14, 2025 at 10:59:48AM +0200, PICCA Frederic-Emmanuel a écrit :
>
> d/upstream/metadata (what for ?)
Hi!
When I created debian/upstream.metadata I intended that would contain metadata
that is not required for package building and that can change or grow
independently of the source co
Hello,
On Wed 14 May 2025 at 11:29am +02, Simon Josefsson wrote:
> PICCA Frederic-Emmanuel
> writes:
>
>>> There is the Source field in d/copyright where you can put a git remote
>>> URL. Maybe that usage should go into DEP-14 ?
>>
>> So we have upstream informations in
>>
>> d/copyright
>> d/c
> debian/upstream/metadata, Repository field.
>
> For example try `gbp clone --add-upstream-vcs vcsgit:sdl2-compat` which
> uses this field. To make `gbp clone` do this automatically whenever this
> information is available, you can write
>
> [DEFAULT]
> add-upstream-vcs = True
>
> into ~/.gbp.c
On 14/05/2025 10:33, Andrius Merkys wrote:
Yes, there was such an effort advocated by one person, but I cannot
recall any details about it to help locating it.
Best,
Andrius
Was that debputy?
https://salsa.debian.org/debian/debputy
Regards,
Peter
On Wed, May 14, 2025 at 12:33:49PM +0300, Andrius Merkys wrote:
On 2025-05-14 12:29, Simon Josefsson wrote:
Indeed this is a mess. (I wouldn't count d/control Vcs-* though?)
d/control has Homepage as well.
Has there been any work towards a single-file declarative file syntax to
generate all
Hi,
On 14 May 2025 09:29:23 UTC, Simon Josefsson wrote:
>PICCA Frederic-Emmanuel
>writes:
>
>>> There is the Source field in d/copyright where you can put a git remote
>>> URL. Maybe that usage should go into DEP-14 ?
>>
>> So we have upstream informations in
>>
>> d/copyright
>> d/control (git
On Wed, 14 May 2025 at 09:47:18 +0100, Sean Whitton wrote:
On Wed 14 May 2025 at 10:41am +02, PICCA Frederic-Emmanuel wrote:
So where do we put the upstream git URL
If I read this part of DEP-14, I have the information that the remote should
be named 'upstreamvcs' but nothing about where to put
On 2025-05-14 12:29, Simon Josefsson wrote:
Indeed this is a mess. (I wouldn't count d/control Vcs-* though?)
d/control has Homepage as well.
Has there been any work towards a single-file declarative file syntax to
generate all the debian/ files?
Yes, there was such an effort advocated by
PICCA Frederic-Emmanuel
writes:
>> There is the Source field in d/copyright where you can put a git remote
>> URL. Maybe that usage should go into DEP-14 ?
>
> So we have upstream informations in
>
> d/copyright
> d/control (git url of our VCS).
> d/watch (in git mode)
> d/upstream/metadata (wha
> There is the Source field in d/copyright where you can put a git remote
> URL. Maybe that usage should go into DEP-14 ?
So we have upstream informations in
d/copyright
d/control (git url of our VCS).
d/watch (in git mode)
d/upstream/metadata (what for ?). maybe we should standardize on this on
>>> Well, git-debrebase does, and is as compliant with DEP-14 as you'd like
>>> it to be.
>>
>> There is gbp pq, which is probably more widely used.
>
> Right. Both are good.
In fact my question was more.
I would like, something like
dgit clone
or
gbp clone
and get a a DEP-14 organized re
Hello,
On Wed 14 May 2025 at 10:41am +02, PICCA Frederic-Emmanuel wrote:
Well, git-debrebase does, and is as compliant with DEP-14 as you'd like
it to be.
>>>
>>> There is gbp pq, which is probably more widely used.
>>
>> Right. Both are good.
>
> In fact my question was more.
>
> I wo
On May 13, 2025 16:37, Johannes Schauer Marin Rodrigues
wrote:
>
> Quoting Andrey Rakhmatullin (2025-05-12 12:29:40)
> > On Mon, May 12, 2025 at 11:58:45AM +0200, Santiago Vila wrote:
> > >El 12/5/25 a las 9:49, Holger Levsen escribió:
> > >>I dont want to use git-buildpackage and I don
On Mon, May 12, 2025 at 02:37:18PM -0700, Otto Kekäläinen wrote:
Using gbp pq is easy, and it is also backwards compatible with quilt,
and automatically uses DEP-3 headers
(some of them)
--
WBR, wRAR
signature.asc
Description: PGP signature
Sorry but most of this looks like expanding on what I've said but maybe
I've misunderstood something.
--
WBR, wRAR
signature.asc
Description: PGP signature
Quoting Andrey Rakhmatullin (2025-05-12 12:29:40)
> On Mon, May 12, 2025 at 11:58:45AM +0200, Santiago Vila wrote:
> >El 12/5/25 a las 9:49, Holger Levsen escribió:
> >>I dont want to use git-buildpackage and I don't want a gpb.conf. Please
> >>accept
> >>this. Thanks.
> >
> >I also don't like the
> > >> debian/README.source as described in the developers-reference.
> > >
> > > It would be great also to have an easy way to cherry peak from the
> > > upstream
> > > git repository in order to prepare patch series.
> > >
> > > Do we have a tool around DEP-14, which allows this ?
> >
> > Well,
> >Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
> >and that adding a gbp.conf in every package doesn't sound too great for
> >teams that maintain hundreds or thousands of packages...
>
> Yes, please.
That could have been an option 10 years ago when people were creating
On Mon, 12 May 2025 15:04:38 +0200, Lucas Nussbaum wrote:
Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or thousands of packages...
Yes, please.
Cheers,
gregor, who
Hello,
On Mon 12 May 2025 at 03:04pm +02, Lucas Nussbaum wrote:
> On 12/05/25 at 07:49 +, Holger Levsen wrote:
>> > Regardless of what branch names packages use today or in the future,
>> > they should all have a debian/gbp.conf file that defines what branches
>> > and packaging practices are
On 12/05/25 at 07:49 +, Holger Levsen wrote:
> > Regardless of what branch names packages use today or in the future,
> > they should all have a debian/gbp.conf file that defines what branches
> > and packaging practices are being used *right now*.
>
> I dont want to use git-buildpackage and I
Hello,
On Mon 12 May 2025 at 01:27pm +02, Bálint Réczey wrote:
> Hi,
>
> Sean Whitton ezt írta (időpont: 2025. máj.
> 12., H, 13:11):
>>
>> Hello,
>>
>> On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>>
>> >> debian/README.source as described in the developers-reference.
>> >
Hi,
Sean Whitton ezt írta (időpont: 2025. máj.
12., H, 13:11):
>
> Hello,
>
> On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>
> >> debian/README.source as described in the developers-reference.
> >
> > It would be great also to have an easy way to cherry peak from the upstream
Hello,
On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>> debian/README.source as described in the developers-reference.
>
> It would be great also to have an easy way to cherry peak from the upstream
> git repository in order to prepare patch series.
>
> Do we have a tool aroun
On Mon, May 12, 2025 at 11:58:45AM +0200, Santiago Vila wrote:
El 12/5/25 a las 9:49, Holger Levsen escribió:
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
I also don't like the idea of adding a gpb.conf to each and every package.
Yes, in most c
On 12/05/25 10:31, Andrey Rakhmatullin wrote:
On Mon, May 12, 2025 at 09:54:38AM +0200, Gioele Barabucci wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *righ
El 12/5/25 a las 9:49, Holger Levsen escribió:
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
I also don't like the idea of adding a gpb.conf to each and every package.
Most of my packages don't have such file and Salsa CI is able to build them.
M
> debian/README.source as described in the developers-reference.
It would be great also to have an easy way to cherry peak from the upstream git
repository in order to prepare patch series.
Do we have a tool around DEP-14, which allows this ?
On Mon, May 12, 2025 at 08:32:24AM +, Holger Levsen wrote:
> debian/README.source as described in the developers-reference.
and even in
https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|la
On Mon, May 12, 2025 at 09:09:23AM +0100, Richard Lewis wrote:
> > I dont want to use git-buildpackage and I don't want a
> > gpb.conf. Please accept this. Thanks.
> is there another way people can use to understand how to build the
> package?
debian/README.source as described in the developers-re
On Mon, May 12, 2025 at 09:54:38AM +0200, Gioele Barabucci wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *right now*.
I dont want to use git-buildpackage a
On Mon, 12 May 2025 09:54:38 +0200, Gioele Barabucci
wrote:
>On 12/05/25 09:49, Holger Levsen wrote:
>> On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
>>> Regardless of what branch names packages use today or in the future,
>>> they should all have a debian/gbp.conf file that def
On 12/05/25 09:49, Holger Levsen wrote:
On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
Regardless of what branch names packages use today or in the future,
they should all have a debian/gbp.conf file that defines what branches
and packaging practices are being used *right now*.
Holger Levsen writes:
> On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
>> Regardless of what branch names packages use today or in the future,
>> they should all have a debian/gbp.conf file that defines what
>> branches and packaging practices are being used *right now*.
>
> I
On Sun, May 11, 2025 at 03:58:12PM -0700, Otto Kekäläinen wrote:
> > > I think this significantly underestimates the annoyance involved in
> > > renaming
> > > existing long-lived branches (in that all clients have to re-clone or
> > > manually adjust), which is certainly why I generally avoid doi
40 matches
Mail list logo
