Re: Updating khal to fix RC bug #1023341
Hello Jonas, On 16/12/2022 20:53, Jonas Smedegaard wrote: Seems I only_after_ last release corrected the watch file to fetch from true source at Github. If I guessed wrong and it was something else, then please just ask. You guessed, now I see, many thanks! Cheers, -- Daniele Tricoli https://mornie.org OpenPGP_0x8BAF522C0D6CCEDD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Updating khal to fix RC bug #1023341
Quoting Daniele Tricoli (2022-12-16 20:03:09) > Hello Jonas, > > On 16/12/2022 15:10, Jonas Smedegaard wrote: > [CUT] > > > I will have a closer look now, then get back to you. > > Oh, many thanks! :) > > > Ususally when I "look" at a package I routinely update it as well. > > I like this approach, it keep all the stuff clean. > > > 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. :-) > > I would love to learn, but please don't roll back your changes, time is > our most precious resource. :) > > I made a copy of my local clone and I dropped all the new commits you > made, so I will be able to use the DIY approach. :) > I must confess that I peeked at the new commits while I was searching > the commit I had to halt the dropping, so I already know that repacking > is not needed anymore, but for me the mystery about the release 0.10.4 > remains and I'm eager to learn about it... if you have the time to > explain. :) I am happy to elaborate more. Let me guess: What is still a mystery to you is PKG-INFO file in older releases? Seems I only _after_ last release corrected the watch file to fetch from true source at Github. If I guessed wrong and it was something else, then please just ask. - 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 signature.asc Description: signature
Re: Updating khal to fix RC bug #1023341
Hello Jonas, On 16/12/2022 18:51, Jonas Smedegaard wrote: 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. Thanks you did the right thing, thanks for taking care of khal, unfortunately I was able to look at this list only now and your last email just arrived to my MUA after I sent my previous one. 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. Many thanks, it is know: I was lost between second and third layer! I have now updated our replacement routines plus a range of other householding changes, and released the new packaging release. Thanks for this! 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. We are a team. ;) ...so I have now also sprinkled a few comments in debian/rules file, to aid future baffld Debian maintainers. countless Cheers, -- Daniele Tricoli https://mornie.org OpenPGP_0x8BAF522C0D6CCEDD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Updating khal to fix RC bug #1023341
Hello Jonas, On 16/12/2022 15:10, Jonas Smedegaard wrote: [CUT] I will have a closer look now, then get back to you. Oh, many thanks! :) Ususally when I "look" at a package I routinely update it as well. I like this approach, it keep all the stuff clean. 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. :-) I would love to learn, but please don't roll back your changes, time is our most precious resource. :) I made a copy of my local clone and I dropped all the new commits you made, so I will be able to use the DIY approach. :) I must confess that I peeked at the new commits while I was searching the commit I had to halt the dropping, so I already know that repacking is not needed anymore, but for me the mystery about the release 0.10.4 remains and I'm eager to learn about it... if you have the time to explain. :) Many thanks in advance, -- Daniele Tricoli https://mornie.org OpenPGP_0x8BAF522C0D6CCEDD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Updating khal to fix RC bug #1023341
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 signature.asc Description: signature
Re: Updating khal to fix RC bug #1023341
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. :-) > P.S. Jonas I don't know if you are subscribed to this list, so I'm > adding you to CC. Thanks, I am indeed not subscribed to the list, so please keep me cc'd in this thread. - 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 signature.asc Description: signature
Re: Python 3.11 for bookworm?
On 12/15/22 16:18, Thomas Goirand wrote: On 12/13/22 00:51, Graham Inggs wrote: Dear Python Team Looking at the current state of the 'adding Python 3.11 as a supported version' transition [1], the tracker [2] shows only 12 red packages (excluding unknowns and packages not in testing) remaining, copied below for reference. We believe all FTBFS and autopkgtest regression bugs have already been filed and tagged. The current state of bugs tagged 'python3.11' [3] is 116 resolved and 49 still open. Many thanks to everyone who has contributed to fixing these, and especially to the organizers of the recent Python sprint [4]. As this transition is non-blocking (i.e. uploaded packages are able to migrate ahead of python3-defaults), we could wait for the remaining bugs to be fixed, or for auto-removal to take its course. However, with the bookworm transition freeze only one month away [5], we'd like to hear from the Python Team within the next week whether they wish to proceed with Python 3.11 being the only supported version for bookworm (in which case we will allow python3-defaults to migrate right now) or, revert the changes in python3-defaults and have Python 3.10 as the only supported version for bookworm. Should it be the former, we'd like an undertaking from the Python Team that they will help resolve the remaining bugs against key packages [6], as these cannot easily be avoided by manual or auto-removals. On behalf of the Release Team Graham Hi Graham, For OpenStack, I believe I was able to fix all Python 3.11 bugs (often with the help of upstream, a few times, on my own but very trivial fixes like the easy getargspec -> getfullargspec). The remaining filled RC bugs because of Python 3.11, I don't really mind (even if these 5 packages are AUTORM, I'm fine with that, they aren't key packages from the OpenStack perspective). However, there's still one very annoying bug in flask-restful that makes it not rebuild under Python 3.11. Keystone needs flask-restful, so I *must* fix it. Note here that #1024913 is because of another issue (ie: the autopkgtest functional test doesn't support more than one available Python interpreter, though it's easy to fix: simply kill the server between runs...). Though it hides the real FTBFS issue (failure in unit tests), which I believe is probably due to my upgrade of werkzeug 2.2.2 rather than Python 3.11. Help would be greatly appreciated fixing this bug. Hopefully, I can get this done during my holidays (and avoid any other work...). Cheers, Thomas Goirand (zigo) FYI, I have just uploaded a new Debian release of this package that fixes all the issues, thanks to a colleague of mine that had time to help (which I didn't really have...). So, I believe I'm all good regarding OpenStack packages right now (even if that last one was werkzeug 2.2.2 related, not python 3.11). Cheers, Thomas Goirand (zigo)
