With all the recent talk about increasing the use of git for
packaging, I'd like to address one thing: git-buildpackage is very
complex to use. As an alternative, I'd like to propose a simpler
setup:
- Only store debian/ in the repository and use origtargz for the rest.
- One branch per distribution you target.
- Only tag debian revisions.
That's it, less is more. The master branch would be just a single
debian directory. What it specifically wouldn't have is an upstream
branch and no extracted upstream sources in any permanent branch.
I've been a DD longer than git-buildpackage has been around and I've
been looking at using it at various times but pretty much every time
my reaction's been "must I?" I know a lot of people do use gbp daily
for work with good effect but somehow I suspect even they had quite a
steep learning curve to get into it. I wouldn't fancy the idea of
trying to explain how to use it to someone on d-mentors.
With all the recent talk about increasing the use of git for
packaging, I'd like to address one thing: git-buildpackage is very
complex to use. As an alternative, I'd like to propose a simpler
setup:
- Only store debian/ in the repository and use origtargz for the rest.
- One branch per distribution you target.
- Only tag debian revisions.
That's it, less is more. The master branch would be just a single
debian directory. What it specifically wouldn't have is an upstream
branch and no extracted upstream sources in any permanent branch.
gbp dch would still be useful with this workflow. gbp pq could be
made to work with this if you extracted orig.tar and committed it to a temporary local working branch and used it against it.
I guess interfacing with upstream's git with gbp has its uses but it
just seems to me that the capability comes with a hefty cost. If you
can maintain a package with having orig.tar files be your interface to upstream's releases then it simplifies things on our side a whole lot.
I've been a DD longer than git-buildpackage has been around and I've
been looking at using it at various times but pretty much every time
my reaction's been "must I?" I know a lot of people do use gbp daily
for work with good effect but somehow I suspect even they had quite a
steep learning curve to get into it. I wouldn't fancy the idea of
trying to explain how to use it to someone on d-mentors.
I must say that I haven't been that impressed with the DEP-18
discussion I've seen. It seems like the message has pretty
consistently been "if you don't use git you're the problem" and I'm
sick of it and I can tell you it only makes me want to ignore you.
If you ask me it's git-buildpackage's irreducible difficulty of use
that's the largest road block to increase the use of git for packaging.
However... different people are used to different workflows.
I personally really, really like the fact that I have the Git history of
all the upstream files in the same repo and I don't have to go over to
a different repo to figure out what changed when. Also, I like that immediately after `gbp import-orig` I can run `git show upstream` to
review the diff (TBH, me being very pedantic, I usually have already
given it a quick glance using `diff -urN` on unpacked tarballs before
even importing it, if only to figure out if there are new files that
I need to exclude, but that's not always the case), and that I can
at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path`
or similar commands. I have even been known to use `git bisect` in
a Debian package directory in some weird cases.
And yes, all of that can be handled in a separate Git repo with
a clean checkout of the upstream repository without any of
the Debian fluff; however, that would require me switching between terminals/tmux panes/whatever, and sometimes that seems like too much
work when I can have it all in a single repository :)
So... yes, a simpler setup would work for some people, and it may be
better for beginners. However, there are some benefits to a full
repository containing both the upstream source and the Debian changes,
and some people like to use them every now and then.
Still, thanks for your desire to make working on Debian easier and
better!
However... different people are used to different workflows.
I personally really, really like the fact that I have the Git history of all the upstream files in the same repo and I don't have to go over to
a different repo to figure out what changed when. Also, I like that immediately after `gbp import-orig` I can run `git show upstream` to
review the diff (TBH, me being very pedantic, I usually have already
given it a quick glance using `diff -urN` on unpacked tarballs before
even importing it, if only to figure out if there are new files that
I need to exclude, but that's not always the case), and that I can
at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path`
or similar commands. I have even been known to use `git bisect` in
a Debian package directory in some weird cases.
And yes, all of that can be handled in a separate Git repo with
a clean checkout of the upstream repository without any of
the Debian fluff; however, that would require me switching between terminals/tmux panes/whatever, and sometimes that seems like too much
work when I can have it all in a single repository :)
Preface, just in case: I list a few git commands, don't try running
them if you have uncommitted changes.
Okay, I could amend what I proposed originally with this option: Do
the debian work in a fork of upstream's repository, but never merge
the debian branch and upstream branch. That is, the start of Debian maintenance would be by cloning upstream and then with "git checkout
--orphan debian" followed by "git reset --hard".
Do you think you could do all of the above with that model, with a
command like "git checkout debian -- ." to insert the debian contents
to an upstream branch?
I'm thinking that it's the merging of debian and upstream branches and maintaining it that really causes the warts in gbp and I'm not at all
sure if there are any actual workflows that require having that. "upstreamless" as I described it may be a bit too much for general use
but could there be a case for doing everything with a mergeless model instead?
Furthermore, I think import-orig should really be only about
establishing a particular byte string as the orig.tar. Think of
object storage. If there's a connection to a particular commit hash
or release tag in the repository it would better be represented as a
separate entry. Perhaps as a text file like debian/upstream-commits
that would be a list of upstream version/commit hash or tag pairs.
From where I stand, the way these disparate concerns have been merged
seems to be one root cause for all sorts of unintended consequences.
With all the recent talk about increasing the use of git for..
packaging, I'd like to address one thing: git-buildpackage is very
complex to use. As an alternative, I'd like to propose a simpler
setup:
sick of it and I can tell you it only makes me want to ignore you. If
you ask me it's git-buildpackage's irreducible difficulty of use
that's the largest road block to increase the use of git for
packaging.
fwiw, I'm also not using git-buildpackage and I don't want to. (Step learning curve, too much magic, hard to debug and I dont see benefits for the packages I maintain.) I'm also not a beginner. And I love gbp-dch.
please dont enforce git-buildpackage on everyone.
emacs might be better than nano for many usecases, but not all. if someone would force me to use emacs, I'd be out. (FWIW, i'm a vim user, this is an analogy.)
fwiw, I'm also not using git-buildpackage and I don't want to. (Step learningI think git-buildpackage is great, and I am a happy user. However, it
curve, too much magic, hard to debug and I dont see benefits for the packages
I maintain.) I'm also not a beginner. And I love gbp-dch.
took me quite a while to figure out what is the optimal way to use it,
as it has so many options. Can you elaborate what is the specific action/workflow you think git-buildpackage you were frustrated with?
I am not enforcing git-buildpackage on everyone. I am accelerating the convergence of workflows so that it is easier for maintainers to
collaborate, so we can have more code reviews, more new maintainers,
and in the long run perhaps decrease the number of single-maintainer
packages for packages where the maintainer does not want to be the
sole maintainer.
Otto Kekäläinen <otto@debian.org> writes:
I think this will be more successful if you frame this as good patterns
to follow for people who wish to opt-in on the premise of adopting this workflow. That framing follows other DEP's. Now it reads as a mandate
for everything. Acknowledging existance of exceptions to the rules
within the rules may also help to gain acceptance.
and you seem to think adding another Debian specific complex tool will attrack new people? Most people^wcontributors out there know git already,
for them a simple git only workflow is *much* more inviting than having
to learn gbp *only* to contribute to Debian.
- Only store debian/ in the repository and use origtargz for the rest.
I am not enforcing git-buildpackage on everyone. I am accelerating the convergence of workflows so that it is easier for maintainers to collaborate, so we can have more code reviews, more new maintainers,
and in the long run perhaps decrease the number of single-maintainer packages for packages where the maintainer does not want to be the
sole maintainer.
and you seem to think adding another Debian specific complex tool will attrack new people? Most people^wcontributors out there know git already,
for them a simple git only workflow is *much* more inviting than having
to learn gbp *only* to contribute to Debian. gbp is useless outside
Debian (and derivatives. Yet, thats only a part of the free software world.)
I am contemplating if I should also make videos on Debian packaging best practices, or have start a new Matrix channel specifically to help maintainers setup their git repositories correctly and find the optimal git-buildpackage commands for each thing they want to do.
I am not enforcing git-buildpackage on everyone. I am accelerating the convergence of workflows so that it is easier for maintainers to
collaborate, so we can have more code reviews, more new maintainers,
and in the long run perhaps decrease the number of single-maintainer
packages for packages where the maintainer does not want to be the
sole maintainer. Currently the learning curve on how to contribute
prevents many people from doing it.
fwiw, I'm also not using git-buildpackage and I don't want to. (Step learningI think git-buildpackage is great, and I am a happy user. However, it
curve, too much magic, hard to debug and I dont see benefits for the packages
I maintain.) I'm also not a beginner. And I love gbp-dch.
took me quite a while to figure out what is the optimal way to use it,
as it has so many options. Can you elaborate what is the specific action/workflow you think git-buildpackage you were frustrated with?
sigh. see above.
in addition to the above: gbp is great if it works, if it doesn't I can
start to learn to debug a complex system, while on the contrary, if I use
git and debuild/pbuilder/sbuild manually all the time, I know those tools, they are rather easy to debug etc.
I think this will be more successful if you frame this as good patterns
to follow for people who wish to opt-in on the premise of adopting this workflow. That framing follows other DEP's. Now it reads as a mandate
for everything. Acknowledging existance of exceptions to the rules
within the rules may also help to gain acceptance.
This!
and you seem to think adding another Debian specific complex tool will attrack new people? Most people^wcontributors out there know git already, for them a simple git only workflow is *much* more inviting than having
to learn gbp *only* to contribute to Debian.
This. Exactly this.
This is the reason I can contribute small improvements to Alpine and
other projects with reasonable effort for small improvements. The
tools are the same tools I already use elsewhere, and stuff is as
transparent as it needs to be for outside contributors.
Time to get build people where they are, and not where we are.
I'm thinking that it's the merging of debian and upstream branches and maintaining it that really causes the warts in gbp and I'm not at all
sure if there are any actual workflows that require having that. "upstreamless" as I described it may be a bit too much for general use
but could there be a case for doing everything with a mergeless model instead?
Yes, changing Debian so that the required workflows are more simple is
much better but also impossible.
I like to read of other people's workflows but then I often do not see
how their workflows can possibly fit my packages. There seem to be
many people who have the upstream git as part of their packaging
git. I'm happy that works for them but I don't see how I can leave my tarball-centered workflows (even though all my upstream work in git)
if all my upstreams ship DFSG non-free material which I have to remove
from their tarballs first.
So given all this, the point I wanted to make was: I'd like to watch your videos if you make them. But at least for me you do not have to go through the
trouble of shooting videos. Just some HTML docs would be just fine for me. Currently, I'm missing a long-term maintained document which explains "the" (haha) recommended Debian git workflow through the lifetime of a package from its initial creation to backports or stable updates.
...in addition to the above: gbp is great if it works, if it doesn't I can
start to learn to debug a complex system, while on the contrary, if I use
git and debuild/pbuilder/sbuild manually all the time, I know those tools, >> they are rather easy to debug etc.
Personally I think gbp is very easy to debug. You just add --verbose
to any command and it will print out what it is doing. Example:
gbp import-orig --uscan --verbose
I like to read of other people's workflows but then I often do not see how their workflows can possibly fit my packages. There seem to be many people who have the upstream git as part of their packaging git. I'm happy that works for them but I don't see how I can leave my tarball-centered workflows (even though all my upstream work in git) if all my upstreams ship DFSG non-free material which I have to remove from their tarballs first.This works fairly well these days: use Files-Excluded: in d/copyright and "dversionmangle=s/\+ds\d*$//,repacksuffix=+ds" in d/watch. Tools like gbp, uscan, origtargz seems to do the right thing automatically.
Quoting Simon Josefsson (2024-11-22 12:18:36)
I like to read of other people's workflows but then I often do not see how >> > their workflows can possibly fit my packages. There seem to be many people >> > who have the upstream git as part of their packaging git. I'm happy that >> > works for them but I don't see how I can leave my tarball-centeredThis works fairly well these days: use Files-Excluded: in d/copyright and
workflows (even though all my upstream work in git) if all my upstreams
ship DFSG non-free material which I have to remove from their tarballs
first.
"dversionmangle=s/\+ds\d*$//,repacksuffix=+ds" in d/watch. Tools like gbp, >> uscan, origtargz seems to do the right thing automatically.
That's what I'm doing. But that works with tarballs not with upstream
as git. If upstream (deliberately, so this will not change) has DSFG-non-free content in it, then I should not copy that into a git
packaging repo that is targeting main. Removing the problematic parts
from the upstream git repos would rewrite their history, invalidate
tags etc, so the result would not be very useful anymore. Thus, I
usually have one directory on my PC with the upstream git and another
with my Debian packaging git. The packaging git does not have the
upstream git with non-free content int it. Instead my packaging git
regularly imports new upstream releases as tarballs and removes the
non-free content via Files-Excluded and dversionmangle/repacksuffix in d/watch. I don't see how I can get rid of the tarballs here but
instead embrace the (non-free) upstream git. Maybe I'm missing
something?
Doesn't 'gbp import-orig --uscan' work if you have a watch-file like this:
version=4
opts="mode=git, pgpmode=none,\
dversionmangle=s/\+ds\d*$//,repacksuffix=+ds" \
https://github.com/withfig/autocomplete-tools.git \
HEAD debian
If the upstream publishes the released tarball via its web interface, please use it instead of using this mode. This mode is the last resort method.
Also is there a problem to mirror upstream's non-DFSG content on Salsa?
The important aspect seems to be that *.orig.tar.* and debian/* uploaded
into the archive shouldn't contain non-DFSG stuff if it targets main. I thought Salsa can be used to maintain contrib/non-free/non-free-firmware projects too, so I assume there is no restriction that Salsa git repositories may only contain DFSG-content.
NOTICE: 'tinyusb' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/debian/tinyusb.git
Please use:
git clone https://salsa.debian.org/debian/tinyusb.git
to retrieve the latest (possibly unreleased) updates to the package.
commands, iI am contemplating if I should also make videos on Debian packaging best practices, or have start a new Matrix channel specifically to help maintainers setup their git repositories correctly and find the optimal git-buildpackage commands for each thing they want to do.
I'd describe myself of being in the camp of "I don't care about the
don't care how my git branches are named, just document one thing so thatmy
packages can do the same thing that most other packages do". For thatreason I
so far created new package repos with "gbp import-dsc" and used all the defaults that come with that. I don't think I care much for what thesedefaults
are at least I didn't see myself reading past discussions about this and thinking "nooooo don't name this branch debian/latest instead ofdebian/foo" or
something. I like to read of other people's workflows but then I often donot
see how their workflows can possibly fit my packages. There seem to bemany
people who have the upstream git as part of their packaging git. I'mhappy that
works for them but I don't see how I can leave my tarball-centeredworkflows
(even though all my upstream work in git) if all my upstreams ship DFSG non-free material which I have to remove from their tarballs first.
You can have upstream git and tarballs at the same time, and even have DFSG cleanup take place and git show you exactly the differences of all the versions.
If you look at https://salsa.debian.org/debian/entr/-/network/debian%2Flatest?extended_sha1=debian%2Flatest&filter_ref=1
(or better, gbp clone it locally to more easily browse it with `gitk --all`) you can see how the upstream release git tag "5.6" was merged on branch 'upstream/latest' which is the target of tarball imports, and that was then merged on the 'debian/latest' branch. Commands how to do this are in https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/README.source.md
and the https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf has the configs so git-buildpackage can be used without the need to constantly pass it information about upstream git tag format etc.
For dfsg-filtering the watchfile options only apply for uscan/tarball. To ensure the upstream/latest branch stays dfsg-clean on git merges, configure 'filter' in debian/gbp.conf.
Which package do you have DFSG tarballs? I can take a look and help you convert it into something where the import is as automatic as possible.
I thought about the gbp aspect of the lets-move-things-to-salsa and I
suggest to consider if they are better left orthogonal. Could you make
one DEP for lets-move-to-salsa and one DEP for lets-document-a-build-workflow?
There is a debian/gbp.conf in 13573 packages in Debian
How common debian/gbp.conf points at something else: perhaps gbp's defaults are not good, if that many packages need to override them.
Yes, as they don't enable pristine-tar
and cannot guess your branch naming system.
On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
and cannot guess your branch naming system.
I haven't checked, but in an ideal world gbp would default to the same
values for these as described in DEP-14. In that same ideal world, we'd
have DEP-14 out of Draft status.
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
and cannot guess your branch naming system.
I haven't checked, but in an ideal world gbp would default to the same
values for these as described in DEP-14. In that same ideal world, we'd
have DEP-14 out of Draft status.
* Jonathan Dowland <jmtd@debian.org> [241126 12:59]:
On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like pristine-tar. Instead of pristine-tar, invent new tooling to manage
tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean
either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like pristine-tar. Instead of pristine-tar, invent new tooling to manage tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean
either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Until we record expected upstream tarball hashes in a debian/* file, an acceptable approach seems to be to skip the pristine-tar branch and be
sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible).
I have never understood what value there is in duplicating the uploaded tarball in the git repository. Recording a hash of it is sufficient.
But I'm also happy to work with pristine-tar branches when that is the workflow for a particular package. I just wish the tooling handled
*.asc files better, and stored them too automatically.
Chris Hofstaedtler <zeha@debian.org> writes:
* Jonathan Dowland <jmtd@debian.org> [241126 12:59]:
On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like pristine-tar. Instead of pristine-tar, invent new tooling to manage tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean
either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Until we record expected upstream tarball hashes in a debian/* file, an acceptable approach seems to be to skip the pristine-tar branch and be
sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible).
I have never understood what value there is in duplicating the uploaded tarball in the git repository. Recording a hash of it is sufficient.
Yes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like pristine-tar. Instead of pristine-tar, invent new tooling to manage tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Until we record expected upstream tarball hashes in a debian/* file, an acceptable approach seems to be to skip the pristine-tar branch and be
sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible).
This is 1). It cannot be done generically as it requires knowing
where to download from, etc.
One possible rebuttal to this is "gbp needs to do the right thing then". Currently gbp by default generates a broken tarball, which is also a
source of confusion for many.
Do you have a bug report number?
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the use-case here that am I missing?
On Tue, Nov 26, 2024 at 06:54:18PM +0100, Chris Hofstaedtler wrote:
This is 1). It cannot be done generically as it requires knowingYes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like
pristine-tar. Instead of pristine-tar, invent new tooling to manage
tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean
either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Until we record expected upstream tarball hashes in a debian/* file, an
acceptable approach seems to be to skip the pristine-tar branch and be
sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible). >>
where to download from, etc.
The archive, when the tarball is already there.
These suggestions never discuss what to do when the tarball was never uploaded yet, even I didn't discuss that for simplicity. It makes sense
from some PoVs, at least when one doesn't use pristine-tar to make a
tarball that has differences in the actual content, not just bit
differences in the tarball itself while have identical file contents.
On Tue, Nov 26, 2024 at 08:49:44PM +0100, Simon Josefsson wrote:
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the
use-case here that am I missing?
CI for a new-upstream-release commit you've pushed but haven't uploaded
to the Debian archive yet, because you're waiting for CI.
pristine-tar certainly isn't the only way here (it's true that CI could
in principle fetch it directly from upstream), but I find it much easier
than the alternatives.
On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:Not really. The debian branches of all of my packages[1] are based off
Yes, as they don't enable pristine-tarIs pristine-tar still valuable these days?
Colin Watson <cjwatson@debian.org> writes:
CI for a new-upstream-release commit you've pushed but haven't uploaded
to the Debian archive yet, because you're waiting for CI.
pristine-tar certainly isn't the only way here (it's true that CI could
in principle fetch it directly from upstream), but I find it much easier than the alternatives.
I often wait for CI before making an upload of a new upstream release,
even without pristine-tar, and Salsa CI hasn't had trouble automatically finding a orig.tar.gz to work with for me. So maybe there is some
additional assumption for your situation?
On Nov 26, Jonathan Dowland <jmtd@debian.org> wrote:
On Tue Nov 26, 2024 at 10:50 AM GMT, Andrey Rakhmatullin wrote:Not really. The debian branches of all of my packages[1] are based off
Yes, as they don't enable pristine-tarIs pristine-tar still valuable these days?
the upstream git repository, which is what I also use to review new
upstream releases and generate the .orig.tar.xz file for the archive.
I could not care less if that file is not bit per bit identical to the upstream one (the git trees have signatures), or even if it does not
contain the same files (this is usually better, so I do not need to carry around files which we like to rebuild anyway).
How common debian/gbp.conf points at something else: perhaps gbp's
defaults are not good, if that many packages need to override them.
Until we record expected upstream tarball hashes in a debian/* file, an acceptable approach seems to be to skip the pristine-tar branch and be
sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible).
This is 1). It cannot be done generically as it requires knowing
where to download from, etc.
I have never understood what value there is in duplicating the uploaded tarball in the git repository. Recording a hash of it is sufficient.
The hash is sufficient for knowing it changed, but you still have to
get the actual tarball from somewhere.
One possible rebuttal to this is "gbp needs to do the right thing then". Currently gbp by default generates a broken tarball, which is also a source of confusion for many.
Do you have a bug report number?
No.
I've found #902249 which is titled "Pull tarballs from the archive (or upstream location)", maybe that's the one you think about. I haven't read
it, except for the "I hoped we could stay out of that business in 2018 but since tarballs are still _the_ _thing_ in Debian" line, which I liked.
For the avoidance of doubt, I don't think gbp *can* do the right thing
there. It's not my rebuttal. Maybe gbp should just refuse to generate a random tarball from a commit-ish and let^Wrequire people to provide one or provide a way to generate one in a correct way.
If the upstream tarball is in the archive, it's probably okay to retrieve one from there. It's not always trivial because now you need to have the right "deb-src" lines enabled in your apt sources.list but it's possible. But how doIt is trivial enough if I have deb-src configured, or else I spend 30
you collaborate with others on packages that were not uploaded to the desired suite yet? Do you not use git for collaboration until the package has passed NEW?I am not sure why I would need a matching .orig.tar.xz for a package
On Tue, Nov 26, 2024 at 09:25:12PM +0100, Simon Josefsson wrote:
Colin Watson <cjwatson@debian.org> writes:
CI for a new-upstream-release commit you've pushed but haven't uploaded to the Debian archive yet, because you're waiting for CI.
pristine-tar certainly isn't the only way here (it's true that CI could in principle fetch it directly from upstream), but I find it much easier than the alternatives.
I often wait for CI before making an upload of a new upstream release,
even without pristine-tar, and Salsa CI hasn't had trouble automatically finding a orig.tar.gz to work with for me. So maybe there is some additional assumption for your situation?
Maybe it runs uscan or something in that case;
Still, as long as it's building source packages as part of the
process, conceptually I prefer it having all the information in the repository rather than having to go out to an upstream site that might
be unreliable.
That's what I'm doing. But that works with tarballs not with upstream
as git.
If upstream (deliberately, so this will not change) has DSFG-non-free
content
in it, then I should not copy that into a git packaging repo that is targeting
main. Removing the problematic parts from the upstream git repos would rewrite
their history, invalidate tags etc, so the result would not be very
useful
anymore. Thus, I usually have one directory on my PC with the upstream
git and
another with my Debian packaging git.
Hi Johannes,
Le 2024-11-22 12:45, Johannes Schauer Marin Rodrigues a écrit :
That's what I'm doing. But that works with tarballs not with upstream
as git.
If upstream (deliberately, so this will not change) has DSFG-non-free content
in it, then I should not copy that into a git packaging repo that is targeting
main. Removing the problematic parts from the upstream git repos would rewrite
their history, invalidate tags etc, so the result would not be very
useful
anymore. Thus, I usually have one directory on my PC with the upstream
git and
another with my Debian packaging git.
For most projects but the larger ones, you could simply add an
`upstream` remote to your local packaging repo. This makes it easier to
diff or look/import specific upstream commits.
For packaging I usually work with 3 remotes (and no `origin` to avoid mistakes):
- debian (the team-managed packaging repo on salsa)
- clone (my own clone of the packaging repo as I don't have update
rights on team repos)
- upstream, which is very convenient for their tags, history and cherry picking.
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the use-case here that am I missing?
On Tue, 26 Nov 2024 20:49:44 +0100, Simon Josefsson wrote:
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the
use-case here that am I missing?
Person A creates a package, person B wants to work on it; use cases:
teams in general, and sponsoring within or outside of teams.
As person B I don't want to go hunting for a tarball and place it in
the right place, I want gbp to re-create it from the pristine-tar
branch.
Andrey Rakhmatullin <wrar@debian.org> writes:
On Tue, Nov 26, 2024 at 06:54:18PM +0100, Chris Hofstaedtler wrote:
This is 1). It cannot be done generically as it requires knowing
where to download from, etc.
The archive, when the tarball is already there.
These suggestions never discuss what to do when the tarball was never uploaded yet, even I didn't discuss that for simplicity. It makes sense from some PoVs, at least when one doesn't use pristine-tar to make a tarball that has differences in the actual content, not just bit differences in the tarball itself while have identical file contents.
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the use-case here that am I missing?
This is 1). It cannot be done generically as it requires knowingYes, as they don't enable pristine-tar
Is pristine-tar still valuable these days?
Unfortunately yes. AFAIK the two options for fixing this that are
usually proposed are:
1) treat it as a problem of each individual developer, just like
pristine-tar. Instead of pristine-tar, invent new tooling to manage
tarballs.
This path often tries to solve the problem only for Debian and only
in a narrow scenario.
2) Have all uploads always supply a new orig.tar.gz. This could mean >> > > either treating every package as Debian-native, or some other
solution.
This is a global solution and reduces complexity instead of adding
to it.
Until we record expected upstream tarball hashes in a debian/* file, an >> > acceptable approach seems to be to skip the pristine-tar branch and be >> > sure to download the previous orig.tar.* + orig.tar.*.asc from the
Debian archive, instead of attempting to re-generate it from the
upstream/ branch (which isn't guaranteed to be bit-by-bit reproducible). >>
where to download from, etc.
The archive, when the tarball is already there.
These suggestions never discuss what to do when the tarball was never uploaded yet, even I didn't discuss that for simplicity. It makes sense from some PoVs, at least when one doesn't use pristine-tar to make a tarball that has differences in the actual content, not just bit differences in the tarball itself while have identical file contents.
If you haven't made an upload, then wouldn't you have the tarball
locally while working on preparing the upload?
And if someone doesn't have the orig.tar.gz locally, then why would
anyone want to get it from a random git repository, rather than fetching
it from the Debian archive or from upstream's release page? What is the use-case here that am I missing?
Yup, as I said it makes sense. It just feels fragile to me when the "pristine" tarball for a given upstream tag in a given repo is not
determined until someone uploads it.
One possible rebuttal to this is "gbp needs to do the right thing then".
Currently gbp by default generates a broken tarball, which is also a source of confusion for many.
Do you have a bug report number?
No.
I've found #902249 which is titled "Pull tarballs from the archive (or upstream location)", maybe that's the one you think about. I haven't read it, except for the "I hoped we could stay out of that business in 2018 but since tarballs are still _the_ _thing_ in Debian" line, which I liked.
For the avoidance of doubt, I don't think gbp *can* do the right thing there. It's not my rebuttal. Maybe gbp should just refuse to generate a random tarball from a commit-ish and let^Wrequire people to provide one or provide a way to generate one in a correct way.
I often hear this complaint about pristine-tar, but I don't take it
seriously until somebody actually files a bug report and has a
reproducible case. For every single package I maintain I use
pristine-tar and it works correctly.
On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
Yup, as I said it makes sense. It just feels fragile to me when the "pristine" tarball for a given upstream tag in a given repo is not determined until someone uploads it.
I would love to have a possibility to just push a new upstream tarball
into the archive at the very beginning of the process of packaging the
new upstream version (and without triggering anything else in Debian).
* Marc Haber <mh+debian-devel@zugschlus.de> [241127 13:28]:
On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
Yup, as I said it makes sense. It just feels fragile to me when the "pristine" tarball for a given upstream tag in a given repo is not determined until someone uploads it.
I would love to have a possibility to just push a new upstream tarball
into the archive at the very beginning of the process of packaging the
new upstream version (and without triggering anything else in Debian).
I hear what you're saying, but in the end it is still a workaround,
right?
Just uploading a new tarball with every debian revision seems so
much more straightforward.
On Wed, Nov 27, 2024 at 01:48:33PM +0100, Chris Hofstaedtler wrote:
* Marc Haber <mh+debian-devel@zugschlus.de> [241127 13:28]:
On Wed, Nov 27, 2024 at 04:58:00PM +0500, Andrey Rakhmatullin wrote:
Yup, as I said it makes sense. It just feels fragile to me when the "pristine" tarball for a given upstream tag in a given repo is not determined until someone uploads it.
I would love to have a possibility to just push a new upstream tarball into the archive at the very beginning of the process of packaging the new upstream version (and without triggering anything else in Debian).
I hear what you're saying, but in the end it is still a workaround,
right?
It's just "putting a nail" into a new upstream version.
Just uploading a new tarball with every debian revision seems so
much more straightforward.
That means that the upstream tarball is possible to get wrong with any
new upload. I am not sure whether I like that.
I might motivate me,
though, to finally explore which of the tools I am holding wrong with upstream tarball handling.
I have never understood what value there is in duplicating the uploaded tarball in the git repository.
On Nov 27, gregor herrmann <gregoa@debian.org> wrote:
As person B I don't want to go hunting for a tarball and place it inWho cares? gbp export-orig takes care of it, unless you need to actually upload it to the archive.
the right place, I want gbp to re-create it from the pristine-tar
branch.
As person B I don't want to go hunting for a tarball and place it inWho cares? gbp export-orig takes care of it, unless you need to actually upload it to the archive.
the right place, I want gbp to re-create it from the pristine-tar
branch.
On Nov 27, gregor herrmann <gregoa@debian.org> wrote:
As person B I don't want to go hunting for a tarball and place it inWho cares? gbp export-orig takes care of it, unless you need to actually upload it to the archive.
the right place, I want gbp to re-create it from the pristine-tar
branch.
On Tue, Nov 26, 2024 at 04:27:37PM +0100, Simon Josefsson wrote:
I have never understood what value there is in duplicating the uploaded
tarball in the git repository.
The actual cost of storing the pristine tarball is quite small.
For example:
commit 91c7ab39337da63371b4814bef2b2aaf85a9e37c (origin/pristine-tar, pristine-tar)
Author: Theodore Ts'o <tytso@mit.edu>
Date: Mon May 20 23:12:54 2024 -0400
pristine-tar data for e2fsprogs_1.47.1.orig.tar.gz
e2fsprogs_1.47.1.orig.tar.gz.asc | 11 +++++++++++
e2fsprogs_1.47.1.orig.tar.gz.delta | Bin 0 -> 63961 bytes
e2fsprogs_1.47.1.orig.tar.gz.id | 1 +
3 files changed, 12 insertions(+)
Compare if I had to keep all of the old release tarballs around:
9.5M e2fsprogs-1.47.1.tar.gz
The reason why I find pristine-tar *super* valuable is because it
stashes the signed tarball and tarball in a highly efficient way, and
which can be easily backed up by just doing a "git push" to github / git.kernel.org / salsa. I can then just kick off a git-buildpackage
in a super-convenient way, so the tooling is quite mature and
convenient for development velocity.
I could imagine an alternate way of generating data for
git-buildpackage, by replacing the pristine with something that stores
the detached GPG signature, and then a shell script which generates
the orig.tar.gz, for example at [1]. But now we'd have third-party
users who want to rebuild the debian packages from source executing an arbitrary shell script found in the git repository to generate the orig.tar.gz file, which would be a security nightmare. Pristine-tar
is a much better from that perspective.
[1] https://github.com/tytso/e2fsprogs/blob/master/util/gen-git-tarball
I think this is a good example of us talking past each other in this
thread: some people question the value of pristine in the first place
(and I've been compelled by those arguments), and some people argue that
the cost is small and there are no bugs (or at least lack of bug
reports).
As person B I don't want to go hunting for a tarball and place it inWho cares? gbp export-orig takes care of it, unless you need to actually upload it to the archive.
the right place, I want gbp to re-create it from the pristine-tar
branch.
Often I want to upload it to the archive, that's quite typical in
teams: A uploads -1 and B uploads -2 with a bugfix or whatever.
Often I want to upload it to the archive, that's quite typical inThe hypothetical change in the tools to silently download the tarball from the archive will make this easy.
teams: A uploads -1 and B uploads -2 with a bugfix or whatever.
pristine-tar almost always fail when there are multiple orig tar files.
I did not report bugs since the limitation of not working 100% is a
known issue already.
Hi,
On 11/28/24 10:56, Pirate Praveen wrote:
pristine-tar almost always fail when there are multiple orig tar
files. I did not report bugs since the limitation of not working 100%
is a known issue already.
I'm surprised to hear this. src:cacti is using multiple orig tar files
(2) for several years now and I've been using pristine-tar (via gbp) to
store them.
Paul
https://salsa.debian.org/debian/cacti/-/tree/pristine-tar?ref_type=heads
On Thu, Nov 28, 2024 at 10:49:09AM +0100, gregor herrmann wrote:
As person B I don't want to go hunting for a tarball and place it in the right place, I want gbp to re-create it from the pristine-tar branch.Who cares? gbp export-orig takes care of it, unless you need to actually upload it to the archive.
Often I want to upload it to the archive, that's quite typical in
teams: A uploads -1 and B uploads -2 with a bugfix or whatever.
The hypothetical change in the tools to silently download the tarball from the archive will make this easy.
On 11/28/24 5:22 PM, Paul Gevers wrote:
Hi,
On 11/28/24 10:56, Pirate Praveen wrote:
pristine-tar almost always fail when there are multiple orig tar
files. I did not report bugs since the limitation of not working 100%
is a known issue already.
I'm surprised to hear this. src:cacti is using multiple orig tar files
(2) for several years now and I've been using pristine-tar (via gbp)
to store them.
Do you import them using gbp import-orig --pristine-tar as well? or just pristine-tar commit?
Paul
https://salsa.debian.org/debian/cacti/-/tree/pristine-tar?ref_type=heads
Hi,
On 11/28/24 10:56, Pirate Praveen wrote:
pristine-tar almost always fail when there are multiple orig tar files.
I did not report bugs since the limitation of not working 100% is a
known issue already.
I'm surprised to hear this. src:cacti is using multiple orig tar files (2) for several years now and I've been using pristine-tar (via gbp) to store them.
This can now be reproduced with node-cacache
pravi@mahishi2:/tmp$ gbp clone --pristine-tar git@salsa.debian.org:js-team/node-cacache.git
gbp:info: Cloning from 'git@salsa.debian.org:js-team/node-cacache.git' pravi@mahishi2:/tmp$ cd node-cacache/
pravi@mahishi2:/tmp/node-cacache$ less debian/gbp.conf pravi@mahishi2:/tmp/node-cacache$ origtargz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
fatal: ambiguous argument '60b4383b8c982ac64553f2754abaefe7ca7ebf79^{tree}': unknown revision or path not in the working tree.
Same works with
pravi@mahishi2:/tmp/node-cacache$ gbp export-orig --pristine-tar
Same works with
pravi@mahishi2:/tmp/node-cacache$ gbp export-orig --pristine-tar
Not sure what does this imply.
2024, നവം 28 5:46:47 PM Andrey Rakhmatullin <wrar@debian.org>:
Same works with
pravi@mahishi2:/tmp/node-cacache$ gbp export-orig --pristine-tar
Not sure what does this imply.
gbp is able to recreate the orig tars when origtargz fails. So it is a known work around.
I think this is a good example of us talking past each other in this
thread: some people question the value of pristine in the first place
(and I've been compelled by those arguments), and some people argue that
the cost is small and there are no bugs (or at least lack of bug
reports).
If we are worried about malicious upstreams replacing tarballs, or man-in-the-middle attacks, I think my debian/upstream/*SUMS approach is
a more effective solution to that problem.
In summary: nothing in this is an argument to stop using pristine-tar
in all packages. I think Theodore Ts'o also laid out pretty well all
the benefits of pristine-tar and why it was originally developed, and
those requirements and benefits still stand.
Perhaps we could avoid talking past we formally had a list of
requirements, and then match possible alternative approachs with how
well they meet the agreed-upon requirements, and which requirements proponents want to dispense with because (at least for them), It's
Just Not Worth It?
If we are worried about malicious upstreams replacing tarballs, or
man-in-the-middle attacks, I think my debian/upstream/*SUMS approach is
a more effective solution to that problem.
Maybe... if there were tools that made it super easy to validate the
tarball against the *SUMS files without needing to unpack the tarball
first?
Possibly with an inline GPG signature so we don't have to have
separate SHA256SUM and SHA256SUM.asc files? For bonus points, maybe
also a tool that validates a SHA256SUM file with a git commit id,
again without needing to do a "git checkout" first?
I will note that this approach would break backwads compatibility with existing Debian source packaging, right? That is, you're proposing
that the debian/usptream/*SUMS file would replace the
*.orig.tar.gz.asc file?
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
Thanks Pirate Praveen for providing the first actual concrete case in
this thread where pristine-tar had some issue!
I noticed an interesting thing about this case:
± origtargz --download-only
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
pristine-tar: successfully generated ../node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
fatal: ambiguous argument
'60b4383b8c982ac64553f2754abaefe7ca7ebf79^{tree}': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: not a valid object name: 60b4383b8c982ac64553f2754abaefe7ca7ebf79^{tree}
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
pristine-tar: command failed: git archive --format=tar 60b4383b8c982ac64553f2754abaefe7ca7ebf79\^\{tree\} | (cd '/tmp/pristine-tar.obWgetreHi' && tar x)
± git show 60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: bad object 60b4383b8c982ac64553f2754abaefe7ca7ebf79
± git fetch origin 60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: remote error: upload-pack: not our ref 60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: the remote end hung up unexpectedly
± gbp export-orig --pristine-tar
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
And then suddenly the git ref has emerged:
± git show a1567ff8077126b7aa8536b779e3e445ba367a49
tree a1567ff8077126b7aa8536b779e3e445ba367a49
.github/
LICENSE.md
README.md
index.js
package.json
test/
± gbp export-orig --pristine-tar
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz gbp:info: Creating /home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
Also comparing output with what I manually downloaded from https://github.com/npm/cacache/releases/tag/v17.0.3
$ sha256sum v17.0.3.tar.gz node-cacache_17.0.3+~cs10.3.7.orig.tar.gz 2daa2c943a9cf316eef10eda6883ac967ca32cc28de9decef147ea42bdc34283 v17.0.3.tar.gz
2daa2c943a9cf316eef10eda6883ac967ca32cc28de9decef147ea42bdc34283 node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
Not sure what happened here. However in the end pristine-tar worked,
and I was able to use it to verify the tarball. Longer notes in https://pad.debian.net/p/node-cacache-pristine-tar.
There are however a lot of oddities in this package that makes it unusual
- You don't have 'pristine-tar = True' in debian/gbp.conf. You should
have it to enforce it is used and git pulled and git pushed
consistently.
- There is no README.source explaining what this '+~cs10.3.7' thing in
the version is. I assumed you had repackaged something, but then also
was surprised that it actuall was the same as upstream.
- This package consists of the main package and 5 components that are
all mangled together. Is that necessary? I am surpised such a complex
thing actually seems to work
In summary: nothing in this is an argument to stop using pristine-tar
in all packages. I think Theodore Ts'o also laid out pretty well all
the benefits of pristine-tar and why it was originally developed, and
those requirements and benefits still stand. Sure, we can in future
also have other ways to do this in a future debian package format 3.1,
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
Le 2024-11-29 03:17, Otto Kekäläinen a écrit :
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
Would it be possible to make it the default when there is already an existing `pristine-tar` branch in the repo being worked on?
Quoting sre4ever@free.fr (2024-11-29 13:29:05)
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Please consider filing that as a bugreport against bit-buildpackage -
I suspect that has a far better traction than asking speculatively in
this mailinglist and assuming that others picks up your thought and
does
that task for you.
The only record of this is
indirectly with the maintainer signing the *.changes file during
package
upload. But that is weak (only successfully uploaded packages are
protected, not work-in-progress) and not widely audited (*.changes
files
aren't stored forever, or are they?).
Le 2024-11-29 15:12, Jonas Smedegaard a écrit :
Quoting sre4ever@free.fr (2024-11-29 13:29:05)
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Please consider filing that as a bugreport against bit-buildpackage -
I suspect that has a far better traction than asking speculatively in
this mailinglist and assuming that others picks up your thought and
does
that task for you.
That would be a duplicate though, someone else already had that great
idea: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557606
opened 15 years and a few days ago.
Quoting sre4ever@free.fr (2024-11-29 16:57:23)
opened 15 years and a few days ago.
Great that you took "filing a bugreport" to imply checking first if
the issue was already reported.
far better tractionof reporting bugs ... I would even dare to write that the continued
How common debian/gbp.conf points at something else: perhaps gbp's
defaults are not good, if that many packages need to override them.
First of all may I ask you to not use terms like 'not good' as it may
come off negative towards the maintainer of that software. Guido has
done an amazing job with git-buildpackage and we certainly want him to continue iterating on it.
I also suggest you to participate in gbp development, as currently it
is 95% Guido alone. At https://salsa.debian.org/agx/git-buildpackage/-/commits/master you can
for example suggest changes to those defaults along with a migration
path, or you can help with just improving the documentation so people
more easily end up choosing the right options.
Secondly, it is perfectly valid for evey single package to have a debian/gbp.conf and I would in fact prefer that. For every upstream we
need to have metadata on:
- do they have tarball releases (pristine-tar true/false)
On Tue, Nov 26, 2024 at 06:53:01PM +0100, Mechtilde Stehmann wrote:
One possible rebuttal to this is "gbp needs to do the right thing then". >> > Currently gbp by default generates a broken tarball, which is also a
source of confusion for many.
Do you have a bug report number?
No.
I've found #902249 which is titled "Pull tarballs from the archive (or upstream location)", maybe that's the one you think about. I haven't read
it, except for the "I hoped we could stay out of that business in 2018 but since tarballs are still _the_ _thing_ in Debian" line, which I liked.
For the avoidance of doubt, I don't think gbp *can* do the right thing
there. It's not my rebuttal. Maybe gbp should just refuse to generate a random tarball from a commit-ish and let^Wrequire people to provide one or provide a way to generate one in a correct way.
*) As much as possible, we want to be able to use the unmodified
source files are officially released by upstream. Which might be a
tarball and/or a signed git tag.
One possible rebuttal to this is "gbp needs to do the right thing then". >> > Currently gbp by default generates a broken tarball, which is also a
source of confusion for many.
Do you have a bug report number?
No.
I've found #902249 which is titled "Pull tarballs from the archive (or upstream location)", maybe that's the one you think about. I haven't read it, except for the "I hoped we could stay out of that business in 2018 but since tarballs are still _the_ _thing_ in Debian" line, which I liked.
For the avoidance of doubt, I don't think gbp *can* do the right thing there. It's not my rebuttal. Maybe gbp should just refuse to generate a random tarball from a commit-ish and let^Wrequire people to provide one or provide a way to generate one in a correct way.
'origtargz' from devscripts usually does the right thing.
Then just make one: 'git deborig'.
I appreciate not everyone is happy with this, but it solves the
problem.
No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.
Hi all, I've tried catching up with the whole thread, but didn't fully yet. So excuse me if this has been asked/answered before.
On Tue Dec 3, 2024 at 3:40 AM CET, Sean Whitton wrote:
Then just make one: 'git deborig'.
I appreciate not everyone is happy with this, but it solves the problem.
It seems that we're all agreeing on trying to unify our different workflows as much as possible.
Why do we have `git deborig`, `gbp export-orig`, `origtargz`, etc.?
Couldn't we decide to unify on a single "front end" command, which
chooses different backends automatically depending on the situation?
It would be a starting point. To new contributors, we could say, for
example, "to generate the tarball, just run origtargz", independently of whether they use gbp, git-debrebase, no git at all, etc.
No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.
Couldn't we decide to unify on a single "front end" command, which
chooses different backends automatically depending on the situation?
On Sat, Dec 07, 2024 at 10:39:43PM +0500, Andrey Rakhmatullin wrote:
No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.
I agree with the first sentence but I think the 2nd sentence is too much drama.
Those many workflows exists for reasons, some good, some not so good.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 43:25:45 |
| Calls: | 10,392 |
| Files: | 14,064 |
| Messages: | 6,417,222 |