On Wed Nov 27, 2024 at 4:30 AM GMT, Otto Kekäläinen wrote:

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 was really surprised to receive this feedback. I agree with using intentional language and not denigrating other's work. I spent a few
days reflecting on what I wrote and how you've responded to it, and I
haven't come to a conclusion as to whether I agree with you or not. On
the one hand, juxtaposing "not good" with "gbp" could be taken badly,
and using something like "not correct" or "not appropriate" may have
avoided that; on the other, I believe I was clear in expressing that I
was talking about the software's defaults rather than the software
itself.

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.

Presently I prefer not to use gbp, so I don't think this would be an
efficient use of my time. I'm also undecided on whether gbp should be recommended as the default tool that we recommend to developers for
managing packages. I feel that engaging with your efforts on DEP18, considering how to progress DEP14 and the related discussions on -devel
are a better use of my resource at the present moment.

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)

Please don't infer the answer to "does upstream have tarball releases"
from "pristine-tar true/false", as they are not the same thing. I'm sure
there are packages repositories where upstream's tarball is ignored, a
"git archive"-produced tarball, or a GitHub release-derived tarball, is
used instead, *and* the pristine-tar branch duly populated (which again
is independent from whether the maintainers have provided a
debian/gbp.conf with a pristine-tar key value in it.) Likewise there are package repositories where the packaging is based on an upstream tarball,
but pristine-tar is not used, and/or its use not documented in a debian/gbp.conf.

More generally I think the *right* place for much of this metadata is
not gbp.conf but should be somewhere more tool-agnostic, at least unless
we actually agree to elevate gbp to the status of "use this unless you
have a very good reason not to".

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Tue 26 Nov 2024 at 11:28pm +05, Andrey Rakhmatullin wrote:

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.

'origtargz' from devscripts usually does the right thing.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Thu 28 Nov 2024 at 10:29am -10, Theodore Ts'o wrote:

*) 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.

I ignore this completely, and I'm not the only one.

Even for traditionally maintained software like Emacs, Rob and I push upstream-signed git tags to dgit.debian.org instead, and use 'git
archive' to generate a tarball to satisfy dak.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmdOcKAZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAjTD/4irS5Y5SNRT0coNC5cAUbc sF8De7a1tYHsXU/94fKhWZR7yZK73H5pwv3SOWLxJxB4IwSAEFxJa8vAMfqkS/mA 76QHy00Xkv3adiNbyROMFb3u+93j86RlhyoX+FFiU+5vb402bb22UXJAc9FY3lJ0 ENi3m84zMy6oy4AZ+u/avdkkXIf0y2wakJRvdX6yOWv4rhZ/N7wJ9zvwuxEQmYt7 QOnYCKVrKcCQqL2K4j3up6X/tjgObJLx1vFZ38+xcIsoUgcIEWiFNcSU0ujIqDYO zp4z0nPTqmVMLAi+fO3G7YTpvCz/s7DHupII6GFM9WdN2eA7PtxenzpGQ1aplJAG POoCmwAtk3DgZNRIbLWZ7SVXtoOdOWOgy6OKBNrhFhey9gHYYbeAk4PxPIzsVn8l tuS297KnqHsMTjAphyyBCwu7qdg19C4nqCUiI7jR/KX1LFuIFVi4nI1q1b2CCKXK nc7LAsFAzt4PBSdaC6s8euQegpoU8yIZxBqsB4SGaDk66U+bhusYxyM8HbGRBqio XLyq7KQwx8e8WJVFz//uXlQRw/y0lykawbE07ahDLArH+BQAuZBaArzKkMCHOZSb ERdNetBcsW77kBsS0VLmpkY7JNNFkk3R96iy9sO2iAACbeShRZp/8FRqRO9Ry5C1 run8LHJuEaVcypZMxF2Y5w==dmeD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On Tue, Dec 03, 2024 at 10:40:03AM +0800, Sean Whitton 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.

'origtargz' from devscripts usually does the right thing.

Yeah, but it's a separate command. Some parts of this discussion are specifically about the straightforward gbp-clone+gbp-buildpackage workflow.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdOwTctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh QSUP/2TWFtjQ8nvts5UEDkwFVOgg+of7MnBK/qoJWauofefjEsFqrmQ4IjfnGViy DX711swQkBviWegxEvdSl7db4T25q2HYiD0dqJpVeCHSmFZaiWKdAVm/6nEYqbDy Mo8bRShv4luyDxiT1cK8nRULs6aqW3e8LqhMLRgYPPTgQlT/fxDSExX5uwQdZVbh pbirm/wqbU9DPIEVazNjZ4h4Ds2Xl7XlXvh11MpFsbZ6WPws9SHrQo10r0Mm04sL nv1iDRF5SLlE5OrDVGOODSJzmy66R2iQG4EVhUuxVo2aG6juO3Z68cAYv1hfGTxp 7uIZFlJNJoeqa3nM53KzAw5GasUxHvf3myPZDC8mIkr4RtXIffbxL3FcMZuhf2sw etagXAuNmMjEig+H5sDPFWEUfz2YM2gaNWZm25r/xCebgr7kHeLdE5e2gFlLW06p KDfrSClVfnyL25Buqh13MKHF1tRu9q9852jWGTmXtdxU7PpcdZwju9QHFjIRG8UY pKHkUhM09eaI9J9tlRlVp/m9amdimkbZDr2Ruvg9Y7yYEMpGitpH6bnkwbCGJDbp xjAyPLEWYpNgRY5Ye7/KSTbbXaCqrm262/H/v7x7mA3VWqBg8VWH4gbolsodjYci Q1leZwdhRh0oUDPTLmmwL+q98nN/Mps2fQ14WFGLerbRaEBx
=huJp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Bye!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Even if we agreed on the one superiour workflow tomorrow (which won't happen just because some people think that would be a good idea, but let's assume so), it would still take years to achieve.

Which is not to say that cannot be done, but changing 30k source packages
takes years, probably rather a decade. Changing 2000 people decades old
habbits will probably take even longer.

What could be done much more easily however, would be to agree on one
default recommended workflow & toolchain for NEW packages and people.

Maybe.

OTOH, some of us do this already, eg the rust team. And because we are the Debian rust team, we also have exceptions to this rule... ;)


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Klimakatastrophe bedeutet kompletter sozialer Kollaps.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmdUiuMACgkQCRq4Vgaa qhwCqw/+JIRJ/yerN9ODqVZhejPGj2ywZiUMEoRFK0BIG7704VkV71w+AavQpNDm 1RE9Xrp/cwROBPfqB/0mVGitNAgCJqK3gYsoREP6lgOQWGzjhzl//PzbUohpc3A7 qCPQ/6HCRJ09Acpn8EXJZsWiWfpfVPY6zznngH5PSuZFKhXLGVn70TV/MGmR/GuN Grgah7ZPjUMp4bnDXiWQja2S2MGFRr3znzqrh3A+4vZGa+aTEi3D65dQFCaeM2vn TpGhcEOIf/rgEqe72YcgflR+aQqQjZAhWqlKAGyy51qTcbKVyli1avc6ycq3Itxv NlCCGsasBrU+c3sapGdFO0ZVQw7/+EfUlefGnX/BTDR3pBDohOQqrSHbR4kR+FEI B/nGTq+fIY/4KdWxrQQsKPRZZTo+KwaRHjhnk5mr0HQjdv5wfndtT3qcOAzl9LqQ JthhGzwh9tQYte3+LL0VEgjDiEgSxPaQ15wlw6C6UaQ6NQApNqrCxIYuDvoNVXoP HsLLwxM83dURK20JH2XX6LqKTuNJop60WmOnkh2J4HKuwsx7bOGtFbFEt8vFKQfl EmGQLEPCFslN85d4oV6m/3559ReuGP+p8n8NUwGQZO+LPBaQtpQzIknZP5

On Sat, Dec 07, 2024 at 02:34:20PM +0100, Andrea Pappacoda wrote:

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.

No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.

Why do we have `git deborig`, `gbp export-orig`, `origtargz`, etc.?

They are parts of different incompatible workflows.

Couldn't we decide to unify on a single "front end" command, which
chooses different backends automatically depending on the situation?

That seems unlikely.
It can't be a command that runs the full workflow and it can't be a set of separate commands that run separate parts of different workflows because
the parts themselves are unlikely to be possible to uinify.

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.

Ideally one shouldn't need to run any separate commands to generate the
tarball from a repo. E.g. the gbp workflow doesn't require this.
Additionally, e.g. gbp expects the tarball to be in the build-dir, while
no unrelated tools could know the location of the gbp build-dir.
See?

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdUiFgtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh IckP/0pF2cd3ByFCU/NiQvMO5GTce0aprQo81ngLYnO0mrkoqTHzna1H2P+Eol/T 5RxGMelYinI3gSbxJz7x0kWPadkvwvi7DKqAjjU/H1zdp7hkPqqYaB3NuqEUOrmr k3Uri1fP3e75pbVCsmGx0dK8THo6b67Nh7Yenh54o5k0G+EcTtIQ/7HPzcd/6hnW 2+A9ZcMNB6ix86DhyG62UW8RlZmfbb14Bpk2Y61aLtJibZ2ojqTFiOg1nqXURThi 4lJLS87CyB4FZvvSOG4BPT/FqcnzT68gdfmcaQS3Fi+gsWL4e3tFtLzCMRWyeL1F ERK3DeaW9Qbmvbv3NI5/SJQcgQUUM1R+mzu8fekI7TFTHnPRbwXfcev5WIf2MPOf E+C15LGJzS/1Bineby45YPhzbs8lYgICh2NZpm7VoQxpIfzwVz+k4bUQowRn0HkR L7zQC7ugK4jfMEqM8HMZZxVc09SGqzI58Ik+kls/BU0/QSe1tDMkCfa0KtwAhct5 9V2rh/8l//8RdeZzqlgFaduPK66rmtago3YffEbGi0cYkv1hfduMRb/mEhEbMnuR Yw3bfBX/Jv/EnkOmsEmSysJoXeGOalrvfAZfD4d4MqfG2PZL2bQ7iYLcaK9NMy/s u4UbsdQMnwTl2gJIyr1VyA/ax39dzV4yvQc3ElWh4nRzMzpX
=OOeC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat Dec 7, 2024 at 5:39 PM GMT, Andrey Rakhmatullin wrote:

No, there is clearly no consensus on unifying any workflows. Everyone
thinks their workflow is superior and canneeds to stay.

I'm more optimistic than this. I don't think we'll ever reach *one*
workflow, but I think there may be a steadily emerging consensus about a common "highway" workflow. So long as it's not mandatory, and we
recognise that many packages will not be suited to it, I hope even those
who won't be transitioning to it would recognise the value of having it.

On Sat, Dec 07, 2024 at 02:34:20PM +0100, Andrea Pappacoda wrote:

Couldn't we decide to unify on a single "front end" command, which
chooses different backends automatically depending on the situation?

I can see the appeal of having a single "front-end" for this (and many
other actions), especially for newcomers, but I think the general
approach of introducing a new front-end wrapper would cause more harm
than good.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat 07 Dec 2024 at 05:50pm GMT, Holger Levsen wrote:

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.

Right. And there are many package-specific needs.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)