Bug#1082739: Spin is compiled without -DNXT
Package: spin
Version: 6.5.2+dfsg-1
Severity: normal
Dear Maintainer,
When I compile Spin manually, without changing anything to its
makefile, it supports the "X" (next) operator. For instance:
% ./spin -V
Spin Version 6.5.2 -- 6 December 2019
% ./spin -f 'X a'
never {/* X a */
accept_init:
T0_init:
do
:: (1) -> goto accept_S0
od;
accept_S0:
T0_S0:
do
:: atomic { ((a)) -> assert(!((a))) }
od;
accept_all:
skip
}
However the version shipped with Debian does not:
% spin -V
Spin Version 6.5.2 -- 6 December 2019
% spin -f 'X a'
tl_spin: expected predicate, saw 'X'
tl_spin: X a
--^
My understanding is that this is because Src/makefile has
CFLAGS?=-O2 -DNXT -Wall -pedantic
but debhelper very likely defines its own CFLAGS, so this line
get ignored, and -DNXT (needed for "next" support) is lost.
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.10.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages spin depends on:
ii libc6 2.40-2
spin recommends no packages.
spin suggests no packages.
-- no debconf information
Bug#1082658: libgdk-pixbuf-2.0-0: gnome-shell panel icons showing wheel icon, games cannot load svg
Hi,
> This may be related https://bugs.debian.org/669562
Please read #625203 (https://bugs.debian.org/625203) instead
('/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory)
Thanks,
Alex
Bug#1082658: libgdk-pixbuf-2.0-0: gnome-shell panel icons showing wheel icon, games cannot load svg
Package: libgdk-pixbuf-2.0-0 Version: 2.42.12+dfsg-1 Severity: normal Dear Maintainer, On a laptop that's used by someone who may have not ensured proper shutdown possibly during upgrades, I encountered the following situation. Please note that dpkg states were all clean and the machine was stuck in the described situation. Also, debsums was all ok. gnome-shell icons were showing the gear wheel in the launcher, and in notifications and in many other places. gnome-games were crashing after displaying many GTK warnings such as: Couldn't recognize the image file format for file '/foo/bar.svg' I fixed the problem on this particular machine with the following command: $ sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \ --update-cache and close/open user session. I suspect ignoring error in the cache update script may have something to do with this problem, and I would expect a failed trigger/postinst flashes to the system administrator, probably prompting for a "apt --fix-broken install". debian/libgdk-pixbuf-2.0-0.postinst.in: /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \ $(find $LOADERS_DIR $LOADERS_DIR_OLD -name *.so 2> /dev/null | LC_ALL=C sort) \ > /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/2.10.0/loaders.cache || true ^^^ This may be related https://bugs.debian.org/669562 Thanks, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgdk-pixbuf-2.0-0 depends on: ii libc62.40-2 ii libgdk-pixbuf2.0-common 2.42.12+dfsg-1 ii libglib2.0-0t64 2.82.1-1 ii libjpeg62-turbo 1:2.1.5-3 ii libpng16-16t64 1.6.44-1 ii libtiff6 4.5.1+git230720-5 ii shared-mime-info 2.4-5 Versions of packages libgdk-pixbuf-2.0-0 recommends: ii libgdk-pixbuf2.0-bin 2.42.12+dfsg-1 libgdk-pixbuf-2.0-0 suggests no packages. -- no debconf information
Bug#1082002: openjdk-21-jre-headless: please provide shlibs info for libjvm.so
Package: openjdk-21-jre-headless Version: 21.0.5~6ea-1 Severity: normal Dear Maintainer, I'm building a plugin[1] for src:uwsgi that needs to link against libjvm.so . Currently dpkg-shlibdeps does not generate to correct dependecy to openjdk-21-jre-headless (which contains libjvm.so my plugin links against) and I need to hardcode the binary package dependency. I would guess this would all be done automatically and maybe provide appropriate debian/*shlibs or debian/*symbols files. Thanks, Alex [1] https://salsa.debian.org/uwsgi-team/uwsgi-plugin-java -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-21-jre-headless depends on: ii ca-certificates-java 20240118 ii java-common 0.76 ii libc6 2.40-2 ii libgcc-s1 14.2.0-5 ii libjpeg62-turbo 1:2.1.5-3 ii liblcms2-22.14-2+b1 ii libnss3 2:3.103-1 ii libpcsclite1 2.3.0-1 ii libstdc++614.2.0-5 ii util-linux2.40.2-8 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages openjdk-21-jre-headless recommends: ii libasound2t64 1.2.12-1 ii libcups2t64 2.4.10-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype62.13.3+dfsg-1 ii libharfbuzz0b 9.0.0-1 Versions of packages openjdk-21-jre-headless suggests: ii fonts-dejavu-extra 2.37-8 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei | fonts-wqy-zenhei ii libnss-mdns0.15.1-4 -- no debconf information
Bug#1081966: ITP: uwsgi-plugin-lua -- Lua WSAPI plugin for uWSGI (Lua 5.1)
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-lua Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Lua WSAPI plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Lua plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-lua Alex
Bug#1056206: graphite-web: saving graphs in dashboard is broken (only in stable version 1.1.8-2)
Hi, > graphite-web in bookworm (1.1.8-2) does not allow saving dashboards due to > missing function > htmlEncode from dashboard.js. Workaround is to install 1.1.10-1 from testing, > where > dashboard.js contains the definition of htmlEncode. > > As a note to others: js is cached in the browser for quite some time, so the > showing up of the bug was delayed > > Please consider the applied patch for bookwoorm which simply adds the missing > function. I would but uploads to stable need a bug with severity important (per policy § 5.5.1 [1]) or in a special cas (per policy § 5.5.2 [1]) which does not seem the case here. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#picking-a-distribution The simpler solution would be to use a backport. I use such backport, see http://deb.zincube.net/pool/main/g/graphite-web/graphite-web_1.1.10-8~bpo12+1_all.deb I would prepare an upload if a DD steps in and says that upload would be sponsored. Same for a backport. Otherwise, this can simply be closed. Thanks, Alex
Bug#1081427: tomopy: build-depends on python3-nose or uses it for autopkgtest
Source: tomopy Version: 1.14.1+ds1-1 Severity: important X-Debbugs-Cc: Roland Mas , Dmitry Shachnev User: python-modules-t...@lists.alioth.debian.org Usertags: nose-rm Dear Maintainer, For some reason tomopy was not included it this previous MBF. I do it now. python3-nose is as of today RC-buggy. Greetings, --- Dear Maintainer, Your package still uses nose [1], which is an obsolete testing framework for Python, dead and unmaintained since 2015 [2][3]. If you received this bug report, it means that your package either has a build-dependency on python3-nose or uses that package in debian/tests/control. If that is not the case, please reply and CC me explicitly. Please port your package to one of the alternatives: nose2 [4], pytest [5] or unittest from Python standard library [6]. There is a script called nose2pytest [7] which can assist with migrating from nose to pytest. This mass bug filing was discussed on debian-devel in [8]. [1]: https://tracker.debian.org/pkg/nose [2]: https://github.com/nose-devs/nose/commit/0f40fa995384afad [3]: https://pypi.org/project/nose/#history [4]: https://docs.nose2.io/en/latest/ [5]: https://docs.pytest.org/en/latest/ [6]: https://docs.python.org/3/library/unittest.html [7]: https://github.com/pytest-dev/nose2pytest [8]: https://lists.debian.org/debian-devel/2022/08/msg00184.html -- Dmitry Shachnev
Bug#1018509: python-hkdf: build-depends on python3-nose or uses it for autopkgtest
control: tag -1 +wontfix This old & dead upstream package should be retired and it's usage replaced by "doubleratchet" or "cryptography".
Bug#1081382: python-oldmemo: please remove stale dependency on python3-hkdf
Source: python-oldmemo Version: 1.0.3-2 Severity: normal Dear Maintainer, The old testing system python3-nose is RC buggy and being retired from Debian. python3-hkdf still declares a dependency on this test framework. python-oldmemo also declares a dependency on python3-hkdf. Luckily, python-oldmemo does not seems to use hkdf at all anymore, so please remove the stale extraneous line from d/control to help untie this old dependencies network. Greetings, Alexandre
Bug#1081381: python-omemo: please remove stale dependency on python3-hkdf
Source: python-omemo Version: 1.0.4-1 Severity: normal Dear Maintainer, The old testing system python3-nose is RC buggy and being retired from Debian. python3-hkdf still declares a dependency on this test framework. python-omemo also declares a dependency on python3-hkdf. Luckily, python-omemo does not seems to use hkdf at all anymore, so please remove the stale extraneous line from d/control to help untie this old dependencies network. Greetings, Alexandre ~/deb/python-omemo$ grep hkdf -r debian/control: python3-hkdf, ~/deb/python-omemo$
Bug#1076420: Processed: ITPs block move away from cdbs
Hi, > > Bug #1076420 [src:uwsgi] uwsgi: move away from cdbs > > […] > > Added blocking bug(s) of 1076420: 1078557 > > Wrong bug number? #1078557 is for a leaf package and has nothing to do > with uwsgi or CDBS. Sorry for that, fixing my mess. Alex
Bug#1081281: ITP: uwsgi-plugin-psgi -- Perl PSGI and Coro::AnyEvent plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-psgi Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Perl PSGI and Coro::AnyEvent plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the psgi plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-psgi Alex
Bug#1081280: ITP: uwsgi-plugin-rados -- Ceph/RADOS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-rados Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Ceph/RADOS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the rados plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-rados Alex
Bug#1081279: ITP: uwsgi-plugin-glusterfs -- GlusterFS storage plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-glusterfs Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : GlusterFS storage plugin for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the glusterfsplugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-glusterfs Alex
Bug#1081278: ITP: uwsgi-plugin-gccgo -- Go plugin for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-gccgo Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : Go plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the Go plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-gccgo Alex
Bug#1077434: unittest2: FTBFS: TypeError: expected string or bytes-like object, got 'late_version'
python-oauth2client is also itself deprecated. https://bugs.launchpad.net/ubuntu/+source/python-oauth2client/+bug/2074069 removal of unittest2 already led to 3 other removals so far and that would be a 4th one. Greetings Le dim. 8 sept. 2024 à 18:45, Colin Watson a écrit : > There are a few more than that: > > $ reverse-depends -b src:unittest2 > Reverse-Testsuite-Triggers > == > * python-oauth2client (for python3-unittest2) > > Reverse-Build-Depends-Indep > === > * python-oauth2client (for python3-unittest2)
Bug#1080606: Missing Build-Depends on python3-setuptools
Hi, > This package failed build from source when test-built against a version of > dh-python without a python3-setuptools dependency. > > distutils is no longer part of the Python standard library, since 3.12. But a > minimal version of it becomes available when the python3-setuptools package is > installed. > > Please add a Build-Depends on python3-setuptools to your package, or migrate > the package's build system away from setuptools/distutils. A fixed package is awaiting sponsorship at: https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-2.dsc Thanks, Alex
Bug#1081232: pyroon: please remove extreneaous dependency on python3-six
Source: pyroon Version: 0.1.6-2 Severity: minor Dear Maintainer, After a fast grep through this project, I do not see any remaining usage of six. I already send a PR upstream to clean the very last reference to it: https://github.com/pavoni/pyroon/pull/81 Alternatively you can decide to include this one line change as a patch for Debian using this url: https://github.com/pavoni/pyroon/pull/81.patch Greetings Alexandre
Bug#1077434: unittest2: FTBFS: TypeError: expected string or bytes-like object, got 'late_version'
I will take care of esda. Le dim. 8 sept. 2024, 19:17, Alexandre Detiste a écrit : > Hi, > > I didn't knew about "reverse-depends", nice. > > The 3 Reverse-Build-Depends-Indep only need one line removed from > d/control, > and I blindly guess it's the same but about d/test/control for the 4 first > ones. > > Funcsigs has already been removed. > > Greetings > > Le dim. 8 sept. 2024, 18:45, Colin Watson a écrit : > >> $ reverse-depends -b src:unittest2 >> Reverse-Testsuite-Triggers >> == >> * esda (for python3-unittest2) >> * python-django-netfields (for python3-unittest2) >> * python-oauth2client (for python3-unittest2) >> * yarsync (for python3-unittest2) >> >> Reverse-Build-Depends-Indep >> === >> * designate-dashboard (for python3-unittest2) >> * python-jenkins(for python3-unittest2) >> * python-oauth2client (for python3-unittest2) >> >> -- >> Colin Watson (he/him) [cjwat...@debian.org] >> >
Bug#1077434: unittest2: FTBFS: TypeError: expected string or bytes-like object, got 'late_version'
Hi, I didn't knew about "reverse-depends", nice. The 3 Reverse-Build-Depends-Indep only need one line removed from d/control, and I blindly guess it's the same but about d/test/control for the 4 first ones. Funcsigs has already been removed. Greetings Le dim. 8 sept. 2024, 18:45, Colin Watson a écrit : > $ reverse-depends -b src:unittest2 > Reverse-Testsuite-Triggers > == > * esda (for python3-unittest2) > * python-django-netfields (for python3-unittest2) > * python-oauth2client (for python3-unittest2) > * yarsync (for python3-unittest2) > > Reverse-Build-Depends-Indep > === > * designate-dashboard (for python3-unittest2) > * python-jenkins(for python3-unittest2) > * python-oauth2client (for python3-unittest2) > > -- > Colin Watson (he/him) [cjwat...@debian.org] >
Bug#1073001: fixed upstream
Le lun. 2 sept. 2024 à 18:56, Colin Watson a écrit : > On Thu, Jul 18, 2024 at 02:08:32PM +0200, Hans-Christoph Steiner wrote: > > It is fixed upstream: > > https://github.com/buildbot/buildbot/commit/291df50dc3f27adb47a001fc154cf4c55490687e > > Thanks. > And then I noticed that Alexandre committed a new upstream release to > the repository two months ago, but didn't upload it, and it's in this > broken state so I don't know what to do with it. Alexandre, can you > comment, and ideally fix it up? I was stuck really hard trying to make it work with SQLAlchemy 2.x and dropped the ball. I refreshed the patches. I now guess you may want to remove debian/patches/sqlalchemy2.0 really soon. The package is yours. > (I try to avoid leaving unreleased new-upstream-version commits in > debian/master branches for so long. It makes it quite unclear for other > developers what state things are in and what they can do - or at least > it does for me.) I try too, I failed. Greetings
Bug#1079842: Should debbugs be removed from unstable
Hi, I thing that when someone tries to "sell" it's product it should at least eat it's own dog food. On a more practical note, this is a native package. The bugs belong here, if package is RM'ed all theses bugs will be automatically closed. Where should else they go ? They could be reassign beforehand to a virtual package, but that looks like a lot of triage work to identify if a bug belongs only to the generic Debbugs or only Debian's instance. Greetings
Bug#1078184: python-funcsigs: please remove python3-unittest2 dependency by using provided patch
Actually this other old backport should be removed for the distribution too, please forget my patch. Greetings
Bug#1077619: graphite-carbon 1.1.10-2 sponsorship request
Hi, I think src:graphite-carbon users would benefit having this new release in Debian: it includes an autopkgtest which can help alert if broken in unstable. https://mentors.debian.net/debian/pool/main/g/graphite-carbon/graphite-carbon_1.1.10-2.dsc Thanks, Alex
Bug#1079881: Fix committed
Hi, A fix is awaiting review and sponsorship: https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/c3259147da042a0cde0428d6a3a45b8e99b874dc Thanks, Alex
Bug#1080170: loggerhead: please drop leftover dependency on python3-simplejson
Hi Jelmer, I don't want to be annoying with this one, but there's still a runtime dependency overide on python3-simplejson (and a lot of Python2->3 scar tissue everywhere in the distribution) have a nice weekend
Bug#1080186: hiera-py: please patch-out the generation of the useless python3-simplejson dependency
Hi, This is an eye opener for me. I don't do blind MBF with carefully crafted header letter and some false positives, I instead go the extra mile of checking every single package ang showing the steps that lead to this conclusion. I will now take in consideration your suggestion in the future; I ve the same kind of problems at the job where nobody ever tell you what to do to improve yourself. Greetings Have a nice weekend 1079842 is on my todo list... It is a carefully crafted MBF bug which can be harmful. later. Or raise your voice if you see too the big problem with this one. Le dim. 1 sept. 2024, 08:53, Carsten Schoenert a écrit : > Hello Alexandre, > > Am 31.08.24 um 11:38 schrieb Alexandre Detiste: > could you be please a bit elaborate in the future? > > What about using a classical starting for such bug report? > > "You package is using simplejson as a binary depending package, but this > module isn't any there used later in hiery-py. It's obviously not needed > as an dependency. > > Could you please remove this unneeded dependency because of ..." > > Your bug report comes due its shortness and without any kindness a bit > rude. > That's not the art and style I did experience in the past decade while > working in Debian. Unfortunately I did see this kind of communication > from you in various places! :-( > > -- > Regards > Carsten >
Bug#1080193: graphite-web: please drop the stale dependency on python3-simplejson
Source: graphite-web Version: 1.1.10-6 Severity: normal Dear Maintainers, graphite-web now uses the "json" module from the standard library. /tmp/graphite-web-1.1.10$ grep simplejson -r debian/control: python3-simplejson, debian/control: python3-simplejson, /tmp/graphite-web-1.1.10$
Bug#1080186: hiera-py: please patch-out the generation of the useless python3-simplejson dependency
Source: hiera-py Version: 0.0.1+20190629-2 Severity: normal Hi, I think all it takes is removing this one line. Greetings tchet@quieter:/tmp/hiera-py$ grep simplejson -r setup.py:install_requires = ['simplejson'], tchet@quieter:/tmp/hiera-py$
Bug#1080185: libervia-pubsub: please drop the old dependency on python3-simplejson
Source: libervia-pubsub Version: 0.5.0~hg489-1 Severity: normal python3-simplejson was a backport of Python3 "json" module to Python2. It is now being removed from Debian. Please remove the stale ref. in d/control. Thanks
Bug#1080171: translate-toolkit: please drop the dependencies on ancient python3-simplejson
Source: translate-toolkit Version: 3.13.2-2 Severity: normal "simplejson" was a backport of Python3' "json" module for Python2. It is now being slowly removed from Debian. Greetings tchet@quieter:/tmp/translate-toolkit$ grep simplejson -r debian/changelog: * debian/control: Added a Build-Depends-Indep on python-simplejson. debian/changelog: * debian/control: Added a Recommends on python-simplejson (used by debian/control: python3-simplejson, debian/control: python3-simplejson, debian/tests/control: python3-simplejson, debian/tests/control: python3-simplejson, debian/tests/control: python3-simplejson, tchet@quieter:/tmp/translate-toolkit$
Bug#1080170: loggerhead: please drop leftover dependency on python3-simplejson
Source: loggerhead Version: 2.0.1+bzr541+ds-2 Severity: normal Most of the work was already done upstream. Greetings tchet@quieter:/tmp/loggerhead-2.0.1+bzr541+ds$ grep simplejson -r NEWS:- Drop dependency on simplejson in favour of the standard library's json NEWS: simplejson. (Jelmer Vernooij, #586611) NEWS: to improve performance. This adds a dependency on simplejson or debian/control: python3-simplejson, debian/control:Depends: <...>, python3-simplejson, <...> tchet@quieter:/tmp/loggerhead-2.0.1+bzr541+ds$
Bug#1080169: python3-x2go: please drop the dependency on python3-simplejson
Package: python3-x2go Version: 0.6.1.4-1 Severity: normal Dear Maintainers, "simplejson" was a backport of the "json" from Python3.x standard library to Python 2. It is now obsolete and slowly being removed from Debian. Greetings
Bug#1080166: pgxnclient: please remove externeous dependency on python3-simplejson
Source: pgxnclient Version: 1.3.2-3 Severity: normal Dear Maintainers, "simplejson" was a backport of Python3.x "json" module for Python2. pgxnclient does not use it anymore Greetings
Bug#1080156: RM: python-funcsigs -- RoQA; obsole backport of Python3.2 module to 2.6
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-funcs...@packages.debian.org Control: affects -1 + src:python-funcsigs User: ftp.debian@packages.debian.org Usertags: remove The last remaining rdep is nipype. nipype broke hard with _my_ upload of python3-traits and is not going to be fixed anytime soon. https://github.com/nipy/nipype/issues/3661
Bug#1080028: antlr: please update python3-compat.patch to allow python3-six removal
Package: antlr
Version: 2.7.7+dfsg-13
Severity: normal
Hi,
Here's an updated file to replace the old one.
Only 3 lines were changed to keep delta as low as possible.
Then python3-six can be removed from debian/control.
Greetings
Description: Python3 compat
Author: Thomas Goirand
Bug-Debian: https://bugs.debian.org/614505
Forwarded: no
Last-Update: 2017-10-24
--- antlr-2.7.7+dfsg.orig/lib/python/antlr/antlr.py
+++ antlr-2.7.7+dfsg/lib/python/antlr/antlr.py
@@ -2,13 +2,11 @@
## details..Copyright (C) Wolfgang Haefelinger, 2004.
## get sys module
+from __future__ import print_function
import sys
-version = sys.version.split()[0]
-if version < '2.2.1':
-False = 0
-if version < '2.3':
-True = not False
+
+
######
### global symbols ###
@@ -45,7 +43,7 @@ def version():
def error(fmt,*args):
if fmt:
-print "error: ", fmt % tuple(args)
+print("error: ", fmt % tuple(args))
def ifelse(cond,_then,_else):
if cond :
@@ -55,7 +53,7 @@ def ifelse(cond,_then,_else):
return r
def is_string_type(x):
-return (isinstance(x,str) or isinstance(x,unicode))
+return (isinstance(x,str) or isinstance(x,str))
def assert_string_type(x):
assert is_string_type(x)
@@ -549,9 +547,9 @@ class Token(object):
Token.badToken = Token( type=INVALID_TYPE, text="")
if __name__ == "__main__":
-print "testing .."
+print("testing ..")
T = Token.badToken
-print T
+print(T)
######
### CommonToken ###
@@ -622,16 +620,16 @@ class CommonToken(Token):
if __name__ == '__main__' :
T = CommonToken()
-print T
+print(T)
T = CommonToken(col=15,line=1,text="some text", type=5)
-print T
+print(T)
T = CommonToken()
T.setLine(1).setColumn(15).setText("some text").setType(5)
-print T
-print T.getLine()
-print T.getColumn()
-print T.getText()
-print T.getType()
+print(T)
+print(T.getLine())
+print(T.getColumn())
+print(T.getText())
+print(T.getType())
######
###CommonHiddenStreamToken ###
@@ -811,7 +809,7 @@ class CharBuffer(InputBuffer):
### use unicode chars instead of ASCII ..
self.queue.append(c)
-except Exception,e:
+except Exception as e:
raise CharStreamIOException(e)
##except: # (mk) Cannot happen ...
##error ("unexpected exception caught ..")
@@ -901,7 +899,7 @@ class TokenStreamSelector(TokenStream):
while 1:
try:
return self._input.nextToken()
-except TokenStreamRetryException,r:
+except TokenStreamRetryException as r:
### just retry "forever"
pass
@@ -1342,23 +1340,23 @@ class CharScanner(TokenStream):
self.setColumn(nc)
def panic(self,s='') :
-print "CharScanner: panic: " + s
+print("CharScanner: panic: " + s)
sys.exit(1)
def reportError(self,ex) :
-print ex
+print(ex)
def reportError(self,s) :
if not self.getFilename():
-print "error: " + str(s)
+print("error: " + str(s))
else:
-print self.getFilename() + ": error: " + str(s)
+print(self.getFilename() + ": error: " + str(s))
def reportWarning(self,s) :
if not self.getFilename():
-print "warning: " + str(s)
+print("warning: " + str(s))
else:
-print self.getFilename() + ": warning: " + str(s)
+print(self.getFilename() + ": warning: " + str(s))
def resetText(self) :
self.text.setLength(0)
@@ -1418,16 +1416,16 @@ class CharScanner(TokenStream):
return c.__class__.lower()
def traceIndent(self):
-print ' ' * self.traceDepth
+print(' ' * self.traceDepth)
def traceIn(self,rname):
self.traceDepth += 1
self.traceIndent()
-print "> lexer %s c== %s" % (rname,self.LA(1))
+print("> lexer %s c== %s" % (rname,self.LA(1)))
def traceOut(self,rname):
self.traceIndent()
-print "< lexer %s c== %s" % (rname,self.LA(1))
+print("< lexer %s c== %s" % (rname,self.LA(1)))
self.traceDepth -= 1
def uponEOF(self):
@@ -1492,7 +1490,7 @@ class CharScanner(TokenStream):
func=args[0]
args=args[1:]
apply(func,args)
-except RecognitionException, e:
+except RecognitionException as e:
## catastrophic failure
self.reportError(e);
self.consume();
@@ -1548,7 +1546,7 @@ clas
Bug#1079915: lasso: please trim or remove usage of python3-six
Merci
Bug#732019: [pkg-uWSGI-devel] Bug#732019: PyPy plugin support for uWSGI
Hi, > Quoting Alexandre Rossi (2024-08-28 11:38:22) > > Is there still interest in this? > > I think it quite unteresting to offer support for PyPy3: That allows > experimenting with running Python-based services more lightweight. I managed to find patches to make it work. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-pypy Alex
Bug#1079842: Should debbugs be removed from unstable
Hi, This mostly automated email made me smile, knowing that debbugs is the thing running https://bugs.debian.org/ and processing this very email. I know of one single other instance at https://debbugs.gnu.org/ Greetings
Bug#1079973: python-jsonschema: please drop the extraneous python3-six build dependency
Source: python-jsonschema Version: 4.19.2-3 Severity: normal Dear Maintainer, Usage of six is gone. Greetings /tmp/python-jsonschema$ grep six -r debian/changelog:- python3-six debian/control: python3-six, json/tests/draft3/optional/format/color.json:"description": "a valid six-digit CSS color code", /tmp/python-jsonschema$
Bug#1079907: otf2: please phase-out python3-six usage
Le mer. 28 août 2024 à 22:30, Samuel Thibault a écrit : > 300 is a lot, that's why I'm wondering why targeting six? because it's a big target and .. it's _fun_ I can play around with UDD, interrogate the BTS with it's soap API; I need to contact many teams; send upstream patches in so many different ways. Some other package like python3-nose might break at any moment and be a big problem for the packages still depending on it. There is so sense of urgency, not for "six". Still, there's some economy of scale at looking for all these "Dead Batteries" at once. https://wiki.debian.org/Python/Dead%20Batteries#preview > I doubt otf2 would be in a problematic dependency chain. Agreed > Not all free software is developed in the open. They probably use git > internally, but don't expose it, that's their choice. Ok, I'll use git interally too and provide a patch > > > https://www.vi-hps.org/projects/score-p > > This one does not contains otf2 > It does. Sorry, meant https://gitlab.com/score-p/scorep
Bug#1079907: otf2: please phase-out python3-six usage
Le mer. 28 août 2024 à 21:02, Samuel Thibault a écrit : > What problem does it actually pose? :) I think this one package is at minimal threat, but at the distro-level; depending on old libraries (some unmaintained) is a risk, there are stil 300 packages needing six. Some things could break in half expected ways ... again. We had this dependency chain before: pytest -> requests -> urllib3(v1) -> six. So any package with a build-depends on pytest would get six for free in it's build chroot. After the Urllib3 upgrade to v2 the FTBFS bugs came in waves; some were solved only lately. The whole same thing might happen when the python3-dateutil is upgraded. I think it's better to be proactive than react during the freeze. > > that could be easily patched out. When I first find a git repo ... I can provide a patch on basis of last tarball but that feels 1999 > As debian/control and copyright document, upstream is at > https://www.vi-hps.org/projects/score-p This one does not contains otf2 Greetings
Bug#1079924: python-lesscpy: undeclared runtime dependency on python3-six which caused a FTBFS in prewikka
Le mer. 28 août 2024 à 17:48, Chris Hofstaedtler a écrit : > Right. Will you NMU both python-lesscpy and prewikka? > > Chris Ok, I will do that in two 6hours / dinstall locksteps & I'll be carefull to keep the good half of your NMU. Greetings
Bug#1079924: python-lesscpy: undeclared runtime dependency on python3-six which caused a FTBFS in prewikka
Source: python-lesscpy Version: 0.15.1-0.1 Severity: serious Tags: ftbfs Justification: Policy 7.2 X-Debbugs-Cc: Chris Hofstaedtler , Hans Joachim Desserud , Pierre Chifflier Dear Maintainers, After a carefull reread of the bug report of prewikka #1060985, it appears that the root cause lies instead in lesscpy and should be fixed there instead. https://github.com/lesscpy/lesscpy/issues/122 The problem still exists and could affect any other user of python-lesscpy. When lesscpy, the 5.2.0-2.1 NMU should be reverted: prewikka itself do not use python3-six at all, and python3-six is a legacy helper that should be removed from Debian. Greetings > File "/usr/lib/python3/dist-packages/lesscpy/scripts/compiler.py", line 22, > in > from lesscpy.lessc import parser > File "/usr/lib/python3/dist-packages/lesscpy/lessc/parser.py", line 21, in > > from six import string_types > prewikka: FTBFS: ModuleNotFoundError: No module named 'six' https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060985
Bug#1079917: python-certbot-apache: please remove the extraneous dependency on python3-six
Source: python-certbot-apache Version: 2.9.0-1 Severity: normal Dear Maintainer, six is not needed for anything anymore. Greetings /tmp$ git clone https://salsa.debian.org/letsencrypt-team/certbot/certbot-apache /tmp$ cd certbot-apache/ /tmp/certbot-apache$ grep six -r debian/control: python3-six, /tmp/certbot-apache$
Bug#1079915: lasso: please trim or remove usage of python3-six
Source: lasso
Version: 2.8.2-3
Severity: normal
Dear Maintainer,
https://dev.entrouvert.org/projects/lasso/issues/
I see you are active upstream too.
python3-six is slowly being removed from Debian.
Please consider replacing all thoses "six.print_("
by simple "print(".
If Python 2.7 compatibility still needs to be retained,
a single "from __future__ import print_function"
is needed at the very top of the file.
Greetings
Bug#1079907: otf2: please phase-out python3-six usage
Source: otf2 Version: 3.0.3-3.1 Severity: normal Hi, This package has a realy light usage of six that could be easily patched out. But upstream website is undeciphirable to me. There's seems to be a tarball coming from nowhere -- or from Jülich ?, a nice city by the way -- and that's all. Greetings build-backend/configure:_ax_python_import='$PYTHON -c '\''import six'\'' >&5' build-backend/configure:HAVE_PYMOD_VERSION_SIX=$($PYTHON -c "import six; print(six.__version__)" 2>/dev/null) build-frontend/configure:_ax_python_import='$PYTHON -c '\''import six'\'' >&5' build-frontend/configure:HAVE_PYMOD_VERSION_SIX=$($PYTHON -c "import six; print(six.__version__)" 2>/dev/null) src/python/_otf2/Config.py:import six src/python/_otf2/ErrorCodes.py:import six src/python/otf2/attribute_value.py:from six import string_types src/python/otf2/definitions.py:from six import with_metaclass, integer_types, string_types src/python/otf2/events.py:from six import with_metaclass, string_types src/python/otf2/registry.py:from six import string_types templates/otf2.attribute_value.tmpl.py:from six import string_types templates/otf2.events.tmpl.py:from six import with_metaclass, string_types templates/otf2.registry.tmpl.py:from six import string_types test/python/test_otf2_rewrite_UTF.py:import six
Bug#1079904: gr-osmosdr: please remove the extraneous dependency on python3-six
Source: gr-osmosdr Version: 0.2.6-1 Severity: normal python3-six is an obsolete library that is slowly being removed from Debian. Please remove the one extraneous line from d/control. Greetings /tmp$ git clone https://salsa.debian.org/bottoms/pkg-gr-osmosdr /tmp$ cd pkg-gr-osmosdr/ /tmp/pkg-gr-osmosdr$ grep six -r debian/control: python3-six, /tmp/pkg-gr-osmosdr$
Bug#1079903: gr-gsm: please drop extraneous dependency on python3-six
Source: gr-gsm Version: 1.0.0~20220727-1 Severity: normal Dear Maintainers, six is not needed anymore, please remove hte one reference from d/control. Greetings /tmp$ git clone https://salsa.debian.org/debian-hamradio-team/gr-gsm /tmp/gr-gsm$ grep six -r debian/control:python3-six, /tmp/gr-gsm$
Bug#1079895: gr-dab: please package v0.5 and remove the dependency on python3-six
Source: gr-dab Version: 0.4-2 Severity: normal Dear Maintainers, Usage of deprecated python3-six is gone in latest release: https://github.com/andrmuel/gr-dab/releases/tag/0.5 Greetigs
Bug#1079885: donkey: please drop the obsolete python3-six build dependency
Source: donkey Version: 1.2.0-8 Severity: normal Dear Maintainer, Six is not used anywhere. We are trying to slowly remove python3-six from Debian. Please remove the extraneous dependency from d/control & d/tests/control. Greetings. tchet@quieter:/tmp$ dget -x https://deb.debian.org/debian/pool/main/d/donkey/donkey_1.2.0-8.dsc tchet@quieter:/tmp/donkey-1.2.0$ grep six -r src/configure: *posix*) : src/configure:set -o posix ;; #( src/configure: *posix*) : src/configure:set -o posix ;; #( src/configure: *posix*) : src/configure:set -o posix ;; #( debian/control: python3-six, debian/tests/control: python3-six, tchet@quieter:/tmp/donkey-1.2.0$
Bug#1079869: spice-gtk: please remove dependency on python3-six using provided patch
Source: spice-gtk
Version: 0.42-2.1
Severity: normal
Hi,
The patch is not complete: I don't know how to butcher
subprojects/spice-common/m4/spice-deps.m4.
Please forward this patch upstream.
Greetings
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 71c7bab2..f85e04d1 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,7 +1,7 @@
image: fedora:latest
variables:
- DEPS_COMMON: git make python3 python3-six redhat-rpm-config
+ DEPS_COMMON: git make python3 redhat-rpm-config
python3-pyparsing meson ninja-build gtk-doc glib2-devel
gettext gettext-devel gcc
diff --git a/debian/control b/debian/control
index 48c95c7b..eeca24ac 100644
--- a/debian/control
+++ b/debian/control
@@ -41,7 +41,6 @@ Build-Depends: debhelper-compat (= 13),
meson (>= 0.56),
pkg-config,
python3-pyparsing,
- python3-six,
python3:any,
valac (>= 0.18)
Standards-Version: 4.6.2
diff --git a/debian/control.in b/debian/control.in
index 42e743c4..3643d001 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -37,7 +37,6 @@ Build-Depends: debhelper-compat (= 13),
meson (>= 0.56),
pkg-config,
python3-pyparsing,
- python3-six,
python3:any,
valac (>= 0.18)
Standards-Version: 4.6.2
diff --git a/subprojects/spice-common/.gitlab-ci.yml
b/subprojects/spice-common/.gitlab-ci.yml
index cfa6e720..387e9b5f 100644
--- a/subprojects/spice-common/.gitlab-ci.yml
+++ b/subprojects/spice-common/.gitlab-ci.yml
@@ -3,7 +3,7 @@ image: fedora:latest
before_script:
- >
dnf install git libtool make libasan
-python3 python3-six python3-pyparsing glib-networking
+python3 python3-pyparsing glib-networking
meson ninja-build gdk-pixbuf2-devel
glib2-devel pixman-devel openssl-devel libjpeg-devel
libcacard-devel cyrus-sasl-devel lz4-devel opus-devel
diff --git a/subprojects/spice-common/python_modules/codegen.py
b/subprojects/spice-common/python_modules/codegen.py
index bfb2351b..affe5bc5 100644
--- a/subprojects/spice-common/python_modules/codegen.py
+++ b/subprojects/spice-common/python_modules/codegen.py
@@ -1,5 +1,4 @@
-import six
from io import StringIO
def camel_to_underscores(s, upper = False):
@@ -123,10 +122,7 @@ class CodeWriter:
def write(self, s):
# Ensure its a unicode string
-if six.PY3:
-s = str(s)
-else:
-s = unicode(s)
+s = str(s)
if len(s) == 0:
return
diff --git a/subprojects/spice-common/python_modules/spice_parser.py
b/subprojects/spice-common/python_modules/spice_parser.py
index 4d753cba..1dc7e224 100644
--- a/subprojects/spice-common/python_modules/spice_parser.py
+++ b/subprojects/spice-common/python_modules/spice_parser.py
@@ -1,11 +1,9 @@
-import six
-
try:
from pyparsing import Literal, CaselessLiteral, Word, OneOrMore,
ZeroOrMore, \
Forward, delimitedList, Group, Optional, Combine, alphas, nums,
restOfLine, cStyleComment, \
alphanums, ParseException, ParseResults, Keyword, StringEnd,
replaceWith
except ImportError:
-six.print_("Module pyparsing not found.")
+print("Module pyparsing not found.")
exit(1)
@@ -149,9 +147,9 @@ def parse(filename):
bnf = SPICE_BNF()
types = bnf.parseFile(filename)
except ParseException as err:
-six.print_(err.line, file=sys.stderr)
-six.print_(" "*(err.column-1) + "^", file=sys.stderr)
-six.print_(err, file=sys.stderr)
+print(err.line, file=sys.stderr)
+print(" "*(err.column-1) + "^", file=sys.stderr)
+print(err, file=sys.stderr)
return None
for t in types:
diff --git a/subprojects/spice-common/spice_codegen.py
b/subprojects/spice-common/spice_codegen.py
index d3a1bf59..03fbdd7f 100755
--- a/subprojects/spice-common/spice_codegen.py
+++ b/subprojects/spice-common/spice_codegen.py
@@ -9,7 +9,6 @@ from python_modules import ptypes
from python_modules import codegen
from python_modules import demarshal
from python_modules import marshal
-import six
def write_channel_enums(writer, channel, client, describe):
messages = list(filter(lambda m : m.channel == channel, \
@@ -113,20 +112,17 @@ def write_content(dest_file, content,
keep_identical_file):
f.close()
if content == old_content:
-six.print_("No changes to %s" % dest_file)
+print("No changes to %s" % dest_file)
return
except IOError:
pass
f = open(dest_file, 'wb')
-if six.PY3:
-f.write(bytes(content, 'UTF-8'))
-else:
-f.write(content)
+f.write(bytes(content, 'UTF-8'))
f.close()
-six.print_("Wrote %s" % dest_file)
+print("Wrote %s" % dest_file)
parser = OptionParser(usage="usage: %prog [options]
")
Bug#1079864: ceph-mgr-rook: please remove the extraneous hardcoded dependency on python3-six
Package: ceph-mgr-rook Version: unstable: 18.2.4+ds-6 Severity: normal Dear Maintainer, We are slowly trying to remove python3-six from Debian. Please remove the one leftover extraneous referenrence in debian/control. Greetings tchet@quieter:/tmp$ apt download ceph-mgr-rook Réception de :1 http://ftp.be.debian.org/debian testing/main amd64 ceph-mgr-rook all 18.2.4+ds-6 [71,3 kB] 71,3 ko réceptionnés en 0s (904 ko/s) tchet@quieter:/tmp$ dpkg -X ceph-mgr-rook_18.2.4+ds-6_all.deb peek ./ ./usr/ ./usr/share/ ./usr/share/ceph/ ./usr/share/ceph/mgr/ ./usr/share/ceph/mgr/rook/ ./usr/share/ceph/mgr/rook/__init__.py ./usr/share/ceph/mgr/rook/ci/ ./usr/share/ceph/mgr/rook/ci/Dockerfile ./usr/share/ceph/mgr/rook/ci/cluster-specs/ ./usr/share/ceph/mgr/rook/ci/cluster-specs/cluster-on-pvc-minikube.yaml ./usr/share/ceph/mgr/rook/ci/run-rook-e2e-tests.sh ./usr/share/ceph/mgr/rook/ci/scripts/ ./usr/share/ceph/mgr/rook/ci/scripts/bootstrap-rook-cluster.sh ./usr/share/ceph/mgr/rook/ci/tests/ ./usr/share/ceph/mgr/rook/generate_rook_ceph_client.sh ./usr/share/ceph/mgr/rook/module.py ./usr/share/ceph/mgr/rook/rook_client/ ./usr/share/ceph/mgr/rook/rook_client/__init__.py ./usr/share/ceph/mgr/rook/rook_client/_helper.py ./usr/share/ceph/mgr/rook/rook_client/ceph/ ./usr/share/ceph/mgr/rook/rook_client/ceph/__init__.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephblockpool.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephclient.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephcluster.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephfilesystem.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephfilesystemmirror.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephnfs.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephobjectrealm.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephobjectstore.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephobjectstoreuser.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephobjectzone.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephobjectzonegroup.py ./usr/share/ceph/mgr/rook/rook_client/ceph/cephrbdmirror.py ./usr/share/ceph/mgr/rook/rook_client/ceph/objectbucket.py ./usr/share/ceph/mgr/rook/rook_client/ceph/objectbucketclaim.py ./usr/share/ceph/mgr/rook/rook_client/ceph/volume.py ./usr/share/ceph/mgr/rook/rook_client/ceph/volumereplication.py ./usr/share/ceph/mgr/rook/rook_client/ceph/volumereplicationclass.py ./usr/share/ceph/mgr/rook/rook_cluster.py ./usr/share/ceph/mgr/rook/tests/ ./usr/share/doc/ ./usr/share/doc/ceph-mgr-rook/ ./usr/share/doc/ceph-mgr-rook/changelog.Debian.gz ./usr/share/doc/ceph-mgr-rook/copyright tchet@quieter:/tmp$ grep six peek/ -r tchet@quieter:/tmp$
Bug#1079862: dynamic-motd: please remove the extraneous build-dep on python3-six
Source: dynamic-motd Version: 0.04-1 Severity: normal six is not used anywhere
Bug#732019: PyPy plugin support for uWSGI
Hi, Is there still interest in this? I have preliminary packaging but it requires more work regarding some issues. The first one is that the libpypy-c.so filename is hardoced in the plugin, whereas it contains the version in Debian and there is no symlink (/usr/lib/x86_64-linux-gnu/libpypy3.9-c.so on my sid host). The second one is that the very basic "Hello world" autopkgtest fails in the same way described ias an upstream bug[1]. There seems to exist other issues[2][3] with the pypy plugin upstream. [1] https://github.com/unbit/uwsgi/issues/2342 [2] https://github.com/unbit/uwsgi/issues/2436 [3] https://github.com/unbit/uwsgi/issues/2534 It seems that the pypy plugin has never been ported to pypy3. Things do not seem to be moving upstream. >From the state of things, it does not seem reasonable to introduce this plugin into Debian. Thanks, Alex
Bug#1079857: ITP: uwsgi-plugin-ruby -- Ruby plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-ruby Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : ruby plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the ruby java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-ruby Alex
Bug#1079831: RM: python-redisearch-py -- ROM; obsolete, newer alternative, low popcon
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-redisearch...@packages.debian.org Control: affects -1 + src:python-redisearch-py User: ftp.debian@packages.debian.org Usertags: remove https://github.com/RediSearch/redisearch-py/ "As of redis-py 4.0.0 this library is deprecated. It's features have been merged into redis-py. Please either install it from pypy or the repo." python3-redisearch-py has a popcon of 5 while the newer python3-redis has a popcon of 3500. Greetings
Bug#1079826: python-eventlet: please remove the extraneous python3-six build dependency
Source: python-eventlet Version: 0.35.1-3 Severity: normal Usage of six is gone. Greetings /tmp/python-eventlet-0.35.1$ grep six -r -B 1 NEWS-* Drop support for Python3.3; Python2.6 and python-epoll package NEWS:* external dependencies for six, monotonic, dnspython; Thanks to nat-goodspeed -- debian/control: python3-six,
Bug#1079824: sentinelsat: please drop the extraneous build-depends on python3-six
Source: sentinelsat Version: 1.2.1-1 Severity: normal Six was a helper needed for the Py2 -> 3 transition. This package has completed it's transition and don't need it anymore. tchet@quieter:/tmp/sentinelsat-1.2.1$ grep six -r debian/control: python3-six, tchet@quieter:/tmp/sentinelsat-1.2.1$ Greetings
Bug#1079823: pytorch-text: please drop the extraneous dependency on python3-six
Source: pytorch-text Version: 0.15.2-1 Severity: normal Dear Maintainer, All usage of python3-six has been removed a long time ago. https://github.com/pytorch/text/pull/732 Greetings
Bug#1079818: RM: python-opentracing -- ROM; RB buggy, dead upstream, low popcon, no rdep
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-opentrac...@packages.debian.org, Fabrice BAUZAC-STEHLY Control: affects -1 + src:python-opentracing User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, This package hinder the removal of old python3-mock library an should be removed from unstable. https://github.com/opentracing/opentracing-python This repository has been archived by the owner on May 23, 2023. It is now read-only. Greetings
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
On Wed Aug 21, 2024 at 9:54 AM CEST, Alexandre Rossi wrote: > > Regardless of the userbase being arguably significant, I am ok with the > > approach of trying to pull the plug on them, having a package ready if > > someone provides good reasons for reviving them. > > > > Will you try prepare dropping these alternatives? I imagine that in > > addition to removal of the code and the entries in the control file > > (see my related draft commit in the wip branch), it requires adding an > > entry in debian/NEWS. > > Will do, thanks for your input. Done. https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/c96dcf437e7a277e9da4e161fe720e3cccf9a525 >From our discussion, this ITP can be closed. Packaged apache2 modules could be reintroduced in the future using the work available at: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Cheers, Alex
Bug#1078131: ripe-atlas-tools: ripe-atlas crash due to missing argument on yaml.load
Hi, I'm trying updating the package for other reasons (Nose removal), but I'm stuck with a weird problem. Build works perfectly fine with debuild but tests fails with git-buildpackage & on Salsa. Greetings
Bug#1018329: nmudiff
Hi, The repo for the nmu is here: https://salsa.debian.org/detiste-guest/click-man/ Please import all 3 branches.
Bug#1079534: RM: python-picklable-itertools -- ROM; obsolete, dead upstream for 9 years, depends on Nose
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-picklable-iterto...@packages.debian.org, Fabian Wolff Control: affects -1 + src:python-picklable-itertools User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, This obsolete package hinders the Nose (*) & Six removals. (*) Which might break or not with Python3.13. python-picklable-itertools already has no rdeps left and a very low residual popcon. https://github.com/mila-iqia/picklable-itertools Greetings
Bug#1077824: python3-amqplib: Produced binary package is Python2 only
Hi, Before discovering https://tracker.debian.org/news/1557760/accepted-slimit-081-7-source-into-unstable/ ... I would have said nothing depends on 2to3 anymore and it should be removed ASAP. If someone is still desperate for 2to3 feature they can use python3-fissix (a fork of 2to3). Greetings
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-pyt...@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
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-pyt...@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#1079357: RM: python-dugong -- RoQA; abandonned upstream, RC buggy
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-dug...@packages.debian.org, nikol...@rath.org, Francesco Paolo Lovergine Control: affects -1 + src:python-dugong User: ftp.debian@packages.debian.org Usertags: remove Debian Maintainer is also upstream. https://github.com/python-dugong/python-dugong > This Project is Orphaned > > This project is no longer maintained or developed. > Github issue tracking and pull requests have therefore been disabled. The > mailing list (see below) is still available for use. -- The only current rdep is "s3ql" https://tracker.debian.org/pkg/s3ql More recent releases of s3ql does vendor a fork of dugong. https://github.com/s3ql/s3ql/commit/9819f85ec310b0345e7fe09f5a4805916d7ddeca Vendor in python-dugong module This module is no longer maintained and we'd like to make a number of changes to it (e.g. switch to Trio and native await/async). http.py corresponds 1:1 to dugong/__init__.py from dugong 3.8.2.
Bug#1078805: transmission-common: UPnP is non-functional in version 3.00 and later
forwarded 1078805 https://github.com/transmission/transmission/issues/1254 severity 1078805 normal thanks Hi, Lowering severity has this does not have "a major effect on the usability of [the] package", in my view. > UPnP doesn't work in versions 3.00 and up. This issue isn't specific to me as > other people are having this issue > (https://github.com/transmission/transmission/issues/1254) and I tested this > with another torrent client. Can you explain how this is tested and in which manner this fails? Can you confirm 4.0.6+dfsg-3 also does not work? Thanks, Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
> Regardless of the userbase being arguably significant, I am ok with the > approach of trying to pull the plug on them, having a package ready if > someone provides good reasons for reviving them. > > Will you try prepare dropping these alternatives? I imagine that in > addition to removal of the code and the entries in the control file > (see my related draft commit in the wip branch), it requires adding an > entry in debian/NEWS. Will do, thanks for your input. Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
Hi, > Work is happenning here: > > https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Work feels done unless further comments are coming. Now the question is, is this useful in the Debian archive? Remember, there are 3 available apache2 modules for the uwsgi protocol: - mod-proxy-uwsgi (built from src:apache2, popcon?, I use it) - mod-uwsgi (built from src:uwsgi, popcon 101) - mod-ruwsgi (built from src:uwsgi popcon 7) I do not see any reason to use anything other than mod-proxy-uwsgi. So my take on this is: 1) disable apache2 building in src:uwsgi 2) if someone complains, introduce this package in the archive The alternative is to not wait for someone to complain. Thanks, Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Hi, > > > uwsgidecorators.py would make sense in this package but is not > > > provided by uwsgi-src. OK to add it? > > > > Yes: Anything needed for plugin/module packages should be included in > > uwsgi-src package. > > Waiting for an upload to uncomment uwsgidecorators.py stuff. Done, and finished for what I wanted to do unless you have further comments. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Thanks, Alex
Bug#1079153: python-gnocchiclient: please package v7.1.0 and remove dependency on python3-six
Source: python-gnocchiclient Version: 7.0.8-2 Severity: normal https://github.com/gnocchixyz/python-gnocchiclient/releases/tag/7.1.0 Clean-up PR was merged before this release. Greetings finish Python 2 -> 3 migration, remove dependecy on Six by @a-detiste in #138 New Contributors @Callum027 made their first contribution in #142 @a-detiste made their first contribution in #138
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Hi, I have finished what I think is needed for this package. > > uwsgidecorators.py would make sense in this package but is not > > provided by uwsgi-src. OK to add it? > > Yes: Anything needed for plugin/module packages should be included in > uwsgi-src package. Waiting for an upload to uncomment uwsgidecorators.py stuff. > > My packaging only builds for the default python version. Should we > > plan for multiple python versions supported in sid? My view on this is > > to wait for the need to arise. If ok with this, src:uwsgi should > > probably clean out all the alternatives provided. You view on this? > > I used to strongly favor offering each available version, but nowadays I > don't really care, so if you prefer to reduce to a single non-versioned > package then go ahead - but yes, then be careful to handle the migration > (personally I would find it simpler to *continue* with versioned > packages now that it has been established already, but I leave the > choice to you). Implemented. Left out the rtupdate stuff: very complicated for would require a binNMU in most cases. > > greenlet should be restricted to some archs, looking into that and > > considering specific source package. Advice? > > I recommend to use the same method that I have used. Done. I initially went for a debian/control.in template but later was confused and editing debian/control directly so now I understand your approach of having only debian/control. > You might consider adding support for pypy3, and close bug#732019. pypy is a different set of build deps, so a different source package I think. Thanks, Alex
Bug#1078790: Acknowledgement (htpdate: pid written with -i option is wrong)
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Hi, > Can you try again with 1.6.13-4 and patching > /etc/schroot/setup.d/10mount and replace the line 306 which reads > > mknod -m700 "$CHROOT_PATH/dev/console" c 5 1 > > by > > touch "$CHROOT_PATH/dev/console" The problem disappears with the line changed. Alex
Bug#1078790: htpdate: pid written with -i option is wrong
Package: htpdate Version: 1.2.2-4 Severity: important X-Debbugs-Cc: alexandre@okwind.fr Dear Maintainer, * What led up to the situation? Installing the package invokes systemctl to start it and finally hangs up after a timeout, leaving the service stopped * What exactly did you do (or not do) that was effective (or ineffective)? Running `htpdate -i /run/htpdate.pid` and compared the value in the file and the value seen with `ps aux | grep htpdate` * What was the outcome of this action? File was containing 63038, and with `ps` the value process real pid was 521790 (example values) * What outcome did you expect instead? By compiling myself (simple `make` in the uptream source) and running the same command the pid values were the same. This seems like an arch issue. -- System Information: Debian Release: 11.6 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.21-v8+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages htpdate depends on: ii init-system-helpers 1.60 ii libc62.31-13+rpt2+rpi1+deb11u5 ii lsb-base 11.1.0 htpdate recommends no packages. htpdate suggests no packages. -- no debconf information
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Hi, > > My sbuild setup now fails on my sid systemd-nspawn container. > > So I understand correctly this is a regression to -3? Downgrading to 1.6.13-3+b3 makes the problem disappear. > > $ sudo sbuild-update -u -d unstable > > E: 10mount: mknod: > > /var/run/schroot/mount/unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c/dev/console: > > Operation not permitted > > E: unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c: Chroot setup > > failed: stage=setup-start > > Chroot setup failed > > Error setting up unstable chroot > > > > The error comes from the mknod call at the end of > > /etc/schroot/setup.d/10mount . > > Commenting the associated lines works around the problem with no visible > > drawback for my usecase (sbuild). > > I reckon this was somehow introduced by the change in /etc/schroot/*/fstab, > can > you revert in the applicable file, in other words, replace (as in -4): > > | /dev/pts/dev/ptsdevpts > rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0 > > with (up until -3): > > | /dev/pts/dev/ptsnonerw,bind 0 0 $ grep pts /etc/schroot/sbuild/fstab #/dev/pts/dev/ptsdevpts rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0 /dev/pts/dev/ptsnonerw,bind 0 0 $ sudo sbuild-update -u -d unstable E: 10mount: mknod: /var/run/schroot/mount/unstable-amd64-sbuild-e939c22a-be21-404c-90dd-a145336da608/dev/console: Operation not permitted E: unstable-amd64-sbuild-e939c22a-be21-404c-90dd-a145336da608: Chroot setup failed: stage=setup-start Chroot setup failed Error setting up unstable chroot Chroot setup failed at /usr/bin/sbuild-update line 145. Still fails. Thanks, Alex
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 >
Bug#1078034: python3-urllib3: please mark it with m-a: foreign
Hi Helmut, Can you confirm ? Greetings
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-pyt...@lists.debian.org Dear Maintainer, The library pysimplesoap is obsolete & Orphaned in Debian. Please use an other SOAP library (like Zeep) Greetings
Bug#1078689: schleuder: autopkgtest is flaky, fails most of the time
Source: schleuder Version: 4.0.3-11 Severity: serious Justification: 0 Hi, The autopkgtest is flaky and hinders the update of systemd-cron and likely anything else that needs a cron-daemon. (the tests are actually run with scr:cron, but DebCI is not smart enough to know about alternative providers of cron-daemon) Greetings
Bug#1078576: lektor: please update lektor so that python3-mistune0 can be removed
Source: lektor Version: 3.3.7-2.1 Severity: serious Please switch to regular, alive, python3-mistune. Greetings
Bug#1078547: ITP: uwsgi-plugin-java -- java plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-java Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : java plugins for uWSGI uWSGI source packages build many plugins. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the java plugin packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-java Alex
Bug#1078544: Moreinformation: dead since 2009
Hi, > The project is included in apache2 > > moreover top of website said: > The project is in maintenance mode (only bugfixes and updates for new > languages apis). Do not expect quick answers on github issues and/or pull > requests (sorry for that) A big thanks to all of the users and contributors > since 2009 > > As comaint of apache2 could you give use reason to use this ? There are 3 available apache2 modules for the uwsgi protocol: - mod-proxy-uwsgi (built from src:apache2, popcon?, I use it) - mod-uwsgi (built from src:uwsgi, popcon 101) - mod-ruwsgi (built from src:uwsgii, popcon 7) This ITP is about changing how mod-uwsgi and mod-ruwsgi are built and ease maintainance. We could as well drop them to force transition to mod-proxy-uwsgi. I just did not want to force this. Regarding uwsgi maintenance mode, I use it and care, and not alone (popcon vote ~1000). Thanks, Alex
Bug#1078544: ITP: uwsgi-apache2-mod -- apache2 modules for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-apache2-mod Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : apache2 modules for uWSGI uWSGI source packages build many plugins and even apache2 modules. Some plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins and apache2 modules. This new source package proposes to build the apache2 modules packages from a separate source package, as this has been done for php, mongo and luajit. Work is happenning here: https://salsa.debian.org/uwsgi-team/uwsgi-apache2-mod Alex
Bug#1078541: Questions/advices
uwsgidecorators.py would make sense in this package but is not provided by uwsgi-src. OK to add it? My packaging only builds for the default python version. Should we plan for multiple python versions supported in sid? My view on this is to wait for the need to arise. If ok with this, src:uwsgi should probably clean out all the alternatives provided. You view on this? greenlet should be restricted to some archs, looking into that and considering specific source package. Advice? Please bring up any other comment you might have. Thanks, Alex
Bug#1078541: ITP: uwsgi-plugin-python -- python plugins for uWSGI
Package: wnpp Severity: wishlist Owner: Alexandre Rossi X-Debbugs-Cc: debian-de...@lists.debian.org, Jonas Smedegaard * Package name: uwsgi-plugin-python Version : 0.0.1 * URL : https://uwsgi-docs.readthedocs.io/en/latest/ * License : GPL-2 Programming Lang: C Description : python plugins for uWSGI uWSGI source packages build many plugins. Somes plugins inplement language bindings and building them in the core source package can create transition difficulties. Also, building many plugins in the same d/rules makes it complicated and looses the semantic association between the plugin and its build dependencies, which are mixed for all plugins. This new source package proposes to build the python packages from a separate source package, as this has been done for php, mongo and luajit. Initial packaging is here: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Alex
Bug#1078539: schroot: fails to start in a systemd-nspawn container
Package: schroot Version: 1.6.13-4 Severity: normal Dear Maintainer, My sbuild setup now fails on my sid systemd-nspawn container. $ sudo sbuild-update -u -d unstable E: 10mount: mknod: /var/run/schroot/mount/unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c/dev/console: Operation not permitted E: unstable-amd64-sbuild-c631feb3-ec9a-475b-b19a-407a3bacf44c: Chroot setup failed: stage=setup-start Chroot setup failed Error setting up unstable chroot The error comes from the mknod call at the end of /etc/schroot/setup.d/10mount . Commenting the associated lines works around the problem with no visible drawback for my usecase (sbuild). This is in a sid systemd-nspawn container running on a bookworm host. Adding Capability=CAP_MKNOD to the nspawn configuration does not help. I was not able to correlate this to a systemd upgrade on the host or in the container. Thanks, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages schroot depends on: ii debconf [debconf-2.0] 1.5.87 ii libboost-filesystem1.83.0 1.83.0-3.1 ii libboost-iostreams1.83.01.83.0-3.1 ii libboost-program-options1.83.0 1.83.0-3.1 ii libc6 2.39-6 ii libgcc-s1 14.2.0-2 ii libpam0g1.5.3-7 ii libstdc++6 14.2.0-2 ii libuuid12.40.2-6 ii lsb-base11.6 ii schroot-common 1.6.13-4 ii sysvinit-utils [lsb-base] 3.10-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-tools | unionfs-fuse pn btrfs-progs ii bzip2 1.0.8-5.1 ii debootstrap1.0.137 pn lvm2 pn qemu-user-static ii xz-utils 5.6.2-2 pn zfsutils-linux ii zstd 1.5.6+dfsg-1 -- Configuration Files: /etc/schroot/setup.d/10mount changed [not included] -- debconf information: schroot/bad-names:
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > > src:uwsgi-plugin-python3 > > building uwsgi-plugin-python3 > > building python3-uwsgidecorators > > building uwsgi-plugin-asyncio-python3 > > building uwsgi-plugin-gevent-python3 > > building uwsgi-plugin-greenlet-python3 > > building uwsgi-plugin-tornado-python3 > [...] > > Please confirm or comment, and I'll give it a go for python. > > The above looks good. Please create that, and test (e.g. with debdiff) > that it produces same binary packages as now generated with src:uwsgi > we can release that. No need to touch src:uwsgi at all for this work. I'm there. https://salsa.debian.org/uwsgi-team/uwsgi-plugin-python Issues/questions: uwsgidecorators.py would make sense in this package but is not provided by uwsgi-src. OK to add it? My packaging only builds for the default python version. Should we plan for multiple python versions supported in sid? My view on this is to wait for the need to arise. If ok with this, src:uwsgi should probably clean out all the alternatives provided. You view on this? greenlet should be restricted to some archs, looking into that and considering specific source package. Advice? Please bring up any other comment you might have. Thanks, Alex
Bug#1078538: RM: python-m2r -- RoQA; RC buggy, dead upstream, transitively depends on Nose, no rdep left
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python-...@packages.debian.org, d...@jones.dk Control: affects -1 + src:python-m2r User: ftp.debian@packages.debian.org Usertags: remove As of today, all rdpes have been transitioned. This removal blocks removal of mistune0 (not yet filled). Greetings --- https://github.com/miyakogi/m2r This repository has been archived by the owner on Nov 17, 2022. It is now read-only.
Bug#1078528: python-thriftpy: RM? upstream archived
Thank you. You can proceed with the removal. Le dim. 11 août 2024 à 23:24, Chris Hofstaedtler a écrit : > Upstream has archived the source repo and points users to use > thriftpy2 instead. > > I'm filing this immediately as serious, as there is only one r-dep > (python-py-zipkin), and that one tries to use thriftpy2 instead, but > incorrectly doesn't. > > Chris I'm still thinking of making a spider that goes through all the GitHub projects and generates a list for a MBF. (+ follow up of new occurences) https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28 curl \ -H "Accept: application/vnd.github.v3+json" \ -H "Authorization: token " \ https://api.github.com/orgs/ORG/repos
Bug#1078517: ITP: python-rdflib-endpoint -- SPARQL endpoint for RDFLib
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-rdflib-endpoint Version : 0.5.1 Upstream Contact: Vincent Emonet * URL : https://github.com/vemonet/rdflib-endpoint * License : MIT Programming Lang: Python Description : SPARQL endpoint for RDFLib rdflib-endpoint is a SPARQL endpoint based on RDFLib to easily serve RDF files locally, machine learning models, or any other logic implemented in Python via custom SPARQL functions. --- This will be packaged in Debian Python Team This is a dependency of python-bioregistry packaged by Debian Med Team.
Bug#1018529: python-mapnik: build-depends on python3-nose or uses it for autopkgtest
Nose is back.
Greetings
debian/changelog: * Drop python3-nose from build dependencies.
debian/control: python3-nose,
setup.cfg:[nosetests]
setup.py:'nose',
setup.py:test_suite='nose.collector',
test/python_tests/python_plugin_test.py:# from nose.tools import *
test/run_tests.py:import nose
test/run_tests.py:"Unable to run python tests: the third party
'nose' module is required"
test/run_tests.py:"\nTo install 'nose' do:"
test/run_tests.py:"\n\tsudo pip install nose (or on debian systems: "
test/run_tests.py:"apt-get install python-nose): %s\n" % e)
test/run_tests.py:from nose.plugins.doctests import Doctest
test/run_tests.py:print("- Running nosetests:")
test/run_tests.py:# 3 * '-v' gets us debugging information from nose
test/run_tests.py:if not nose.run(argv=argv,
plugins=[TodoPlugin(), Doctest()]):
Bug#1078443: ITP: python-curies -- tool to manage Compact Uniform Resource Identifiers
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med-packag...@lists.alioth.debian.org * Package name: python-curies Version : 0.7.10 Upstream Contact: Charles Tapley Hoyt * URL : https://pypi.org/project/curies/ * License : MIT Programming Lang: Python Description : tool to manage Compact Uniform Resource Identifiers this Python package can be used by a variety of people: . Data Scientist - someone who consumes and modifies data to suit an analysis or application. For example, they might want to convert tabular data containing CURIEs into IRIs, translate into RDF, then query with SPARQL. . Curator - someone who creates data. For example, an ontologist may want to curate using CURIEs but have their toolchain. cat: µ: Aucun fichier ou dossier de ce nom --- This is a dependency of python-bioregistry, I will maintin it inside the Debian Med Team.
Bug#1078440: ITP: python-bioregistry -- community curated registry, meta-registry, and compact identifier resolver
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med-packag...@lists.alioth.debian.org * Package name: python-bioregistry Version : 0.11.12 Upstream Contact: Alexandre Detiste * URL : https://bioregistry.io/ * License : MIT Programming Lang: Python Description : community curated registry, meta-registry, and compact identifier resolver Here's what that means: . Registry . A collection of prefixes and metadata for ontologies, controlled vocabularies, and other semantic spaces. Some other well-known registries are the OBO Foundry, Identifiers.org, and the OLS. . Metaregistry . A collection of metadata about registries and mappings between their constituent prefixes. For example, ChEBI appears in all of the example registries from above. So far, the Bioregistry is the only metaregistry. . Resolver A tool for mapping compact URIs (CURIEs) of the form prefix:identifier to HTML and structured content providers. Some other well-known resolvers are Identifiers.org and Name-To-Thing. - I will maintain this inside the Debian Med Team. This is a new dependency of pybel also maintained by Med Team.
Bug#1076420: uwsgi: move away from cdbs - status update
Hi, > > All this is currently implemented in GNU make syntax, so this is doable to > > move to debhelper and not introduce some helper script. I'll try to > > come up with something. However, I still think that the handling of the > > plugin build configuration would be easier to maintain with a more capable > > language than GNU make. > > The alternative you didn't list which I prefer is to branch out to > interpreter-specific source packages depending on uwsgi-source and using > dh helpers tailored for each interpreter - same as has been done already > for php and a few others. Now I see what you mean. Can you confirm the list of new src packages you think about? I can think of the following and all helper script to generate binNMUs when uwsgi-abi changes. src:uwsgi-libapache2-mods building libapache2-mod-ruwsgi building libapache2-mod-ruwsgi src:uwsgi-plugin-python3 building uwsgi-plugin-python3 building python3-uwsgidecorators building uwsgi-plugin-asyncio-python3 building uwsgi-plugin-gevent-python3 building uwsgi-plugin-greenlet-python3 building uwsgi-plugin-tornado-python3 src:uwsgi-plugin-ruby building uwsgi-plugin-fiber building uwsgi-plugin-rack building uwsgi-plugin-rbthreads src:uwsgi-plugin-gccgo src:uwsgi-plugin-glusterfs src:uwsgi-plugin-openjdk building uwsgi-plugin-jvm building uwsgi-plugin-jwsgi building uwsgi-plugin-ring building uwsgi-plugin-servlet src:uwsgi-plugin-lua51 src:uwsgi-plugin-mono src:uwsgi-plugin-psgi src:uwsgi-plugin-rados Please confirm or comment, and I'll give it a go for python. Once all done, this should make the move the dh easy with a static list of plugins to build. Thanks, Alex
Bug#1077434: unittest2: FTBFS: TypeError: expected string or bytes-like object, got 'late_version'
python-funcsigs is the only reverse dependency that will need a tiny & trivial patch. Don't waste time keeping this package alive. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078184
