Xiyue Deng <manp...@gmail.com> writes: > Nicholas D Steeves <s...@debian.org> writes: >> Xiyue Deng <manp...@gmail.com> writes: >>> Nicholas D Steeves <s...@debian.org> writes: > >> Also, do you use this package? >> > > Not on a regular basis, but I do use it a bit once in a while as I try > to learn a bit of new programming languages every few months.
Putting yourself in Uploaders means you're going to take a special (and regular) interest in a package in the long term. Is that really what you intend? >> Meanwhile, compression type isn't the problem: >> >> gbp:info: Tarballs 'scala-mode-el_1.1.0+git20221025.5d7cf21.orig.tar.gz' >> not found at '/home/sten/devel/tarballs/' >> gbp:error: v1.1.0+git20221025.5d7cf21 is not a valid treeish >> > > This is because I didn't push the tag to the repo yet. Now this is > done. Thanks. When pushing upstream history, one needs to also push the upstream tag. >> and at the same time, the proposed switch to xz is also arguably a >> regression, because the actual upstream release tarballs of scala-mode >> are currently being used: >> >> $ apt source scala-mode-el >> $ md5sum scala-mode-el_1.1.0.orig.tar.gz >> 615b1f38ed083137fee99fa83fe452a1 scala-mode-el_1.1.0.orig.tar.gz >> # Download release tarball from github manually, or use uscan >> $ md5sum ~/Downloads/emacs-scala-mode-1.1.0.tar.gz >> 615b1f38ed083137fee99fa83fe452a1 >> /home/sten/Downloads/emacs-scala-mode-1.1.0.tar.gz >> >> This indicates that the human maintainer doesn't use "git deborig". >> Being able to reproduce the imports of official upstream tarballs is >> important to a number of developers, and some workflows depend on this >> assumption, so please don't break it. >> > > In this specific case as I'm targeting a snapshot so there is no > upstream tarball, so using xz provides the benefits of a smaller source > tarball that saves space for the Debian source repository. > > For the aspect of the consistency with upstream release tarball, I'm > trying to understand how to make this work. I believe "gbp import-orig > --uscan" should grab the upstream release tarball which follows your > suggestion. However IIUC the repository is configure using the > dgit-maint-merge workflow that uses upstream branch to target upstream > repo and hence uses the tagged version to generate upstream tarball, > which I believe is incompatible with "gbp import-orig --uscan" approach > which directly import the release tarball without the git history. What does "IIUC" mean? This repository doesn't use dgit workflow. Gbp can optionally merge git history. If upstream provides release tarballs in gz rather than xz, and the Debian Maintainer/Uploader uses those, then the repository needs to be configured for gz and not xz. Note that d/watch previously specified gz. Changing that configuration is working against the Maintainer/Uploader. Given this, it is more correct to configure gbp to use gz until upstream switches to xz. "Git deborig" should also be invoked to use gz. > I wonder whether there is a way for "git deborig" or "gbp > buildpackage" to grab upstream tarball automatically? I'm guessing > not, so someone has to do it manually, but please let me know if there > is a way. What do you mean? Just use uscan, or origtargz. Or do you mean accommodating the case where you think moving from a stable release to a snapshot is justified? Tell upstream that Debian highly values stable releases, and convince them to tag one. Problem solved. P.S. I read a message you wrote to an upstream about this, and that github issue didn't look like it would convince anyone of the value of tagged releases...please do better in the future. Nicholas
signature.asc
Description: PGP signature
