[Python-modules-team] Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)
On 1/26/22 13:46, stefa...@debian.org wrote: Hi Thomas (2022.01.26_10:34:13_+) When building 3.0.7, I get: I: pybuild base:237: pypy setup.py clean Traceback (most recent call last): File "setup.py", line 8, in from pyparsing import __version__ as pyparsing_version File "/<>/pyparsing/__init__.py", line 100 major: int ^ SyntaxError: invalid syntax E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: pypy setup.py clean This feels like we need to drop pypy support for this package. Stefano, your thoughts? How should this be handled? It can be dropped, we don't need to keep much Python 2.7 stack alive any more. I'm keeping the bare minimum for virtualenvs to function, and that doesn't require this. There is one reverse-dep, python-packaging, that should have it's 2.7 bits dropped, too. SR I saw it. The package has Matthias Klose as Maintainer, no VCS, and no team. Matthias, can I NMU "your" package to remove the pypy flavor before I fix pyparsing? Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)
On 1/26/22 01:13, Nicholas D Steeves wrote: Hi Pierre-Elliott and Matthew, Pierre-Elliott Bécue writes: Source: pyparsing Version: 2.2.0+dfsg1-2 2.4.7-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the pyparsing package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. Pierre-Elliott, I noticed that Matthew was listed as an Uploader and that the Maintainer is the DPT. If Matthew is still active, then it should be enough to drop Barry from the list. Matthew, are you still active in Debian? If so, PyParsing needs work at Bugs #960548 and #997839, and this bug (#970158) can be solved at the same time :-) Regards, Nicholas When building 3.0.7, I get: I: pybuild base:237: pypy setup.py clean Traceback (most recent call last): File "setup.py", line 8, in from pyparsing import __version__ as pyparsing_version File "/<>/pyparsing/__init__.py", line 100 major: int ^ SyntaxError: invalid syntax E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: pypy setup.py clean This feels like we need to drop pypy support for this package. Stefano, your thoughts? How should this be handled? Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 10/25/21 8:18 PM, Dmitry Shachnev wrote: > However, it would be still nice to remove nose at some future point, maybe > before Bookworm release. Will do, probably for the next version of OpenStack (last one made me update 220 packages: that's a good way to review everything). > I'm impressed by the number of packages you have depending on nose, but if > they all come from the same upstream, maybe you can convince this upstream > to not rely on dead software. I believe most dependencies on Nose could be removed (for example, all of the OpenStack dashboard stuff...), but just right after a release isn't the best time to start the work... Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 10/24/21 3:24 PM, Dmitry Shachnev wrote: > Hi all! > > On Sun, Oct 24, 2021 at 01:49:30PM +0200, Lucas Nussbaum wrote: >> Source: nose >> Version: 1.3.7-7 >> Severity: serious >> Justification: FTBFS >> Tags: bookworm sid ftbfs >> User: lu...@debian.org >> Usertags: ftbfs-20211023 ftbfs-bookworm >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build >> on amd64. >> >> [...] > > It happens because setuptools v58.0.0 removed support for 2to3 during builds, > which nose relied on (because it has a Python 2 codebase). > > Instead of spending time on a proper Python 3 port, I would prefer to simply > let nose die (it is abandoned since 2016). > > If anyone is still using nose (1.x), please port your packages to nose2, > pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF > in a few weeks when I have more time. > > -- > Dmitry Shachnev Hi, I'm referenced for 55 packages. Please don't force me to do this right away, that's too much work. I very much would prefer if we could have a smoother transition. Note that it's possible that for many packages mentioned, only removing the dependency should be enough. Still, that's some work to do... :/ Other alternative would be: help with NMU fixes (or I can add any of you in the OpenStack team if you need...). Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#995783: python-marshmallow-sqlalchemy autopkgtest fails with SQLAlchemy 1.4.23+ds1-2
Source: python-marshmallow-sqlalchemy Version: 0.19.0-1 Severity: serious Hi, As per this log: https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-marshmallow-sqlalchemy/15788075/log.gz Please fix this ASAP. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#971530: dnspython 2.x breaks all of OpenStack
On 5/26/21 2:57 PM, Filippo Giunchedi wrote:
> On Thu, Oct 01, 2020 at 12:15 PM, Thomas Goirand wrote:
>> Package: python3-dnspython
>> Version: 2.0.0-1
>> Severity: important
>>
>> Hi,
>>
>> I'm sending this just to let you know that dnspython broke Eventlet,
>> which is unfortunately the base of many OpenStack stuff. As a
>> consequence, the websocket of Nova is broken over SSL, and many
>> other stuff, due to the API change in dnspython.
>>
>> I'm sending this as only severity: important, though I was considering
>> a higher severity. I'd like to first discuss the mater with the
>> maintainers of dnspython.
>
> I very much think this bug should be RC: unless I'm missing something the
> code below doesn't work but should:
>
> $ python3 -c 'from eventlet.green import socket ;
> print(socket.getaddrinfo("debian.org", 443))'
Hi,
Well, Eventlet itself works. DNSPython itself works too. Just the 2
together (ie: resolving with eventlet greedns) doesn't work. This
doesn't make any of the packages completely broken and unuseable (so
it's not RC), this is just a bug that should be fixed.
FYI, since some fixes in Eventlet, OpenStack now works... Though the
Eventlet greendns API shall still be fixed.
Cheers,
Thomas Goirand (zigo)
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#989171: Please allow not-configured resolv.conf
Source: dnspython
Version: 2.0.0-1
Severity: important
Hi,
In this commit:
https://github.com/rthalley/dnspython/commit/03176dea4c56ede85c34cf6bec127c96c85a8bf4
we're seeing:
-self.nameservers.append('127.0.0.1')
+raise NoResolverConfiguration
This, as a consequence, raises an error when Eventlet is imported, and if the
/etc/resolv.conf doesn't contain a valid:
nameserver
thingy. Indeed, Eventlet apparently instanciates a resolver object at import
time, which fails if /etc/resolv.conf doesn't have a valid nameserver entry.
This causes all sorts if issues, like this failure to build:
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html
There's about 50 packages that are having the issue, including for example
Designate (that is: OpenStack DNS as a Service).
We've been discussing the problem at large (in the BTS, and over IRC), and we
believe it'd be nice if we could have the above change reverted in dnspython
package itself.
I don't believe this issue is an RC bug, but others have a different opinion,
because they believe package building should always work, even with a non-valid
DNS configuration in /etc/resolv.conf (which is kind of right, I agree with it
in theory, but in practice I don't think this deserve such a high severity).
Your thoughts? Could this be discussed with upstream?
Cheers,
Thomas Goirand (zigo)
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#975087: Not relevant to msgpack itself
Ok, James, please do that, and I'll upload the change to msgpack. I don't think msgpack deserves a RC bug for this in the mean time. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#971530: dnspython 2.x breaks all of OpenStack
Package: python3-dnspython Version: 2.0.0-1 Severity: important Hi, I'm sending this just to let you know that dnspython broke Eventlet, which is unfortunately the base of many OpenStack stuff. As a consequence, the websocket of Nova is broken over SSL, and many other stuff, due to the API change in dnspython. I'm sending this as only severity: important, though I was considering a higher severity. I'd like to first discuss the mater with the maintainers of dnspython. Would you consider reverting the 2.0 upload, and get back to 1.16, until this can be fixed in Eventlet? FYI, the issue is tracked here upstream: https://github.com/eventlet/eventlet/issues/619 Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#958848: Bug#937769: python-funcsigs build-dependencies now unsatisfiable in testing, removal of pypy-pytest
On 6/4/20 10:33 PM, peter green wrote: > A few days ago Sandro Tosi uploaded the python-unittest2 and > python-funcsigs source packages. It seems that both of these were > effectively "team uploads" though they were not marked as such. A few years ago, I've been flamed, them banned from the DPMT for less than this... Though I don't think we should put the blame on Sandro. He did a lot and we should be thankful for his work on Python 2 removal. > The > python-unittest2 upload dropped python 2 support while the > python-funcsigs package dropped python 2 and pypy support. > > python-unittest2, python-traceback2 and python-linecache2 have now > migrated to testing, the result of this is that the build-dependencies > of python-traceback2 and python-linecache2 are now satisfiable in > testing, but those of python-funcsigs are now broken in testing. > > python-funcsigs is unable to migrate to testing because pypy-pytest > depends on pypy-funcsigs . The thing is, funcsigs is a backport of the PEP 362 function signature features from Python 3.3's inspect module (as per the package description), so it should in fact go away if possible. I'm really not sure what's going to be the faith of pypy-pytest, maybe it should be replaced by pypy3-pytest? If I remember well the discussion, we wrote that we would just disable the tests for things depending on python 2 test suites. Maybe this includes pypy-pytest? Your thoughts? Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#938756: 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) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#938756: 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/ ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#938756: 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) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#955650: python-tablib: FTBFS: E NotImplementedError: DataFrame Format requires `pandas` to be installed. Try `pip install tablib[pandas]`.
On 4/3/20 9:55 PM, Lucas Nussbaum wrote: > Source: python-tablib > Version: 0.13.0-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200402 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. To whoever reads this: the OpenStack team is no longer interested in this package (it's not an OpenStack dependency anymore), please take it over. I wont be fixing this bug. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#955473: Please upgrade to 2.7.1
Package: python3-paramiko Severity: normal Hi, OpenStack Ussuri, due next month, uses Paramiko 2.7.1. It'd be nice if we could have that version in unstable soonish. Thanks, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Bug#936806: koji: Python2 removal in sid/bullseye
On 2/14/20 2:30 AM, Holger Levsen wrote: > On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote: >> thanks! I'm gonna go ahead and file an RM bug for the following pkgs >> too: yum createrepo python-lzma yum-metadata-parser mock yum-utils >> dtc-xen deltarpm >> >> they are a closed set > > thank you for cleaning up after all of us, now that we reached containers. > (which used to be called virtualisation mainframes before... ;) > > I mean, rpm is definitly still useful to have on Debian, but yum and > friends??? I am the one that maintained yum for about a decade in Debian. Yum is (was?) useful because it does the same thing as debootstrap. Ie: with it, you can bootstrap a CentOS chroot from a Debian host, which may be useful for example if using Xen (or other virtualization systems). That was in fact my use case. Anyway, yum is kind of dead, as distros have been moving to dnf. I see therefore no reason to keep it. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1
On 12/22/19 10:22 PM, Dmitry Shachnev wrote: > Hi Sandro! > > On Sun, Dec 22, 2019 at 02:47:10PM -0500, Sandro Tosi wrote: >>> The current version packaged in Debian is very outdated, >>> even in unstable. Please consider packaging the current >>> upstream release. >> >> I'm echoing this request: the just released numpy/1.18.0 requires >> sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx. >> please consider package it at the earliest. > > Unfortunately sphinx ≥ 2.0 dropped support for Python 2. > > So I should either wait until all blocking bugs of #938528 are resolved, or > introduce a new source package like sphinx-python2 for the old version. > > However the latter solution will mean that we can no longer have shared > sphinx-common and libjs-sphinxdoc packages, and we will need to have two > versions of dh_sphinxdoc too (or one version that will generate different > dependencies for old and new sphinx). This is something I wanted to avoid, > because it is extra work for supporting a Python 2 version that will be > dead in a few days. > > Recently your script bumped many Python 2 removal bugs to RC, with the > intention to accelerate porting those packages to Python 3 (or getting them > removed). Maybe better to wait a couple of months and then just upload new > Sphinx and break its Python 2 reverse build-dependencies? > > Can you patch old Sphinx support into numpy for the time being? > > -- > Dmitry Shachnev At this point in time, I'm not sure if it is worth spending even one second on the Python 2 version of Sphinx. :) Thanks for taking care of the Sphinx packaging, I can feel the pain... Thomas ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#943937: suds: failing tests with python3.8
On 11/1/19 7:36 AM, Steve Langasek wrote: > For the moment I have worked around the failure in Ubuntu by changing the > packaging to test only against the current version of python3 and not > against all supported versions, but this is a very short-term fix given that > python3.8 will become the default in the next 6 months. Hi Steve! Thanks a lot for doing things this way, as a proper transition. I very much appreciate it. FYI, I could reproduce by adding python3.8 in the build-depends, and then using: sbuild --source-only-changes --build-dep-resolver=aspcud \ --extra-repository='deb file:///home/ftp/debian experimental main' to build the package. Then I could fix it, and I'm uploading the fix. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#937926: python-pbr package
On 10/25/19 9:46 PM, Daniel Schepler wrote: > In a message to #937926 you said that you've re-introduced python-pbr. > Could I ask where that was re-introduced? I've checked the new upload > of src:python-pbr version 5.4.3-1, and I've also checked unstable and > NEW for anything like a python2-pbr source package without seeing > anything relevant. > My bad, this is now re-uploaded a correct package now. I had to re-introduce it because python-mock needs it, and python-mock has *A LOT* of reverse dependencies that we need to fix first. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#943476: Package was fixed, but uploaded with binaries
Hi, It appears it was fixed indeed, but uploaded with binaries, and therefore didn't migrate to testing. I'm re-uploading to fix that. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#943476: django-reversion: Python2 removal in sid/bullseye + Django 2.2 support
Source: django-reversion Version: 3.0.3-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Dear maintainer, Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests (the specific reason can be found searching this source package in https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ). Please stop using Python2, and fix this issue by one of the following actions. - Convert your Package to Python3. This is the preferred option. In case you are providing a Python module foo, please consider dropping the python-foo package, and only build a python3-foo package. Please don't drop Python2 modules, which still have reverse dependencies, just document them. This is the preferred option. - If the package is dead upstream, cannot be converted or maintained in Debian, it should be removed from the distribution. If the package still has reverse dependencies, raise the severity to "serious" and document the reverse dependencies with the BTS affects command. If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". - If the package has still many users (popcon >= 300), or is needed to build another package which cannot be removed, document that by adding the "py2keep" user tag (not replacing the py2remove tag), using the debian-pyt...@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. This is the least preferred option. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list. Moreover, this package needs to add support for Django 2.2 which is is SID since 3 days after Buster is released. Your package will be AUTORM if you don't do anything to fix the situation. Cheers, Thomas Goirand (zigo) -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#936418: Please add support for Django 2.2
Hi, Your package also needs to support Django 2.2, which is in Sid, and which your package is blocking the transition. At this point, as there's only 4 Django packages remaining, your package may be left behind and AUTORM from Testing. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#943474: Doesn't build with Django 2.2
Source: django-modeltranslation Version: 0.12.2-1 Severity: serious Hi, Your package doesn't build with Django 2.2, which is blocking is transition to Testing. Please fix this ASAP. This also means fixing Py2 removal, as there's no Py2 support in Django 2.2. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#937926: Lowered severity
Hi, I've re-introduced python-pbr, so the severity of this bug can be lowered back to just 'important'. We'll revisit Py2 removal from this package once these are fixed: http://sandrotosi.me/debian/py2removal/python-mock_1.svg Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#933921: src:python-tablib: Unsafe use of yaml.load()
On 8/6/19 1:58 AM, Joseph Herlant wrote: > Hi, > > Thanks Scott for the report. > Tomas: the repository in Openstack was archived long ago because it > was ported to https://salsa.debian.org/python-team/modules/python-tablib > The module is used by other packages than openstack (like > django-tables if I remember correctly), so could you please hold off > the removal request please? > If the repo in the openstack group bother you, you can drop it but > please don't drop tablib (at least not the python3 version). > > Thanks, > Joseph > Indeed, it has a single reverse build-depends. Closing the RM bug then. I'd still advise upstream against using this library which is of lower code quality. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#933921: src:python-tablib: Unsafe use of yaml.load()
On 8/5/19 7:35 AM, Scott Kitterman wrote: > Package: src:python-tablib > Version: 0.12.1-2 > Severity: grave > Tags: security > Justification: user security hole > > The new version of pyyaml no longer allows use of yaml.load() without a > loader being specifed. This raises a deprecation warning which has > caused and autopkgtest failure on this package. These are generally > trivial to fix, see the upstream guidance [1]. > > Scott K > > [1] https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation > > Hi, FYI, I have just filed a removal bug for this one, as it's not used by any OpenStack things anymore. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#933146: FTBFS, not Django 2.2 ready
Package: python-django-rosetta
Version: 0.7.6-1
Severity: serious
Tags: patch
Hi,
Please find attached patch for the Python 2 removal part.
The package still FTBFS after this patch:
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd
/<>/.pybuild/cpython3_3.7_django-rosetta/build; python3.7 -m
unittest discover -v
rosetta.tests (unittest.loader._FailedTest) ... ERROR
==
ERROR: rosetta.tests (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: rosetta.tests
Traceback (most recent call last):
File "/usr/lib/python3.7/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.7/unittest/loader.py", line 377, in
_get_module_from_name
__import__(name)
File
"/<>/.pybuild/cpython3_3.7_django-rosetta/build/rosetta/tests/__init__.py",
line 1, in
from .tests import *
File
"/<>/.pybuild/cpython3_3.7_django-rosetta/build/rosetta/tests/tests.py",
line 3, in
from django.contrib.auth.models import User, Group
File "/usr/lib/python3/dist-packages/django/contrib/auth/models.py", line 2,
in
from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager
File "/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line
47, in
class AbstractBaseUser(models.Model):
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 103, in
__new__
app_config = apps.get_containing_app_config(module)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 252, in
get_containing_app_config
self.check_apps_ready()
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 134, in
check_apps_ready
settings.INSTALLED_APPS
File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 79, in
__getattr__
self._setup(name)
File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 64, in
_setup
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS,
but settings are not configured. You must either define the environment
variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing
settings.
--
Ran 1 test in 0.000s
FAILED (errors=1)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.7_django-rosetta/build; python3.7 -m
unittest discover -v
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:10: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Build finished at 2019-07-26T21:43:50Z
diff -u -N -r debian/changelog ../debian/changelog
--- debian/changelog2019-07-26 23:44:33.561224883 +0200
+++ ../debian/changelog 2019-07-26 23:43:01.840631647 +0200
@@ -1,4 +1,4 @@
-python-django-rosetta (0.7.6-1) UNRELEASED; urgency=medium
+python-django-rosetta (0.7.6-1) unstable; urgency=medium
[ Michael Fladischer ]
* New upstream release.
@@ -24,7 +24,14 @@
* d/watch: Use https protocol
* Convert git repository from git-dpm to gbp layout
- -- Michael Fladischer Tue, 04 Aug 2015 09:47:58 +0200
+ [ Thomas Goirand ]
+ * Team upload.
+ * Ran wrap-and-sort -bast.
+ * Switch to debhelper-compat=11.
+ * Removed Python 2 support.
+ * Add missing build-depends: python3-django, python3-polib.
+
+ -- Thomas Goirand Fri, 26 Jul 2019 23:35:51 +0200
python-django-rosetta (0.7.2-1) unstable; urgency=low
diff -u -N -r debian/compat ../debian/compat
--- debian/compat 2019-07-26 23:44:33.561224883 +0200
+++ ../debian/compat1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-7
diff -u -N -r debian/control ../debian/control
--- debian/control 2019-07-26 23:44:33.561224883 +0200
+++ ../debian/control 2019-07-26 23:42:33.088444857 +0200
@@ -1,50 +1,29 @@
Source: python-django-rosetta
Maintainer: Debian Python Modules Team
-Uploaders: Michael Ziegler
+Uploaders:
+ Michael Ziegler ,
Section: python
Priority: optional
-Build-Depends: debhelper (>= 7.0.50~),
- dh-python,
- python,
- python-setuptools,
- python3-all,
- python3-setuptools
+Build-Depends:
+ debhelper-compat (= 11),
+ dh-python,
+ python3-all,
+ python3-django,
+ python3-polib,
+ python3-setuptools,
Standards-Version: 3.9.6
Vcs-Browser: https://salsa.debian.org/python-team/modules/python-django-rosetta
Vcs-Git: https://salsa.debian.org/python-team/modules/python-django-rosetta.git
Homepage: http://code.google.co
[Python-modules-team] Bug#933143: FTBFS, not Django 2.2 ready
Package: python-django-mptt
Version: 0.8.7-1
Severity: serious
Tags: patch
Hi,
Please find attached patch to do the Python 2 removal.
After this patch, your package continues to FTBFS. Please
get a fix for it.
Cheers,
Thomas Goirand (zigo)
From 373d818427a37e26e91b5e39084c634ce1d3c613 Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Fri, 26 Jul 2019 23:21:21 +0200
Subject: [PATCH] * Team upload. * Removed Breaks+Replaces:
python-django-mptt (<< 0.6.1-1~) after Buster release. * Removed Python
2 support.
---
debian/changelog | 11 --
debian/control | 52 +++-
debian/links | 1 -
debian/rules | 2 +-
4 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 19ded1a..9cbaf5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,15 @@
-python-django-mptt (0.8.7-2) UNRELEASED; urgency=medium
+python-django-mptt (0.8.7-2) unstable; urgency=medium
+ [ Ondřej Nový ]
* Use debhelper-compat instead of debian/compat.
- -- Ondřej Nový Sat, 20 Jul 2019 00:11:07 +0200
+ [ Thomas Goirand ]
+ * Team upload.
+ * Removed Breaks+Replaces: python-django-mptt (<< 0.6.1-1~) after Buster
+release.
+ * Removed Python 2 support.
+
+ -- Thomas Goirand Fri, 26 Jul 2019 23:19:09 +0200
python-django-mptt (0.8.7-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 8abd33b..aaea1a8 100644
--- a/debian/control
+++ b/debian/control
@@ -2,20 +2,25 @@ Source: python-django-mptt
Section: python
Priority: optional
Maintainer: Debian Python Modules Team
-Uploaders: Brian May
-Build-Depends: debhelper-compat (= 9), dh-python, python3-sphinx,
- python-all (>= 2.6.6-3~), python-setuptools, python-django (>= 1.6),
- python3-all, python3-setuptools, python3-django (>= 1.6),
+Uploaders:
+ Brian May ,
+Build-Depends:
+ debhelper-compat (= 9),
+ dh-python,
+ python3-all,
+ python3-django (>= 1.6),
+ python3-setuptools,
+ python3-sphinx,
Standards-Version: 3.9.7
Homepage: https://github.com/django-mptt/django-mptt
Vcs-Git: https://salsa.debian.org/python-team/modules/python-django-mptt.git
Vcs-Browser: https://salsa.debian.org/python-team/modules/python-django-mptt
-Package: python-django-mptt
+Package: python-django-mptt-doc
+Section: doc
Architecture: all
-Suggests: python-django-mptt-doc
-Depends: ${misc:Depends}, ${python:Depends}, libjs-jquery, python-django,
libjs-underscore
-Provides: ${python:Provides}
+Depends:
+ ${misc:Depends},
Description: Modified Preorder Tree Traversal Django application
Django MPTT is a reusable/standalone Django application which aims to
make it easy for you to use Modified Preorder Tree Traversal with your
@@ -23,26 +28,21 @@ Description: Modified Preorder Tree Traversal Django
application
.
It takes care of the details of managing a database table as a tree
structure and provides tools for working with trees of model instances.
-
-Package: python3-django-mptt
-Architecture: all
-Suggests: python-django-mptt-doc
-Depends: ${misc:Depends}, ${python3:Depends}, libjs-jquery, python3-django,
libjs-underscore
-Provides: ${python3:Provides}
-Description: Modified Preorder Tree Traversal Django application
- Django MPTT is a reusable/standalone Django application which aims to
- make it easy for you to use Modified Preorder Tree Traversal with your
- own Django models in your own applications.
.
- It takes care of the details of managing a database table as a tree
- structure and provides tools for working with trees of model instances.
+ This package contains the documentation.
-Package: python-django-mptt-doc
-Section: doc
+Package: python3-django-mptt
Architecture: all
-Depends: ${misc:Depends}
-Breaks: python-django-mptt (<< 0.6.1-1~)
-Replaces: python-django-mptt (<< 0.6.1-1~)
+Suggests:
+ python-django-mptt-doc,
+Depends:
+ libjs-jquery,
+ libjs-underscore,
+ python3-django,
+ ${misc:Depends},
+ ${python3:Depends},
+Provides:
+ ${python3:Provides},
Description: Modified Preorder Tree Traversal Django application
Django MPTT is a reusable/standalone Django application which aims to
make it easy for you to use Modified Preorder Tree Traversal with your
@@ -50,5 +50,3 @@ Description: Modified Preorder Tree Traversal Django
application
.
It takes care of the details of managing a database table as a tree
structure and provides tools for working with trees of model instances.
- .
- This package contains the documentation.
diff --git a/debian/links b/debian/links
index bf454c2..ab7e0de 100644
--- a/debian/links
+++ b/debian/links
@@ -1,3 +1,2 @@
/usr/share/javascript/jquery/jquery.js
usr/share/doc/python-django-mptt/html/static/jquery.js
/usr/share/javascript/underscore/underscore.js
usr/share/doc/python-django-mptt/html/static/underscore.js
-
diff --git a/debian/rules b/debian/rules
index 97b51ee..f7154df 100755
--- a/debian/rules
+++ b/
[Python-modules-team] Bug#933130: FTBFS, not Django 2.2 ready
_MODULE=tests.settings django-admin test tests
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make[1]: *** [debian/rules:13: override_dh_auto_test] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
------------
Build finished at 2019-07-26T20:34:30Z
Finished
From 9c6245ffaae2f1c5dd62937f137c7cb0c31283ad Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Fri, 26 Jul 2019 22:31:05 +0200
Subject: [PATCH] * Team upload. * wrap-and-sort -bast. * Removed Python
2 support. * Removed version in python3-sqlparse, useless after Buster.
---
debian/changelog | 9 -
debian/control | 79
debian/rules | 7 ++--
debian/tests/control | 10 +-
4 files changed, 49 insertions(+), 56 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 0dd1075..6b7c7e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
python-django-debug-toolbar (1:1.9.1-2) UNRELEASED; urgency=medium
+ [ Ondřej Nový ]
* d/control: Set Vcs-* to salsa.debian.org
* d/copyright: Use https protocol in Format field
* d/changelog: Remove trailing whitespaces
@@ -8,7 +9,13 @@ python-django-debug-toolbar (1:1.9.1-2) UNRELEASED;
urgency=medium
* Convert git repository from git-dpm to gbp layout
* Use debhelper-compat instead of debian/compat.
- -- Ondřej Nový Tue, 13 Feb 2018 10:08:38 +0100
+ [ Thomas Goirand ]
+ * Team upload.
+ * wrap-and-sort -bast.
+ * Removed Python 2 support.
+ * Removed version in python3-sqlparse, useless after Buster.
+
+ -- Thomas Goirand Fri, 26 Jul 2019 22:29:45 +0200
python-django-debug-toolbar (1:1.9.1-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 5dd2c80..6f961b6 100644
--- a/debian/control
+++ b/debian/control
@@ -2,35 +2,30 @@ Source: python-django-debug-toolbar
Section: python
Priority: optional
Maintainer: Debian Python Modules Team
-Uploaders: Andrew Starr-Bochicchio
-Build-Depends: debhelper-compat (= 9),
- dh-python,
- python-all,
- python3-all,
- python-django,
- python3-django,
- python-django-jinja,
- python3-django-jinja,
- python-html5lib,
- python3-html5lib,
- python-setuptools,
- python3-setuptools,
- python-sphinx (>= 1.0.7+dfsg-1~),
- python-sqlparse (>= 0.2.0),
- python3-sqlparse
+Uploaders:
+ Andrew Starr-Bochicchio ,
+Build-Depends:
+ debhelper-compat (= 9),
+ dh-python,
+ python3-all,
+ python3-django,
+ python3-django-jinja,
+ python3-html5lib,
+ python3-setuptools,
+ python3-sphinx,
+ python3-sqlparse,
Standards-Version: 4.1.2
Homepage: https://github.com/django-debug-toolbar/django-debug-toolbar
Vcs-Git:
https://salsa.debian.org/python-team/modules/python-django-debug-toolbar.git
Vcs-Browser:
https://salsa.debian.org/python-team/modules/python-django-debug-toolbar
-Package: python-django-debug-toolbar
+Package: python-django-debug-toolbar-doc
Architecture: all
-Depends: python-sqlparse (>= 0.2.0),
- ${misc:Depends},
- ${python:Depends}
-Recommends: python-pygments
-Suggests: libjs-jquery, python-django-debug-toolbar-doc
-Description: Embedded debugging toolbar for Django projects
+Section: doc
+Depends:
+ ${misc:Depends},
+ ${sphinxdoc:Depends},
+Description: Embedded debugging toolbar for Django projects (documentation)
The Django Debug Toolbar is a plug-in Django application that displays a set
of panels which conveys information about the current request at the top of
the
rendered page. It can show:
@@ -45,14 +40,20 @@ Description: Embedded debugging toolbar for Django projects
* HTTP headers
* Total requests, time, hits and misses of the cache.
* Which templates were rendered the context provided to each template.
+ .
+ This is the common documentation package.
Package: python3-django-debug-toolbar
Architecture: all
-Depends: python3-sqlparse (>= 0.2.0),
- ${misc:Depends},
- ${python3:Depends}
-Recommends: python3-pygments
-Suggests: libjs-jquery, python-django-debug-toolbar-doc
+Depends:
+ python3-sqlparse,
+ ${misc:Depends},
+ ${python3:Depends},
+Recommends:
+ python3-pygments,
+Suggests:
+ libjs-jquery,
+ python-django-debug-toolbar-doc,
Description: Embedded debugging toolbar for Django projects (Python 3 version)
The Django Debug Toolbar is a plug-in Django application that displays a set
of panels which conveys information about the current request at the top of
the
@@ -70,25 +71,3 @@ Description: Embedded debugging toolbar for Django projects
(Python 3 version)
* Which templates were rendered the context provided to each templ
[Python-modules-team] Bug#932960: python-django don't fix CVE and drop Python 2 support at the same time
On 7/25/19 9:20 AM, Paul Gevers wrote: > Source: python-django > Control: found -1 python-django/2:2.2.3-5 > Severity: important > User: debian...@lists.debian.org > Usertags: breaks > X-Debbugs-CC: debian...@lists.debian.org > Affects: django-maintenancemode django-restricted-resource > Affects: django-tables django-testscenarios factory-boy lava > Affects: python-django python-django-debug-toolbar python-django-mptt > Affects: python-sparkpost django-sekizai > > Dear maintainers, > > Your package is trying to fix a CVE, but at the same time dropping > Python 2 support. There is a multitude of packages that need updating > for that because they (test-) depend on python-django. I think it is > smart to revert the Python 2 removal and have the security fix migrate > to testing. Hi, I respectfully don't agree. We need to drop Python 2 support *now* for all the Django packages. I did a lot of that work already (at least a dozen of packages are fixed already), there's not so much remaining. Also, Django 2.2 does *not* have Python 2 support upstream anymore, so there's no way we can maintain this by ourselves. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#932985: Please remove Python 2 support
Source: django-session-security
Version: 2.6.5+dfsg-1
Severity: serious
Tags: patch
Hi,
Please remove Python 2 support. Attached patch may help.
Thomas
diff --git a/debian/changelog b/debian/changelog
index 50bbfe1..e9b3fe2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,15 @@
-django-session-security (2.6.5+dfsg-2) UNRELEASED; urgency=medium
+django-session-security (2.6.5+dfsg-2) unstable; urgency=medium
+ [ Ondřej Nový ]
* Use debhelper-compat instead of debian/compat.
* Bump Standards-Version to 4.4.0.
+ [ Thomas Goirand ]
+ * Team upload.
+ * Removed Python 2 support.
+ * Correctly overrides override_dh_sphinxdoc rather than auto_build.
+ * Add missing (build-)depends python3-six.
+
-- Ondřej Nový Sat, 20 Jul 2019 00:30:59 +0200
django-session-security (2.6.5+dfsg-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 7542d93..fab6569 100644
--- a/debian/control
+++ b/debian/control
@@ -3,10 +3,9 @@ Section: python
Priority: optional
Build-Depends: debhelper-compat (= 9),
dh-python,
- python-all,
- python-setuptools,
python3-all,
python3-setuptools,
+ python3-six,
python3-django,
python3-sphinx
Maintainer: Debian Python Modules Team
@@ -16,23 +15,10 @@ Vcs-Git:
https://salsa.debian.org/python-team/modules/django-session-security.gi
Standards-Version: 4.4.0
Homepage: http://django-session-security.rtfd.org/
-Package: python-django-session-security
-Architecture: all
-Depends: ${python:Depends},
- ${misc:Depends},
- ${sphinxdoc:Depends}
-Recommends: libjs-jquery
-Description: Python2 Django module to log a user out after X minutes
- A little javascript and middleware work together to ensure that the
- user was active during the past X minutes in any tab he has open.
- Otherwise, display a warning leaving a couple of minutes to show any
- kind of activity like moving the mouse. Otherwise, logout the user.
- .
- This is the Python 2 version.
-
Package: python3-django-session-security
Architecture: all
-Depends: ${python3:Depends},
+Depends: python3-six,
+ ${python3:Depends},
${misc:Depends},
${sphinxdoc:Depends}
Recommends: libjs-jquery
diff --git a/debian/python-django-session-security.install
b/debian/python-django-session-security.install
deleted file mode 100644
index dbdb301..000
--- a/debian/python-django-session-security.install
+++ /dev/null
@@ -1 +0,0 @@
-/usr/lib/python2*
diff --git a/debian/python-django-session-security.links
b/debian/python-django-session-security.links
deleted file mode 100644
index 67da37a..000
--- a/debian/python-django-session-security.links
+++ /dev/null
@@ -1 +0,0 @@
-/usr/share/javascript/jquery/jquery.js
/usr/lib/python2.7/dist-packages/session_security/tests/project/static/jquery.js
diff --git a/debian/rules b/debian/rules
index a655966..3842756 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,8 +1,10 @@
#!/usr/bin/make -f
#DH_VERBOSE=1
%:
- dh "$@" --with python2,python3,sphinxdoc --buildsystem=pybuild
+ dh "$@" --with python3,sphinxdoc --buildsystem=pybuild
-override_dh_auto_build:
- dh_auto_build -O--buildsystem=python_distutils
+override_dh_sphinxdoc:
+ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
python3 setup.py build_sphinx
+ dh_sphinxdoc
+endif
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Update for SQLAlchemy to address CVE-2019-7164 CVE-2019-7548
Dear package maintainer, We're about to upgrade SQLAlchemy in Buster to address an SQL injection issue. The fixed package is in unstable, under the version 1.2.18+ds1-2. In some rare cases, this update may break reverse depenencies, leading to non-working SQL queries. This is why I'm writing this email to you today: to ask you to please test your application with SQLAlchemy 1.2.18+ds1-2 ASAP, to address any potential unforecast issue before the Buster release. Details about the discussion can be seen here in the Debian bug #929321. Best regards, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#837764: python-pip: Using `--extra-index-url` results in `HTTPError: 404 Client Error: NOT FOUND`
The fix is available from here: https://github.com/pypa/pip/pull/6367/commits/f8292a304deebcf0e4cda2e40caa226c70030f11 Dear maintainer, do you mind if I push this to unstable right away, in the hope that the fix reaches Buster before the release? Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#837764: Confirmed
Hi, I can confirm this bug. Step to reproduce. Put this in /etc/pip.conf: [global] timeout = 60 index-url = http://mirror.dfw.rax.openstack.org/pypi/simple trusted-host = mirror.dfw.rax.openstack.org extra-index-url = http://mirror.dfw.rax.openstack.org/wheel/ubuntu-18.04-x86_64 then any pip install command will fail. For example: virtualenv --no-download venv ./venv/bin/pip2 install -U It'd be nice to have this fixed for Buster. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#910101: I'll take care of this package from now on
No worries, I'm taking care of it. It's been months that it's been hitching to do it, seeing the lack of care. I'll take back the package in the OpenStack team, as the previous attempt to let Alison take care of it is a complete failure. She used this package upload as a way to become DD, but probably to lack of time, she didn't take care of it. I do believe that giving her 2 years of time was enough and that now is the time to act on things. Hopefully, this will give her the sign that she needs contributing to Debian more to stay an uploading DD. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#869896: Not to be removed from buster: let's close this bug?
Hi Felipe, I really would like to have this bug fixed quickly, as we're dangerously approaching the freeze, and some of my key (OpenStack) packages are in danger here. So, Felipe, do I understand well that this bug can be closed without any further action? Or is there anything that shall be done? I'd very much would like to help, and I do have the time to work on this, as long as we agree on what to do. So please let me know your thoughts ASAP. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#911775: Please package Elixir >= 1.6.6
Source: elixir Severity: normal Dear Maintainer, I'm packaging RabbitMQ-server, and the latest upstream release needs Elixir 1.6.6 at least. It'd be nice if you could update the package. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#907807: Wrong bug
Hi, Sorry, wrong bug, this was for Neutron. Thomas ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#907807: Cannot reproduce
Hi Santiago, I tried to reproduce the FTBFS and could not. I'm using a very standard sbuild environment. Adding this in debian/rules didn't help: export http_proxy=127.0.0.1:9 export https_proxy=127.0.0.1:9 export RES_OPTIONS=attempts:0 (not surprising, as this is not related to network access, but to sqlalchemy) So I wonder: what makes it fail in your build, and not in my environment? Any idea? As it seems build env. specific, and unlikely to happen to everyone, I've lowered the severity and tagged "moreinfo". Note this doesn't mean I don't care for this bug, and that I do intend to work on this. But it isn't my opinion that it deserves an RC severity yet. The package builds in a "normal" environment, and is perfectly usable. Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
Re: [Python-modules-team] Mass filing on Python 3.7 async module import?
On 07/09/2018 11:03 PM, Adrian Bunk wrote: > On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote: >> On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote: >>> List of affected packages: >>> >>> openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py >>> pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py >>> python3-astroquery: >>> /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py >>> python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py >>> python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py >>> python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py >>> python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py >>> python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py >>> python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py >>> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py >>> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py >>> python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py >>> python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py >>> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py >>> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py >>> python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py >>> python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py >>> python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py >>> salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py >>> visidata: /usr/lib/python3/dist-packages/visidata/async.py >> >> There's more than this. What you're reporting doesn't seem to include >> packages defining the async function, for example gevent. I also saw >> more than this list, just by trying to rebuild neutron-fwaas: >> python3-oslo.db (we just fixed that one), python3-kafka, python3-pika, >> python3-dogpile.cache (bug with fix already filled, we'll fix soon). >> >> I would anyway very much welcome a mass bug filling, but best would be >> to try not to forget any package. Note that tenacity is already fixed. > > Note that "already fixed in unstable" is only part of the story. > > Most important will be Breaks for all affected packages in *stretch*, > since there might otherwise be nasty problems in stretch->buster > upgrades depending on the undefined order of package upgrades. Do you mean that the interpreter will have to declare Breaks: for the affected packages? Cheers, Thomas Goirand (zigo) ___ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
