XPost: linux.debian.devel, linux.debian.policy
From: sanvila@debian.org
On Wed, Feb 11, 2026 at 02:48:19PM +0100, Jochen Sprickerhof wrote:
> * Santiago Vila [2026-02-11 14:37]:
> > Sorry, I can't give examples because I did not take notes, but I
> > remember that it was not a mismatch between orig tarball and git
> > branch (I am usually quite careful about that) but rather some
> > difficulty from Salsa CI to create an orig tarball. I believe it had
> > something to do with uscan and the flaky network connectivity of
> > ftp.gnu.org some weeks/months ago.
> >
> > I know Salsa CI uses some heuristics to create the orig.tar.gz and
> > it uses uscan and the watch file in some cases. I assume there
> > is a high overlap between Salsa CI having to do that and
> > lack of a pristine-tar branch.
>
> salsa-ci uses gbp export-orig and falls back to origtargz in case that fail:
>
> https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/
alsa-ci.yml?ref_type=heads#L440
>
> gbp export-orig uses only git and does not use pristine-tar by default.
> origtargz can fallback to uscan. So it would be even more interesting where
> it failed for you.
I see gbp export-orig tries to use the upstream tag when there is no
pristine-tar branch, so it's possible that I just forgot to push the
upstream branch with its tag. This might have triggered the origtargz
thing, which in turn may have failed because of poor connectivity at
ftp.gnu.org and the fact that it was a -1 version (because Salsa CI
is also able to get the tarball from the archive when it exists).
That's my best theory so far. Sorry that I can't provide more details,
this is the kind of thing that you forget about when you find a
workaround that works.
Thanks.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
