| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 64:45:59 |
| Calls: | 482 |
| Calls today: | 1 |
| Files: | 1,072 |
| Messages: | 96,344 |
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 dont want to use git-buildpackage and I don't want a
gpb.conf. Please accept this. Thanks.
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*.
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
gbp.conf would probably be more widely accepted if it were called >"Debian.source.conf" or something neutral like that.
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 don't want a gpb.conf. Please accept
this. Thanks.
gbp.conf would probably be more widely accepted if it were called >"Debian.source.conf" or something neutral like that.
I dont want to use git-buildpackage and I don't want ais there another way people can use to understand how to build the
gpb.conf. Please accept this. Thanks.
package?
debian/README.source as described in the developers-reference.
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
debian/README.source as described in the developers-reference.
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.
Maybe we could assume that if there is no gbp.conf, you can always build
the package by creating a source package from the git repo first,
as Salsa CI does?
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 ?
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 around DEP-14, which allows this ?
Well, git-debrebase does, and is as compliant with DEP-14 as you'd like
it to be.
--
Sean Whitton
Hi,
Sean Whitton <spwhitton@spwhitton.name> 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
git repository in order to prepare patch series.
Do we have a tool around DEP-14, which allows this ?
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.
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 don't want a gpb.conf. Please accept
this. Thanks.
On 12/05/25 at 07:49 +0000, 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 don't want a gpb.conf. Please accept
this. Thanks.
"I dont want to use git-buildpackage" sounds a bit like "I don't want to
use debhelper". There are many cases where it makes sense to standardize
on workflows and tools (and accept that it reduces the number of degrees
of freedom, and many using inferior tools). And there are some cases
where it makes sense to use specific workflows and tools (because it
gives more power to optimize stuff).
Maybe DEP-14 should focus on being the debhelper of git-based packaging,
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, 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.
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 cases when it's needed it's because your branch names and/or pristine-tar usage flag don't match the gbp defaults.
Most of my packages don't have such file and Salsa CI is able to build them.
Because they use the gbp defaults?
Using gbp pq is easy, and it is also backwards compatible with quilt,
and automatically uses DEP-3 headers
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 <package>
or
gbp clone <package>
and get a a DEP-14 organized repository, where the upstream/latest point to the upstream git repository.
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 this url in our Debian files.
If I need to find and add manually these information each time I checkout a debian package, It is not viable.
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.
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 one. d/gbp.conf
other files ?
There is the Source field in d/copyright where you can put a git remote
URL. Maybe that usage should go into DEP-14 ?
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 this url in our Debian >> files.
There is the Source field in d/copyright where you can put a git remote
URL.
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 one person, but I cannot
recall any details about it to help locating it.
Yes, there was such an effort advocated by one person, but I cannot
recall any details about it to help locating it.
Best,
Andrius
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.conf (I personally think this should be the default, but currently it isn't).
PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> 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 (what for ?). maybe we should standardize on this one. >> d/gbp.conf
other files ?
Indeed this is a mess. (I wouldn't count d/control Vcs-* though?)
Has there been any work towards a single-file declarative file syntax to generate all the debian/ files?
Except for debian/patches/ and debian/tests/ I think this could work.
Compare rpm's *.spec or Homebrew files.
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...
Despite this, it is good practice toThis kind of personal opinions proposed as if they were the consensus
not push any upstream branch to the packaging repository so as to not >confuse anyone about the purpose of the Git repository.
Le 2025-05-12 15:04, Lucas Nussbaum a Θcritá:
Regarding "I don't want a gbp.conf", I think that we should aim forCould having a way to manage "team defaults" for gbp provide some
DRY,
and that adding a gbp.conf in every package doesn't sound too great for >>teams that maintain hundreds or thousands of packages...
relief here? These could maybe be distributed with the gbp package, or
a separate distribution-wide package, or by separate packages managed
by each team. The idea would be to add some logic to gbp to apply
different defaults depending on the declared maintainer of the
package. Such defaults could still be overriden by gbp.conf the same
way as current gbp built-in defaults can be.