Nicholas D Steeves <sten@debian.org> writes: > [[PGP Signed Part:Undecided]] > Xiyue Deng <manphiz@gmail.com> writes: > >> Nicholas D Steeves <sten@debian.org> writes: >>> Xiyue Deng <manphiz@gmail.com> writes: >>>> Nicholas D Steeves <sten@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? > I will regularly monitor the bug tracker and fix any issues regarding building and tests. I hope this is sufficient to become an uploader. >>> 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? "If I understand correctly" > This repository doesn't use dgit workflow. Gbp can optionally merge > git history. Ack. I also converted my patch using Gbp Pq and updated the forward info[1]. > > 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. I will buy your argument in this package and hence revert that change in [2]. Though I still believe preparing a release from a git tag has its value in general, especially in post-Jia-Tan world. I believe tag2upload is another step towards that goal. > "Git deborig" should also be invoked to use gz. > See above. >> 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. > Well, I think part of the problem is that the upstream is essentially MIA as the last commit was 6 months ago, which means a new tagged release is not likely to happen any time soon. Preparing the latest snapshot would be the next best thing we can do IMHO. Anyway, PTAL with my recent commits that fixes some of the issues you mentioned. > Nicholas > > [[End of PGP Signed Part]] [1] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/ed8cf56a432351c743a139173c5f121f1f73db6c [2] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/857b767743df6548a821f070711dcc9e1b8df739 -- Xiyue Deng
Attachment:
signature.asc
Description: PGP signature