Re: Update PyZstd to 0.16.0+ds-2 to fix FTBFS bug
Hi Yokota, yokota, on 2024-06-17: > Hello Étienne, > > PyZstd package was updated to fix FTBFS bug on Calibre and Py7zr. > Please upload it to Debian. > > https://salsa.debian.org/python-team/packages/python-pyzstd I had a look at your changes and saw they consisted in enforcing the build dependency on libzstd >= 1.5.6. Checking closely, the mere rebuild of the package resolved the various bugs, which suggested the package could have been eligible to a binary only NMU[1] instead of a full fledged upload. Nevertheless, the symbols discrepancy resulted in serious issues affecting other packages, and your changelog contained enough metainformation to close the identified bugs, so I thought better to upload. [1]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus Thanks for your continuous work on maintaining Python compression modules! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/6, please excuse my verbosity `-on air: Threshold - Choices signature.asc Description: PGP signature
Re: DPT ideas to organize
Hi, Am Mon, Jun 17, 2024 at 02:07:55AM -0400 schrieb Louis-Philippe Véronneau: > > Another > > question is: what should we do with packages that are not under the > > team's umbrella but are affecting Python 3.12? Salvage[2] those packages? > > On the other hand, we could assess if there are any improvements needed > > in our tools, such as pybuild, or determine which packages require, for > > instance, autopkgtests, lintian, etc. Or maybe we can start making short > > IRC meetings once a week or every two weeks? Experienced members > > of the team, do you think this is feasible given the DPT workflow? I > > would like to hear the opinion from the team :-) > > > > > > [0] https://deb.li/3T4QN > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025181 > > I agree with the points you raise. It's true the DPT isn't a very organised > entity (although there's much worse teams in Debian :9). I agree as well (with both ;-) ) > I think more would be possible if we were more organised. Having regular > meetings would surely help. Possibly IRC meetings (as far as I know Perl team is doing so) might be some first step. > On my side though, I sadly don't have time for that. I'm already part of > plenty of Teams in Debian (some of which do have regular meetings, like the > DebConf Videoteam) and I only have so many spoons... If others want to push > this way, I'll root for you! +1 > That said, if I had more time, I would probably prioritise reviewing and > sponsoring more DPT packages, something I haven't done in a while. I'd also recommend the "advent bug squashing party" done by the Debian Med team. We do team wide bug squashing from Dezember 1st - 24th and everybody tries to squash a personal bug of the day (no matter who is Uploader of the package). Kind regards Andreas. [2] https://wiki.debian.org/PackageSalvaging -- https://fam-tille.de
Re: Handling sponsorship requests by new contributors (was: Request for Python Team assistance in Debian Mentors)
Am Sun, Jun 16, 2024 at 06:56:51PM +0200 schrieb Peter Wienemann: > > What we could do if the idea of giving broad commit rights to newcomers > > poses issues is to create a specific namespace in python-team for > > newcomers. (then we'd need to have some migration plan and then oh dear) > > I agree with both of you that it would be good to encourage new contributors > to put their Python packages in the Python team namespace. ACK. My personal policy is to sponsor only packages from some team space in Salsa for various reasons, mainly because: 1. The sponsee should feel connected to some team to make me as sponsor "replaceable" by other team members. 2. Its way easier if I commit some slight changes to Git myself and write extensive commit messages than asking the sponsee to do change XY and move it to mentors again. I'm fine with using some sub-namespace (never worked with this in other teams but it might be appropriate here). Kind regards Andreas. -- https://fam-tille.de
