Re: Bug#1057830: qgis: please remove extranous dependency on python3-future
Hi, Le sam. 9 déc. 2023 à 07:53, Sebastiaan Couwenberg a écrit : > > qgis has some dependencies for the sake of plugins which cannot pull in > dependencies on their own. > > Are there plans to remove python3-future from Debian or it being > deprecated upstream? There's no plan yet. The default plan would be to remove python3-future when nothing needs it anymore. That's what is happening right now with all these old GTK2 & SDL1 frameworks I've removed trivial usage of python3-future from 3 games yesterday, I will continue. I guess all packages are not that easy to patch and there will be some blocker with a dead upstream. A quite smarter plan would be to patch python3-future so it's start emitting a Debian-specific DeprecationWarning that will come up: - in CI of other packages using it (?) (after "duplicity" is updated not to annoy too many people at once) - in QGIS users scripts (Ubuntu 24.04 would be a nice "test bed") Greetings DONE: ardentryst_1.71-10_source.changes ACCEPTED into unstable -from past.builtins import cmp +def cmp(x, y): return (x > y) - (x < y) bouncy_0.6.20071104-9_source.changes ACCEPTED into unstable -from past.builtins import long +long = int unknown-horizons_2019.1-7_source.changes ACCEPTED into unstable d/control: - python3-fututre, was already clean TODO, with popcon: qgis of course duplicity10757 -> new upstream version pending python3-impacket 573 ycmd 448 vim-youcompleteme442 chirp321 python3-uncertainties262 python3-plaso212 python3-yade 192 python3-mdp 143 python3-django-q 138 python3-galpy125 multiqc 113 python3-nipype 106 python3-cpuset 90 python3-proselint83 gnome-keysign82 weechat-matrix 71 python3-bibtexparser 71 renpy66 buildbot-worker 63 python3-gnocchiclient47 bugwarrior 40 python3-pyocd34 python3-pyswarms 30 osdlyrics30 radon29 python3-scikit-rf26 python3-flask-autoindex 25 python3-biomaj3 24 insilicoseq 21 autoradio17 turing 16 python3-picopore 16 python3-graphite216 onionbalance 16 python3-pyxnat 11 python3-pyhamtools 8 python3-junitparser 7 python3-stomper 6 python3-grapefruit 6 python3-emperor 5 graide 5 rocketcea3 openqa-client3 python3-bioxtasraw 2 dioptas 2 python3-mir-eval 1 python3-gnocchi 0
Re: Request to join the team
Hi, I would like to join the Debian Python team too, my Salsa login is detiste-guest. https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst ACK I'm interested: - fixing the bug I submitted - checking if old python2 compatibility layers are actually still used: - unittest2 - future - six - dose1 - ( I also check upstreams & send PR if upstream is still active) - add typing annotations to native packages (alike python3-debian, python3-debconf, apt-listchanges ...) - helping with Py3.12 support & random RC bugs Greetings
Bug#1058055: galpy: please remove extraneous dependency on python3-future
Source: galpy Version: 1.8.1-2 Severity: important X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainer, The removal of the python3-future library is being evaluated. It's obsolete & unmaitained upstream. Your package seems not to have required python3-future for a long time. Please remove the hardcoded dependency from debian/control. Greetings, /tmp/galpy $ grep future -r setup.py:# Note for the futureL could now get the actual compiler in the BuildExt class debian/control: python3-future, debian/control: python3-future, debian/changelog: * Add python3-future as build and package dependency /tmp/galpy $ grep past -r HISTORY.txt: examples to the user's clipboard for easy pasting into a Python /tmp/galpy $ -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1058056: multiqc: please remove extraneous dependency on python3-future
Source: multiqc Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainers, Your package's setup.py declares an extraneous dependency on old compatibility layer python3-future. > setup.py:"future>0.14.0", But it doesn't need it at all: no import of "past" or "future" libraries. Please report it upstream and in the meantime build a package with this line patched-out. Greetings, Alexandre -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1058057: impacket: please remove erroneous extraneous reference to 'future' from setup.py
Source: impacket Severity: important X-Debbugs-Cc: debian-python@lists.debian.org Dear Maitainer, Upstream mistakenly added 'future' to the requirements in setup.py Maybe they tought it was needed to get the "from __future__ import ..." statements working. That would had been "from future import ..." / "from past import ...". Nowadays it means that your package is pulling in python3-future. This library is obsolete and mostly unmaintained and should be removed from Debian. So please patch it out from the build. Greetings, Alexandre -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Re: Bug#1056419: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Le lun. 11 déc. 2023 à 17:02, Jochen Sprickerhof a écrit : > I think the right thing here is to package the new uncertainties version > which drops the past import: > > https://github.com/lebigot/uncertainties/releases/tag/3.1.7 +1 > Also we should probably get rid of python-future at some point. I removed it from three games this week-end and filled 6 more bugs since to remove extraneous stale dependency. There are in fact more fake stale dependencies than remaining true ones It takes like 10 minutes to review one package. It's a peaceful life. https://salsa.debian.org/games-team/ardentryst/-/commit/fc6901b0e90b6bb3ec19b23c1c2d458d653b2d4a I will continue this review. The existing bugs can be tagged someway if that helps. Greetings python3-gnocchi 0 python3-mir-eval 1 dioptas 2 python3-bioxtasraw 2 openqa-client3 rocketcea3 graide 5 python3-emperor 5 python3-grapefruit 6 python3-stomper 6 python3-junitparser 7 python3-pyhamtools 8 python3-pyxnat 11 onionbalance 16 python3-graphite216 python3-picopore 16 turing 16 autoradio17 #1054207 python3-biomaj3 24 python3-flask-autoindex 25 python3-scikit-rf26 radon29 osdlyrics30 python3-pyswarms 30 python3-pyocd34 bugwarrior 40 python3-gnocchiclient47 buildbot-worker 63 python3-bibtexparser 71 weechat-matrix 71 gnome-keysign82---> upstream python3-proselint83 python3-cpuset 90 python3-mdp 143 old_div python3-yade 192 c++ python3-plaso212 RM python3-uncertainties262 package new version chirp321 non duplicity10757
Re: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
The worse thing is when upstreams ask you to sign a CLA to accept a PR that removes one extraneous line from requirements.txt. Is it even copyrightable ? Le dim. 17 déc. 2023 à 20:21, Graham Inggs a écrit : > > Hi Andreas > > On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > > Is there > > any better way than editing debian/obitools.substvars in d/rules by > > adding some override_dh_gencontrol? > > Remove the line: > > Cython>=0.24 > > from requirements.txt.
Re: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Le lun. 11 déc. 2023 à 16:43, Andreas Tille a écrit :
> Control: tags -1 help
>
> [Bug #1056419 in CC since the issue seems to be caused by python-future]
>
> Hi Vincent,
>
> I tried to upgrade python-future to the latest upstream version in the
> hope that this would solve the issue reported in bug #1042244.
> Unfortunately this is not the case and now with Python3.12 we also
> have to deal with the removal of imp (which affects bug #1056419).
>
> I'd like to ask for help on debian-python list since I'm pretty
> overworked with other stuff. Please also review my rude patch[1] to
> hack around a shinx issue. It would be great to have some better
> solution here.
The better solution is to remove python3-future altogether.
I've set up a tracker with remaining packages:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059934
(list is not complete)
There might be some nmu needed too if maintainers don't react.
@Vincent: this one package "gtextfsm" is yours
do you green light an upload ?
Greetings,
https://salsa.debian.org/python-team/packages/gtextfsm/-/pipelines/621238
gtextfsm $ cat debian/patches/no-future.patch
From: Alexandre Detiste
--- a/setup.py
+++ b/setup.py
@@ -53,5 +53,5 @@
},
include_package_data=True,
package_data={'textfsm': ['../testdata/*']},
- install_requires=['six', 'future'],
+ install_requires=['six'],
)
Re: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit : > > @Vincent: this one package "gtextfsm" is yours > > do you green light an upload ? > > If you ask me the package is team maintained and a "Team upload" > should be fine. Hi, I just try to follow the rules I agreed on last month. https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id2 | Team in Uploaders is a weak statement of collaboration. Help in maintaining the package is appreciated, | commits to the Git repository are freely welcomed, but before uploading, please contact the Maintainer for the green light. There are not so many packages where "Uploader = DPT" to begin with, so this might not well a well-known practice... So I'm formally asking Ana & PaN for approval to upload "lexicon" and "dioptas". (lexicon is a one line change, dioptas needs to package a new release) @Vincent: thanks. Greetings - Debian Python Team dioptas (U) gtextfsm (U) lexicon (U) Ana Custura lexicon Debian PaN Maintainers dioptas
QA python3-unittest2
Hi, I'm busy with the (tentative-) removal of python3-unittest2. unitest2 is an old version of what has become "unittest.mock" in the standard library 90% of dependencies are stale and only need a quick edit of debian/control for the other I submit patches upstream Can I get (minimal) Salsa team membership for this one task ? maybe also checking for python3-mock & python3-six at the same time. I do not plan to do any upload of these packages and more generally I do not even fully grasp what OpenStack is about. I can maybe handle just this urgent one #1059108 [i|P|♔] [src:gnocchi] gnocchi: please remove extraneous dependency on python3-future python3-unittest2: """ designate-dashboard keystone mistral murano-agent neutron python-django-compressor python-funcsigs python-jenkins python-kafka python-linecache2 python-novaclient python-oauth2client python-pecan python-pymysql sahara-dashboard senlin-dashboard testresources trove-dashboard python3-six: #1053966 [n| | ] [python3-ironic-ui] python3-ironic-ui: please remove extraneous, obsolete, dependency on python3-six #1054151 [n| | ] [python3-neutron-vpnaas] python3-neutron-vpnaas: please remove obsolete python3-six dependency #1060114 [n| |↝] [src:python-txaio] python-txaio: please remove extraneous dependency on python3-six (so not these ones, unless requested) #1052512 [n| | ] [src:python-pysaml2] python-pysaml2: please package v7.4.2 and remove python3-six dependency #1053378 [n| | ] [src:python-gabbi] python-gabbi: please package v2.10.0 and remove dependency on python3-six Greetings
Bug#1060421: python3-botocore: botocore as a (useless) undeclared dependency on python3-six
Package: python3-botocore Version: 1.31.49+repack-1 Severity: important X-Debbugs-Cc: debian-python@lists.debian.org python3-core is importing python3-six for absolutely no reason this package only work by luck for now because the library got pulled-in by something else (most likely python3-urllib2) $ grep ' six' /usr/lib/python3/dist-packages/botocore -r | grep import /usr/lib/python3/dist-packages/botocore/compat.py:import six Greetings, A possibility to catch this earlier would be to add a deprecation warning inside python3-six ? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-botocore depends on: ii python3 3.11.4-5+b1 ii python3-dateutil 2.8.2-3 ii python3-jmespath 1.0.1-1 ii python3-requests 2.31.0+dfsg-1 ii python3-urllib3 2.0.7-1 python3-botocore recommends no packages. python3-botocore suggests no packages. -- no debconf information
Re: QA python3-unittest2
Le jeu. 11 janv. 2024 à 10:47, Thomas Goirand a écrit : > > I'm busy with the (tentative-) removal of python3-unittest2. > > > > unitest2 is an old version of what has become "unittest" in the > > standard library > > > > 90% of dependencies are stale and only need a quick edit of debian/control > > for the other I submit patches upstream > > Will you also send patches to upstream OpenStack? If so, please note > that OpenStack uses Gerrit, and you need to follow the instructions > detailed here for a new account: > https://docs.openstack.org/contributors/en_GB/common/accounts.html I will learn Gerrit because I'm curious... ...but 90% of these remaining dep on unittest2 are really only about removing 1 line from debian/control ... only committing this change + setting the bug as pending would already help with triaging I can send Salsa MR if that's easier for everyone too. > I'd strongly recommend sending patches upstream rather than in > downstream Debian packages only. The next OpenStack release (codename: > Caracal) is due for April, so if you send patches upstream now, it's > going to be in Debian soonish. Great > Note that upstream OpenStack has been actively removing the Six > dependency, and they'll be very happy to have some kind of help > finishing the work. I'll do. have a nice day
Re: QA python3-unittest2
Le mer. 17 janv. 2024 à 17:14, Thomas Goirand a écrit :
> On 1/17/24 14:25, Alexandre Detiste wrote:
> > Le jeu. 11 janv. 2024 à 10:47, Thomas Goirand a écrit :
> >>> I'm busy with the (tentative-) removal of python3-unittest2.
> >>>
> >> https://docs.openstack.org/contributors/en_GB/common/accounts.html
> > I can send Salsa MR if that's easier for everyone too.
>
> If you just send me the list of packages affected, with no change to be
> sent upstream, I can take care of it in a few minutes myself.
Yes please
>Or have you already filled the bugs?
I've filled a handful of bugs then it felt wrong so I dropped the ball
10 cases with the 1 extraneous line in d/control
keystone/debian/control: python3-unittest2,
neutron/debian/control: python3-unittest2,
python-django-compressor/debian/control: python3-unittest2,
python-kafka/debian/control: python3-unittest2,
python-novaclient/debian/control: python3-unittest2,
python-oauth2client/debian/control: python3-unittest2,
python-pecan/debian/control: python3-unittest2,
sahara-dashboard/debian/control: python3-unittest2,
senlin-dashboard/debian/control: python3-unittest2,
trove-dashboard/debian/control: python3-unittest2,
3 cases with 1 extraneous line in test-requirements.txt &
1 extraneous line in d/control
... removing the Debian line may trigger a regression
when someone package the next update.
These would be my first 3 Gerrit-requests
murano-agent/test-requirements.txt:unittest2>=1.1.0 # BSD
murano-agent/debian/control: python3-unittest2,
designate-dashboard/test-requirements.txt:unittest2>=1.1.0 # BSD
designate-dashboard/debian/control: python3-unittest2,
mistral/test-requirements.txt:unittest2>=1.1.0 # BSD
mistral/debian/control: python3-unittest2,
and then more, but that is scripted.. and will be for a next iteration
#!/bin/bash
lists=/var/lib/apt/lists/ftp.be.debian.org_debian_dists
mkdir -p /tmp/unittest2
grep-dctrl python3-unittest2 -n -s Vcs-Git
${lists}_*{Sources,Packages} | grep openstack | sort -u | while read
url
do
dir=$(basename $url)
git clone --depth=1 $url /tmp/unittest2/$dir
done
(cd /tmp/unittest2; grep -r unittest2 .)
Re: Fix for pysmbc -Python 3.12 transition
Hi, Thanks again I may have an identical pytest -> python3-pytest commit stuck in my home computer, but whatever. Please someone pick this up Greetings Le lun. 22 janv. 2024 à 09:31, Yogeswaran Umasankar a écrit : > > Hi Alexandre, > Came across pysmbc, saw that there was an issue while building. Worked > on the issue in a different branch “py312 transition’ [0]. If it looks > ok, please feel free to merge the branch. I hope the revisions help > Python 3.12 transition. > > [0] > https://salsa.debian.org/python-team/packages/pysmbc/-/tree/py312-transition?ref_type=heads > > Best regards, > Yogeswaran.
RM: nb2plots -- ROM; leaf package
control: tag -1 +moreinfo Hi, I'm using this (nice, alive...) package and I'm willing to maintain it in the Python Team. Greetings, Alexandre
Re: Suggesting change in DPT policy
+1 for this policy change too, I went through the same hurdles & thinking progress, but it's much fresher in py head because I m only contributing to DPT since 1/1/2024, doing exactly what I said I would do on my membership application mail. Before this talk happened I would not have recommended anybody to join the team. I m glad it is being resolved. Greetings Le dim. 3 mars 2024, 00:30, Emmanuel Arias a écrit : > +1 for this DPT policy change. > > When I started to contribute I received these kind of comments that made > me think if I could really start contributing to Debian. As time went by, > I learned to read first who is the maintainer of the package before read > the bug reported, no matter if the package is (apparently) under the DPT > umbrella. > -- > cheers, > Emmanuel Arias
Re: Would you agree with swapping Maintainer and Uploaders in eric?
Hi Jan, I see on the tracker that you have both set the LowNMU flag (like I did too) and also made use of the special rule of the DPT policy discussed from [1]; that seems a bit of a contradiction to me but I have read that it was the default behaviour of some source package templating tool which might explain where it came from. Would you agree to swap Maintainer & Uploader fields like proposed ? My offer to refresh the package still stands on. I would need this anyway for my work anyway in the coming months, that seems like a waste of time not to share this work. (we are currently using the bookworm .deb on buster and it justs works...) Greetings [0] https://tracker.debian.org/pkg/python-pika Le lun. 11 mars 2024 à 22:30, Andreas Tille a écrit : > > Hi Gudjon, > > in case you agree with the suggested change of policy discussed on the > debian-python mailing list[1] would you agree to set DPT as maintainer? > If yes, I'd volunteer to do this, fix bug #1065855 and #1060736. > > Kind regards and thanks for working on this package > Andreas. > > [1] https://lists.debian.org/debian-python/2024/02/msg00052.html
Re: morph's abandoned packages (list)
Hi, I would pick-up matplotlib I guess, I have some special connection to it, It was one the packages that enabled me to escape my horrible SAS-Insitute powered previous job/life. It's a big one. Help is appreciated, I already cherry picked some commits from Ciel's PR. I already adopted python3-pygraphviz Greetings
Re: morph's abandoned packages (list)
Just add yourself. Le ven. 15 mars 2024 à 15:38, Martin a écrit : > > On 2024-03-15 14:21, Alexandre Detiste wrote: > > I would pick-up matplotlib I guess, I have some special connection to it, > > I *might* help on this, because we use matplotlib at $DAYJOB, but can't > promise much, as my workload is already pretty high.
Re: morph's abandoned packages (list)
Hi, The arguments to remove flask-basicauth looks sensible, can someone confirm ? CCing Daniele who uploads bespoken flask-login and Carsten who manage whole flaks ecosystem. Greetings Le jeu. 14 mars 2024 à 07:20, Julian Gilbey a écrit : > > Dear all (and Bcc-ing the RM bugs), > > For information, here is a list of packages that morph has either > requested removal of or orphaned. If you are interested in taking one > or more of them on, that would be great! > > Removal requested: > > #1066146 RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package
Re: python-debian | remove some Python2 dead code (!131)
Hi, Does anyone know some automated tool to convert Python2-style annotations into Python3-style ? python-debian $ grep '# type' -r | wc -l 1499 Greetings Le dim. 17 mars 2024 à 13:46, Jelmer Vernooij (@jelmer) a écrit : > > Jelmer Vernooij commented on a discussion: > > Yes, we should be able to migrate to modern type annotations - happy to > review PRs that make that change :) https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/131
matplotlib
If you have the time/will, I would suggest to overhaul build to from 7 to new debhelper 13 with the automagic "%: dh $@" rule. Almost all other Python projects have already been converted. wc -l */debian/rules 29 lincity-ng/debian/rules 25 lmfit-py/debian/rules 21 logbook/debian/rules 28 logilab-constraint/debian/rules 35 love/debian/rules 21 ltris/debian/rules 15 lua-lpeg/debian/rules 13 magic-wormhole/debian/rules 206 matplotlib/debian/rules 14 mdp/debian/rules 18 microsoft-authentication-library-for-python/debian/rules 56 minetest/debian/rules 13 mir-eval/debian/rules 12 mrrescue/debian/rules 18 mu-cade/debian/rules
Re: Updated package list with packages open for adoption (Was: morph's abandoned packages (list))
Hi, I'd like to add paramiko to the list of semi-orphaned packages that needs more maintainers. high popcon, major upgrade, lots of rdeps: this would be a small transition by itself, like pytest 8 ... Le jeu. 28 mars 2024 à 10:24, Andreas Tille a écrit : > > ? #1065199 RM: pprintpp -- ROM; leaf package > Do we need this package? It looks dead upstream & was a trivial utility, let's drop it. > ? #1065246 O: contourpy -- Python library for calculating contours of 2D > quadrilateral grids > rdepends: python3-matplotlib > Taken by alexandre.deti...@gmail.com, deba...@debian.org https://salsa.debian.org/python-team/packages/contourpy/-/jobs/5508432 E ImportError: Python version mismatch: module was compiled for Python 3.11, but the interpreter version is incompatible: 3.12.2 dh-python or newer dh-sequence-python3 is missing from d/control (?) could it be the cause of the FTBFS ? I'l try again soon. > #1065325 O: matplotlib -- Python based plotting system >--> alexandre.deti...@gmail.com > + deba...@debian.org Not finished, was still debhelper 7 or 8 based from memory, had to kill xvfb-run several times to let the build complete successfully (?!) the resulting .deb does work. > General remark: I'd prefer if we would at least have [*] two maintainers per maintainer. > If you find my name in any Uploaders field and you are > interested in this package (no matter whether it is in this list or not) > please simply add your name and move on with doing on that package what > you feel necessary to do. If something might break we can fix it later. Please do the same. I'm bit of scatterbrain and can at some times only allocate small time slots to do small things so anything that hasn't been touched on the very same day is up for grab. ... but I do have some tooling to track my unfinished stuff. I'm moving python-socketio-client to DPT I can move "dosage" too if someone is interested (my only remaining non-team maintained package is "cruft-ng"; but that's not python ... anybody is welcome there too) Greetings
Re: New upstream version for python-pint
I've packaged font-awesome5 at work, for sure it's not in Debian. The upgrade to v5 was rightfully reverted but it's in limbo since. https://packages.debian.org/sid/fonts-font-awesome fonts-font-awesome (5.0.10+really4.7.0~dfsg-4.1) <-- Please note that this package provides Font Awesome 4 (not Font Awesome 5 or Font Awesome 6 which are different fonts with different licensing). Le lun. 1 avr. 2024 à 21:26, Antonio Valentino a écrit : > > Dear Thomas, > > Il 01/04/24 17:52, Thomas Goirand ha scritto: > > On 3/31/24 21:05, Antonio Valentino wrote: > >> Dear Thomas, > >> > >> Il 30/03/24 22:25, Thomas Goirand ha scritto: > >>> On 3/29/24 15:13, Antonio Valentino wrote: > Dear Thomas and Ondřej, > a couple of packages that I maintain are impacted by an RC bug in > python-pint (#1067318). > I think that an update to the to the latest pint version 0.23 should > be sufficient to fix the issue. > > If you agree, I would like prepare the package for the new upstream > version in the salsa. > Of course I will let to you the review and upload. > > Please let me know, > > > kind regards > >>> > >>> Please go ahead and feel free to add yourself as uploader. > >>> > >>> Thomas > >> > >> Thanks Thomas > >> The packages is now updated in salsa. > >> Unfortunately the reprotest job fails in CI, but I'm not able to > >> reproduce on my laptop and it seems not to be a regression. > >> I will try to fix it in future uploads but for the moment I would > >> prefer to have an upload to fix a couple of RC bugs. > >> > >> Could you please review and upload? > >> > >> I have also put myself as uploader. > >> I'm a DM so I kindly ask you to grant me upload permissions as > >> described in [3]. > >> > >> > >> kind regards > > > > Hi! > > > > Thanks for the work Antonio. > > > > 1/ In the clean target, please also clean: > > - Pint.egg-info > > - docs/savefig > > > > 2/ There's a typo in d/changelog, you wrote: "d/copuright". > > > > 3/ I'm really not sure about the python-pint-doc.lintian-overrides > > overriding "font-in-non-font-package". Can't you use the fonts from > > system instead? > > > > Cheers, > > > > Thomas Goirand (zigo) > > 1/ and 2/ are now fixed > > For 3/ I indeed did a quick search but I was not able to find a font > package providing the needed fonts > > $ apt-file search fa-brands-400.ttf > gnunet: > /usr/share/doc/gnunet/html/_static/vendor/fontawesome/6.1.2/webfonts/fa-brands-400.ttf.gz > icinga-php-library: > /usr/share/icinga-php/ipl/asset/static/font/awesome/fa-brands-400.ttf > node-fortawesome-fontawesome-free: > /usr/share/nodejs/@fortawesome/fontawesome-free/webfonts/fa-brands-400.ttf > ntopng-data: > /usr/share/ntopng/httpdocs/fontawesome-free-5.11.2-web/webfonts/fa-brands-400.ttf > omnidb-common: > /usr/lib/python3/dist-packages/OmniDB_app/static/OmniDB_app/lib/fa/webfonts/fa-brands-400.ttf > petsc3.18-doc: > /usr/share/doc/petsc3.18-doc/docs/_static/vendor/fontawesome/6.1.2/webfonts/fa-brands-400.ttf.gz > petsc3.19-doc: > /usr/share/doc/petsc3.19-doc/docs/_static/vendor/fontawesome/6.1.2/webfonts/fa-brands-400.ttf.gz > python-astroplan-doc: > /usr/share/doc/python-astroplan-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-astropy-doc: > /usr/share/doc/python-astropy-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-blosc-doc: > /usr/share/doc/python-blosc-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-cogent-doc: > /usr/share/doc/python-cogent-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-dask-doc: > /usr/share/doc/python-dask-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-distributed-doc: > /usr/share/doc/python-distributed-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-django-doc: > /usr/share/doc/python-django-doc/html/_static/fontawesome/webfonts/fa-brands-400.ttf.gz > python-h5netcdf-doc: > /usr/share/doc/python-h5netcdf-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-imageio-doc: > /usr/share/doc/python-imageio-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-md-toc-doc: > /usr/share/doc/python-md-toc-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-mpl-sphinx-theme-doc: > /usr/share/doc/python-mpl-sphinx-theme-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-nbformat-doc: > /usr/share/doc/python-nbformat-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-pandas-doc: > /usr/share/doc/python-pandas-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-pyqtgraph-doc: > /usr/share/doc/python-pyqtgraph-doc/html/_static/vendor/fontawesome/5.13.0/webfonts/fa-brands-400.ttf.gz > python-pystac-doc: > /usr/share/doc/python-
Re: Requests to join DPT haven't been processed for months
Thank you both Le mer. 3 avr. 2024 à 17:48, Christian Kastner a écrit : > > On 2024-04-03 16:50, Stefano Rivera wrote: > > We've added a new owner to help out. Thanks peb! > > > > Stefano > > Excellent, thanks Stefano and of course Pierre-Elliott for taking care > of this! > > Best, > Christian >
Fwd: [cdent/paste] Potentially ceasing development of Paste (Discussion #91)
Might interrest more here. -- Forwarded message - De : Chris Dent Date: ven. 5 avr. 2024, 19:18 Subject: [cdent/paste] Potentially ceasing development of Paste (Discussion #91) To: cdent/paste Cc: Alexandre Detiste , Mention < ment...@noreply.github.com> paste uses a lot of deprecated functionality, much of it related to old libraries like cgi and cgitb. When Python 3.13 becomes the main Python release this deprecated functionality will be removed and without a fair bit of work paste will stop working. I personally do not think we should continue to maintain paste. It is an old tool using old technology that is no longer aligned with modern techniques or tools. I would like us to consider winding it down but I'm not certain who should be involved in the discussion so pinging some of the people who have made contributions to the project over the last while: @a-detiste <https://github.com/a-detiste> , @amitmarkel <https://github.com/amitmarkel> , @benjaminp <https://github.com/benjaminp> , @Cito <https://github.com/Cito> , @cjwatson <https://github.com/cjwatson> , @CyrilRoelandteNovance <https://github.com/CyrilRoelandteNovance> , @blueyed <https://github.com/blueyed> , @brondsem <https://github.com/brondsem> , @hugovk <https://github.com/hugovk> , and of course @ianb <https://github.com/ianb> . Please register your opinion. If you feel like paste should carry on living, and want to volunteer to take over maintenance I'm very willing to transfer ownership. I also maintain pastescript and feel it should end too, so if someone wants to take them as a package deal that would be great. — Reply to this email directly, view it on GitHub <https://github.com/cdent/paste/discussions/91>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB47WUDN2YPOYOCW6TVPC5TY33MGFAVCNFSM6ABFZQFRXSVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGQ3DKMBVGQ> . You are receiving this because you were mentioned.Message ID:
Re: Status of sqlalchemy
Le lun. 15 avr. 2024 à 11:20, Thomas Goirand a écrit : > The rest of: > - pymodbus > > I don't even know what they do. Life is better when one does not have to deal with modbus :-) This package is outdated and need a refresh. > All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid and > we move on... Agreed, please move on
Re: Orphaning mu-editor, firmware-microbit-micropython, and their (build)-deps
Hi, I did this upstream bump because I think that MR on upstream & pristine-tar brach should not be allowed. (the Games Team did received several such MR from XZ-hack "Hans Jansen" puppet socket) Now Keith can rebase his changes unto that. Greetings Le sam. 20 avr. 2024, 00:34, Nick Morrott > Keith Packard (CC'd) is interested in contributing and co-maintaining > mu-editor, and there is a current MR in the repo. The mu-editor > repository has also just had a drive-by upstream bump to version 1.2.0 > but nothing else so far... > > Thanks, > Nick > >
Re: Orphaning mu-editor, firmware-microbit-micropython, and their (build)-deps
Hi, I understand you. Maybe the best option is to co-maintain this outside of the D Python Team. Greetings Le sam. 20 avr. 2024, 01:56, Keith Packard a écrit : > > > Now Keith can rebase his changes unto that. > > My changes involve stripping the non-DFSG elements out of the package, > and that requires shipping a non-upstream .tar.gz file for the source > archive. Because of that, I'm using a pure git process and not bothering > to generate pristine tar bits -- there's no usable upstream tarball > anyways. > > I'm willing to continue to maintain this package using that process, but > I don't really have any interest in using the existing python packagers > process because I don't think it applies in this case. > > -- > -keith >
Re: Status of pymodbus (was: Status of sqlalchemy)
Hi, I ll check back home, but it's most likely I was waiting for SQLAlchemy 2.xx. I know for share that one package does wait for SA 2.xx but can t remember which one. > It looks like all but one of the debian/patches are obsolete now? Sure Le lun. 22 avr. 2024, 08:09, Martin a écrit : > On 2024-04-15 11:38, Alexandre Detiste wrote: > > Le lun. 15 avr. 2024 à 11:20, Thomas Goirand a écrit : > >> The rest of: > >> - pymodbus > >> > >> I don't even know what they do. > > > > Life is better when one does not have to deal with modbus :-) > > Yes! > > > This package is outdated and need a refresh. > > As I see, you already pushed a new upstream to git in January/February, > but did not yet upload the package. Are there any blockers? It looks > like all but one of the debian/patches are obsolete now? >
Re: Status of pymodbus (was: Status of sqlalchemy)
Le lun. 22 avr. 2024, 09:57, Martin a écrit : > > 1. privacy-breach-fixes.patch (I updated this, can push > These ones are annoying to maintain. I wish dh_installdocs would be smart enough to strip these tiny widget that are present in so many Readme.md on GitHub. They re quite formulaic and it could be done with a regexp (but dh is in Perl 😢). Thanks
RM: pyannotate -- ROM; leaf package
control: tag -1 -moreinfo This one should still be removed ... It hasn't moved an inch still 2019 https://github.com/dropbox/pyannotate https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065045
paramiko: FTBFS: dh_auto_test: error: pybuild
> E ModuleNotFoundError: No module named 'six' This happens because we unknot the python3-mock -> python3-pbr -> python3-six dependency chain. I did this _on purpose_ to discover missing python3-six (build-)dependencies and/or upstream that needs a cleanup. Here it's of course better to do this long overdue paramiko update than merely adding python3-six as build-dep for a quick fix. Greetings and thank you https://tracker.debian.org/news/1492697/accepted-python-mock-510-1-source-into-unstable/ python-mock (5.1.0-1) unstable; urgency=medium . * Team Upload * New upstream version 5.1.0 (Closes: #717192, #717193, #1030887) (LP: #1248066) * remove obsolete build-dep python3-pbr & python3-unittest2 * use new dh-sequence-python3 https://tracker.debian.org/news/1505240/accepted-python-pbr-600-1-source-into-unstable/ python-pbr (6.0.0-1) unstable; urgency=medium . * New upstream release (Closes: #1060153). * Do not use six anymore.
Re: please be more careful about your team uploads
Hi, That was the very first day I got to work on DPT packages; so well yes, I did some mistakes at first; and having been DM for far too long (~10 years) I needed to retrain; I had so many things stuck in my queue at first. https://lists.debian.org/debian-python/2023/12/msg00012.html I'm now going through the ITP's needed for stalled package updates. Greetings Le mer. 8 mai 2024 à 15:58, Antoine Beaupré a écrit : > > Hi, > > I'm working on updating the python-invoke package and see you've done > two uploads on the package: > > https://tracker.debian.org/news/1491303/accepted-python-invoke-200-11-source-into-unstable/ > https://tracker.debian.org/news/1491393/accepted-python-invoke-200-12-source-into-unstable/ > > So, first off: thanks for fixing those issues! :) > > But, second, could you be a little more careful about how you do those? > Normally, I would have expected those changes to be pushed to salsa so > that I can build on top of. > > Or, at the very least, you should have sent a debdiff... The uploads are > a little bizarre too, because they have a NMU-like versionn number > (e.g. 2.0.0-1.1) yet they say "Team upload" on the changelog. Clearly > that should have yielded lintian warnings, did you ignore those? > > In any case, i'm now in the rather unfortunate position of having to > retrofit that stuff back in the package, and it's making my life a > little harder than it should... > > So please be a little more careful next time around, thanks! > > a.
Re: please be more careful about your team uploads
Ok I guess you want to do this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008768
Re: please be more careful about your team uploads
It is now in the NEW queue. https://salsa.debian.org/python-team/packages/python-pytest-relaxed/-/pipelines/675307 Le mer. 8 mai 2024 à 16:19, Antoine Beaupré a écrit : > On 2024-05-08 16:11:46, Alexandre Detiste wrote: > > Ok I guess you want to do this one: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008768 > > Not really! It's a RFP, if I was going to do it, I would have renamed > that package to "ITP" and reassigned it... > > a.
Bug#1070772: ITP: python-mutf8 -- encoders and decoders for the MUTF-8 character encoding
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-mutf8 Version : 1.0.0 Upstream Contact: Tyler Kennedy * URL : https://pypi.org/project/mutf8/ * License : MIT Programming Lang: Python Description : encoders and decoders for the MUTF-8 character encoding This package contains simple pure-python as well as C encoders and decoders for the MUTF-8 character encoding. In most cases, it can also parse the even-rarer CESU-8. These days, you'll most likely encounter MUTF-8 when working on files or protocols related to the JVM. Strings in a Java .class file are encoded using MUTF-8, strings passed by the JNI, as well as strings exported by the object serializer. This library was extracted from Lawu, a Python library for working with JVM class files. I will maintain this inside DPT. This is a new dependency of androguard
Re: Bug#1065325: morph's abandoned packages (list)
Yes do please. Le sam. 11 mai 2024 à 20:51, Nilesh Patra a écrit : > > Quoting Alexandre Detiste : > > I would pick-up matplotlib I guess, I have some special connection to it, > > It was one the packages that enabled me to escape > > my horrible SAS-Insitute powered previous job/life. > > > > It's a big one. > > > > Help is appreciated, I already cherry picked some commits from Ciel's PR. > > Would you consider to add me in as an Uploader (co-maintainer) alongside you? > > I am a Debian Developer. > > Best, > Nilesh
Re: Status of pymodbus (was: Status of sqlalchemy)
helper.py is not so helpful (and not even used in test/conftest.py ?) anyway it builds now but maybe upstream would accept a patch to help reduce the downstream patch (maybe read certificates location from env variable, this needs more eyes) It's almost done. Greetings Le mar. 23 avr. 2024 à 00:06, Martin a écrit : > > Hi Alexandre, > > I pushed my changes to debian/master. If you have time to work on > pymodbus (e.g. update disable-failing-unittests.patch), please go on. > I probably can't work on that this week. > > Cheers
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit : > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > >Debian unstable. > > Please transition all the rdepends first. Asking before that's done just > creates more work for everyone. > > Scott K It looks like for this one package it's already clear. @Julian: here it looks you forgot to check build-depends: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200 I don't know what's the best way to check this, I use this template hereunder Greetings #!/bin/sh Sources=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_source_Sources Packages=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_binary-amd64_Packages ben query '.build-depends ~ "python3-lazy-fixture"' $Sources -s Package,Maintainer ben query '.build-depends-indep ~ "python3-lazy-fixture"' $Sources -s Package,Maintainer ben query '.depends ~ "python3-lazy-fixture"' $Packages -s Package,Maintaine
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
Le mar. 14 mai 2024 à 08:35, Julian Gilbey a écrit : > > On Mon, May 13, 2024 at 11:07:54PM +0200, Alexandre Detiste wrote: > > Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit > > : > > > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > > > >Debian unstable. > > > > > > Please transition all the rdepends first. Asking before that's done > > > just creates more work for everyone. > > > > > > Scott K > > > > It looks like for this one package it's already clear. > > > > @Julian: here it looks you forgot to check build-depends: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200 > > Oh, gosh, I thought I had done so (this is cython3-legacy), but I > clearly made a serious mistake in my attempt! I made a mistake in my attempt too..., here's the real list: Maintainer: Sandro Tosi Package: prettytable Maintainer: Debian GIS Project -> CC'ing Antonio Package: pycoast Package: pyresample Maintainer: Debian Python Team Package: python-django-timezone-field Package: python-limits Package: python-marshmallow-sqlalchemy
Bug#1071992: sqlmodel: please make this package compatible with SQL Alchemy 2.x
Source: sqlmodel Version: 0.0.16-1 Severity: important X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainer, This package hinders the transition to SQLAlchemy 2.x https://ci.debian.net/packages/s/sqlacodegen/testing/amd64/47034051/#S3 Greetings
Re: Status of pymodbus (was: Status of sqlalchemy)
Hi, I finally got it working here ! For a very short time. Then it breaks again with today's new Pytest. https://salsa.debian.org/python-team/packages/pymodbus/-/jobs/5780102 -> "test" branch. https://github.com/pytest-dev/pytest/issues/12269 It needs a new pytest-asyncio ... https://tracker.debian.org/pkg/python-pytest-asyncio I look at it. Greetings Le mar. 23 avr. 2024 à 00:06, Martin a écrit : > > Hi Alexandre, > > I pushed my changes to debian/master. If you have time to work on > pymodbus (e.g. update disable-failing-unittests.patch), please go on. > I probably can't work on that this week. > > Cheers
urllib3 v2.0.7-1
Hi, Can we upload urllib3 v2.0.7 to unstable ? (more recent versions breaks backward compatibility) It is in Ubuntu stable [0] with very little breakage so far [1]: [0] https://launchpad.net/ubuntu/+source/python-urllib [1] https://salsa.debian.org/python-team/packages/python-chemspipy/-/commit/693d4c9e474a58149cf5c70a404e32d1a48b2d3d
Re: urllib3 v2.0.7-1
There was a timebomb in the code ... :-( It did worked on 2023-11-12, it fails from 2024-01-01 ... > assert RECENT_DATE > (datetime.datetime.today() - two_years).date() 2777E AssertionError: assert datetime.date(2022, 1, 1) > datetime.date(2022, 6, 13) Then it breaks again because some exception strings changed since in a lower SSL layer (python-cryptography ...?) I check this. Greetings Le mer. 12 juin 2024 à 15:36, Daniele Tricoli a écrit : > Hello! > > On 6/12/24 11:56, Alexandre Detiste wrote: > > Can we upload urllib3 v2.0.7 to unstable ? > > (more recent versions breaks backward compatibility) > > Please go ahead, and thanks!
Bug#1073178: awscli: please update awsci and/or botocore to support urllib3 2.x
Source: awscli Version: 2.15.22-1 Severity: serious Justification: FTBFS X-Debbugs-Cc: debian-python@lists.debian.org, Noah Meyerhans Dear Maintainers, Please update awscli and/or botocore to untangle the urllib3 2.x transition. https://tracker.debian.org/pkg/python-urllib3 : see failing autopkgtests that leads here: https://github.com/aws/aws-cli/issues/7905 "cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'" https://github.com/boto/botocore/pull/2924/files Greetings Alexandre
Bug#1073179: python-requests-cache: please apply patch for urlllib3 2.x compatibility
Source: python-requests-cache Version: 0.9.8-2 Severity: serious X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainer, Please consider applying Ubuntu patch to add urllib3 2.x compatibility, or alternatively package a newer version of python-requests-cache https://patches.ubuntu.com/p/python-requests-cache/python-requests-cache_0.9.8-1ubuntu1.patch Greetings Alexandre
Bug#1073180: python-requests-unixsocket: please replace abandonned python-requests-unixsocket by src:python-requests-unixsocket2 fork
Source: python-requests-unixsocket Version: 0.3.0-4 Severity: serious Justification: FTBFS X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainers, python-requests-unixsocket is abandonned and was never adapted to work with urllib3 2.x released 2023-04-26. Please consider updating to this fork (versionned 0.4) https://gitlab.com/thelabnyc/requests-unixsocket2 > Since this project seems to be abandoned, > but its longevity is important to my team, > we've forked the project as requests-unixsocket2. > It should be a drop in replacement for this package. > > PyPI: https://pypi.org/project/requests-unixsocket2/0.4.0/ > Repository: https://gitlab.com/thelabnyc/requests-unixsocket2 Fedora already does that: https://src.fedoraproject.org/rpms/python-requests-unixsocket/raw/rawhide/f/python-requests-unixsocket.spec I found out thanks to repology.com. Greetings
Re: Contacting DPT
Hi, Le mer. 12 juin 2024 à 16:22, Thomas Goirand a écrit : > On 6/6/24 17:40, Andreas Tille wrote: > >- Do you consider the workload of your team equally shared amongst its > > members? > > The team probably lacks organization, and there's no clear enough > strategy for end goals. > > I know we're moving toward getting rid of: > - six > - mock > - nose and unittest2, and zombie-imp, and 2to3, and cython3-legacy and m2r and mistune0 and ... Even only listing all of these on wiki with what they could be replaced with would be good starter. We could rely on the standard transition tracker to see what remains: https://release.debian.org/transitions/ or having those get from FTP-Masters an "oldlibs" overide. I've my own tracker but it's mostly a toy I build to see what could be done with UDD and playing around with matplotlib. An optimal moment to check whether these old dependencies can be removed seems to be when a new upstream is available. (m = mock, n=nose, s=six) $ cat snap androguard m (depends on Java stuff..) backblaze-b2 m n s (huge) elasticsearch-curator m n (depends on new spun out library too ITP) fabric n (I tried) heudiconv m(attempted uploaded to experimental) mu-editor m (discussion on mailing list about packaging style went nowhere) pagure m s Now I think I could sort this by upstream release date & make an RSS out of it ;-) > but is anyone doing any type of coordination for the work to be done ? I guess people being members of several Teams could give precious help. I don't see myself pledging to join Teams just to remove a handful lines from d/control files, and then be gone forever. > It's been a way too long. Agree Greetings
Re: urllib3 v2.0.7-1
Here comes the breakage ... (thanks Lucas) this breaks actually more things than the Urllib3 2.x version bump. https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240615;users=lu...@debian.org #1073360 [S|⛺| ] [src:fabric] fabric: FTBFS: ModuleNotFoundError: No module named 'six' #1073361 [S|⛺| ] [src:python-ldappool] python-ldappool: FTBFS: ModuleNotFoundError: No module named 'six' #1073365 [S|⛺| ] [src:django-cas-server] django-cas-server: FTBFS: ModuleNotFoundError: No module named 'six' #1073366 [S|⛺| ] [src:ansible-runner] ansible-runner: FTBFS: ModuleNotFoundError: No module named 'six' #1073368 [S|⛺| ] [src:python-flickrapi] python-flickrapi: FTBFS: ModuleNotFoundError: No module named 'six' #1073371 [S|⛺| ] [src:gitsome] gitsome: FTBFS: ModuleNotFoundError: No module named 'six' #1073376 [S|⛺| ] [src:python-fedora] python-fedora: FTBFS: ModuleNotFoundError: No module named 'six' #1073487 [S|⛺| ] [src:cdist] cdist: FTBFS: Could not import extension cdist.sphinxext.manpage (exception: No module named 'six') #1073488 [S|⛺| ] [src:python-releases] python-releases: FTBFS: Could not import extension releases (exception: No module named 'six') Le mer. 12 juin 2024 à 15:36, Daniele Tricoli a écrit : > > Hello! > > On 6/12/24 11:56, Alexandre Detiste wrote: > > Can we upload urllib3 v2.0.7 to unstable ? > > (more recent versions breaks backward compatibility) > > Please go ahead, and thanks!
Bug#1073544: ITS: python-flickrapi
Source: python-flickrapi Version: 2.1.2-5.1 Severity: important X-Debbugs-Cc: Debian Python Dear Maintainer, I did uploaded a NMU for python-flickrapi right now to fix this RC bug: #1073368 [S|⛺| ] [src:python-flickrapi] python-flickrapi: FTBFS: ModuleNotFoundError: No module named 'six' This new upload also fix all existings Debian & Ubuntu bugs and help untangle the Nose removal. On a longer term I plan to maintain this package under the Python Team umbrella. Greetings
Re: Contacting DPT
Hi, Le jeu. 20 juin 2024 à 06:50, Emmanuel Arias a écrit : > On Fri, Jun 14, 2024 at 06:41:58PM +0200, Alexandre Detiste wrote: > > Le mer. 12 juin 2024 à 16:22, Thomas Goirand a écrit : > > > I know we're moving toward getting rid of: > > > - six > > > - mock > > > - nose > > > > and unittest2, > > and zombie-imp, > > and 2to3, > > and cython3-legacy > > and m2r > > and mistune0 > > and ... > > > > Even only listing all of these on wiki with > > what they could be replaced with would be good starter. > Hi, could you please share the list of those? I have in mind six, mock, > nose unittest2, 2to3 and cython3-legacy. > > Cheers, https://wiki.debian.org/Python/Dead%20Batteries > If the team are OK I can update the wiki with this information. It's a wiki ... I think anybody can improve it without asking permission. The mail software didn't like my last email with a tiny, monochrome, graphviz rendering in attachment. I haven't figured out how to include images on the wiki yet. Here's an online rendering: https://dreampuf.github.io/GraphvizOnline/?compressed=CYSw5gTghgDgFgAggUwLYHsBuUA2BnBAbwCgEE8QAPUhDAYwGsaA7dPZGgL3VQCMRkAfRCoYCANo4ovZDgC8AIm58BAWhEwFAXRowAngGYAjACYJddDnQQ5kZMmY6yOELxMAXdAYlSZ8hR5e2jR0eu5w6MwGgjjIYFChPtKyiqHhkQaqsfGhwWSoIHjuAK7MyAAMNKgmEAg0pSDu7shFJjRWjABmILE0oEXF7j14NO2ugd6qAHwI%2BsZtZP0lQ-gI0wgubp4GLGzIazPK-EIaIWERUTFxCXoHCEcCwqK77HebE1WFJWXld6zsVRqdwKAx%2BZDI7XQXR6%2B3W-w4AF8gA
Re: urllib3 v2.0.7-1
I fixed this one too, now a little VAC. "fabric" is the most complex one. - ansible-runner (2.4.0-0.1) unstable; urgency=medium + Non-maintainer upload. * New upstream version 2.4.0 (Closes: #1073366, #1068087) * Add dependency on pybuild-plugin-pyproject * Remove dependency on python3-mock (Closes: #1068086) * Add watch file * Add gbp.conf matching existing repos * Use new dh-sequence-python3 Le dim. 16 juin 2024 à 22:55, Alexandre Detiste a écrit : > > Here comes the breakage ... (thanks Lucas) > this breaks actually more things than the Urllib3 2.x version bump. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240615;users=lu...@debian.org > > #1073360 [S|⛺| ] [src:fabric] fabric: FTBFS: ModuleNotFoundError: No > module named 'six' > #1073361 [S|⛺| ] [src:python-ldappool] python-ldappool: FTBFS: > ModuleNotFoundError: No module named 'six' > #1073365 [S|⛺| ] [src:django-cas-server] django-cas-server: FTBFS: > ModuleNotFoundError: No module named 'six' > #1073366 [S|⛺| ] [src:ansible-runner] ansible-runner: FTBFS: > ModuleNotFoundError: No module named 'six' > #1073368 [S|⛺| ] [src:python-flickrapi] python-flickrapi: FTBFS: > ModuleNotFoundError: No module named 'six' > #1073371 [S|⛺| ] [src:gitsome] gitsome: FTBFS: ModuleNotFoundError: > No module named 'six' > #1073376 [S|⛺| ] [src:python-fedora] python-fedora: FTBFS: > ModuleNotFoundError: No module named 'six' > #1073487 [S|⛺| ] [src:cdist] cdist: FTBFS: Could not import extension > cdist.sphinxext.manpage (exception: No module named 'six') > #1073488 [S|⛺| ] [src:python-releases] python-releases: FTBFS: Could > not import extension releases (exception: No module named 'six') > > Le mer. 12 juin 2024 à 15:36, Daniele Tricoli a écrit : > > > > Hello! > > > > On 6/12/24 11:56, Alexandre Detiste wrote: > > > Can we upload urllib3 v2.0.7 to unstable ? > > > (more recent versions breaks backward compatibility) > > > > Please go ahead, and thanks!
Re: Proposal IRC meeting DPT
Hi, Should the severity of the distutils removal bugs be bumped now ? Example such bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065939 Greetings Le sam. 29 juin 2024 à 10:46, Matthias Klose a écrit : > binNMUs are now done, next thing is to get python3-defaults migrating, > filing bug reports and fixing for all the failed autopkg tests triggered > by https://tracker.debian.org/pkg/python3-defaults > > plus looking at the messages on the same page like > > migrating python3/3.12.2-1/amd64 to testing makes FOO uninstallable > > and fixing those.
Re: Finalize Python 3.12. migration (Re: Proposal IRC meeting DPT)
Here I was precisely asking about the remaining open 46 bugs [0] that ask to remove the (mostly stale) "python3-distutils" dependencies. python3-distutils has been removed from Ubuntu since 24.04 [1] and a lot of these 46 packages carry there these single line patch: [2] while some Debian packages are not in Ubuntu at all too. Making these bugs RC now seems like a reasonable idea. [0] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.12;users=debian-python@lists.debian.org;include=subject%3Adistutils [1] https://packages.ubuntu.com/search?keywords=python3-distutils [2] https://patches.ubuntu.com/d/docker-pycreds/docker-pycreds_0.3.0-1.1ubuntu1.patch
Bug#1074527: RM: versiontools -- RoQA; RC buggy, dead upstream, distutils is gone from Py3.12
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: versionto...@packages.debian.org, Benjamin Drung , debian-python@lists.debian.org Control: affects -1 + src:versiontools User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, This piece of software hasn't seen any upstream activity since 2012 and is not compatible with more recent Python. There is already no reverse-dependency left. Greetings
Re: Finalize Python 3.12. migration (Re: Proposal IRC meeting DPT)
Le lun. 1 juil. 2024 à 00:09, Emmanuel Arias a écrit : > On Sat, Jun 29, 2024 at 10:08:46PM +0200, Alexandre Detiste wrote: > > Here I was precisely asking about the remaining open 46 bugs [0] > > that ask to remove the (mostly stale) "python3-distutils" dependencies. > > > Making these bugs RC now seems like a reasonable idea. > Make sense. > > I think that we can tackle this (?). Searching this: `python3-distutils > path:debian/control` > I found around 90 packages. > > I don't know the steps to do this, but I think fill RC bugs and then Graham filled these bugs back then, but I raised the severity. I have this script [s] but it seems it gives me false positives. An official transition tracker would be easier for everyone. (it uses the "ben" syntax/tool too underneath) https://release.debian.org/transitions/ I fixed the one Orphaned package: it was easy ;-) https://sources.debian.org/src/djvubind/1.2.1-6/debian/patches/remove-distutils.patch/ [s] #!/bin/sh Sources=/var/lib/apt/lists/ftp.be.debian.org_debian_dists_unstable_*_source_Sources Packages=/var/lib/apt/lists/ftp.be.debian.org_debian_dists_unstable_*_binary-amd64_Packages ben query '.build-depends ~ "python3-distutils"' $Sources -s Package,Maintainer ben query '.build-depends-indep ~ "python3-distutils"' $Sources -s Package,Maintainer ben query '.depends ~ "python3-distutils"' $Packages -s Package,Maintainer
python3-lazy-fixture removal / prettytable
Hi Sandro, Please upload a new prettytable. It is the last package hindering the removal of pytest-lazy-fixture. The live fork is now pytest-lazy-fixtures with an extra "s". https://lists.debian.org/debian-python/2024/05/msg00081.html Greetings >Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit : > > I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > > Debian unstable. > Please transition all the rdepends first. > Asking before that's done just creates more work for everyone. > Scott K
distutils removal : shotwell
Hi, I found this package awaiting sponsoring on Mentors: https://mentors.debian.net/package/shotwell/ I see the RFS on the tracker https://tracker.debian.org/pkg/shotwell I guess that will mean one less NMU to do :-) Good night
distutils removal: pyroma
Hi, Do you need help from the team to finish this update ? https://salsa.debian.org/debian/pyroma/-/commit/aa929c56945978287336bd036e132189ba73c7df Greetings
Re: python-debian | remove some Python2 dead code (!131)
Ha ! https://github.com/ilevkivskyi/com2ann Le dim. 17 mars 2024 à 23:01, Thomas Goirand a écrit : > > On 3/17/24 14:56, Alexandre Detiste wrote: > > Hi, > > > > Does anyone know some automated tool to convert Python2-style annotations > > into Python3-style ? > > > > python-debian $ grep '# type' -r | wc -l > > 1499 > > > > Greetings > > You may try to run "sixer" which was written by a Python core developer, > and used to convert all of OpenStack to python2 + 3 using six. Once it > has found all the things that may use six, you can manually convert to > *not* use six anymore. I did this multiple times, and it worked well for > me at least. > > I hope this helps, > Cheers, > > Thomas Goirand (zigo) >
Bug#1076459: RM: python-pytest-lazy-fixture -- ROM; RC buggy, not compatible with Pytest8, dead upstream, has a replacement
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-pytest-lazy-fixt...@packages.debian.org, debian-python@lists.debian.org Control: affects -1 + src:python-pytest-lazy-fixture User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, Usage of unmaintained "python-pytest-lazy-fixture" has been replaced with "python-pytest-lazy-fixtures" (the new one with an extra 'S' at the end.) Greetings
Re: Consul library packaging
Le mer. 17 juil. 2024 à 22:18, Tomasz Rybak a écrit : > I'm interested in Python Consul package, as I'm using it at work. > Alexandre - do you need help with packaging? Yes I need help with this one. I won't be available for two more weeks > Question to DPT - what are we doing with python-consul2? > I'd propose to RM it after uploading newest version pf python-consul, > but wanted to discuss it first. If I ask "ben", it says nothing needs python3-consul2 anymore; I'd propose to file the RM bug right away. ben query '.build-depends ~ "python3-consul2"' $Sources -s Package,Maintainer ben query '.build-depends-indep ~ "python3-consul2"' $Sources -s Package,Maintainer ben query '.depends ~ "python3-consul2"' $Packages -s Package,Maintainer
Re: Consul library packaging
Le mer. 17 juil. 2024 à 22:43, olivier sallou a écrit : > Or adding a new python-consul3 package Please no There are not so many reverse dependencies to begin with (and 0 for python3-consul2) a new version of consul would be first uploaded to experimental. Debian Med Packaging Team biomaj3-daemon biomaj3-download biomaj3-process biomaj3-user Debian OpenStack masakari-monitors python-tooz Debian PostgreSQL Maintainers patroni
jupyterhub: Unsatisfiable Build-Depends python3-pydantic (>= 2)
version: 5.0.0+ds1-1 Hi, I uploaded Pydantic 2.x today. jupyterhub did build
[no subject]
Hi Nilesh, I joined Astro team and took care of matplotlib rdeps there. I'm struggling with basemap... I don't understand how this multi-package with it's 3 setup.py works. It's the very last rdpeps that will block migration later on. I think it's the right time to upload to Unstable. --- matplotlib build is failing right now too. Salsa CI logs are truncated & useless. dh_sphinxdoc -O--buildsystem=pybuild dh_sphinxdoc: error: debian/python-matplotlib-doc/usr/share/doc/python-matplotlib-doc/html/search.html does not load searchindex.js make: *** [debian/rules:26: binary] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package Greetings
Re: basemap
Le lun. 22 juil. 2024, 12:59, Drew Parsons a écrit : > On 2024-07-22 11:40, Alexandre Detiste > I'm struggling with basemap... I don't understand how > > this multi-package with it's 3 setup.py works. > > It's the very last rdpeps that will block migration later on. > > > > I think it's the right time to upload to Unstable. > Done. matplotlib 3.9 can be uploaded to experimental to see what next breaks elsewhere. The new basemap has pushed setup.py down into one of the subdirs. I've > haven't looked into it deeply, but I'm wondering if it might work just > setting appropriate PYBUILD_* variables in debian to point sourcedir at > the new subdir containing setup.py? i.e. activating pybuild's --dir > option. Not sure if that would mean a PYBUILD_DIR variable or something > else. Depends on whether we can ignore the other new subdirs. I haven't > checked for correspondence between the new and the old basemap source. > > Drew > If the upstream tarball is really 3 projects duct-taped together we could maybe import it in 3 different sources packages. The mk-orig-tgz would be a tad complicated, but build would be easy again. That needs checking. Greetings
Re: Alternative libraries for PEP-594
Hi, I will need some "zombie-telnetlib" (so exactly the same API as existing telnetlib) because I maintain proprietary .deb (not "Debian packages") that need to be installable without rebuild on Buster, Bookworm & Trixie. I understand that "telnetlib3" / "exscript" are 'better/newer' API but that does not fit the need. Debian could also benefit from this zombie-telnetlib. Should it be a native package or one with real upstream on PyPi ? Greetings Le ven. 2 août 2024 à 09:13, Louis-Philippe Véronneau a écrit : > telnetlib: > * telnetlib3: a Telnet Client and Server library for python [2] > * exscript: automating network connections over protocols such as Telnet or > SSH [3] > > Is anyone in the DPT interested in packaging and maintaining these libraries? > They will likely be very useful for the 3.13 transition. > > From the stats I have, I currently count: > > * 37 packages using telnetlib
Re: Alternative libraries for PEP-594
Le ven. 2 août 2024 à 11:19, Louis-Philippe Véronneau a écrit : > > Should it be a native package or one with real upstream on PyPi ? So it seems there's a global need for those zombie-libraries. > eamanu said he would make a list of upstream projects we could package, > but if you have some time, getting a list of projects would be great. Just add those there + mention these are not yet packaged: https://wiki.debian.org/Python/Dead%20Batteries > The last thing we want is to maintain some deprecated zombie-libraries > forever in Debian :( We don't want be we have to
Re: Alternative libraries for PEP-594
Le ven. 2 août 2024 à 12:25, Blair Noctis a écrit : > > Debian could also benefit from this zombie-telnetlib. > > How? > > On the other hand, it would allow packages to continue relying on a thing > expunged from upstream, a maintenance burden for both Debian and upstream. If we for example need to patch 10 dead-upstream projects to re-add telnetlib.py & the corresponding stanza in d/copyright it might be less work to scale it out in an external source package. All of this depends on how many packages will need this telnetlib. codesearch gives pages and pages of stuff with a lot of false positives https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5
Bug#1077848: pudb: please update to 2024.1.2 to remove usage of telnetlib
Source: pudb Version: 2022.1.3-1 Severity: important X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainers, The telnetlib module has been removed from Python3.13. Usage of this module has already been removed upstream. https://github.com/inducer/pudb/pull/626 pudb/remote.py:import telnetlib as tn pudb/remote.py:raw_sock_file.write(tn.IAC + tn.WILL + tn.SGA) pudb/remote.py:assert resp == tn.IAC + tn.DO + tn.SGA pudb/remote.py:raw_sock_file.write(tn.IAC + tn.WILL + tn.ECHO) pudb/remote.py:assert resp == tn.IAC + tn.DO + tn.ECHO Greetings, Alexandre
Bug#1077850: murano-tempest-plugin depends on deprecated telnetlib
Source: murano-tempest-plugin
Version: 2.7.0-2
Severity: important
X-Debbugs-Cc: debian-python@lists.debian.org
Dear Maintainer,
murano-tempest-plugin (ab)uses telnetlib to do some port knocking.
telnetlib has been removed from Python 3.13
I also see that this project has been archived upstream.
Greetings
https://opendev.org/openstack/murano-tempest-plugin
"This project is no longer maintained."
https://sources.debian.org/src/murano-tempest-plugin/2.7.0-2/murano_tempest_tests/tests/functional/common/utils.py/?hl=21#L21
@classmethod
def verify_connection(cls, ip, port):
"""Try to connect to specific ip:port with telnet.
:param ip: Ip that you want to check
:param port: Port that you want to check
:return: :raise RuntimeError:
"""
tn = telnetlib.Telnet(ip, port)
tn.write('GET / HTTP/1.0\n\n')
try:
buf = tn.read_all()
LOG.debug('Data:\n {data}'.format(data=buf))
if len(buf) != 0:
tn.sock.sendall(telnetlib.IAC + telnetlib.NOP)
return
else:
raise RuntimeError('Resource at {0}:{1} not exist'.
format(ip, port))
except socket.error as e:
LOG.error('Socket Error: {error}'.format(error=e))
Re: Alternative libraries for PEP-594
Le ven. 2 août 2024 à 13:41, Blair Noctis a écrit : > > https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5 > > Searching in regex mode with `import.*telnetlib path:*.py` should give more > accurate results. Thank you, it gaves indeed better results. Filed two bugs & uploaded pychess; there's not s much to review for this one library; (but we have like 20-something deprecated libraries in Py3.13) This one is awesome ;-), it reminds of old time screen-scrapping https://sources.debian.org/src/astrometry.net/0.95+dfsg-1/util/horizons.py/ No one will ever dare to rewrite this with another library. --- What should we do for the new netmiko that vendors importlib wholesale in next to-package release ?: - simply paper over it in d/copyright - unvendor & depends on python3-zombie-telnetlib for better tracability https://github.com/ktbyers/netmiko/commit/b2700b56337dc7a04e6d8980e2a71eb4215e5d4e > Please file bugreports/issues to ask the packages you care about to migrate. I don't care for any of these packages but more for the distribution as a whole. MBF with the new fixed Lintian tag is the way to go. Greetings
Re: Requesting membership in Debian Python team for Taavi Väänänen
I've done some work upstream on mwclient and it is nice to see it adopted. (I can't proceed your request, only encourage it) Greetings Le sam. 10 août 2024 à 08:35, Taavi Väänänen a écrit : > > Hi, > > I'm requesting membership in the Debian Python team in order to adopt[0] > the mwclient package[1] which seems like a good fit for the team. > > I have read and accept the Python team policy. My Salsa username is 'taavi'. > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068659 > [1]: https://tracker.debian.org/pkg/mwclient > > thanks in advance, > Taavi
Bug#1078691: r4d: please move away from pysimplesoap that is Orphaned & slated for removal
Source: r4d Version: 1.7-4.1 Severity: serious Forwarded: https://github.com/ci-rt/r4d/issues/2 X-Debbugs-Cc: debian-python@lists.debian.org Dear Maintainer, The library pysimplesoap is obsolete & Orphaned in Debian. Please use an other SOAP library (like Zeep) Greetings
Re: Bug#1078664: ITP: sphinx-jinja2-compat -- Patches Jinja2 v3 to restore compatibility with earlier Sphinx versions
Hi, > "as it is a dependency for another package" Can you give more details ? It seems usage of this compat lib could/should be patched-out. Greetings Le mer. 14 août 2024 à 01:57, Kathara Sasikumar a écrit : > > Package: wnpp > Severity: wishlist > Owner: Kathara Sasikumar > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: sphinx-jinja2-compat > Version : 0.3.0 > Upstream Contact: Dominic Davis-Foster > * URL : https://github.com/sphinx-toolbox/sphinx-jinja2-compat > * License : Expat > Programming Lang: Python > Description : Patches Jinja2 v3 to restore compatibility with earlier > Sphinx versions > > Sphinx-jinja2-compat provides patches for Jinja2 v3 to ensure compatibility > with older Sphinx versions. > > I wish to package sphinx-jinja2-compat as it is a dependency for another > package that I am working on. I intend to maintain it within the Debian Python > Team. > > > Thank you, > Kathara Sasikumar >
Re: Python2 idiosyncrasies in Python3 scripts
Hi, We should patch modernize in Debian to make --no-six the default. (otherwise it is a big pitfall) "It does not guarantee, but it attempts to spit out a codebase compatible with Python 2.6+ or Python 3. The code that it generates has a runtime dependency on six, unless the --no-six option is used. Version 1.9.0 or later of six is recommended. Some of the fixers output code that is not compatible with Python 2.5 or lower." Le jeu. 15 août 2024, 13:39, Andrey Rakhmatullin a écrit : > On Thu, Aug 15, 2024 at 01:11:23PM +0200, Jerome BENOIT wrote: > > > > is there a reliable way to isolate Python2 idiosyncrasies in Python3 > scripts ? > Try modernize or any linter. > > -- > WBR, wRAR >
Bug#1079377: graypy: please replace usage of python3-amqplib with python3-amqp
Source: graypy
Version: 2.1.0-1
Severity: important
X-Debbugs-Cc: debian-python@lists.debian.org
Dear Maintainer,
graypy is the only (remaining ?) user of python3-amqplib which
is RC buggy and needs some 2to3 magic to be kept alive.
https://github.com/severb/graypy/pull/143/files
Please consider applying this upstream patch.
Greetings.
Alexandre
---
>From 916cf0db7fb66ede18241bb54a3e3e77d4d02ecc Mon Sep 17 00:00:00 2001
From: "felix.gao"
Date: Tue, 24 Oct 2023 12:16:59 +0800
Subject: [PATCH] Replace dependency amqplib with amqp
---
graypy/rabbitmq.py | 3 ++-
setup.py | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/graypy/rabbitmq.py b/graypy/rabbitmq.py
index ea7be2cdf..2d03b24cf 100644
--- a/graypy/rabbitmq.py
+++ b/graypy/rabbitmq.py
@@ -8,7 +8,7 @@
from logging import Filter
from logging.handlers import SocketHandler
-from amqplib import client_0_8 as amqp # pylint: disable=import-error
+import amqp
from graypy.handler import BaseGELFHandler
@@ -98,6 +98,7 @@ def __init__(self, cn_args, timeout, exchange, exchange_type,
routing_key):
self.exchange_type = exchange_type
self.routing_key = routing_key
self.connection = amqp.Connection(connection_timeout=timeout,
**self.cn_args)
+self.connection.connect()
self.channel = self.connection.channel()
self.channel.exchange_declare(
exchange=self.exchange,
diff --git a/setup.py b/setup.py
index 925dc12b7..38ba42bcb 100755
--- a/setup.py
+++ b/setup.py
@@ -80,10 +80,10 @@ def run_tests(self):
"pylint>=1.9.3,<2.0.0",
"mock>=2.0.0,<3.0.0",
"requests>=2.20.1,<3.0.0",
-"amqplib>=1.0.2,<2.0.0",
+"amqp>=5.1.1",
],
extras_require={
-"amqp": ["amqplib==1.0.2"],
+"amqp": ["amqp==5.1.1"],
"docs": [
"sphinx>=2.1.2,<3.0.0",
"sphinx_rtd_theme>=0.4.3,<1.0.0",
Bug#1079379: RM: python-amqplib -- ROM; dead upstream for 9 years, still depends on 2to3, drop-in alternative
Package: ftp.debian.org Severity: normal Tags: moreinfo X-Debbugs-Cc: python-amqp...@packages.debian.org, debian-python@lists.debian.org Control: affects -1 + src:python-amqplib User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Master, This old library has one rdep left: "graypy", which can (in theory) easily be patched to use python-amqp instead. https://github.com/barryp/py-amqplib Greetings
Python3.12 and a half
Hi, Would it be possible to remove 2to3 from Python3.12 without waiting for 3.13 ? I see in the meantime a new usage was brought back. I'll check if this "slimit" package can be easily switched to python3-fissix; which is a 2to3 fork that is already used to keep python3-nose artificially alive. Upstream doesn't have the nicest ward about this module; I guess nobody will miss it by now. https://bugs.python.org/issue40360 "Now we just have to remember to actually remove the damn thing in 3.13 😂" Greetings --- Date: Wed, 21 Aug 2024 15:12:40 -0300 Version: 0.8.1-7 Urgency: medium Maintainer: Debian Python Team Changed-By: Antonio Terceiro Changes: slimit (0.8.1-7) unstable; urgency=medium . * Team upload. * Add build dependency on python3-lib2to3 (Closes: #1076961)
Re: Python3.12 and a half
Thank you, less-is-more it seems. Le ven. 23 août 2024 à 12:27, Antonio Terceiro a écrit : > FWIW I tried just dropping the check for 2to3, and all the tests for slimit > itself passed. Rebuilding reverse build dependencies and autopkgtest for > reverse dependencies also worked. > > So I uploaded a new version with that change.
wrong autoremoval ? unittest2 -> funcsigs -> makefun -> yubikey
Hi, unittest2 & funcsigs need to go: these were independent modules that are now part of the standard library under different names. I don't know why "makefun" is marked for autoremoval, maybe the autoremoval script does not understand this dependency: "Depends: python3-funcsigs | python3-supported-min (>= 3.3)," Fixed python3-makefun should migrate before the deadline. Greetings Debian Authentication Maintainers yubikey-manager-qt: buggy deps unittest2, flagged for removal in 8.8 days yubikey-manager: buggy deps unittest2, flagged for removal in 8.8 days yubioath-desktop: buggy deps unittest2, flagged for removal in 8.8 days
Re: Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"
Hi, >From my personal experience, the most common cause of missing tests is because d/watch follow pypi where the tarball is incomplete and the typical fix is to switch to github tarball. Could this "1139 NO TESTS RAN" correlated with d/watch ? > - 25 use nose Even less as of today ;-) Greetings Le mar. 10 sept. 2024 à 17:06, Stefano Rivera a écrit : > > Hi Julian (2024.09.09_15:19:51_+) > > That seems a bit heavy to ask for. > > > > Is there any way of identifying those packages that do genuinely use > > unittest? > > From 6438 build logs: > - 651 don't call dh_auto_test > - 2180 do something custom > - 1989 use pytest > - 25 use nose > - 18 use nose2 > - 23 use tox > - 3 use stestr > - 1561 packages use pybuild's unittest runner > * 391 pass > * 1170 fail > + 1139 NO TESTS RAN > + 33 the test suite failed > > (numbers don't quite add up, because this was a lot of grep | wc -l)
Re: Bug#1078734: ITP: legacycrypt -- The legacycrypt module is a standalone version of https://docs.python.org/3/library/crypt.html (deprecated), to ease 3.13 transition.
Thank you for keeping an eye on this. There was an even more specific proposal of the Python Team to use the "python-zombie-*" namespace for all the modules removed by PEP594 and further future deprecation PEPs; this is based on the model of existing python-zombie-imp. https://peps.python.org/pep-0594/ I packaged python-zombie-telnetlib as a "native" package; it's a single file that will likely never change anymore. Someone could create a project on Pypi, maybe... we'll see. Here legacycrypt is an already established name, it can stay as python-legacycrypt. (?) Greetings Le ven. 18 oct. 2024 à 14:36, Guillem Jover a écrit : > > * URL : https://github.com/tiran/legacycrypt > > Description : The legacycrypt module is a standalone version of > > https://docs.python.org/3/library/crypt.html (crypt was removed in Python > > 3.13). > > This seems to be a python module only package, but its source package > name is not currently namespaced. Given that it has not yet passed NEW, > please namespace it with python- to avoid taking on the global namespace, > so that we do not "prevent" packaging something that for example installs > a command with the same name (or having to end up using a non-obvious one > for that, or requiring a future rename), so that it's easier to see what > it is about when doing archive-wide analysis from Sources, or dd-lists, > or even reading changelogs via stuff like apt-listchanges, like the rest > of the language specific teams are doing. :)
Re: RFS: dateparser
Done, thanks Le mar. 22 oct. 2024 à 00:36, Rebecca N. Palmer a écrit : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Please upload dateparser (Salsa HEAD = > commit e0f089a654e1ec1d576ed395695e6fb37d696b5e ). > See #1084190 for details.
Re: Merge Request for python-ciso8601
Uploaded. Thank you very much Le jeu. 3 oct. 2024 à 07:52, Antonio Valentino a écrit : > > Dear Malihe, dear all, > python-ciso8601 has an RC bug (#1080128) and it is marked for > autoremoval on the 30th of October. > > I have provided in salsa [1] a simple patch that should solve the issue. > I kindly ask to review/apply the patch and upload the new version. > > If you prefer I can prepare the package myself and update the git repo > directly, but I would need in any case a DD to sponsor the upload. > > > [1] > https://salsa.debian.org/python-team/packages/python-ciso8601/-/merge_requests/1 > > > kind regards > -- > Antonio Valentino >
Bug#1088143: RFP: rust-mitmproxy -- the Rust bits of mitmproxy
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: rust-mitmproxy Version : 0.10.7 Upstream Contact: 2022, Fabio Valentini and Maximilian Hils * URL : https://github.com/mitmproxy/mitmproxy_rs * License : MIT/X Programming Lang: Rust + Python Description : the Rust bits of mitmproxy For performance reason, it has become a common pattern to rewrite some performance intensive of Python application in Rust. . rust-mitmproxy is one such package . I'm filling this RFP to give this problem more visibility. . There's already #1031210 too. . Greetings
Re: Bug#1080921: rhythmbox: Missing Build-Depends on python3-setuptools
Le mar. 21 janv. 2025 à 12:11, Simon McVittie a écrit : > > Control: severity -1 important > Control: tags -1 + moreinfo unreproducible > > On Thu, 05 Sep 2024 at 16:58:05 +0200, stefa...@debian.org wrote: > > This package failed build from source when test-built against a version of > > dh-python without a python3-setuptools dependency. > > How can this be reproduced? Please could you share a concrete proposed > version of dh-python, or a patch or merge request with the proposed change, > or a failing build log? > > It would be helpful if changes like this, that are expected to cause some > build failures, went via a version of dh-python in experimental that > maintainers could easily test against. > > It would also be helpful for reports of build failures to be accompanied > by a (link to a) build log, so that if the maintainer cannot reproduce the > failure themselves, there is at least some information available. > > I tried building rhythmbox in a schroot against a locally-built version > of dh-python with the attached change (is this what you meant is going > to happen?) but it built successfully (for _amd64 + _all, separately, > in unstable). > > > Please add a Build-Depends on python3-setuptools to your package, or migrate > > the package's build system away from setuptools/distutils. > > I cannot find any references to setuptools or distutils in rhythmbox, > so I think there is nothing to be migrated, and I think it would be > wrong to add a Build-Depends on python3-setuptools. > > Are you sure that the build failure had anything to do with dh-python > dropping its dependency on python3-setuptools? rhythmbox build-depends on > libgirepository1.0-dev and meson, both of which pull in python3-setuptools > (and already did that at the time this bug was opened, as far as I can > see), so I don't see how dh-python dropping its equivalent dependency > would make any difference? > > Looking at recent reproducible-builds results, rhythmbox's upstream test > suite does not seem to be completely stable - is it possible that the > build just failed its tests by bad luck, for reasons that are orthogonal > to setuptools? A typical symptom seems to be that "test-rhythmdb" fails. > I've reported a separate bug for that. > > Thanks, > smcv
Re: URL mangling in https://pypi.debian.net/
Thank you very much for the explanation. It's a quite general problem, but not so important; and it only can be detected after upstream has made at least one release with the new naming convention. I'll see how to follow this in the long run. Greetings Le mer. 18 déc. 2024 à 10:19, Dmitry Shachnev a écrit : > Hi Alexandre! > > On Tue, Dec 17, 2024 at 11:57:18PM +0100, Alexandre Detiste wrote: > > I've noticed a recent pattern with archives published on PyPi : > > the "-" we expect in the regexp specified in d/watch is now an underscore. > > I think pypi.debian.net does not mangle the file names in any way, it just > takes them from upstream PyPI verbatim. Indeed > And the change from - to _ is caused by more build tools adopting this > specification [1], which says: > > [1]: > https://packaging.python.org/en/latest/specifications/binary-distribution-format/#escaping-and-unicode > [2]: > https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name
URL mangling in https://pypi.debian.net/
Hi, I've noticed a recent pattern with archives published on PyPi : the "-" we expect in the regexp specified in d/watch is now an underscore. So the tracker got the false information that everything is up-to-date With some horribly wretched code I can find some projects with updates pending. https://paste.debian.net/1340327/ One field got duplicated in the output but I'm not running the code again immediately because it can be considered abuse by who run pypi.debian.net. Ideas ? Greetings url , current version "up to date" in UDD , stem , (idem version), version upstream, upstream tarball https://pypi.debian.net/python-socketio 5.11.2-1 python-socketio 5.11.2-1 python_socketio-5.11.3.tar.gz https://pypi.debian.net/python-socketio 5.11.2-1 python-socketio 5.11.2-1 python_socketio-5.11.4.tar.gz https://pypi.debian.net/drf-haystack 1.8.13-1 drf-haystack 1.8.13-1 drf_haystack-1.9.tar.gz https://pypi.debian.net/drf-haystack 1.8.13-1 drf-haystack 1.8.13-1 drf_haystack-1.9.1.tar.gz https://pypi.debian.net/mpl-scatter-density 0.7-1 mpl-scatter-density 0.7-1 mpl_scatter_density-0.8.tar.gz https://pypi.debian.net/requests-futures 1.0.1-1 requests-futures 1.0.1-1 requests_futures-1.0.2.tar.gz https://pypi.debian.net/pytest-retry 1.6.2-2 pytest-retry 1.6.2-2 pytest_retry-1.6.3.tar.gz https://pypi.debian.net/time-machine 2.14.1-1 time-machine 2.14.1-1 time_machine-2.14.2.tar.gz https://pypi.debian.net/time-machine 2.14.1-1 time-machine 2.14.1-1 time_machine-2.15.0.tar.gz https://pypi.debian.net/time-machine 2.14.1-1 time-machine 2.14.1-1 time_machine-2.16.0.tar.gz https://pypi.debian.net/django-braces 1.15.0-4 django-braces 1.15.0-4 django_braces-1.16.0.tar.gz https://pypi.debian.net/tkinter-tooltip 3.0.0-3 tkinter-tooltip 3.0.0-3 tkinter_tooltip-3.1.0.tar.gz https://pypi.debian.net/tkinter-tooltip 3.0.0-3 tkinter-tooltip 3.0.0-3 tkinter_tooltip-3.1.1.tar.gz https://pypi.debian.net/tkinter-tooltip 3.0.0-3 tkinter-tooltip 3.0.0-3 tkinter_tooltip-3.1.2.tar.gz https://pypi.debian.net/django-downloadview 2.3.0-1 django-downloadview 2.3.0-1 django_downloadview-2.4.0.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.0.1.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.0.1rc1.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.1.0.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.1.1.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.2.0.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.3.0.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.3.1.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.4.0.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.4.1.tar.gz https://pypi.debian.net/msoffcrypto-tool 5.0.0-2 msoffcrypto-tool 5.0.0-2 msoffcrypto_tool-5.4.2.tar.gz https://pypi.debian.net/django-python3-ldap 0.15.6-1 django-python3-ldap 0.15.6-1 django_python3_ldap-0.15.7.tar.gz https://pypi.debian.net/django-python3-ldap 0.15.6-1 django-python3-ldap 0.15.6-1 django_python3_ldap-0.15.8.tar.gz https://pypi.debian.net/django-pipeline 3.0.0-2 django-pipeline 3.0.0-2 django_pipeline-3.1.0.tar.gz https://pypi.debian.net/django-pipeline 3.0.0-2 django-pipeline 3.0.0-2 django_pipeline-4.0.0.tar.gz https://pypi.debian.net/pytest-twisted 1.14.1-3 pytest-twisted 1.14.1-3 pytest_twisted-1.14.2.tar.gz https://pypi.debian.net/pytest-twisted 1.14.1-3 pytest-twisted 1.14.1-3 pytest_twisted-1.14.3.tar.gz https://pypi.debian.net/python-vlc 3.0.20123-1 python-vlc 3.0.20123-1 python_vlc-3.0.21201.tar.gz https://pypi.debian.net/python-vlc 3.0.20123-1 python-vlc 3.0.20123-1 python_vlc-3.0.21203.tar.gz https://pypi.debian.net/bids-validator 1.14.5-1 bids-validator 1.14.5-1 bids_validator-1.14.6.tar.gz https://pypi.debian.net/bids-validator 1.14.5-1 bids-validator 1.14.5-1 bids_validator-1.14.7.dev0.tar.gz https://pypi.debian.net/bids-validator 1.14.5-1 bids-validator 1.14.5-1 bids_validator-1.14.7.post0.tar.gz https://pypi.debian.net/djangorestframework-gis 1.0-3 djangorestframework-gis 1.0-3 djangorestframework_gis-1.1.tar.gz https://pypi.debian.net/pylint-plugin-utils 0.7-3 pylint-plugin-utils 0.7-3 pylint_plugin_utils-0.8.tar.gz https://pypi.debian.net/pylint-plugin-utils 0.7-3 pylint-plugin-utils 0.7-3 pylint_plugin_utils-0.8.1.tar.gz https://pypi.debian.net/pylint-plugin-utils 0.7-3 pylint-plugin-utils 0.7-3 pylint_plugin_utils-0.8.2.tar.gz https://pypi.debian.net/sphinxcontrib-svg2pdfconverter 1.2.2-1 sphinxcontrib-svg2pdfconverter 1.2.2-1 sphinxcontrib_svg2pdfconverter-1.2.3.tar.gz https://pypi.debian.net/orange-canvas-core 0.2.2-1 orange-canvas-core 0.2.2-1 orange_canvas_core-0.2.3.tar.gz https
Re: Bug#1087932: ITP: python-deadlib -- Python dead batteries
Hi, The package were I vendored "pipes" is pairtools. I reverted my change in pairtools and will prefer DeadLib from now. Most of the consumers of DeadLib seems to be in Multimedia Team, we should give them a head's up. Greetings Le mer. 20 nov. 2024 à 20:35, Andrey Rakhmatullin a écrit : > > On Wed, Nov 20, 2024 at 02:56:11PM +0100, Alexandre Detiste wrote: > > Maybe not other completely useless modules. (pipes ?) > > I think somebody (you?) recently want to vendor pipes to fix something, or > maybe it was fixed in a different way instead? > > -- > WBR, wRAR
Re: ipmctl: removal of Python standard libraries in Python 3.13
control: tag -1 +patch
Hi,
You now have two almost identical xdrlib revived packages to choose from...
* python3-mda-xdrlib
* python3-standard-xdrlib
I would suggest to use python3-mda-xdrlib because
it already has two others reverse-dependencies
so we don't need to keep around two copies of
the same thing forever.
Greetings
Emmanuel: no harm was made ;-);
it's easy to drop a binary from src:deadlib
---
https://packages.debian.org/sid/all/python3-standard-xdrlib/filelist
https://packages.debian.org/sid/all/python3-mda-xdrlib/filelist
tchet@quieter:~/pipes$ reverse-depends -b python3-mda-xdrlib
Reverse-Build-Depends
=
* mantis-xray
* mdanalysis
apt-cache search xdrlib
tchet@quieter:~/pipes$ apt show python3-standard-xdrlib
Package: python3-standard-xdrlib
Version: 3.13.0-3
Source: python-deadlib
Maintainer: Debian Python Team
Homepage: https://github.com/youknowone/python-deadlib
Description: xdrlib Standard Python Lib (Python 3)
xdrlib was part of the Standard Python Lib. Now it was removed from
Python. See PEP-594.
tchet@quieter:~/pipes$ apt show python3-mda-xdrlib
Package: python3-mda-xdrlib
Version: 0.2.0-3
Source: python-mda-xdrlib
Maintainer: Debian Python Team
Homepage: https://github.com/MDAnalysis/mda-xdrlib
Description: Stand-alone XDRLIB module (from cpython 3.10.8)
mda-xdrlib is a stand-alone XDRLIB module extracted from
cpython 3.10.8. The xdrlib package has historically been
a feature of the core Python library. However, as of
Python 3.11, the module was deemed to no longer be widely
used and has been deprecated, with a target removal version
of Python 3.13. Several of the MDAnalysis projects rely on
the xdrlib module for their functionality, specifically for
parsing GROMACS TPR and EDR files. To avoid a need to vendor
in the xdrlib functionality in multiple projects, the
approach of creating this stand-alone module which contains
the Python 3.10.8 xdrlib code and its relevant tests.
tchet@quieter:~/pipes$ diff -u
/usr/lib/python3/dist-packages/mda_xdrlib/xdrlib.py
/usr/lib/python3/dist-packages/xdrlib/__init__.py
--- /usr/lib/python3/dist-packages/mda_xdrlib/xdrlib.py 2024-09-06
05:56:14.0 +0200
+++ /usr/lib/python3/dist-packages/xdrlib/__init__.py 2024-12-21
02:18:52.0 +0100
@@ -7,6 +7,15 @@
import struct
from io import BytesIO
from functools import wraps
+import warnings
+
+# python-deadlib: Replace deprecation warning not to raise exception
+warnings.warn(
+f"{__name__} was removed in Python 3.13. "
+f"Please be aware that you are currently NOT using standard '{__name__}', "
+f"but instead a separately installed 'standard-{__name__}'.",
+DeprecationWarning, stacklevel=2
+)
__all__ = ["Error", "Packer", "Unpacker", "ConversionError"]
@@ -221,9 +230,7 @@
def unpack_list(self, unpack_item):
list = []
-while 1:
-x = self.unpack_uint()
-if x == 0: break
+while (x := self.unpack_uint()) != 0:
if x != 1:
raise ConversionError('0 or 1 expected, got %r' % (x,))
item = unpack_item()
missing pkg_resources dependencies
Hi,
I'm worried that a lot of undeclared dependencies on
python3-pkg-resources will creep up in Trixie
and none of us will notice because we all have python3-setuptools
installed somehow.
By scrapping UDD & ci.debian.net I can find a lot of failing CI jobs
that needs this one-line fix in d-control.
Of course it would be more effecient to zgrep ModuleNotFoundError
inside https://ci.debian.net,
like what was done for SyntaxWarning inside piuparts architecture.
Another orthogonal worry: the (over-)use of @builddeps@ in
d/test/control let packages
pass CI as Green while they will fail for end-users because of some
missing deps.
Greetings,
Alexandre
-
tchet@quieter:~/udd/ci$ ./ci.py
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz
100s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz
100s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz
100s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz
100s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz
100s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/bernhard/57413994/log.gz
26s ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/biomaj3/57408831/log.gz
57s ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/biomaj3-core/57401997/log.gz
35s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz
66s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz
106s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz
106s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz
106s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz
106s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz
106s E ModuleNotFoundError: No module named 'pkg_resources'
https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/git-review/57422016/log.gz
42s ModuleNotFoundError: No module named 'pkg_resources'
--
#!/usr/bin/python3
# https://udd.debian.org/schema/udd.html
#
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-debian/57324755/log.gz
import time
import requests
import psycopg2
conn =
psycopg2.connect("postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd")
cursor = conn.cursor()
# maybe it's Python, maybe it's Maybelline
SQL = """
select source, arch, run_id
from ci
where suite='unstable'
and status='fail'
and date > TIMESTAMP '%TS% 00:01:01'
and not source like 'cl-%'
and not source like 'golang-%'
and not source like 'haskell-%'
and not source like 'lib%perl'
and not source like 'lua-%'
and not source like 'node-%'
and not source like 'openjdk-%'
and not source like 'php%'
and not source like 'postgresql-%'
and not source like 'ruby-%'
and not source like 'rust-%'
and not source like 'r-bioc-%'
and not source like 'r-cran-%'
order by sour
Re: missing pkg_resources dependencies
And the now obligatory dd-list. python-bioframe was fixed today, pairtools was likely only caused by python-bioframe --- grep pkg_res dump.log | cut -d/ -f9 | sort -u | dd-list -i --nou Debian Astro Team astroquery Debian Astronomy Maintainers mpl-scatter-density Debian Astronomy Team specreduce-data Debian Med Packaging Team biomaj3 biomaj3-core circlator kleborate mirtop pairtools pyensembl python-bioframe Debian OpenStack git-review Debian Python Team afew bernhard geoalchemy2 Jelmer Vernooij lintian-brush Le dim. 16 févr. 2025 à 01:29, Alexandre Detiste a écrit : > > Hi, > > I'm worried that a lot of undeclared dependencies on > python3-pkg-resources will creep up in Trixie > and none of us will notice because we all have python3-setuptools > installed somehow. > > By scrapping UDD & ci.debian.net I can find a lot of failing CI jobs > that needs this one-line fix in d-control. > > Of course it would be more effecient to zgrep ModuleNotFoundError > inside https://ci.debian.net, > like what was done for SyntaxWarning inside piuparts architecture. > > Another orthogonal worry: the (over-)use of @builddeps@ in > d/test/control let packages > pass CI as Green while they will fail for end-users because of some > missing deps. > > Greetings, > > Alexandre > - > > tchet@quieter:~/udd/ci$ ./ci.py > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/afew/57418208/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz > 100s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz > 100s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz > 100s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz > 100s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/a/astroquery/57415625/log.gz > 100s E ModuleNotFoundError: No module named 'pkg_resources' > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/bernhard/57413994/log.gz > 26s ModuleNotFoundError: No module named 'pkg_resources' > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/biomaj3/57408831/log.gz > 57s ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/b/biomaj3-core/57401997/log.gz > 35s E ModuleNotFoundError: No module named 'pkg_resources' > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/c/circlator/57409170/log.gz > 66s E ModuleNotFoundError: No module named 'pkg_resources' > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz > 106s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz > 106s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz > 106s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/g/geoalchemy2/57402616/log.gz > 106s E ModuleNotFoundError: No module named 'pkg_resources' > https://ci.debian.net/data/au
Re: Wiki: Remove "Python/Dead Batteries"?
Yes please keep this page ... the work is not even done. It could be edited better and be included in Trixie Release Notes. Greetings Le lun. 24 mars 2025 à 16:50, Emmanuel Arias a écrit : > > Why remove it? > > IMO is useful. And a good historic page for future :-) > > At least if wiki has some memory problems I guess we can leave it.
Re: Matplotlib 3.10.0 for trixie?
Hey, It uses Wayland now ! (or I mean automagically) I reinstalled the version from testing & checked with xeyes. New version in experimental feels smoother; it also open a nice KDE dialog bog here, not something that looks like tkinter. That's something to fight for. I'll check the CI results too. The list is already much smaller than for the previous version bump. Thank you Le dim. 16 mars 2025 à 15:52, Nilesh Patra a écrit : > Quick update: Uploaded matplotlib 3.10.1 with Jay's patch and a fix > to not set backend to Tkagg system-wide (in /etc/matplotlibrc). > > I will check the pseudo-excuses on britney in around week. Hopefully, this > upload should solve majority of issues. > > Thanks, > Nilesh >
Re: Matplotlib 3.10.0 for trixie?
Le lun. 17 mars 2025 à 03:56, Nilesh Patra a écrit : > I will check the pseudo-excuses on britney in around week. Hopefully, this > upload should solve majority of issues. Only five autopkgtest failing and already two packages fixed ! Can we ask $someone to rebuild everything from unstable that depends on matplotlib against this new version ? (to see what fails) I might remember there was a free-service instance available somewhere but wouldn't mind some hand-holding. Greetings Alexandre
Re: Package review python-ecs-logging
Hi, You meant "wrap-and-sort -abst" ? The default settings are plain bad; but cannot changed ... :-( Greetings Le mer. 5 mars 2025 à 20:49, Emmanuel Arias a écrit : > > Hello! > > Thank you for your work! I took a look to your package. I leave you some > comments > > - d/control: wrap-and-sort can be excecuted.
Re: Matplotlib 3.10.0 for trixie?
Thank you ! Le dim. 30 mars 2025 à 13:32, Nilesh Patra a écrit : > > python-maggma_0.70.0-3_unstable.log > > Failure due to missing dependencies > (pyproject_hooks._impl.BackendUnavailable: Cannot import > 'setuptools.build_meta') + python3-setuptools easy to fix, only wondering why it didn't FTBFS sooner, but this one has a huge maze of build-deps. > > sphinx-copybutton_0.5.2-2_unstable.log > > Dependency issue [Extension error (pydata_sphinx_theme)] This annoying bug is fixed in Experimental only. I think it fell of the radar and it's the right time to push to unstable. https://tracker.debian.org/pkg/sphinx-book-theme tchet@quieter:~/setuptools$ reverse-depends -b python3-sphinx-book-theme Reverse-Build-Depends = * md-toc * pytango * python-xarray * sphinx-copybutton <- * sphinx-design * sphinx-remove-toctrees
Re: Matplotlib 3.10.0 for trixie?
In a later step we could discard unmodified config files based on a list of md5sum of what shipped in stable release. So only users of default settings would get the new default settings. I ve started updating debian/README.Debian Greetings Le sam. 12 avr. 2025, 14:48, James Addison a écrit : > Hi Nilesh, Alex, > > Responding to the first point only, at the moment: > > On Sat, 12 Apr 2025 at 07:39, Nilesh Patra wrote: > > [ ... snip ... ] > > 1. matplotlib has historically shipped /etc/matploblibrc to force tkagg > and patched the code > > to use this if there are no user defined rc files see [1]. However, this > was not > > handled properly via maintscripts so that'd mean over-writing > user-modified /etc/matplotlibrc. > > Ah; what is the problem related to the maintscripts? > > The /etc/matplotlibrc file is considered a config file by apt/dpkg (it > is not removed unless a purge is requested), so I was hoping that > shipping a default/unmodified matplotlibrc in an updated 3.10 upload > (as Alex suggests in his thread) would provide a useful additional > conflict-resolution step for anyone who has modified theirs. >
