Quoting Jonas Smedegaard (2022-12-16 15:10:43) > Hi Daniele, and others, > > Quoting Daniele Tricoli (2022-12-16 07:16:24) > > I tried to update khal to block the autoremoval from testing (due > > #1023341) but it's not clear to me how to import metadata used to parse > > the package version with uscan¹ during repack of the tarball. > > > > PKG-INFO and the egg.info directory are on salsa¹ upstream branch but > > I'm not able to see them in the upstream tarballs (I looked also the > > commit on salsa with hash ba53a6bfb845ab4df3d5298f91f323b070084f4b): > > also PKG-INFO in the root of the repository is a news to me. > > > > How can I put them in the repacked tarball? In d/watch is indicated that > > for update the classic uscan invocation (through gbp) is used. > > > > The only way I can think of is to manually repack (AFAIK uscan doesn't > > support adding files before the invocation of mk-origtargz)... but it > > not seems that this was the procedure used according documentation on > > d/watch. > > > > AFAIU this mechanism was introduced to fix #1002406.³ > > > > Jonas do you have the time to explain? > > I will have a closer look now, then get back to you. > > Ususally when I "look" at a package I routinely update it as well. > Would you prefer that I roll back whatever changes I do during my > "looking at it" and guide you to gain same understanding as me? > Because if your interest is simply to get khal updated then > simpler for me is do (hopefully) all myself and only tell you without > leaving room for you to redo and potentially learn more from that DIY > experience. I am happy to do that slower process - I find it fun to > collaborate (am just not very used to it), so please do tell if you are > eager to learn. :-) As you might have noticed by now, I took the liberty of releasing my changes when I understood what was going on - because by then I had a functioning package ready for upload. It was multiple layers of cause for confusion: First layer: Upstream uses setuptools-scm to resolve release version, which is bad because it makes assumptions about things outside of the project - specifically it interacts with VCS (meta)data and assumed that is not replaced by that of another distro by the time the project is built. So our packaging patches away the use of setuptools-scm. Second layer: Our replacement involved grep'ing for upstream release version from file PKG-INFO which, as you correctly point out, is missing from upstream tarball. It was however included in previous upstream tarball, so this is an upstream change. So our replacement needed to be adjusted (to now instead grep CHANGELOG). Third layer: Debian build routines call clean target regardless if patches are applied or unapplied. Our patch affects dh_auto_clean so our replacement is extended with checking if patch is applied and skipping dh_auto_clean when it isn't. This makes it appear as if our "clean" target succeeds easily leading to the wrong assumption (at least for me) that it must be something upstream that fails - something mysteriously looking for a missing PKG-INFO file... Hope that was understandable. I have now updated our replacement routines plus a range of other householding changes, and released the new packaging release. Thanks a lot for bringing it to my attention. In fact I had old work lying around locally from July 30th that had stalled at that exact same failure, so I myself was evidently baffled as well (and then got distracted by something else), despite my having introduced the patch myself. ...so I have now also sprinkled a few comments in debian/rules file, to aid future baffld Debian maintainers. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature