Bug#1067014: accesses internet during build
Source: mapclassify Version: 2.6.1-3 Severity: important Hi, During the build, mapclassify is using intersphinx, which is collecting information from the internet during build. Please remove the intersphinx module from docs/conf.py. Cheers, Thomas Goirand (zigo) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1043240: transition: pandas 1.5 -> 2.1
On 12/11/23 08:12, Matthias Klose wrote: On 10.12.23 14:06, Rebecca N. Palmer wrote: I'd like to move forward with the pandas 1.5 -> 2.1 transition reasonably soon. Given that pandas 2.x is *not* required for Python 3.12 (but is required for Cython 3.0), should we wait for the Python 3.12 transition to be done first? These are broken by pandas 2.x and have a possible (but untested) fix in their bug - please test and apply it: dask(?) dials influxdb-python* python-altair python-feather-format python-upsetplot seaborn tqdm* (* = this package is currently also broken for a non-pandas reason, probably Python 3.12, that I don't have a fix for) These are broken by pandas 2.x and have no known-to-me fix: augur cnvkit dyda emperor esda mirtop pymatgen pyranges python-anndata python-biom-format python-cooler python-nanoget python-skbio python-ulmo q2-quality-control q2-demux q2-taxa q2-types q2templates sklearn-pandas Some generic things to try are pandas.util.testing -> pandas.testing, .iteritems() -> .items(), and if one exists, a more recent upstream version. Is this an acceptable amount of breakage or should we continue to wait? Bear in mind that if we wait too long, we may be forced into it by some transition further up the stack (e.g. a future Python or numpy) that breaks pandas 1.x. up to the maintainers. But please wait at least until the current pandas and numpy migrated to testing, e.g. that the autopkg tests of pandas and numpy triggered by python3-defaults pass. Is there a way to see the binNMUs which are still stuck in unstable, and don't migrate? Matthias As a reminder: it's best practice to first upload the new release to Experimental, so we can see what happens with autopkgtest before destroying everything at once... Cheers, Thomas Goirand (zigo) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#943135: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/22/20 6:23 AM, Valentin Vidić wrote: > On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: >> You can remove all of the python-oslo* from the list. The versions in >> Experimental, which are the next version of OpenStack, are fixed. In 2 >> weeks of time, I'll upload all what I staged in Experimental to Sid >> (maybe 150 packages?) and that's going to fix it all. > > Will the new OpenStack version also fix this issue? > > #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: > 'Sphinx' object has no attribute 'info' Hopefully yes. As I understand, the issue is in oslo-sphinx, which is deprecated. I checked, and the master branch of murano-pkg-check doesn't use oslo-sphinx (and is therefore fixed). I'm waiting for it to be released, hopefully this week or the next one. Cheers, Thomas Goirand (zigo) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#943135: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 2:51 PM, peter green wrote: > On 20/04/2020 08:57, Thomas Goirand wrote: >>> Option 1: fix all four packages to be python 2 free. >>> >>> Option 2: Remove python2 stuff from traceback2, python-funcsigs and >>> numba. Break the dependencies of nipype in sid. >>> >>> Option 3: Remove python2 stuff from traceback2, modify python-funcsigs >>> so it still builds the python2 package but does not run tests with >>> python 2. >> Funcsigs is a backport of the PEP 362 function signature features from >> Python 3.3's inspect module. > Thanks for the info. >> Python 2 has never been removed from this >> package. Though instead, we shall remove this source package entirely >> from Debian. > # Broken Depends: > nipype: python-nipype > pytest: pypy-pytest > python-logfury: python3-logfury > python-oslo.utils: python3-oslo.utils > > # Broken Build-Depends: > beaker: python3-funcsigs > kombu: python3-funcsigs > nipype: python-funcsigs > pagure: python3-funcsigs > pytest: pypy-funcsigs > python-oslo.log: python3-funcsigs > python-oslo.utils: python3-funcsigs (>= 0.4) > ripe-atlas-cousteau: python3-funcsigs You can remove all of the python-oslo* from the list. The versions in Experimental, which are the next version of OpenStack, are fixed. In 2 weeks of time, I'll upload all what I staged in Experimental to Sid (maybe 150 packages?) and that's going to fix it all. For the others, probably I should start filling bugs... > If what you say is correct then it sounds like the python3-funcsigs > revese depedencies could be dealt with fairly easily. > > But that still leaves the question of what to do about the dependency of > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > it's reverse-dependencies in the same way that regular python2 modules > were? how feasible is that? are pypy-* packages only useful with python2 > pypy or are they also useful with python3 pypy? I really don't know about pypy. Probably the pypy-pytest should indeed go away, as the initial plan was to switch to pypy3. Maybe tumbleweed (Stefano Rivera) would be able to answer. I'm adding him as Cc. >> Traceback2 *already* has Python 2 support removed in Sid. I uploaded >> this on the 21st of march, pressured by its potential autoremoval. > > Sorry it seems I got my package names mixed up when writing the list of > options. I said traceback2 where I meant unittest2. So, if I'm following correctly, what you seem to propose, is to remove Python 2 from unittest2. If that's the case, then I agree with such a plan. I just didn't dare to do it yet. Though in fact, I already worked on that, but stopped, also because unittest2 FTBFS when I try building it on my laptop. So I've pushed it in its normal Git repo [1] under a py2-removal branch. If anyone has some time available to look at it, that'd be nice (I currently don't...). Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/python-team/modules/unittest2/ -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#943135: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 4:36 AM, peter green wrote: > (using -quiet aliases where multiple involved packages have the same > maintainer listed. > > Hi > > I have just been running some self-contained buildability tests on > bullseye and these tests indicated that the python-linecache2 and > python-traceback2 source packages have been unbuildable in testing for > 170+ days. Both are fixed in unstable by removing python 2 support, but > can't migrate to testing because the python-unittest2 binary package > depends on the python-traceback2 binary package. The python2 removal bug > for python-traceback2 lists python-funcsigs as a blocker. The python2 > removal bug for python-traceback2 lists nipype and numba as blockers. > > unittest2 and python-funcsigs seem to be just module packages, so > dropping python2 support should be simple. numba seems to be a case of > leftover recommends and test-triggers so that should be a pretty easy > job to clean up too. > > nipype on the other hand looks like it needs a new upstream release. It > seems this was previously blocked on a package passing new, but said > package has now passed new. > > python-funcsigs seems to have a build-dependency on python-traceback2 > but not a binary dependency, this suggests that the dependency is only > used to run tests at build time. > > nipype and numba are not currently in testing. > > This IMO leaves three potential ways forward > > Option 1: fix all four packages to be python 2 free. > > Option 2: Remove python2 stuff from traceback2, python-funcsigs and > numba. Break the dependencies of nipype in sid. > > Option 3: Remove python2 stuff from traceback2, modify python-funcsigs > so it still builds the python2 package but does not run tests with > python 2. Funcsigs is a backport of the PEP 362 function signature features from Python 3.3's inspect module. Python 2 has never been removed from this package. Though instead, we shall remove this source package entirely from Debian. Traceback2 *already* has Python 2 support removed in Sid. I uploaded this on the 21st of march, pressured by its potential autoremoval. > If the maintainers of nipype are willing to upload a python 3 version > soon, then option 1 is IMO the preffered way forward, but a new upstream > version is not something I would be prepared to NMU. There's no other choice but to fix nipype at this point, or wait until it gets autoremoved from Testing. IMO, it'd be fine to NMU a new upstream release if you contact the current maintainer and/or using the delayed queue. > Otherwise I am inclined towards option 2. Depending on what responses I > get to this mail I may implement this option through NMUs later. IMO, we should get unittest2 free of Py2 support ASAP, and open an FTP team bug to get funcsigs removed from Debian. Cheers, Thomas Goirand (zigo) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#938661: theano: remove python2
Hi Rebecca, I've just uploaded the Python 2 removal from deepnano (ie: I switched it to Python 3). It looks like working... ;) So, now there's no blockger for theano. Please upload what I saw you commited in the Git repo for Theano! Since you're a DM, I'm guessing you already have a ACL for this package. If you still need sponsoring, let me know, and I'll sponsor the upload for you. Thanks for your work, Cheers, Thomas Goirand (zigo) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
