Hi Otto, Thank you for your email. I also have questions would like to ask the same. :)
You are correct. It was meant for experimental and might be thrown away or might be able merged when it's suitable for upload into unstable. Due to I'm not enrirely certain the changes are suitable for unstable at the moment. So I target my MR into debian/experimental branch and the package were upload into experimental as well. However, these broken packages in unstable were serioutsly, out of date. I don't think it's suitable to use these as excuse to prevent any updated package upload into experimental. My attention was trying to prepare updated packages in debian/experimental, which helps for packages that I wanted to package for Debian(also in experimental first) and may also benefit others to updating or packaging packages for their need. Thank you for point out the `debian/gbp.conf` settings and `Vcs-tags` in `debian/control` file. Can we put these into team workflow please? So I may keep tracked them correctly for future uploads. I hope not to blocks anyone. Please feel free to fix any of the package I already uploaded into experimental without suitable changes on these in the meantime. I was also confused and unable to build from `debian/latest`. And then I use `uscan --download-current-version` to fetch the tarball, and then the package builds. I found team workflow that says the pristine-tar branches should goes away, but still exist: https://go-team.pages.debian.net/workflow-changes.html Hi Team, Since I was the first time and also the last one who touch the repo. Could someone who has more experiemce may give me some hints on how to clean up the current mess in `golang-go.crypto` repo or may clean up the mess directly? Best regards, -Andrew On Mon, Jan 19, 2026 at 5:00 PM Otto Kekäläinen <[email protected]> wrote: > > Hi, > > What is the status with golang-go.crypto? > > I see Andrew uploaded a new version to experimental. What is the plan > for putting it in unstable? > > There are at least two reverse dependencies failing. Are you planning to > fix them or shall we just abandon the experimental upload and continue > with current version? > > Gitaly is already broken in debci and has unsatisfiable build > dependency, it might be reasonable to ignore it for now. The version > of golang-github-azure-azure-sdk-for-go is very old as the > debian/watch is misconfigured and unaware of new versions. > > Why did you do the commits on a new branch debian/experimental? Are > you thinking those commits were temporary and might be thrown away > instead of being done on the default branch? When are you going to > merge in on debian/latest? Are people who want to make improvements to > the package expected to target MRs on debian/latest or on > debian/experimental? If you upload from the non-default branch, should > you change it to the repository default branch? Or in the upload add a > `-b debian/experimental` suffix to the debian/control:Vcs-Git line so > that vcswatch can keep track of that real state of the package? > > > Status pages: > https://tracker.debian.org/pkg/golang-go.crypto > https://tracker.debian.org/pkg/gitaly > https://tracker.debian.org/pkg/golang-github-azure-azure-sdk-for-go > > Also I am not able to build neither the current debian/latest nor > debian/experimental as it fails on: > > gbp:info: Creating /debcraft/golang-go.crypto_0.45.0.orig.tar.xz > gbp:error: Cannot find pristine tar commit for archive > 'golang-go.crypto_0.45.0.orig.tar.xz' > > Maybe a `gbp push` was forgotten? > > Or if you intentionally want to stop using pristine-tar,t hen remove > it from debian/gbp.conf? -- -Andrew
