Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

argggh removed the wrong address, adding Nick On Fri, Jul 31, 2020 at 1:27 PM Sandro Tosi wrote: > > >* d/control: > > - Mark package python3-uflash-doc as M-A: foreign > > This -doc package doesnt follow the policy, of having a python- prefix > and not a pytho

Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

>* d/control: > - Mark package python3-uflash-doc as M-A: foreign This -doc package doesnt follow the policy, of having a python- prefix and not a python3- prefix -- please fix -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitt

Granting `Janitor` direct access to our teams repos

Hello, I don't know the technicalities required to do that (nor i have permissions to do it myself anyway), but I'm wondering if we should grant direct access to our repos to the Janitor user. I don't think any of us checks those PRs in depth, and most of the time Jelmer comes in and bulk-merges t

Re: Newcomers project: DPMT/PAPT pristine-tar verification

On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog wrote: > > Hi, > > On Fri, 10 Jul 2020, Sandro Tosi wrote: > > The checks i have in mind for now, are: > > > > * pristine-tar branch must exist, if not -> it's a bug > > * pristine-tar + upst

Re: RFH: Problemas with test process on python-jsonrpc-server

did you run the -v option, as suggested by the error? it may lead to what the problem is On Sat, Jul 18, 2020 at 7:03 PM Pablo Mestre wrote: > > Hi, > > Im trying to packages python-jsonrpc-server to solve the dependencies > for upgrade Python IDE Spyder. > > I get this issue with the test proces

Re: Request to join DPMT

Luca, > I have read and accept the policy.rst - if accepted, I will update the > branch policy of my modules to match the policy (mainly > s|debian/sid|debian/master|) and update the Maintainer field, > everything else already matches. In your request to join email, you agreed to accept and follo

Re: mercurial switch to python3 in debian unstable - July 16th, 2020

> I guess a lot of things are unlocked now. I wonder how we can help > fixing what's remaining. I think i already took care of all the packages that got (recursively) freed up by switching mercurial to python3. > Please do share your thoughts on that. I guess one can always look at http://sandro

Re: mercurial switch to python3 in debian unstable - July 16th, 2020

> If we dont hear otherwise, we plan to upload the python3 version of > mercurial in unstable on or around next Thursday, July 16th. mercurial/5.4.1-2 has just been uploaded to unstable, switching it to use python3. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian:

Re: The python command in Debian

> It seems to be a little bit more controversial what should happen to the > python > command in the long term. Some people argue that python should never point to > python3, because it's incompatible, > however Debian will have difficulties to > explain that decision to users who start with Pyt

Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00

> src:dbus-python cannot drop its Python 2 support until all of the reverse > dependencies of python-dbus have done so (or been removed from testing, but > that's unlikely to happen while they include key packages like avahi, > jackd2 and pyqt5). this is now the case: bin:python-dbus has no more r

Re: Request to join Python Modules Team

> Imaging you are the person that wants to join this cool project. > You made some effort to apply for membership and sent in the request. > Then you wait humblely. Humble as you are, you wait another day. > On third day you start wondering "Is asking again expressing > that you care or i

Re: [Python-modules-team] pychromecast_7.1.1-1_source.changes ACCEPTED into unstable

Andrej, the pristine-tar branch has not been updated (not sure if you didnt push it or it was not imported with the --pristine-tar option) On Sat, Jul 11, 2020 at 1:04 PM Debian FTP Masters wrote: > > > > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat

Newcomers project: DPMT/PAPT git repos verification

Hello, i would like to propose a project to make sure our teams (DPMT/PAPT) repos are being used correctly; it has a broader set of requirements than the pristine-tar one (and so it's more complex), thus a separate message. The checks i have in mind for now, are: * packages in DPMT/PAPT need to h

Newcomers project: DPMT/PAPT pristine-tar verification

Hello, i would like to propose a project to make sure our teams (DPMT/PAPT) repos are using pristine-tar properly. The checks i have in mind for now, are: * pristine-tar branch must exist, if not -> it's a bug * pristine-tar + upstream branch must produce the same tarball as downloaded from the a

mercurial switch to python3 in debian unstable - July 16th, 2020

Hello, this email is to inform the maintainers of the reverse dependencies of mercurial of the plan to upload to unstable the python3 version next Thursday. We want to be extra-safe with the switch, hence this email. In To: to this email the maintainers mailing list + key other MLs and addresses,

Re: py2removal - make all leaf applications RC

> I propose to raise the severity of all leaf applications in 3 days, if > i dont hear any objections. This is now enabled and at the next run (in ~50 minutes) it will take effect. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: h

py2removal - make all leaf applications RC

Hello, Currently only leaf applications (ie something that doesnt start with `python-`) with popcon <= 1000 get their py2removal bug bumped to RC. I propose to raise the severity of all leaf applications in 3 days, if i dont hear any objections. The current list of applications, and their popcon,

Re: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

> > > Do you need any help in coordinating with the packaged extensions, > > > testing changes, preparing patches? a lot of time has passed since we > > > started asking about mercurial and python3 and it is becoming the only > > > reverse-dependency of several packages that could be removed if > >

Re: Maintaining all of the testing-cabal packages under the OpenStack team

> Running the script shows that 279 reverse (build?) dependencies are > affected by mock. This clearly isn't something one wants to run on a > personal computer, and even less a test which one wants to run sequentially. > > Has any thought went into having some kind of runners running on a cloud >

Re: Maintaining all of the testing-cabal packages under the OpenStack team

> Is anyone from the team opposing to this? Yes, i'm against your proposal. > If so, please explain the > drawbacks if the OpenStack team takes over. 1. you're personally attacking Ondrej, who is one of the very few members of this team doing team-wide work, and that should be enough to reject i

Future of PyPy (not PyPy3) in Debian

Hello all, it looks like i started a process that would require the removal of several PyPy (as in pypy-* depending on the `pypy` package) packages from the archive. I'm now wondering: what should we do with the entire pypy ecosystem? should we treat pypy-* packages like python-* ones and remove t

Bug#962024: RFP: cppy -- collection of C++ headers which make it easier to write Python C extension modules

Package: wnpp Severity: wishlist * Package name: cppy Version : 1.1.0 Upstream Author : The Nucleic Development Team * URL : https://github.com/nucleic/cppy * License : BSD 3-Clause Programming Lang: Python Description : collection of C++ headers which m

Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

> Any trick to avoid those errors in general? when i push i always do $ git push --all ; git push --tags i also have these in ~/.gitconfig [push] default = current followTags = true with should make the `git push --tags` unnecessary after `git push --all` (as tags will "follow" t

Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

Antoine, you did not push the upstream branch. please do so, in order to keep the repo consistent On Mon, May 11, 2020 at 10:15 PM Debian FTP Masters wrote: > > paramiko_2.7.1-1_source.changes uploaded successfully to localhost > along with the files: > paramiko_2.7.1-1.dsc > paramiko_2.7.1.

Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package

Package: wnpp Severity: wishlist * Package name: hstspreload Version : 2020.5.5 Upstream Author : Seth Michael Larson * URL : https://github.com/sethmlarson/hstspreload * License : BSD-3 Programming Lang: Python Description : Chromium HSTS Preload list a

Re: issues installing psutil with pip in virtual environment

> I am running into an issue installing psutil: pip3 install psutil, in a > virtual environment. I have upgraded my pip and setuptools with no > avail. I am getting this error: https://pastebin.com/2Xb7UN9g psutil is not pure python, and contains some extensions that need to be compiled, so your s

Re: khard_0.16.1-1_source.changes ACCEPTED into unstable

On Thu, Apr 23, 2020 at 12:51 PM Debian FTP Masters wrote: > > > > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Thu, 23 Apr 2020 10:05:57 +0200 > Source: khard > Architecture: source > Version: 0.16.1-1 > Distribution: unstable > Urgency: medium > Maintai

Re: [Python-modules-team] python-xlib_0.26-1_source.changes ACCEPTED into unstable

-team/modules/urwid/-/tree/pristine-lfs On Sat, Mar 21, 2020 at 3:31 PM Scott Kitterman wrote: > > On Saturday, March 21, 2020 3:02:27 PM EDT Andrej Shadura wrote: > > Hi, > > > > On Sat, 21 Mar 2020 at 19:39, Sandro Tosi wrote: > > > > On Sat, 21 Mar 2020 at 18

Re: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

wait a second: i dont like this idea that DPMT/PAPT are a dumping ground you can throw away your packages you dont care about that much so that someone will take care of then. we still require a human maintainer behind the team name (either they be in Maintainer or Uploaders, with the different mea

Re: py2removal: drop python-pytest by not running tests for python2 packages

> so i was playing with the idea of tackling python-pytest removal by > updating all its rdeps and not run unittests for the python2 binary > (so dropping pytest and the other b-d* only used for tests). this is completed, and i've just uploaded pytest removing python-pytest Thanks, -- Sandro "mo

py2removal: drop python-pytest by not running tests for python2 packages

Hello, python-pytest is blocking 18 packages from removal, most of them would be leaves once python-pytest is gone. so i was playing with the idea of tackling python-pytest removal by updating all its rdeps and not run unittests for the python2 binary (so dropping pytest and the other b-d* only us

Re: [Help] Re: Bug#953052: psychopy: python2 dependencies

On Wed, Apr 8, 2020 at 12:09 PM Andreas Tille wrote: > > Control: tags -1 help > > Hi DPMT, > > I need to admit I'm currentl overwhelmed with COVID-19 hackathon. > A quick view does not really show any suspicious things to me. > Any help (including team upload / NMU) would be appreciated. didnt t

Re: Telepathy-gabble and python2-rm

On Fri, Apr 3, 2020 at 5:04 PM Scott Kitterman wrote: > > There was a telepathy-gabble upload this week that took out a bunch of python2 > build-deps, but it looks like telepathy-gabble-tests retained many of them as > depends: > > https://packages.debian.org/unstable/telepathy-gabble-tests > > In

Re: py2removal: proposal to increase apps popcon limit

> I propose to raise the popcon threshold to 1000. this is now enabled (and will start working from the next run, in ~30 mins) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi

Re: py2removal: proposal to increase apps popcon limit

>> Maybe you can paste the list of 20 affected apps, though? > I'm more interested in the 18 that are above 1000. Could you please just > list them all 38, sorted by popocon? here's the list: cvs2svn - popcon = 303, chirp - popcon = 350, gnat-gps - popcon = 354, cfv - popcon = 387, fretsonfire-

py2removal: proposal to increase apps popcon limit

Hello, as part of the py2removal process, we're not raising the bug priority to serious if it's associated with an application and popcon is bigger than 300 There are currently: * 38 apps that are leaf packages and popcon > 300; ** 13 out of 38 have popcon < 600 ** 20 out of 38 have popcon < 1000

Re: When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until end...)

> python-fixture (the binary) is gone, therefore we have #952130 and > #952127. I've been reluctant to remove Py2 support from these, because > unittest2 needs it, and this would break a lot of packages (including, > indirectly, stuff like sphinx, pytest, etc.). you can remove them when http://sa

Re: Questions about including tests/ directory into package

> packages=find_packages("src"), > > Setuptools will only find "tinyalign" under the "src" folder, as a > python module to package, which is why that's the only thing that is > going to be packaged. > > IMO, the best approach to this problem is to convince upstream to move > their tests folder into

Bug#954115: RFP: capturer -- Easily capture stdout/stderr of the current process and subprocesses

Package: wnpp Severity: wishlist https://capturer.readthedocs.io/en/latest/ https://pypi.org/project/capturer/ this is a dependency of the test suite of humanfriendly. Thanks, Sandro

Re: 2Removal: handling circular dependencies

Hey Rebecca, do you have an updated list of these cycles? On Wed, Oct 23, 2019 at 6:39 PM Rebecca N. Palmer wrote: > > [Summary of previous messages: I noted that packages with circular > dependencies can't be removed one at a time without breakage. Replies > were to remove multiple packages at

Re: ITS: pssh

On Thu, 20 Jun 2019 06:24:13 -0700 Mo Zhou wrote: > Source: pssh > Version: 2.3.1-1 > > I plan to salvage pssh and fix at least the following bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891340 Not sure if Mo is still interested in salvaging this package, other wise this could be a ni

Re: Bug#937177: obitools: Python2 removal in sid/bullseye

> > This > > package is blocking several others. Would it be best to remove it? It can > > always be re-introduced if a python3 port appears. > > Since some time I've pushed a 2to3 based port to Git. I've now fixed > some issues of this and I wonder whether we might give it a try to do > the por

Re: Bug#952952: RM: src:ipykernel-py2 -- RoM for Python 2 removal

> The src:ipykernel-py2 package provides python-ipykernel, which is to be > removed for the Python 2 removal transition. Cc-ing Gordon explicitly: the last time we spoke, Gordon wanted to keep the python2 stack of ipython/ikernel/jupyther for people to still have a py2 infrastructure to run their

Bug#951348: RFP: scalene -- high-performance, high-precision CPU and memory profiler for Python

Package: wnpp Severity: wishlist * Package name: scalene Version : 0.7.5 Upstream Author : Emery Berger * URL : https://github.com/emeryberger/scalene * License : Apache Programming Lang: Python Description : high-performance, high-precision CPU and memo

Re: Where can I find packages that need a maintainer?

> I recently started as a maintainer of a package for Debian which is > currently awaiting approval to be reintroduced into the repositories. [1] > > With the desire to continue contributing I would like to know where I > can find other packages that need a maintainer. you can start from here: htt

Re: python-babel

> In such case, could you provide me with the source package, rather than > just letting me try with Git? Maybe this is going to work then... whatever turns out to be, please ensure the package is buildable from the git repo. and matches what's going to be uploaded. We have already enough packages

Re: Proposal on how to proceed with Python 2 removal from bullseye

On Sun, Dec 22, 2019 at 5:58 AM Simon McVittie wrote: > > On Wed, 18 Dec 2019 at 01:08:11 -0500, Sandro Tosi wrote: > > let me know if this makes sense or additional changes are required. > > #942941 in src:dbus-python was bumped to serious because: > > python-dbus-tes

Re: [Python-apps-team] Bug#938682: Future of Trac in Debian

> > if i dont hear anything back withing a week, i'll most likely opening > > those RM bugs, so that we can work on their transitive dependencies. > > Just go ahead. I hope, we can reintroduce Trac in one or two > years, maybe in time for Debian 12 (bookworm), but probably not > for Debian 11 (bull

Re: Future of Trac in Debian

Hello Martin, On Fri, Nov 29, 2019 at 6:55 PM Martin wrote: > > On 2019-11-29 18:13, Nicholas D Steeves wrote: > > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > > ticket informing them of our plan. > > I linked to the email of 2019-10-14: > https://trac.edgewall.org/ticke

Re: Proposal on how to proceed with Python 2 removal from bullseye

> 1) all Python 2 removal bugs *can* be raised to RC level by the > maintainers of the packages they belong to, but: > > 2) maintainers of non-key packages should carefully consider the > backslash for their transitive reverse (normal, build and test) > dependencies before raising the bug severity

Re: RFS [RC] jsonpickle, python-serverfiles

both sponsored, thanks for your contribution to Debian! On Sat, Dec 14, 2019 at 3:10 AM Håvard Flaget Aasen wrote: > > Hello, > > Can someone please do an upload of jsonpickle? It is marked for > autoremoval on 19 January. This update fixes the issue, it also updates > to the latest upstream rele

Re: Severity bump script

there seems to be disagreement on how to proceed, so for the time being i suspended the severity bump part of the py2removal tracking script. let me know when everybody agrees on a solution, and what that solution is, and i'll code it and re-enable. regards, Sandro On Thu, Dec 5, 2019 at 6:07 AM

Re: Severity bump script

> You'll fix that, right? Because why would the tree stop at Python? A > leaf package is a package without Depends/Build-Depends in Debian. (I > appreciate it very much that you consider Recommends and > autopkgtest-triggers as well). so the revised logic should be: * it's an app (package name do

Re: Severity bump script

> > huh? We are not bumping any "blocked" bugs. > > Depends/Build-Depends/Recommends/autopkgtests usage marks bug as > > blocked. Any example of "wrong definition" please? > > #942999 and #936537 the blocks are only between py2removal packages, so if a package un-related to the py2removal effort d

Re: Severity bump script

Paul, this is the thread i was talking about. you were copied in the original email: https://lists.debian.org/debian-python/2019/10/msg00098.html if there is something the RT wants to discuss about this effort, please do so here, not directly to me (i may be the mail address sending those control

Re: RFS: spyne/2.13.11a0-0.1 [NMU, RC] -- Python library for writing and calling soap web service

> I am looking for a sponsor for the package "spyne" which has a > py2removal RC bug and will be autoremoved on December 13th. The package > is Python 2 only but the current alpha version has Python 3 support. I > uploaded a Python 3 compatible package in January and referenced it in > #877783 but

Future of Trac in Debian

Hello everyone, i'd like to discuss the future of Trac in Debian. as we all know, Trac is still python2, and while there are plans to port it to python3 (https://trac.edgewall.org/ticket/12130) that port is not there yet, and it may take quite some time to reach a state it can be tested, let alone

Re: Severity bump script

> I think we should use something simple/short like this: > > --cut-- > Raising severity of Python 2 removal bugs, for details see: > https://lists.debian.org/debian-devel-announce/2019/11/msg0.html > --cut-- this is live now, with the following header: # Part of the effort for the removal o

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

On Thu, Nov 28, 2019 at 11:11 AM Andreas Tille wrote: > > On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote: > > > > > Is there any trick to enable autopkgtest-pkg-python detecting the correct > > > module name? > > > > > > > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/me

Re: Severity bump script

On Wed, Nov 27, 2019 at 2:16 PM Ondrej Novy wrote: > > Hi, > > pá 22. 11. 2019 v 22:22 odesílatel Sandro Tosi napsal: >> >> I've removed bugs that are marked as blocked by; we're now down to 487 >> unique severity raies > > > cool. Checked and

Re: Discussing next steps for the Python2 removal

> i have a semi-working script that produced ~400 package depending on > py2 packages with missing py2removal bugs, i'll try to finalize it in > the coming days and submit those bugs when done i found approximately 140 more packages that depends on python/cython and dont have a py2removal bug; i'l

Re: Severity bump script

On Fri, Nov 22, 2019 at 3:23 AM Ondrej Novy wrote: > > Hi Sandro, > > thanks for first version. I randomly checked few lines and found this: > > # libufo0 is an application and has low popcon (25 < 300) > severity 938743 serious > # libufo-bin is an application and has low popcon (4 < 300) > sever

Re: Bug#937657: Issue with numpy under Python 3.8

On Sun, Nov 17, 2019 at 10:58 AM Andrey Rahmatullin wrote: > > On Sun, Nov 17, 2019 at 04:29:56PM +0100, Andreas Tille wrote: > > > 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. P

Re: Severity bump script

> I see that the script considers some -doc packages as modules. good point; fixed, but that only brings down the unique severity bumps to 688 > I can’t tell if we should remove them, but maybe the description could > be updated? Like “python-foo-doc is a documentation package has 0 external > rd

Re: Severity bump script

On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy wrote: > > Hi Sandro, > > -- Forwarded message - > > We are going to raise the severity of the py2removal bugs to "serious" in > > several steps. In the > > first phase we are going to raise severity of the py2removal bugs for > > all l

Re: reducing matplotlib2 build-depends.

On Tue, Nov 12, 2019 at 9:24 AM peter green wrote: > I am guessing that many of these are to get testsuite coverage for optional > features and are not strictly needed for the build, while testing stuff is > nice I don't think it's vital for software that is on it's way out. I tried > removing

Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

that policy is well written down, at https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin - give it a look and see if it clarifies your doubt about team maintenance and why someone would prefer to have the ultimate responsibility for the quality of a package. you already created the openstack

Re: Severity bump script

On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy wrote: > > Hi Sandro, > > -- Forwarded message - > > We are going to raise the severity of the py2removal bugs to "serious" in > > several steps. In the > > first phase we are going to raise severity of the py2removal bugs for > > all l

Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

> On 11/8/19 8:54 AM, intrigeri wrote: > > - In https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, > >the "Policy About Maintainer and Uploaders Fields" section > >mentions an "unwritten policy". Said policy seems to have been > >written since: > > > > https://salsa.debian.

Re: Discussing next steps for the Python2 removal

> notes from this meeting > (https://gobby.debian.org/export/Teams/Python/Py2Removal): small additional note: the py2removal tracker script now ignores Suggests and wont mark them as rdeps -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi T

Re: Discussing next steps for the Python2 removal

On Thu, Oct 24, 2019 at 4:09 PM Ondrej Novy wrote: > We want to bump all bugs to RC bugs, if they are: Was there anyone from the RT that ack'd this? Paul is here and i guess he can do that now: there could be hundreds of new RC bugs in a blink. > * leaf package > * with py2 binary do we really

Re: Discussing next steps for the Python2 removal

> i have a semi-working script that produced ~400 package depending on > py2 packages with missing py2removal bugs, i'll try to finalize it in > the coming days and submit those bugs when done here's the list: https://people.debian.org/~morph/mass-bug-py2removal_take2.txt in format all of the

Re: dh-python now generates dependencies on python2 instead of python

> The py2removal bugs have a section > > """ > - 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-python@lists.debian.

Re: Discussing next steps for the Python2 removal

On Tue, Oct 22, 2019 at 11:05 AM Matthias Klose wrote: > > Paul Gevers from the release team pointed out that the Python2 removal is > causing some uninstall-ability issues in testing because some packages > apparently are removed too early, but never the less are migrating to testing. in a hope

Re: [Python-apps-team] pylint3 reverse dependencies.

> A team Upload is accepted, isn't? :-) the package is not maintained by a formal team (but there are 2 people registered in Maintainers/Uploaders) so that wont be possible. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.

Re: [Python-apps-team] pylint3 reverse dependencies.

On Fri, Oct 4, 2019 at 10:15 AM Sandro Tosi wrote: > > Piotr, please do not hold onto the upload - the reason is still there > it's because it's a cruft package, which will be removed once we fix > dh-python and make pylint conflict with pylint3 (instead of just > provide i

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

On Tue, Oct 15, 2019 at 12:55 PM Thomas Goirand wrote: > > On 10/15/19 5:00 AM, Craig Small wrote: > > > > > > On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, > > wrote: > > > > Please re-read the excellent contribution from Neil Williams > > in this thread, and expl

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

On Mon, Oct 14, 2019 at 10:14 PM Thomas Goirand wrote: > > On 10/14/19 3:54 PM, Sandro Tosi wrote: > >>> But in both cases, it's going to take a very long time. Do we really > >>> want to get stuck on these packages for like forever, or would it feel > >&

Re: Python2 removal: package with low-popcon reverse dependencies

> It's becoming increasingly clear to me that, at some point, we will need > to just ignore the breakage. no, please dont. it's way too early to even think about that. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

>> But in both cases, it's going to take a very long time. Do we really >> want to get stuck on these packages for like forever, or would it feel >> ok to raise the severity to serious, so that the package gets >> auto-removed and then we can work on removing Python 2 from its >> dependencies? > >

Re: [Python-apps-team] pylint3 reverse dependencies.

Piotr, please do not hold onto the upload - the reason is still there it's because it's a cruft package, which will be removed once we fix dh-python and make pylint conflict with pylint3 (instead of just provide it), which we currently cant do due to dh-python still producing the pylint3 dependency

Re: 2Removal: handling circular dependencies / dropping tests before the binary?

> Note that having an unbuildable package in sid for several days, until > it's updated to a no-py2 version, is perfectly acceptable. please note that may not be fine with every maintainer. dont just drop packages without checking rdeps and/or if you know that will make packages uninstallable/unbu

Re: Webpage to track py2removal bugs & packages

On Sat, Aug 31, 2019 at 2:31 AM 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`. the website will now (from the next push) also check Testsuite-Triggers field content when

Re: Re: Bug#920127: Removed package(s) from unstable

On Sun, Sep 8, 2019 at 11:26 PM Paul Wise wrote: > > On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote: > > > This was sent to the FTP Team, but it seems like someone with some bandwidth > > to assist from DPMT/PAPT would be a better audience. Note that the > > removal's > > already been done

Re: Webpage to track py2removal bugs & packages

On Sat, Aug 31, 2019 at 2:31 AM 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`. there was a bug in the script populating that page that's now been fixed: if a sour

Re: Webpage to track py2removal bugs & packages

On Tue, Sep 3, 2019 at 10:11 AM PICCA Frederic-Emmanuel wrote: > I can not find python-pyqtgraph in your list. > > It seems to me that this package has reverse dependencies, but the python2 > binaries where remove..., but this is another problem. the script that produces that page only checks fo

Re: Webpage to track py2removal bugs & packages

> Within a given rdeps count it currently has secondary sorting made on > Bug No. It would polish off the forward deps if they could be used for > secondary sorting instead (highest number to lowest). Bonus points for > making the headers clickable so the reader can choose which secondary > sortin

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. > >

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 sensibl

Re: dh-python and pylint

On Sat, Aug 31, 2019 at 9:21 AM PICCA Frederic-Emmanuel wrote: > > Hello, > > I am preparing the new spyder package. > since the removal of pylint3 from the src:pylint. > > I need to remove the Build-Depends: pylint3. > > Now dh_python3 still produce a pylint3 dependency for the binary packages. >

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 >

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

Webpage to track py2removal bugs & packages

Hello, i've prepared a small website, http://sandrotosi.me/debian/py2removal/index.html, to keep track of the bugs user-tagged `py2removal`. * i'm sure there are bugs * it's pretty brutal html, but should provide useful information * it tries to account for crufted binary packages * it ignores the

Python 2 removal and r-deps -- a tool

Hello, currently there are a lot of cruft packages in unstable (due to the removal from their source packages, but still being referenced by other binpkgs, so they are left in the archive) that running `apt rdepends` produces a lot of false entries. I wrote a small script to: * parse the local Sou

Re: Matplotlib 3.0 - update ok?

> Now, I am tempted to create a package matplotlib3 instead of forcing please dont. the right course of action is: - fork src:matplotlib2 from src:matplotlib to only provide the python2 package - update src:matplotlib to upstream 3.x to provide only py3k modules (and since there was also a discus

Re: dh_python3 --no-ext-rename does not work (Was: Bug#910284: r-cran-fastcluster does not build Python modules for all supported Python versions)

are you building the package for python3.7 too? you are showing an ls of an extension built for 3.6 while Gard is using 3.7 On Thu, Oct 4, 2018 at 8:45 AM Andreas Tille wrote: > > Control: tags -1 help > > Hi, > > I tried to fix the issue reported below by using > dh_python3 --no-ext-rename > (s

Re: Report from the Python BoF @ DebConf18

> This also means finding > solutions for edge-cases such as astroid, whose 2.0 branch is the only to > support Py3.7, but also drops 2.x support. this is becoming less of an edge-case and more the current situation of several "core" python modules: drop python2 support (eventually maintaining a L

Re: Is there a tool to debianize for the first time a package from pypi

https://packages.debian.org/unstable/pypi2deb On Fri, Aug 3, 2018 at 9:45 AM PICCA Frederic-Emmanuel wrote: > > Hello, I need to create a new package for > > spyder_kernels. > > Is there a tool which allows to create the first version of a package which > create the debian/directory from the setu

Re: git-dpm -> gbp conversion (mass-change)

> 1. convert git-dpm -> gbp thanks for doing this! > 2. change default branch to debian/master please dont. a quick check to the perl team and it seems they dont require it, so should we? if someone wants to follow DEP-14 then just do so and document it on debian/README.source (and repoint HEAD)

Re: Wanting to repackage virtualenvwrapper

On Thu, Jun 21, 2018 at 2:27 PM Joel Cross wrote: > > Dear mailing list, > > I was looking to make some changes to the packaging of the virtualenvwrapper > package, in order to fix bug #760080 (no Python 3 support). I have done most > of the work on repackaging, but now realise that the package

<    1   2   3   4   5   6   >