Re: Webpage to track py2removal bugs & packages
Sandro Tosi wrote: i've prepared a small website, http://sandrotosi.me/debian/py2removal/index.html, to keep track of the bugs user-tagged `py2removal`. It could be useful to add another column counting the Dependencies in the other direction. i.e. for all the leaf packages ready for processing, which one should be given priority? Which one has the most impact on Dependencies further down the tree? Drew
Re: updating mechanize - help concerning tests with pybuild
Dear Raphael, > Maybe you could have bumped debhelper to 12 and standards-version to 4.4.0 Done that now, and removed the last lintian warning. Uploading later today. All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: updating mechanize - help concerning tests with pybuild
Hi all, On Sun, 01 Sep 2019, Norbert Preining wrote: > Done that now, and removed the last lintian warning. And now also - fixed building in clean chroot (missing build deps for tests and run) - install docs made via sphinx - updated copyright file to match what is advertised in the package Package is uploaded to experimental as it needs to go through NEW queue ... oh holy , uploads that need the NEW queue need to include the binaries, right? Advertising source only uploads and then requiring NEW queue processing to include binaries is **really**
Bug#939098: RM: mocker -- RoM; no Python 3 support and no reverse deps; low popcon
Package: ftp.debian.org Severity: normal User: debian-python@lists.debian.org Usertags: py2removal No upstream releases since 2010. Popcon is 19. Reverse deps checked with dak rm -Rnb python-mocker -- WBR, wRAR signature.asc Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
Hi, On Sun, 01 Sep 2019, Norbert Preining wrote: > At all: anything you want to see before I upload the new version? I checked the package quickly (without building it), it looks good. Maybe you could have bumped debhelper to 12 and standards-version to 4.4.0 but that's a minor detail. Thanks for leading this! Cheers, > On September 1, 2019 9:43:33 AM GMT+09:00, Matthias Klose > wrote: > >On 01.09.19 01:59, Norbert Preining wrote: > >> Hi Raphael, > >> > >> @Matthias, please read on. > >> > >> On Sat, 31 Aug 2019, Raphael Hertzog wrote: > >>> https://salsa.debian.org/python-team/modules/python-mechanize > >> > >> Thanks, that is perfect. I pushed my work there, changed control VCS, > >> maintainer, and uploader. > >> > >> ATM I only put me into the uploaders. Please, those who are > >interested, > >> put yourself in there, thanks! > >> > Do we go through package salvaging? > https://wiki.debian.org/PackageSalvaging > >>> > >>> I don't think it's required here. The bugs have been open for long > >enough > >>> without any activity. > >> > >> Hmmm... I don't feel confident simply uploading someone's else > >package. > >> Best would probably be if Matthias Klose, one of the current > >Uploaders, > >> agrees to that and uploads the current package thus passing over > >> maintainership. > >> > >> Matthias? > > > >did you see my comment in #936270? > > > -- > PREINING Norbert http://www.preining.info > Accelia Inc. + JAIST + TeX Live + Debian Developer > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#939134: ITP: python-pypathlib -- Polygon package for Python
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: python-pypathlib Version : 0.1.2 Upstream Author : Nico Schlömer * URL : https://github.com/nschloe/pypathlib * License : MIT Programming Lang: Python Description : Polygon package for Python Lightweight package for working with 2D paths/polygons. pypathlib is fully vectorized, so it's pretty fast. (Not quite as fast as mathplotlib.path.contains_points though.) pypathlib is required by dmsh (python-dmsh), a python module capable of generating 2D meshes. To be packaged under the Debian Science team alongside other related packages by the same author: meshio (mesh file conversion), pygalmesh (3D meshes), and dmsh (2D meshes)
Re: Webpage to track py2removal bugs & packages
On Sun, Sep 1, 2019 at 1:15 PM Drew Parsons wrote: > It could be useful to add another column counting the Dependencies in > the other direction. > > i.e. for all the leaf packages ready for processing, which one should be > given priority? Which one has the most impact on Dependencies further > down the tree? I'm afraid i dont understand the question, or maybe it's just a different process than the one i use. the main idea (behind the webpage) is that you cant remove a package unless it doesnt have any reverse-dependency: so if the count it's 0, you can go ahead and remove it. if it has rdeps, then you need to address them _first-, and that's where the rdeps graph comes handy, as it tells you the actual packages. but what i personally use is a level 4 graph (so up to 4 levels of reverse depends): say you want to work on pkgA, but it turns out it has some rdeps, pkg0..8; now, how many rdeps does each of these packages have? hard to say with only a level=1 graph, as you dont see further in the deps tree (the risk it get crazy pretty quickly, in particular with sci packages, as currently all debian-science tasks packages depend on the py2 pkgs, if one of them gets pulled in it's hard to read). Let me know if i can make the webpage more useful for you, i just dont know how to address your request -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Webpage to track py2removal bugs & packages
> I definitely think it will be helpful. Thanks for putting it together. It's > the best thing I've seen yet for answering the question of what can we try to > kill off now. > > Please keep it updated. i set a cron every 2 hours (when the laptop is on) also added a new column for the Maintainer (not uploaders), it may help checking "your" packages and/or the one for dpmt/papt -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Webpage to track py2removal bugs & packages
On Sun, Sep 1, 2019 at 9:54 PM Drew Parsons wrote: > Yes, your script counts the dependencies along one direction (rdeps), > identifying which packages are ready to be de-python2-ised next. > > I'm talking about dependencies in the opposite direction, deps not > rdeps. Upstream vs downstream. > > My question is, of the 844 packages now currently on rdeps=0 and ready > for processing, which one should be processed first? Which one will > free up the largest number of upstream packages? Which one gives the > biggest bang for buck? gothca, i hope. I've added the number of forward dependencies in the last update to the webpage; it's not super-accurate (f.e. python dep is counted twice, due to the nature of how it's produced, > 2.7 < 2.8) but it should give a general idea of what you asked for -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: updating mechanize - help concerning tests with pybuild
Hi, > The current maintainers/uploaders are > Maintainer: Debian/Ubuntu Zope Team > > Uploaders: Brian Sutherland , >Fabio Tranchitella , >Jérémy Bobbio , >Matthias Klose , >Arnaud Fontaine > (In CC, but Brian removed, he already declared he does not want to > maintain the package anymore, see bug #869439) > > I would be interested in adopting mechanize if the current maintainers > / uploaders are fine with it. Or we put it into the python modules team > and I do the stuff there. All is fine for me. As I have no plan to work on it, I think it is better if someone else maintains it, so please go ahead and thanks for taking over maintenance! Regards, -- Arnaud Fontaine
Re: Python 3 transition question
> I would just stop building these. And if the reverse dependencies have a > py2removal bug itself, then comment in these issues that the > suggested/recommended package gets removed. If they don't have a py2removal > bug, please file the bugs for these packages. i dont believe this is a sensible approach; for example i maintain python-mpmath, that would be rendered uninstallable the moment python-gmp2 is removed. Now, python-mpmath has 3 external reverse-dependencies (just to name a couple, sagemath and simpy) that would be then uninstallable, and so on and so forth for all their rdeps. Martin, i think for now the only option is to keep the py2 packages around until we're ready to drop them (ie they have 0 rdeps). Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Python 3 transition question
On 01.09.19 21:48, Martin Kelly wrote: Hi, I maintain python-gmpy and python-gmpy2, which need to transition to Python 3. However, they have several packages that have Suggests or Recommends (not a hard dependency) pointing to python-gmpy/python-gmpy2. These other packages appear to be Python 2 only. Should I stop building the Python 2 versions of these packages (and invalidate the Suggests/Recommends of these other packages), or should I instead just document this issue? If I document it, where should this documentation go? I would just stop building these. And if the reverse dependencies have a py2removal bug itself, then comment in these issues that the suggested/recommended package gets removed. If they don't have a py2removal bug, please file the bugs for these packages.
Re: updating mechanize - help concerning tests with pybuild
Dear Arnaud, thanks a lot for agreeing, and all your work on mechanize! All the best Norbert On Mon, 02 Sep 2019, Arnaud Fontaine wrote: > As I have no plan to work on it, I think it is better if someone else > maintains it, so please go ahead and thanks for taking over maintenance! -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
RE:dh-python and pylint
Hello Sandro, > I've just submitted > https://salsa.debian.org/python-team/tools/dh-python/merge_requests/9 > to address this; not sure how quickly it will get merged & released thanks a lot, but what about backports. On backports we still need this mapping. Cheers
Re: Webpage to track py2removal bugs & packages
On 2019-09-02, Sandro Tosi wrote: On 2019-09-02 01:15, Drew Parsons wrote: Sandro Tosi wrote: i've prepared a small website, http://sandrotosi.me/debian/py2removal/index.html, to keep track of the bugs user-tagged `py2removal`. It could be useful to add another column counting the Dependencies in the other direction. i.e. for all the leaf packages ready for processing, which one should be given priority? Which one has the most impact on Dependencies further down the tree? I'm afraid i dont understand the question, or maybe it's just a different process than the one i use. the main idea (behind the webpage) is that you cant remove a package unless it doesnt have any reverse-dependency: so if the count it's 0, you can go ahead and remove it. if it has rdeps, then you need to address them _first-, and that's where the rdeps graph comes handy, as it tells you the actual packages. Yes, your script counts the dependencies along one direction (rdeps), identifying which packages are ready to be de-python2-ised next. I'm talking about dependencies in the opposite direction, deps not rdeps. Upstream vs downstream. My question is, of the 844 packages now currently on rdeps=0 and ready for processing, which one should be processed first? Which one will free up the largest number of upstream packages? Which one gives the biggest bang for buck? Drew -- . please CC: me in replies
