Request to join Python Modules Packaging Team
Hi Any Project Admins for python-modules on Alioth around? I sent a request to join on Alioth some time ago but it hasn't been approved. My username on Alioth is 'ginggs-guest'. I'd like to do some QA work on python-messaging [1], orphaned in bug #787110. Python-messaging's VCS is already on Alioth [2]. Regards Graham [1] https://packages.qa.debian.org/p/python-messaging.html [2] http://anonscm.debian.org/viewvc/python-modules/packages/python-messaging/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAM8zJQsUi9muV9u7MHp4GoL=cTVVp9917ErLLvMJSJJ=f76...@mail.gmail.com
Re: Problem backporting python-pyvcf
Hi Andreas Try the following in debian/rules: export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
Re: pytest 4 and autopkgtest dependency loops
Hi Scott On Fri, 9 Aug 2019 at 18:01, Scott Talbert wrote: > However, there's one package that seems like it is going to cause a > problem. I uploaded pytest-xdist 1.29.0-1, which *requires* pytest 4, so > pytest-xdist won't migrate to testing until pytest 4 does. On the other > hand, pytest 4 won't migrate to testing until all its autopkgtest failures > (which include pytest-xdist) clear (right?). So it seems we have a loop > here. How do we resolve it? I believe the solutions is for python-pytest and python3-pytest to add Breaks: python-pytest-xdist (<< 1.29.0-1~) and Breaks: python3-pytest-xdist (<< 1.29.0-1~) respectively. Regards Graham
Re: pytest 4 and autopkgtest dependency loops
On Fri, 9 Aug 2019 at 19:28, Scott Talbert wrote: > Thanks. As an aside, what does the tilde at the end of the version number > mean? I have seen that in control files before, but I've been unable to > find anything in the documentation about it. The tilde is to accommodate backports. e.g. a backport of python-pytest-xdist might be versioned 1.29.0-1~bpo10+1 in that case, it would still be broken by (<< 1.29.0-1) without the tilde.
Re: Bug#937657: Issue with numpy under Python 3.8
Hi Andreas On Sat, 16 Nov 2019 at 16:09, Andreas Tille wrote: > Its not about testing. Its the usual build time test. If I'd do a > source upload of this package it will FTBFS under the current state > of the archive. If you look on the numpy tracker page [1], you'll see there is a note: "This package is part of the ongoing testing transition known as python3.8. Please avoid uploads unrelated to this transition, they would likely delay it and require supplementary work from the release managers." Regards Graham [1] https://tracker.debian.org/pkg/numpy
Re: Any reason why python-scipy version 1.3.1 remains in experimental?
Hi Andreas On Sun, 1 Dec 2019 at 20:36, Andreas Tille wrote: > according to the answer to an issue I opened agains scikit-bio[1] the > test suite would work with scipy version 1.3.1. I wonder what might be > the reason to stick to version 1.2.2 instaed of upgrading to the version > in experimental. In case this situation would not change in the next > weeks I'd consider to simply deactivate the said test. scipy 1.3.3-1 is NEW since 2019-11-27 [1] Regards Graham [1] https://ftp-master.debian.org/new/scipy_1.3.3-1.html
Re: Autopkgtest issues blocking python3.8 as default transition
Hi Scott On Sat, 21 Mar 2020 at 06:41, Scott Kitterman wrote: > I've gone through and statused the issues currently listed on the package > tracker for python3-defaults migration that are autopkgtest related [1]. I > stuffed it into a pastebin [2]. Thanks for your work on this! I filed bug #954395 against fdroidserver I filed bug #954403 against joblib affecting circlator and spades siconos already has a FTBFS bug #952601 I marked sagemath FTBFS bug #950147 affecting brial and sagetex Regards Graham
Re: Bug#967174: monster-masher: Unversioned Python removal in sid/bullseye
Hi Vincent On Tue, 18 Aug 2020 at 10:54, Vincent Cheng wrote: > src:monster-masher has no build dependencies on python2, the only > binary package it builds (monster-masher) has no runtime dependencies > on python2, and this package has no autopkgtests. There's actually not > a single line of python in this package. Can I go ahead and close this > bug, or have I missed something? This may have been due to libglade2-dev not being installable (#967157) Regards Graham
Re: Granting `Janitor` direct access to our teams repos
On Tue, 28 Jul 2020 at 02:19, Sandro Tosi wrote: > So: let's just make that automatic? Thoughts? +1 from me. Apparently, all that's required[1] is to give @janitor-bot commit access to the repositories. [1] https://janitor.debian.net/lintian-fixes/#this-is-great-how-do-i-get-it-to-automatically-push-improvements-to-my-repository
Re: Python 3.9 & Numba
Hi Diane On Tue, 19 Jan 2021 at 08:04, Diane Trout wrote: > Does Mo Zhou want to review the commits to numba? Or should I push them > to the main numba packaging repository? (I'm in the python, science, > and med teams) Numba is orphaned, see #935626, so I think go ahead and adopt the package and push to the main repo. > I was guessing the most likely path would be to make an experimental > release of numba 0.52.0 with the compatibility patch and then see how > pandas, astro team packages do with it. Numba is not in testing, so I don't see why you shouldn't upload directly to unstable. Packages that optionally depend on numba can upload versions re-enabling numba support to experimental and see how they fare. Regards Graham
Re: Why is isal limited to just three archs?
Hi On Sat, 16 Oct 2021 at 10:42, Thomas Goirand wrote: > > On 10/16/21 9:09 AM, Nilesh Patra wrote: > > Hi Ondřej, > > > > I see that isal package is limited to amd64, arm64 and kfreebsd-amd64. > > Is there a particular reason for this? -- Is it possible to extend > > support to other archs? > > > > Actually, a -med team package fastp has started to depend on > > libisal-dev, and this > > now is limited to the few archs isal supports. So it would be really > > nice if isal > > can build on more archs. > > > > Please do let me know. > > > > Nilesh > > Hi, > > Did you look into the source package? isal is written in assembly > language... > > Cheers, > > Thomas Goirand (zigo) I see at least an erasure_code/ppc64le directory. I did a quick test build in Ubuntu and the package built and passed its tests on armhf, ppc64el and riscv64, failing only because of missing symbols. Perhaps the reduced libisal2.symbols.arm64 can be used for other architectures as well? Regards Graham
Re: Python 3.11 for bookworm?
Hi Matthias On Wed, 21 Dec 2022 at 18:24, Matthias Klose wrote: > while we have not an 100% agreement to go ahead, I think we should aim for > 3.11. Action speaks louder than words, and there's been a whole lot of work done to push this forward. > The following steps would be: > > - accept the current python3-defaults into > testing (adding 3.11 as supported) This has been done. > - ask for a transition slot to upload (see #1026825) > python3-defaults with 3.11 as the default We're currently waiting on the PHP 8.2 (#1014460) and qtbase-opensource-src (#1025863) transitions. Although, there's been no progress on PHP 8.2, so this may be reconsidered. qtbase-opensource-src is currently blocked on a pyqt5 FTBFS on mipsel (#1026980), but there is a possible workaround. We hope to be able to start with the remaining steps soon. > - start the no-change NMUs > - file bug reports. > - fix issues > - let 3.11 as default migrate to testing. > If things don't go as planned, we could default back to 3.10. Mostly that > would > be no-change uploads, however in the case of a 3.11 specific fix that doesn't > work for 3.10, these fixes would need reverting. I have no idea who many of > these we will introduce with this transition. OK, good to know we can still back out if we have to. > Also we might want to ask for some freeze exceptions for third party > libraries, > that we can't fix before the feature freeze, unfortunately at this point we > cannot say which and how many packages would be affected. The release team is prepared to consider these on a case-by-case basis. Regards Graham
Re: Python 3.11 for bookworm?
Hi Timo, Stefano On Thu, 22 Dec 2022 at 18:46, Stefano Rivera wrote: > > Hi Timo (2022.12.22_12:56:20_+) > > > There have been rebuilds in Ubuntu that give us some idea of how much > > > work remains. I think it's tractable, but also will have some package > > > casualties. > > I have some spare time right now, and I am happy to help > > work on problematic cases, so hopefully nobody will feel left out in > > the cold with their favorite packages. > > Offhand, the one I most expect trouble with is numba. We were reliant on > upstream for the 3.10 transition, and probably will be for 3.11. > > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to > port that without upstream, but it did end up being tractable. > > I'm expecting to have more time in the upcoming weeks, too. > > So, release team, I still think we should go ahead! Thanks for committing your time to this, and for the fixes you've already uploaded (and to everyone else who has helped). Please let the release team know if you need things unstuck. Regards Graham
Python 3.11 for bookworm?
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 [1] https://bugs.debian.org/1021984 [2] https://release.debian.org/transitions/html/python3.11-add.html [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11=debian-python@lists.debian.org [4] https://veronneau.org/debian-python-team-2022-sprint-report.html [5] https://release.debian.org/bookworm/freeze_policy.html [6] https://udd.debian.org/bugs/?release=bookworm=ign=7=7=only=python3.11=debian-python%40lists.debian.org=1=1=id=asc=html#results Dependency level 2 omniorb-dfsg python-pgmagick pythonmagick xdmf Dependency level 7 boost1.74 guiqwt python-line-profiler python-xmlsec Dependency level 8 cypari2 renpy Dependency level 10 pybdsf Dependency level 13 sunpy
Re: Python 3.11 for bookworm?
Hi Andrius On Tue, 13 Dec 2022 at 07:13, Andrius Merkys wrote: > Am I right that whichever the choice, there will be only one supported > Python version in bookworm? Yes, I believe that was the decision made at DebConf 22. > I believe there are many packages that will > FTBFS with Python 3.11 as default (i.e., packages that use only the > default Python). Was there an attempt to rebuild the archive with that > setting? A typical test rebuild will only catch FTBFS in dependency level one (and maybe level two) of the transition tracker. In the higher levels, you'll get false positives due to failed imports of the modules that need rebuilding. Similarly, uploading python3-defaults to experimental and checking for autopkgtest failures will also result in false positives. For reference, the python3.11-add tracker lists 594 packages (excluding unknowns), and the python3.11-default tracker lists 351. With the ben files currently used in the trackers, packages still red on the first tracker also appear on the second. For what it's worth, an incremental test rebuild of the first three dependency levels was done in an Ubuntu PPA [3]. Roughly 80% of the packages involved in the python3.11-default transition were tested, and roughly 80% of the builds were successful. All build failures are counted here, including dependency-wait and architectures that have never had a successful build. A similar test rebuild was done in January 2022 for Python 3.10 [4] and I think the numbers indicate we are in a very similar state. Regards Graham [1] https://release.debian.org/transitions/html/python3.11-add.html [2] https://release.debian.org/transitions/html/python3.11-default.html [3] https://launchpad.net/~pythoneers/+archive/ubuntu/python3.11-default [4] https://launchpad.net/~pythoneers/+archive/ubuntu/python3.10-default
Re: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
Hi Andreas On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > Is there > any better way than editing debian/obitools.substvars in d/rules by > adding some override_dh_gencontrol? Remove the line: Cython>=0.24 from requirements.txt. Regards Graham
Re: numpydoc 1.6.0 available on salsa
Hi Chiara On Tue, 9 Jan 2024 at 19:39, Chiara Marmo wrote: > upstream kindly fixed the failing test in numpydoc for python 3.12 [1][2] and > I have patched the 1.6.0 version > Still autopkgetest is failing [3] because of an obsolete version of > python3-tabulate. > This is also stopping the upgrade of pandas [4]. > Tabulate has been updated on salsa but not uploaded yet. > > Is someone with upload rights available to upload tabulate? > This will help a lot I've uploaded python-tabulate/0.8.10-1 and numpydoc/1.6.0-1. Once both packages are built, we'll be able to trigger the autopkgtests in unstable to confirm whether the issue with Python 3.12 is resolved. Regards Graham
Re: Bug#1043240: transition: pandas 1.5 -> 2.1
Hi On Tue, 23 Jan 2024 at 14:38, Julian Gilbey wrote: > We're nearly there (the transition page says it's 99% done), and when > this transition is complete, then python3-defaults 3.11.6+ will be > able to migrate to testing. python3-defaults/3.11.6-1 with Python 3.12 as a supported version is now in testing [1]. > Yes - please don't upload it to unstable yet. Uploading to > experimental is fine. Uploading to unstable now should be fine, but maybe wait for pandas/1.5.3+dfsg-12 to migrate first (in about four hours). Regards Graham [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055085#29
