Re: Cleaning salsa build cache before a new build
Hi,
Thanks for trying to help me.
Le 30/09/2025 à 20:51, Otto Kekäläinen a écrit :
[...]
The GitLab CI cache is used by ccache to avoid rebuilding the same
files over and over. The cache has nothing to do with the tarball.
Yes, I did not know the cache before someone tells me about it and show
me the web button to force-clean it. But I agree (reading the log) that
is is orthonal to my problem.
I checked out your repository, https://salsa.debian.org/debian/taktuk
and I don't see any commits related to "hand-made tarball",
Yes, there is nothing about it now.
Short story: I pushed to salsa my repo with pristine-tar pointing to
the hand-made tar.gz, then I fixed it locally and force-pushed to
salsa. So my previous mistake is not visible anymore in the git
history on salsa.
Long story :
Initially, I used "uscan" to see if the new upstream version was
detected/downloaded. Then, I talked to upstream to ask him to add
tags in the git repo, in order to get the tarball from the git
(instead of a hand-made tarball done with "make dist" by him).
Then, I changed and fixed debian/watch, checking with
"uscan -v -v --no-download". Eventually, I called
"gbp import-orig --uscan".
However, I missed here, that uscan did not re-download the tarball
as it found one with the same name (downloaded at the beginning,
before changing debian/watch, so being the hand-made tarball).
I went forward, pushed to salsa and upload the new version.
You can see the successful build on salsa here:
https://salsa.debian.org/debian/taktuk/-/commit/c621eab93df65df781307db733277b2f5e6efe4b
Then, dak refused my package, arguing about a new binary package.
I looked more in details, and see that:
1) I missed the NMU about the time64_t transition
2) the tarball in pristine-tar was not the good one
So, I modified all by branches (master, upstream and pristine-tar)
to go back to my initial state.
I applied the NMU patch
I cherry-pick the commit modifying debian/watch
I removed the local (previously downloaded) tarballs
I used "gbp import-orig --uscan"
I cherry-pick my other commits (cleanup, etc.)
I manually removed ../build-area/taktuk_3.7.8.orig.tar.gz (else the build use this
wrong tarball instead of getting it from the upstream and pristine-tar branches)
I locally rebuilt the package (gbp buildpackage ...)
I built the package on a remote machine with a sbuild setup
I pushed to salsa where I cannot get a correct build due to the use of the
presence of the previous taktuk_3.7.8.orig.tar.gz tarball
I ignored the salsa problem and (forced) upload to dak the 3.7.8-1 version again
This upload has been accepted into sid.
so the
issue you describe is not specific to Salsa CI but in general anyone
trying to build your package sources you mention are not visible in
the git branches:
The git branches are now correct. The wrong one are not visible anymore
due to force-push. If you really want to see them, I should be able to
recover them locally with the help of "git reflog" but I do not see
what it will do.
The problem on salsa is the persistence of the wrong tarball on its disk
and the use of this tarball in order to unpack the sources instead of
using the contents of the upstream and pristine-tar branch.
It is not a big deal: it will be "fixed" when there will be a new
upstream release (salsa will then get the tarball from the git repo).
It seems that the "hand-made tarball" you mentioned only exists on
your own computer?
The hand-made tarball is the one linked from the website page:
https://taktuk.gitlabpages.inria.fr/download.html
Upstream builds it by running "make dist" locally and putting it on the webpage.
As seen with the ssh attack last year, this is a weak process. It is difficult
to see the (real) changes with this tarball. I knew that the 3.7.7 and
3.7.8 were very similar, but the changes in the two tarball are important
due to the update of lots of autotools generated files.
If you want to exclude files from the upstream tarball, the best way
to do it is to add an Exclude-Files section to your debian/copyright
file. After that any time running `gbp import-orig --uscan` or just
`uscan` will fetch and repackage and commit the correct upstream
sources. You can see a documented example of this in
https://salsa.debian.org/go-team/packages/golang-github-lorenzosaino-go-sysctl/-/merge_requests/1
I did that before to exclude improper files (bad licences, ...)
Here, it is not the case. It the choice to get the tarball from the
upstream git tag, instead of getting the tarball from the upstream
webpage. Getting it from git avoid all auto-generated files from
autotools.
Without the help of a salsa admin, if I want to fix this before
the next upstream version, all I can imagine is to provide a CI file
that remove this tarball.
Regards,
Vincent
Reply to: