Re: Cleaning salsa build cache before a new build
Le 02/10/2025 à 05:51, Otto Kekäläinen a écrit :
I will try to send you a MR with these fixed later in the week if I have time.
I sent these now in
https://salsa.debian.org/debian/taktuk/-/merge_requests/3 and
https://salsa.debian.org/debian/taktuk/-/merge_requests/4 but really
the repository should also be renamed to use DEP-14 branch names to
not conflict with upstream, and the rename can't be done as a MR.
Would you like me to fix the repository branches and settings for you?
Not now, thanks. I've several scripts to change on my side
when I will rename the branches. And then, I will do it for all my repos
at once.
I found my problem: after fixing my initial mistake, I force-push all branches.
But I forgot to force-push tags. And upstream/3.7.8 was pointing to the previous (wrong) state.
Again, if you have debian/gbp.conf correctly and do all imports with
`gbp import-orig --uscan`, all the branches and tags will
automatically be correct and there is no need for manually fiddling
with them as you described in your email.
Thanks, you help pointing to debian/gbp.conf. This is what explain
the different behavior on salsa CI and locally: I have a $HOME/.gbp.conf
with "pristine-tar = True". When I remove it, "gbp export-orig"
also use the tag locally.
I will quickly push a debian/gbp.conf in all my packages (and, at
this point, I will probably also make the DEP-14 branch rename).
However, I said before, I've always used `gbp import-orig --uscan` to
import a new upstream version. The $HOME/.gbp.conf makes it be possible.
My initial mistake comes from the fact that `gbp import-orig --uscan`
does *not* re-download the tarball if one is already present.
I did a `gbp import-orig --uscan` with the old watch file. I see
many changes in upstream sources, most of them were due to autogenerated
autoconf files being updated. So I change debian/watch to point
to upstream gitlab tags[1], but I forgot to remove the local (previously
downloaded) tarball. So, after locally resetting all branches, my
second `gbp import-orig --uscan` correctly look at upstream git tags
but import in my local git the state of the previous tarball.
I did not see that initially and push it to salsa.
When I saw that, I locally, again, reset all branches and remove tags.
I also removed the (local) tarball. And I did a third
`gbp import-orig --uscan`.
The local state was good, then. I force-pushed to salsa but I
forgot to remove and repush salsa tags. And, as I did not add a
debian/gpb.conf, salsa CI used the (wrong) salsa upstream/3.7.8 tag
to create the tarball.
Regards,
Vincent
[1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor shows us that
autogenerated autoconf files can be used to hide attacks. That is
why I would prefer to base upstream tarball on upstream git tags
instead of upstream (hand-made with "make dist") tarballs.
Reply to: