Bug#1083457: Migrating away from pkg_resources is difficult for namespace packages
While pkg_resources is indeed deprecated upstream, there's nothing that
we can sensibly do about it at the Debian level in lazr.* or zope.*, and
it's not even as clear as you might hope what to do upstream. They all
do something like this in an __init__.py (with unimportant variations):
__import__('pkg_resources').declare_namespace(__name__)
As
https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages
says:
If you are creating a new distribution within an existing namespace
package that uses this method then it’s recommended to continue using
this as the different methods are not cross-compatible and it’s not
advisable to try to migrate an existing package.
I know pkg_resources is deprecated for most other purposes, but even
upstream currently advises here not to try to migrate in this case.
Now, I know there've been some attempts to figure this out:
https://github.com/pypa/sample-namespace-packages thinks a migration may
be possible as long as developers are willing to accept some
limitations. But it's still a difficult migration and upstream hasn't
really got going on it; for Zope, see
https://github.com/zopefoundation/meta/issues/194.
Please can you reconsider, and not force this for Debian trixie? I
think we need to keep pkg_resources around for this use case until a
good deal more work has been done on migrating away from it for
namespace packages.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1018673: Updating bug ownership
On Sun, Feb 11, 2024 at 04:39:56AM +, Nick Morrott (nickm) wrote: > owner 1018673 Nick Morrott Hi Nick, Are you still working on this bug in yotta, or can somebody else take it? It's now release-critical, so if you aren't working on it then it would be good if somebody else could pick it up without stepping on your toes. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1082525: src:ipykernel: unsatisfied build dependency in testing: python3-ipyparallel
On Sat, Sep 21, 2024 at 04:55:18PM +0200, Paul Gevers wrote: > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. To uphold our social contract, > Debian requires that packages can be rebuild from source in the suite > we are shipping them, so currently this is a serious issue with your > package in testing. > > Can you please investigate the situation and figure out how to resolve > it? Regularly, if the build dependency is available in unstable, > helping the maintainer of your Build-Depends to enable migration to > testing is a great way to solve the issue. If your build dependency is > gone from unstable and testing, you'll have to fix the build process > in some other way. I just uploaded a fix for entrypoints, which should help. After that reaches testing I can look at ipyparallel - it's possible its test suite is just a bit flaky and I don't want to spend too much time on it in advance. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052826: tagging 1052826
Control: tag -1 - wontfix On Wed, Aug 07, 2024 at 08:38:26PM +0200, Alexandre Detiste wrote: > tags 1052826 + wontfix I don't mind if we try to remove entrypoints as a separate effort, but I disagree with wontfixing this bug; temporarily moving the *.egg-info directories aside so that pybuild doesn't remove them was quite easy once I figured out how, and it helps with more RC bugs more quickly than going around patching all the reverse-dependencies. Untagging this since I am in fact going to fix it. :-) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081851: python3-scruffy: 0001-Migrate-from-imp-to-importlib.patch breaks with Python 3.12
On Sun, Sep 15, 2024 at 05:07:36PM +0200, Alexandre Detiste wrote: > I'm getting the error "module ‘importlib’ has no attribute ‘find_spec’" > when I try to re-enable tests for voltron; > which is using python3-scruffy for it's build. > > As far as I understand, the sole purpose of python3-scruffy is to build > "voltron". Hi, I had a go at this today. I _think_ I have something that works and is equivalent to the old imp-based code, but I couldn't get the voltron tests completely working and I'm not sure whether the remainder are bugs in python-scruffy, or in voltron, or in my temporary hacks to voltron. Could you please have a look? All these patches are obviously preliminary; I haven't finalized changelogs or anything. diff --git a/debian/changelog b/debian/changelog index 4d3dcc6..2183a80 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +python-scruffy (0.3.8.2-2) UNRELEASED; urgency=medium + + * + + -- Colin Watson Thu, 03 Oct 2024 22:38:08 +0100 + python-scruffy (0.3.8.2-1) unstable; urgency=medium * Team upload. diff --git a/debian/patches/0001-Migrate-from-imp-to-importlib.patch b/debian/patches/0001-Migrate-from-imp-to-importlib.patch index 9e9188f..89c0e55 100644 --- a/debian/patches/0001-Migrate-from-imp-to-importlib.patch +++ b/debian/patches/0001-Migrate-from-imp-to-importlib.patch @@ -1,32 +1,38 @@ From: Dale Richards Date: Mon, 25 Dec 2023 21:41:37 + Subject: Migrate from imp to importlib -Forwarded: https://github.com/snare/scruffy/pull/31 +Forwarded: https://github.com/snare/scruffy/pull/31 --- - scruffy/plugin.py | 6 +++--- - 1 file changed, 3 insertions(+), 3 deletions(-) + scruffy/plugin.py | 11 +++ + 1 file changed, 7 insertions(+), 4 deletions(-) +diff --git a/scruffy/plugin.py b/scruffy/plugin.py +index 9c6853b..6f556f0 100644 --- a/scruffy/plugin.py +++ b/scruffy/plugin.py -@@ -5,7 +5,7 @@ +@@ -5,7 +5,8 @@ Plugin Classes for representing and loading plugins. """ import os -import imp -+import importlib ++import importlib.machinery ++import importlib.util import six -@@ -56,9 +56,9 @@ +@@ -56,9 +57,11 @@ class PluginManager(object): # if it's a file, load it modname, ext = os.path.splitext(filename) if os.path.isfile(filepath) and ext == '.py': -file, path, descr = imp.find_module(modname, [directory]) -+file, path, descr = importlib.find_spec(modname, [directory]) - if file: +-if file: -mod = imp.load_module(modname, file, path, descr) -+mod = importlib.load_module(modname, file, path, descr) ++loader = importlib.machinery.SourceFileLoader(modname, filepath) ++spec = importlib.util.spec_from_loader(modname, loader) ++if spec: ++mod = importlib.util.module_from_spec(spec) ++spec.loader.exec_module(mod) # if it's a directory, recurse into it if os.path.isdir(filepath): And just a rough patch to get voltron running any tests at all (that setting of HOME is obviously crude, and I don't expect we'd want to go back to using nose - I just wanted something that presumably worked at some point): diff --git a/debian/changelog b/debian/changelog index b84069a..11ea1c0 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +voltron (0.1.7+git20200109-5) UNRELEASED; urgency=medium + + * + + -- Colin Watson Thu, 03 Oct 2024 21:52:17 +0100 + voltron (0.1.7+git20200109-4) unstable; urgency=medium * Team upload. diff --git a/debian/control b/debian/control index fc82489..e5854c2 100644 --- a/debian/control +++ b/debian/control @@ -12,7 +12,9 @@ Build-Depends: debhelper-compat (= 13), python3-flask-restful, python3-flask, python3-mock, + python3-nose, python3-pexpect, + python3-pygments, python3-requests-unixsocket, python3-scruffy, python3-setuptools, diff --git a/debian/rules b/debian/rules index 8c3f952..48188ff 100755 --- a/debian/rules +++ b/debian/rules @@ -9,6 +9,5 @@ execute_before_dh_auto_configure: cat debian/*manpages | sed 's/$$/.txt/p' | xargs -n 1 a2x --doctype manpage --format manpage override_dh_auto_test: - # The test needs home directory, so we disable it. - #python3 -m nose -sv tests/gdb_cli_tests.py - #python3 -m nose -sv tests/lldb_cli_tests.py + HOME=$(CURDIR)/debian python3 -m nose -sv tests/gdb_cli_tests.py + HOME=$(CURDIR)/debian python3 -m nose -sv tests/lldb_cli_tests.py Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1018588: python-testing.mysqld: build-depends on python3-nose or uses it for autopkgtest
On Sun, Aug 28, 2022 at 09:52:02PM +0300, Dmitry Shachnev wrote: > 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. I had a go at fixing this, but it's hiding some more serious issues. The tests were disabled in response to https://bugs.debian.org/978259, so in principle we could just drop the build-dependency. However, I'm pretty sure that it's more a matter of the _package_ not working rather than the _tests_ not working. (I'm always very suspicious of "disable the tests" commits for this kind of reason!) I don't want to fix this up if it doesn't actually work. The code you need to initialize a database so that a test suite can connect to it differs between MySQL versions and between MySQL and MariaDB, and as far as I can see testing.mysqld only has what you need for oldish versions of MySQL and not either newer versions of MySQL or MariaDB; you can see evidence of this sort of thing in pytest-mysql, and I remember adding similar logic to Storm's test suite based on pytest-mysql a while back. testing.mysqld hasn't had any upstream commits since 2018. There's a stalled PR for MySQL 8 support (https://github.com/tk0miya/testing.mysqld/pull/9), but on its own I think that would make things worse for MariaDB since (at least according to pytest-mysql) you have to keep using mysql_install_db/mariadb-install-db for MariaDB. After hacking in something like what pytest-mysql does, I found I still needed to add --auth-root-authentication-method=normal to the mysql_install_db call (or possibly some different approach would be better - see https://github.com/tk0miya/testing.mysqld/issues/3). Even after that, there's still a test failure in one error case that I didn't get to the bottom of. Having said all this, I wondered whether it was worth the effort to fix it, so I looked for reverse-(build-)dependencies and found that there currently aren't any. Thus I think we should just remove this from Debian. I've CCed people who've ever uploaded this package and might potentially be interested. If I don't hear objections in a week, I'll reassign this to ftp.debian.org for removal. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1083054: dh-python: PEP440 mode translates == requirements incorrectly
Package: dh-python Version: 6.20240824 Severity: normal pydantic has 'pydantic-core==2.23.4' as a dependency in its pyproject.toml (2.9.2-1 patches that to ">=", but I'm in the process of removing that patch), and I tried to put "pydantic-core python3-pydantic-core; PEP440" in debian/py3dist-overrides to cause that to be translated into appropriate Debian package dependencies. Unfortunately, that resulted in a dependency on "python3-pydantic-core (= 2.23.4)", which is incorrect since python3-pydantic-core isn't a native package. A correct dependency would have been something like "python3-pydantic-core (>= 2.23.4), python3-pydantic-core (<< 2.23.5~)". Relying on versioned Build-Depends here also doesn't work correctly. With "Build-Depends: python3-pydantic-core (>= 2.23.4), python3-pydantic-core (<< 2.23.5~)", dh_python3 only picks up the second of those version constraints, resulting in "Depends: python3-pydantic-core (<< 2.23.5~)". It looks like my only sensible option is to manually duplicate the version constraints into Depends. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.10.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-python depends on: ii python3 3.12.6-1 ii python3-setuptools 74.1.2-2 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.22.11 pn flit ii libdpkg-perl 1.22.11 ii python3-build 1.2.2-1 ii python3-installer 0.7.0+dfsg1-3 ii python3-wheel 0.44.0-2 -- no debconf information -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1082728: openssh: Passive SSH Key Compromise via Lattices (RSA host keys)
On Tue, Sep 24, 2024 at 08:55:29PM -0700, Matt Taggart wrote: > Passive SSH Key Compromise via Lattices > Keegan Ryan, Kaiwen He, George Arnold Sullivan, and Nadia Heninger > https://eprint.iacr.org/2023/1711.pdf > > details an attack that allows a passive observer to potentially compromise > RSA host keys. They also include details on internet-wide scans to measure > the prevalence of vulnerable signatures in the wild. This paper has been public since November 2023, and it also says in section 5 that OpenSSH implements countermeasures against it. Is there something new that's come to light more recently? (I haven't yet had time to read the paper in depth.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1082665: python3-nbconvert: old template file included in .deb
On Tue, Sep 24, 2024 at 01:30:13PM +0200, Twan van Laarhoven wrote: > The solution is likely to do a clean build, that is, remove all files > not in the upstream source archive before running the build script. Debian package builds aren't in general allowed to talk to the internet, so that approach won't work. We just need to update the versions that are embedded in the source package instead. > I also submited an upstream issue: > https://github.com/jupyter/nbconvert/issues/2180 At best this would just make the Debian package build fail due to the files being out of sync (which might not be a bad thing). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1082431: lexgrog: should read a local file if that is on the command line
On Fri, Sep 20, 2024 at 10:35:09PM +, Bjarni Ingi Gislason wrote: > lexgrog ./ > >* What was the outcome of this action? > > lexgrog reads the in the "/usr/share/man/" hierarchy. I can't reproduce this. $ strace -f -etrace=file lexgrog ./lexgrog.1 [...] openat(AT_FDCWD, "./lexgrog.1", O_RDONLY) = 3 ./lexgrog.1: "lexgrog - parse header information in man pages" +++ exited with 0 +++ I also confirmed this by editing the local file to have a different description. Please explain how I can reproduce your problem: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081148: flask-appbuilder: Remove from Debian?
Control: reassign -1 ftp.debian.org Control: affects -1 flask-appbuilder Control: retitle -1 ROM; FTBFS due to incompatibility with flask-sqlalchemy 3, multiple CVEs in Debian, no reverse-dependencies On Sun, Sep 08, 2024 at 06:18:43PM +0100, Colin Watson wrote: > flask-appbuilder has three open RC bugs and four open CVEs in Debian. > It hasn't been possible to build it in unstable since December 2022, > because it's incompatible with flask-sqlalchemy 3 > (https://github.com/dpgaspar/Flask-AppBuilder/issues/2038), and the > latest upstream release is no help here. There doesn't seem to have > been much upstream movement on this for quite a while, despite recent > releases making other changes. It has no reverse-dependencies. > > Should we just remove it from Debian? It can always be reintroduced > later if need be. I'll take silence as consent, and am reassigning this to ftp.debian.org for removal. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1055383: [INTL:ro] Translation of "man_base-passwd" to Romanian)
On Sun, Sep 15, 2024 at 03:57:43PM +0200, Remus-Gabriel Chelu wrote: > I would ask you, if possible, to include the submitted file > (base-passwd_3.6.2_man.ro.po) in the next version of the base-passwd > package. Sorry, I managed to miss this somehow! I've committed it now for my next upload. FYI, I made a few small corrections to translator_ro.add, as shown here: diff --git a/man/po4a/translator_ro.add b/man/po4a/translator_ro.add index def5247..30ce220 100644 --- a/man/po4a/translator_ro.add +++ b/man/po4a/translator_ro.add @@ -1,4 +1,4 @@ -PO4A-HEADER:mode=after;position=^\.SH NOM;beginboundary=FausseLimitePo4a +PO4A-HEADER:mode=after;position=^\.SH NUME;beginboundary=FausseLimitePo4a .SH TRADUCERE Această traducere a fost creată în 2023 de Remus-Gabriel Chelu. Ea este supusă licenței GNU GPL versiunea 2 (sau ulterioară). @@ -8,8 +8,8 @@ Pentru a citi versiunea originală în limba engleză, tastați «man -L C COMMA Vă rugăm să raportați erorile de traducere prin baza de date a erorilor (BTS) de la Debian sau trimițând un e-mail la .nh -<\fIdebian\-l10\-roman...@lists.debian.org\fR>, lista de discuții a traducerilor +<\fIdebian\-l10n\-roman...@lists.debian.org\fR>, lista de discuții a traducerilor în limba romănă a progrmelor și documentelor din Debian, sau direct autorului acestei traduceri la .hy -<remusgabriel.ch...@disroot.org> + -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1038882: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)
I haven't been following the rest of this discussion, but one small point since this is a common source of confusion: On Sat, Sep 14, 2024 at 02:30:08PM +0200, Daniel Gröber wrote: > Lastly I don't quite understand how the ftp-master priority override > mechanism plays into this and indeed why we're using it over just uploading > new revisions with the changes? dak's architecture is that every package in the archive has overrides setting its priority and section; an upload that doesn't match existing overrides goes to NEW. In many (most?) cases those will be equal to the values in the packages themselves, but those values are nevertheless overridden. This means that uploading a new version of a package to attempt to change its priority or section has no effect; if you need to change those, you _must_ get ftpmaster to change the override, and otherwise it just won't work. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081579: python-jsonschema: Upgrade to 4.23.0
Source: python-jsonschema Version: 4.19.2-3 Severity: wishlist Pydantic >= 2.9.0 has a test dependency on jsonschema >= 4.23.0. I'll try to patch this out somehow to unblock the upgrade, but could you please upgrade the Debian package so we don't have to keep such a patch around? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081518: RM: librust-jiter+python-dev -- NBS; no longer built by rust-jiter
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove I converted librust-jiter+python-dev from a real package into a virtual package. The cruft report (below) doesn't quite understand virtual packages and thinks that removing it will break pydantic-core's Build-Depends, but this isn't true since librust-jiter-dev still Provides it. Could you please decruft librust-jiter+python-dev anyway? * source package rust-jiter version 0.5.0-3 no longer builds binary package(s): librust-jiter+python-dev on amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x - suggested command: dak rm -o -m "[auto-cruft] NBS (no longer built by rust-jiter)" -s unstable -a amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x -p -R -b librust-jiter+python-dev - broken Build-Depends: pydantic-core: librust-jiter+python-dev Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081516: unblock: rust-jiter/0.5.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock A few Rust packages are currently blocked from migrating to testing due to what appears to be a bug in piuparts scheduling. I filed https://bugs.debian.org/1081420 about this. However, I particularly care about rust-jiter, because pydantic-core and pydantic and a bunch of other things are stuck behind it. Would it be possible to unblock this? There should still be enough material in the queue to debug whatever's going wrong with the piuparts scheduler. I've run piuparts over librust-jiter-dev locally and it seems fine. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081420: piuparts.debian.org: Some packages are stuck in waiting-to-be-tested
Package: piuparts.debian.org Severity: normal https://piuparts.debian.org/sid/state-waiting-to-be-tested.html shows several packages that have been stuck there for some time with no movement: librust-deb822-lossless-dev (Debian Rust Maintainers ) dependency librust-pyo3-0.22+default-dev is virtual provider librust-pyo3-dev is successfully-tested dependency librust-regex-1+default-dev is virtual provider librust-regex-dev is successfully-tested dependency librust-rowan-0.15+default-dev is virtual provider librust-rowan-dev is successfully-tested dependency librust-serde-1+default-dev is virtual provider librust-serde-dev is successfully-tested dependency librust-serde-1+derive-dev is virtual provider librust-serde-dev is successfully-tested librust-debversion-dev (Debian Rust Maintainers ) dependency librust-chrono-0.4+alloc-dev is virtual provider librust-chrono-dev is successfully-tested dependency librust-lazy-regex+default-dev is virtual provider librust-lazy-regex-dev is successfully-tested dependency librust-pyo3+default-dev is virtual provider librust-pyo3-dev is successfully-tested dependency librust-serde-1+default-dev is virtual provider librust-serde-dev is successfully-tested librust-jiter-dev (Debian Rust Maintainers ) dependency librust-ahash-0.8+default-dev is virtual provider librust-ahash-dev is successfully-tested dependency librust-bitvec-1+default-dev is virtual provider librust-bitvec-dev is successfully-tested dependency librust-lexical-parse-float-0.8+default-dev is virtual provider librust-lexical-parse-float-dev is successfully-tested dependency librust-lexical-parse-float-0.8+format-dev is virtual provider librust-lexical-parse-float-dev is successfully-tested dependency librust-num-bigint-0.4+default-dev is virtual provider librust-num-bigint-dev is successfully-tested dependency librust-num-traits-0.2+default-dev is virtual provider librust-num-traits-dev is successfully-tested dependency librust-pyo3-0.22+default-dev is virtual provider librust-pyo3-dev is successfully-tested dependency librust-pyo3-build-config-0.22+default-dev is virtual provider librust-pyo3-build-config-dev is successfully-tested dependency librust-smallvec-1+default-dev is virtual provider librust-smallvec-dev is successfully-tested Comparing these with their last uploads on tracker, they should have been tested by now. It looks like they're just never getting scheduled, but I don't know where to start looking for why. This blocks testing migration of those packages. In rust-jiter's case (the one I'm interested in), that in turn blocks pydantic-core and a number of other Python packages that need that. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080480: rust-merge: most autopkgtests fail
On Tue, Sep 10, 2024 at 05:21:30PM +0200, Arnaud Ferraris wrote: > Le 04/09/2024 à 21:36, Colin Watson a écrit : > > On Wed, Sep 04, 2024 at 08:04:21PM +0100, Colin Watson wrote: > > > https://ci.debian.net/packages/r/rust-merge/testing/amd64/ appears to > > > have always failed; it looks as though rust-merge:@ and > > > librust-merge-dev:default succeed but everything else fails. > > > > > > [...] > > > > > > There've been no upstream commits since 2020-09-21, only one upstream > > > release ever which was on 2020-09-01, and there are no > > > reverse-dependencies. Should we just remove it? > > Thanks for the notice, I'll have a look ASAP. > > FWIW I intend to package a software depending on this crate, but I'll check > for alternatives and file an RM bug if it can be replaced with something > more actively maintained. Peter fixed it in https://tracker.debian.org/news/1562797/accepted-rust-merge-010-2-source-into-unstable/ (thanks!), so the situation is definitely less bad than it was for Debian; though the apparent lack of upstream maintenance might still be a problem at some point. Cheers, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080168: Patch,
On Mon, Sep 09, 2024 at 01:30:08PM -0600, Charles Laws wrote:
>Admittedly I am a novice at coding, but I believe I have found the issue.
>Adjusting the following appears to allow debmirror to download the
>contents files from proposed-updates.
>--- debmirror 2024-09-09 13:13:06.335485914 -0600
>+++ debmirror.revised 2024-09-09 13:15:21.742485255 -0600
>@@ -3301,7 +3301,7 @@
> my($routine, $routine_args, $operational_params) = @_;
> my @sects = ((map {"/$_"} @sections), "");
> foreach my $dist (keys %distset) {
>- next if $dist=~/\bexperimental\b|-proposed-updates\b/o;
>+ next if $dist=~/\bexperimental\bproposed-updates\b/o;
You're right that this is the cause of the problem, but this isn't quite
the right fix: it excludes --dist items that match a regular expression
defined as "experimental with word boundaries around it, immediately
followed by proposed-updates with word boundaries around it" - it's
literally impossible for this regular expression ever to match any
string, so this can't be what we should do.
When faced with this sort of problem, it's usually best to look back
through history to find out what the offending code was doing in the
first place. Unfortunately doing that exercise here leads us back to a
period where our version control history wasn't very detailed (because
the history was imported from a time before debmirror was
version-controlled at all, I think), but the commit in question is:
https://salsa.debian.org/debian/debmirror/-/commit/10a29dcd2995d6b8a2def028eb46dc49d442d08e
And looking in debian/changelog, there's this entry under 20040926:
* Skip Contents files for *-proposed-updates and experimental
So I think the chances are that -proposed-updates didn't have Contents
files back then. https://archive.debian.org/debian/dists/ doesn't have
complete records here, but they appear to have been added some time
between squeeze (Debian 6.0) and stretch (Debian 9).
However, nowadays debmirror skips files if they don't exist, without
having to explicitly exclude them from consideration up-front. So the
right fix is just to remove this line entirely, and I'll do that.
Thanks for the investigation!
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081014: Should python3-zipp be dropped in trixie?
Control: severity -1 normal
Control: tags -1 wontfix
On Fri, Sep 06, 2024 at 11:39:44PM +0300, Adrian Bunk wrote:
> Looking at CVE-2024-5569 and the potential of future CVEs,
> I wonder whether there is any reason why reverse dependencies
> still need this package or whether they could use the version
> vendored in src:python3.*
>
> If there is a reason, feel free to lower the severity but
> keep the bug open as wontfix to document it (or close the
> bug with a package description update).
I spent some time looking through this today. TL;DR: it might be
_possible_ to avoid it in many cases, but that will get easier as older
versions of Python fall out of upstream support and I'm not convinced
it's worth the effort to accelerate that. However, it's also not clear
that the use of this package will naturally fall to zero over time in
upstream packages due to rolling addition of features. I don't think
it's viable to completely eliminate this package.
$ reverse-depends -b src:python-zipp
Reverse-Testsuite-Triggers
==
* python-mercantile (for python3-zipp)
Reverse-Build-Depends
=
* cpplint (for python3-zipp)
* importlib-resources (for python3-zipp)
* python-importlib-metadata (for python3-zipp)
Reverse-Build-Depends-Indep
===
* python-mercantile (for python3-zipp)
$ reverse-depends src:python-zipp
Reverse-Depends
===
* python3-catalogue [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64
s390x]
* python3-evtx (for python3-zipp)
* python3-importlib-metadata(for python3-zipp)
* python3-importlib-resources (for python3-zipp)
* python3-mercantile(for python3-zipp)
* python3-setuptools(for python3-zipp)
Going through each of these:
* cpplint
Might be easy to remove; it's in test-requirements, but it's hard to
see why.
* importlib-resources
I removed its explicit run-time Depends, although pybuild still adds
a dependency on "python3-zipp | python3-supported-min (>= 3.10)" to
match the upstream requirements.
There's still a Build-Depends, because the test suite explicitly uses
zipp.CompleteDirs which is not public API in zipfile.
* python-catalogue
Actually just "python3-zipp | python3-supported-min (>= 3.8)", so
should go away once dh-python >= 6.20240825 is released and it's
rebuild with that since that suppresses dependencies that would be
satisfied by python3 >= 3.9.
* python-evtx
Might be easy to remove; it's in setup.py, but it's hard to see why.
* python-importlib-metadata
Would require patching, since it explicitly uses zipp without a
zipfile alternative.
* python-mercantile
Would require patching.
* setuptools
I think this has a dependency because it vendors importlib_metadata.
The big deal here will be
https://salsa.debian.org/python-team/tools/dh-python/-/commit/4baa3c5714cebe0ffd457939ec4e7048462c650b;
that should make a lot of the dependencies on
python3-importlib-{metadata,resources} go away, and then this will be a
lot easier. But there'd still be lots of stragglers.
More broadly, https://pypi.org/project/zipp/ indicates that this package
isn't just a static backport, but can provide new features to older
versions of Python ahead of the version in the standard library. This
suggests to me that it may not be the sort of thing that ever completely
goes away; if a package needs something from (say) zipp 3.18 today then
it won't get that until Python 3.13 is the default, so upstreams may
continue adding dependencies on it. For example,
https://github.com/python/importlib_metadata/commit/56b61b3dd90df2dba2da445a8386029b54fdebf3
recently added a dependency on zipp>=3.20. The same sort of thing is
true for importlib_resources and importlib_metadata, which each have
their own compatibility tables with the standard library.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1081205: node-ipydatagrid: diff for NMU version 1.3.2+~cs14.21.116-1.1
Package: node-ipydatagrid Version: 1.3.2+~cs14.21.116-1 Severity: normal Tags: patch pending Dear maintainer, node-ipydatagrid's testing migration has been stuck for a while because of the need for a source-only upload. I've prepared a corresponding NMU for node-ipydatagrid (versioned as 1.3.2+~cs14.21.116-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards, -- Colin Watson (he/him) [cjwat...@debian.org] diff -Nru node-ipydatagrid-1.3.2+~cs14.21.116/debian/changelog node-ipydatagrid-1.3.2+~cs14.21.116/debian/changelog --- node-ipydatagrid-1.3.2+~cs14.21.116/debian/changelog 2024-08-27 17:30:54.0 +0100 +++ node-ipydatagrid-1.3.2+~cs14.21.116/debian/changelog 2024-09-09 11:35:48.0 +0100 @@ -1,3 +1,10 @@ +node-ipydatagrid (1.3.2+~cs14.21.116-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Source-only reupload to allow migration to testing. + + -- Colin Watson Mon, 09 Sep 2024 11:35:48 +0100 + node-ipydatagrid (1.3.2+~cs14.21.116-1) unstable; urgency=medium * Add myself to Uploaders.
Bug#1080278: python-autopage: diff for NMU version 0.4.0-3.1
On Mon, Sep 09, 2024 at 11:15:58AM +0100, Colin Watson wrote: > I've prepared an NMU for python-autopage (versioned as 0.4.0-3.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I should delay > it longer. This is also https://salsa.debian.org/openstack-team/python/python-autopage/-/merge_requests/1 for your convenience. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080278: python-autopage: diff for NMU version 0.4.0-3.1
Control: tags 1080278 + patch Control: tags 1080278 + pending Dear maintainer, I've prepared an NMU for python-autopage (versioned as 0.4.0-3.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards, -- Colin Watson (he/him) [cjwat...@debian.org] diff -Nru python-autopage-0.4.0/debian/changelog python-autopage-0.4.0/debian/changelog --- python-autopage-0.4.0/debian/changelog 2021-11-24 21:19:42.0 + +++ python-autopage-0.4.0/debian/changelog 2024-09-09 11:14:02.0 +0100 @@ -1,3 +1,10 @@ +python-autopage (0.4.0-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Call unittest directly rather than "setup.py test" (closes: #1080278). + + -- Colin Watson Mon, 09 Sep 2024 11:14:02 +0100 + python-autopage (0.4.0-3) unstable; urgency=medium * Add unit test at build time (Closes: #1000525). diff -Nru python-autopage-0.4.0/debian/rules python-autopage-0.4.0/debian/rules --- python-autopage-0.4.0/debian/rules 2021-11-24 21:19:42.0 + +++ python-autopage-0.4.0/debian/rules 2024-09-09 11:10:49.0 +0100 @@ -21,7 +21,7 @@ ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) echo "No tests for now..." set -e ; for pyvers in $(PYTHON3S); do \ - python$$pyvers setup.py test ; \ + python$$pyvers -m unittest discover -v ; \ done endif
Bug#1081148: flask-appbuilder: Remove from Debian?
Source: flask-appbuilder Version: 4.1.4+ds-3 Severity: normal flask-appbuilder has three open RC bugs and four open CVEs in Debian. It hasn't been possible to build it in unstable since December 2022, because it's incompatible with flask-sqlalchemy 3 (https://github.com/dpgaspar/Flask-AppBuilder/issues/2038), and the latest upstream release is no help here. There doesn't seem to have been much upstream movement on this for quite a while, despite recent releases making other changes. It has no reverse-dependencies. Should we just remove it from Debian? It can always be reintroduced later if need be. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077434: unittest2: FTBFS: TypeError: expected string or bytes-like object, got 'late_version'
On Thu, Aug 08, 2024 at 12:57:00AM +0200, Alexandre Detiste wrote: > python-funcsigs is the only reverse dependency that will need > a tiny & trivial patch. Don't waste time keeping this package alive. There are a few more than that: $ 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
On Tue, Sep 03, 2024 at 12:43:43AM +0100, Colin Watson wrote: > Do you want to review any of this, or shall I just go ahead and upload, > maybe after dropping transitional packages per the four open bugs about > that? I've gone ahead and uploaded this now. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080234: serpent: diff for NMU version 1.41-1.1
On Sun, Sep 08, 2024 at 08:32:44AM +0200, László Böszörményi (GCS) wrote: > On Sun, Sep 8, 2024 at 12:42 AM Colin Watson wrote: > > I've prepared an NMU for serpent (versioned as 1.41-1.1) and uploaded it > > to DELAYED/2. Please feel free to tell me if I should delay it longer. > Your changes are correct. You may cancel the NMU, I'm just going to > upload the update as is - crediting you of course. Cancelled, thanks! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080234: serpent: diff for NMU version 1.41-1.1
Control: tags 1080234 + patch
Control: tags 1080234 + pending
Dear maintainer,
I've prepared an NMU for serpent (versioned as 1.41-1.1) and uploaded it
to DELAYED/2. Please feel free to tell me if I should delay it longer.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru serpent-1.41/debian/changelog serpent-1.41/debian/changelog
--- serpent-1.41/debian/changelog 2022-07-18 15:03:02.0 +0100
+++ serpent-1.41/debian/changelog 2024-09-07 23:36:40.0 +0100
@@ -1,3 +1,10 @@
+serpent (1.41-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix tests following the removal of "setup.py test" (closes: #1080234).
+
+ -- Colin Watson Sat, 07 Sep 2024 23:36:40 +0100
+
serpent (1.41-1) unstable; urgency=medium
* New upstream release.
diff -Nru serpent-1.41/debian/rules serpent-1.41/debian/rules
--- serpent-1.41/debian/rules 2021-10-25 05:38:46.0 +0100
+++ serpent-1.41/debian/rules 2024-09-07 23:33:32.0 +0100
@@ -5,11 +5,8 @@
export DH_VERBOSE=1
export PYBUILD_NAME = serpent
-
-override_dh_auto_test:
- $(MAKE) test
+export PYBUILD_TEST_CUSTOM = 1
+export PYBUILD_TEST_ARGS = {interpreter} -m unittest discover -v tests
%:
dh $@ --with python3 --buildsystem=pybuild
-
-.PHONY: override_dh_auto_test
Bug#1079751: setuptools test command is removed
Control: retitle -1 FTBFS: tests/test_functional.py::test_functional[recursion_error_3152] - AssertionError: Wrong message(s) raised for "recursion_error_3152.py" On Tue, Aug 27, 2024 at 09:04:42AM +0200, Matthias Klose wrote: > setuptools test command is removed, the package at least uses this command > in it's autopkg tests. It doesn't - it fails for a different reason. https://ci.debian.net/packages/p/pylint/testing/amd64/51301728/ === FAILURES === test_functional[recursion_error_3152] _ self = def runTest(self) -> None: > self._runTest() E AssertionError: Wrong message(s) raised for "recursion_error_3152.py": E E Unexpected in testdata: E 6: abstract-method E E Actual pylint output for this file: E OutputLine(symbol='abstract-method', lineno=6, column=0, end_lineno=6, end_column=12, object='Custom', msg="Method 'finalize_options' is abstract in class 'Command' but is not overridden in child class 'Custom'", confidence='INFERENCE') E OutputLine(symbol='abstract-method', lineno=6, column=0, end_lineno=6, end_column=12, object='Custom', msg="Method 'initialize_options' is abstract in class 'Command' but is not overridden in child class 'Custom'", confidence='INFERENCE') E OutputLine(symbol='abstract-method', lineno=6, column=0, end_lineno=6, end_column=12, object='Custom', msg="Method 'run' is abstract in class 'Command' but is not overridden in child class 'Custom'", confidence='INFERENCE') /usr/lib/python3/dist-packages/pylint/testutils/lint_module_test.py:147: AssertionError 3.2.7 fixes this; I'll upgrade. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080480: rust-merge: most autopkgtests fail
On Wed, Sep 04, 2024 at 08:04:21PM +0100, Colin Watson wrote: > https://ci.debian.net/packages/r/rust-merge/testing/amd64/ appears to > have always failed; it looks as though rust-merge:@ and > librust-merge-dev:default succeed but everything else fails. > > librust-merge-dev:derive fails with: > > error[E0433]: failed to resolve: could not find `vec` in `merge` > --> examples/user.rs:11:31 > | > 11 | #[merge(strategy = merge::vec::append)] > | ^^^ could not find `vec` in `merge` > | > note: found an item that was configured out > --> /usr/share/cargo/registry/merge-0.1.0/src/lib.rs:205:9 > = note: the item is gated behind the `std` feature > > For more information about this error, try `rustc --explain E0433`. > error: could not compile `merge` (example "user" test) due to 1 previous > error > > librust-merge-dev:merge_derive, librust-merge-dev:num, > librust-merge-dev:num-traits, librust-merge-dev:std, and > librust-merge-dev: fail with a bunch of errors starting with: > > error: cannot find derive macro `Merge` in this scope >--> examples/user.rs:6:10 > | > 6 | #[derive(Merge)] > | ^ > | > note: `Merge` is imported here, but it is only a trait, without a derive > macro >--> examples/user.rs:4:5 > | > 4 | use merge::Merge; > | > help: consider importing this derive macro > > There've been no upstream commits since 2020-09-21, only one upstream > release ever which was on 2020-09-01, and there are no > reverse-dependencies. Should we just remove it? Also CCing the people who were involved in the original packaging in 2022 in case they have a view on this. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080480: rust-merge: most autopkgtests fail
Source: rust-merge Version: 0.1.0-1 Severity: serious Justification: https://release.debian.org/testing/rc_policy.txt 6(a) https://ci.debian.net/packages/r/rust-merge/testing/amd64/ appears to have always failed; it looks as though rust-merge:@ and librust-merge-dev:default succeed but everything else fails. librust-merge-dev:derive fails with: error[E0433]: failed to resolve: could not find `vec` in `merge` --> examples/user.rs:11:31 | 11 | #[merge(strategy = merge::vec::append)] | ^^^ could not find `vec` in `merge` | note: found an item that was configured out --> /usr/share/cargo/registry/merge-0.1.0/src/lib.rs:205:9 = note: the item is gated behind the `std` feature For more information about this error, try `rustc --explain E0433`. error: could not compile `merge` (example "user" test) due to 1 previous error librust-merge-dev:merge_derive, librust-merge-dev:num, librust-merge-dev:num-traits, librust-merge-dev:std, and librust-merge-dev: fail with a bunch of errors starting with: error: cannot find derive macro `Merge` in this scope --> examples/user.rs:6:10 | 6 | #[derive(Merge)] | ^ | note: `Merge` is imported here, but it is only a trait, without a derive macro --> examples/user.rs:4:5 | 4 | use merge::Merge; | help: consider importing this derive macro There've been no upstream commits since 2020-09-21, only one upstream release ever which was on 2020-09-01, and there are no reverse-dependencies. Should we just remove it? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2
On Fri, Mar 29, 2024 at 12:09:31PM -0400, Scott Kitterman wrote: > On Sun, 21 Jan 2024 12:17:53 -0500 Scott Kitterman > wrote: > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in > > response to an RFA for both packages. As these are somewhat security > > sensitive packages (among my first acts after adopting the packages was to > > upload proposed updates for both to address minor security issues in > > Bookworm > > in the next point release - same bug in both), I do not think we should > > release pypdf2 in Trixie and have filed an RC bug to that effect. > > > > If you want this package to be in Trixie, you will need to use pypdf > > instead > > of pypdf2. > > Now that pypdf2 is removed from Trixie, updating to serious. I had a brief look at this and noticed that this package was previously ported to pypdf, but that the port was reverted in https://salsa.debian.org/freexian-team/packages/odoo/-/commit/d68da30bd5746f41e33c19ba5c2b8bc0f100e4d6. CCing Sébastien - was there a problem with the port? (Maybe https://bugs.debian.org/1032300? But that was closed six months before the commit above ...) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073992: debconf: failure between unpack and configure dpkg runs via apt
On Wed, Aug 28, 2024 at 12:56:32AM +0200, Guillem Jover wrote: > On Fri, 2024-06-21 at 10:53:20 +0300, Martin-Éric Racine wrote: > > Unpacking pci.ids (0.0~2024.05.31-1) over (0.0~2024.04.20-1) ... > > debconf: Unable to load Debconf::Element::Dialog. Failed because: Can't > > locate Debconf/Element/Dialog.pm in @INC (you may need to install the > > Debconf::Element::Dialog module) (@INC entries checked: /etc/perl > > /usr/local/lib/i386-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 > > /usr/lib/i386-linux-gnu/perl5/5.38 /usr/share/perl5 > > /usr/lib/i386-linux-gnu/perl-base /usr/lib/i386-linux-gnu/perl/5.38 > > /usr/share/perl/5.38 /usr/local/lib/site_perl) at (eval 19) line 1, > > line 3. > > BEGIN failed--compilation aborted at (eval 19) line 1, line 3. > > > > Can't locate object method "new" via package "Debconf::Element::Dialog" > > (perhaps you forgot to load "Debconf::Element::Dialog"?) at > > /usr/share/perl5/Debconf/FrontEnd.pm line 69, line 3. > > Setting up pci.ids (0.0~2024.05.31-1) ... > > As mentioned on the report, this is not an issue with pci.ids, but > with something (apt) calling debconf (perhaps indirectly) between the > unpack and configure runs. I'd assume an apt hook is causing this. I'm > reassigning this to debconf as the actual thing apparently failing, but > if the actual hook (or caller) can be tracked down then perhaps that > can be reassigned there. (Sorry for passing along this hot potato. :) > > (The BTS contains mails with several log files, and some analysis.) Martin-Éric, could you provide the output of "ls /etc/apt/apt.conf.d/" and "grep -E 'debconf|dpkg-' /etc/apt/apt.conf.d/*"? That would probably speed up the search here. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073481: pydantic-core: FTBFS: make[1]: *** [debian/rules:15: execute_before_dh_auto_build] Error 101
On Tue, Sep 03, 2024 at 07:33:00AM +0100, Julian Gilbey wrote: > This is great, thanks! There's quite a lot of stuff in Rust that's > currently not migrating, though, some of it due to riscv64 being slow > or things breaking on that arch. Yeah, I've been keeping an eye on my DDPO page and occasionally retrying stuff. It doesn't look too bad, though obviously it'd be easier if riscv64 didn't time out half the time. > I'll try to grab some time later in the week to help with the effort! Thanks! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073001: fixed upstream
On Mon, Sep 02, 2024 at 07:15:44PM +0200, Alexandre Detiste wrote: > 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. Thanks. I figured out a workable set of upstream patches to backport on top of 4.0.2 (it was rather more than the one patch above - it ended up being an 11-patch sequence for SQLAlchemy 2.0) and pushed that: https://salsa.debian.org/python-team/packages/buildbot/-/commit/85a3a35f865359c1f4c490e845469380202e7cfb Yes, one of the patches mostly reverts one of the others. But it was easier to keep track of things if I minimized how much editing I needed to do of the upstream patches. Do you want to review any of this, or shall I just go ahead and upload, maybe after dropping transitional packages per the four open bugs about that? Cheers, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073001: fixed upstream
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. I was going to try to work on this bug, but I found that `gbp pq import` in the current repository doesn't work: $ gbp pq import gbp:info: Trying to apply patches at '167d745605609dd91521749db28ad396a1099eaa' gbp:warning: Patch 'remove-future' has no authorship information, using 'Debian Python Team ' gbp:warning: Patch remove-future failed to apply, retrying with whitespace fixup gbp:error: Failed to apply '/home/cjwatson/src/debian/python-modules/python-modules/buildbot/debian/patches/remove-future': Error running git apply: error: patch failed: worker/buildbot_worker/pbutil.py:154 error: worker/buildbot_worker/pbutil.py: patch does not apply error: patch failed: worker/buildbot_worker/runprocess.py:345 error: worker/buildbot_worker/runprocess.py: patch does not apply gbp:error: Couldn't apply patches 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 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.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1056435: Patch added
On Fri, Jun 07, 2024 at 06:12:31PM +0100, Jelmer Vernooij wrote: > I've patched the git repo to mark python 3.12 as supported. > > However, there are several test failures with python 3.12 that need to be > fixed: > > == > ERROR: test_query_float (pony.orm.tests.test_json.TestJson.test_query_float) > -- > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun > return caller(func, *(extras + args), **kw) > > File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line > 519, in new_func > result = func(*args, **kwargs) > ^ > File > "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", > line 91, in test_query_float > self.assertAlmostEqual(val, 9.7) > File "/usr/lib/python3.11/unittest/case.py", line 904, in assertAlmostEqual > diff = abs(first - second) >~~^~~~ > TypeError: unsupported operand type(s) for -: 'NoneType' and 'float' This looks like https://github.com/ponyorm/pony/issues/704. Does the latest upstream release (0.7.19) fare any better? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079345: src:pydantic: fails to migrate to testing for too long: Build-Depends on pydantic-core
On Thu, Aug 22, 2024 at 04:09:07PM +0200, Paul Gevers wrote: > The Release Team considers packages that are out-of-sync between testing and > unstable for more than 30 days as having a Release Critical bug in testing > [1]. Your package src:pydantic has been trying to migrate for 33 days [2]. > Hence, I am filing this bug. The version in unstable Build-Depends on > pydantic-core which isn't in testing and can't migrate due to an RC bug. I've been making progress on this, as documented in #1073481. It's currently blocked on NEW processing of rust-jiter, but after that I should be able to upload all the remaining pieces. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073481: pydantic-core: FTBFS: make[1]: *** [debian/rules:15: execute_before_dh_auto_build] Error 101
Control: owner 1073481 ! On Sun, Sep 01, 2024 at 06:11:12PM +0100, Julian Gilbey wrote: > On Sun, Sep 01, 2024 at 04:31:58PM +0100, Colin Watson wrote: > > On Tue, Aug 20, 2024 at 06:00:16PM +0100, Julian Gilbey wrote: > > > I wonder whether you could take a look at this at some point? I took > > > a quick look at the newer pydantic-core (2.22.0), but there's some bad > > > news here: there are quite a few Rust packages that need updating > > > first, and one that needs an ITP too (assuming I've understood > > > Cargo.toml correctly; I've done this by hand as "cargo debstatus" > > > can't yet cope with the 2021 edition). Here's my annotated version of > > > the relevant sections (I think) of Cargo.toml: > > > > I've started on this, although I had to learn how debcargo worked first > > and as you note one of the packages will need a trip through NEW. Give > > me a little while ... > > Great! I've done the first two already (strum and serde_json). I've uploaded new versions of: rust-datetime rust-enum-dispatch rust-iso8601 rust-num-bigint rust-python3-dll-a rust-smallvec rust-speedate rust-version-check ... and also uploaded rust-jiter to NEW. With all of that and a bit of Cargo.toml patching, pydantic-core now builds for me locally. It also needs a new pydantic, which forces the choice of pydantic-core version: the latest stable release 2.8.2 requires exactly pydantic-core 2.20.1 and breaks with newer versions (well, at least it breaks with 2.23.1 - I didn't try the versions in between). That makes it easier: with the uploads above I now only have to patch Cargo.toml for an older idna, and pydantic 2.8.2 works fairly easily. I'll upload all this once rust-jiter has passed NEW. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073481: pydantic-core: FTBFS: make[1]: *** [debian/rules:15: execute_before_dh_auto_build] Error 101
On Tue, Aug 20, 2024 at 06:00:16PM +0100, Julian Gilbey wrote: > I wonder whether you could take a look at this at some point? I took > a quick look at the newer pydantic-core (2.22.0), but there's some bad > news here: there are quite a few Rust packages that need updating > first, and one that needs an ITP too (assuming I've understood > Cargo.toml correctly; I've done this by hand as "cargo debstatus" > can't yet cope with the 2021 edition). Here's my annotated version of > the relevant sections (I think) of Cargo.toml: I've started on this, although I had to learn how debcargo worked first and as you note one of the packages will need a trip through NEW. Give me a little while ... -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1080168: debmirror: Debmirror does not download or generate contents files for bookworm-proposed-updates, even with --getcontents
On Fri, Aug 30, 2024 at 04:55:52PM -0600, charles wrote: > Added proposed updates to my mirror setup, which completed with out errors. > However apt complains about missing contents files for bookworm-proposed- > updates. Could you please send to this bug your debmirror configuration file (if any) and the full debmirror command line you're using? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079719: python-ipywidgets-doc: uninstallable; depends on unpackaged node-jupyter-widgets-html-manager
On Tue, Aug 27, 2024 at 05:49:43PM +0200, Roland Mas wrote: > Le 26/08/2024 à 20:42, Colin Watson a écrit : > > ipywidgets has been stuck in unstable for a while because […] > > > > Roland, what was the plan here? Do you still have some work in progress > > lying around somewhere that could be polished up and pushed into > > unstable, or should we do something else instead? > > ipywidgets has been sort of stuck waiting for the jupyterlab situation to > stabilize. Thanks to Yadd, jupyterlab is now in a better shape, and I'm > resuming work on ipywidgets and related packages. Thanks to both of you for chasing this up! Just a brief note that node-ipydatagrid will need a source-only upload in order to be able to migrate to testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073530: man.1: table for "-7, --ascii"; (nroff) do not break lines in the first column
On Tue, Jun 18, 2024 at 12:47:09AM +, Bjarni Ingi Gislason wrote: > The table was just changed from having the first column too narrow to being > too > wide. > > What is wrong with using: > > "1) use ".nf" before table, and ".fi" after it" Well, I was trying to avoid it, because this is fine when you're only considering the English text, but regrettably the lengths of translated strings are not usually the same as the original, and in some cases can be substantially longer. This is also why I try to avoid hacks such as calculating the widths of particular strings. I apparently added the text blocks here in 2011, and I don't appear to have written down exactly what the problem I was dealing with was. In some other similar cases I know that it was a problem with some translated pages having overly-wide tables (as can be seen in https://gitlab.com/man-db/man-db/-/commit/6124c25e87). I suspect that I might just have been trying to make the handling of translatable text be the same across all tables in man-db's own manual pages. (The .na and .ad were your additions in https://bugs.debian.org/726266, but it seems that you didn't provide an explanation and I didn't ask for one.) Fundamentally, this is the old problem that text blocks in tbl are formatted in a diversion whose width is calculated in advance, and in the general case there's no very good way for manual page authors to handle this. However, despite all the above: in the intervening 13 years, no translations seem to have arisen that use long enough translations for these strings to cause the table to overflow 80 columns. I believe German comes closest by translating "bullet (middle dot)" to "Aufzählungszeichen (middle dot)", and it still fits. It's therefore probably fine to abandon the idea of text blocks in this particular case, and then neither .nf/.fi nor .na/.ad is needed to get reasonable formatting. I've simplified all this in https://gitlab.com/man-db/man-db/-/commit/8c0076fa743fa015dbe2ea085eeddf78bde740c0, and I think the formatting is now as good as I can get it. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079719: python-ipywidgets-doc: uninstallable; depends on unpackaged node-jupyter-widgets-html-manager
Package: python-ipywidgets-doc Version: 8.1.3-1 Severity: grave Justification: renders package unusable ipywidgets has been stuck in unstable for a while because python-ipywidgets-doc depends on node-jupyter-widgets-html-manager, which doesn't exist. This dependency seems to have been introduced in https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/7cd6bc7ac967ef4ab21ef37f20278213b607f9b1, so presumably it was work in progress at some point, but I can't see it anywhere. Roland, what was the plan here? Do you still have some work in progress lying around somewhere that could be polished up and pushed into unstable, or should we do something else instead? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.10.4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-ipywidgets-doc depends on: pn libjs-mathjax pn libjs-requirejs pn node-jupyter-widgets-html-manager python-ipywidgets-doc recommends no packages. python-ipywidgets-doc suggests no packages. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079697: ruby3.1: diff for NMU version 3.1.2-8.4
Package: ruby3.1
Version: 3.1.2-8.3
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for ruby3.1 (versioned as 3.1.2-8.4) and uploaded
it to DELAYED/2. Please feel free to tell me if I should delay it
longer.
I'm aware that this doesn't fix the pile of CVEs open against ruby3.1.
My motivation here is just to unblock openssh from migrating to testing;
it's currently blocked on openssl, which in turn is blocked on ruby3.1
autopkgtest failures.
For your convenience, I opened
https://salsa.debian.org/ruby-team/ruby/-/merge_requests/8 which is
equivalent to the attached diff here but broken down into separate
commits.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru ruby3.1-3.1.2/debian/changelog ruby3.1-3.1.2/debian/changelog
--- ruby3.1-3.1.2/debian/changelog 2024-03-17 17:06:13.0 +
+++ ruby3.1-3.1.2/debian/changelog 2024-08-26 14:00:57.0 +0100
@@ -1,3 +1,11 @@
+ruby3.1 (3.1.2-8.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix test failures with OpenSSL 3.3 (closes: #1075922).
+ * Deduplicate results from getaddrinfo (closes: #1069399).
+
+ -- Colin Watson Mon, 26 Aug 2024 14:00:57 +0100
+
ruby3.1 (3.1.2-8.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru ruby3.1-3.1.2/debian/patches/deduplicate-getaddrinfo.patch ruby3.1-3.1.2/debian/patches/deduplicate-getaddrinfo.patch
--- ruby3.1-3.1.2/debian/patches/deduplicate-getaddrinfo.patch 1970-01-01 01:00:00.0 +0100
+++ ruby3.1-3.1.2/debian/patches/deduplicate-getaddrinfo.patch 2024-08-26 01:35:23.0 +0100
@@ -0,0 +1,51 @@
+From: Colin Watson
+Date: Mon, 26 Aug 2024 01:35:10 +0100
+Subject: Deduplicate results from getaddrinfo
+
+In certain configurations it's possible to get duplicate results back
+from getaddrinfo: for example, if you accidentally have more than one
+line in /etc/hosts mapping the same name to the same IP address, then
+Linux/glibc systems will return multiple identical entries. This minor
+misconfiguration is normally harmless, but it caused this program to
+fail with `EADDRINUSE`:
+
+require 'socket'
+Socket.tcp_server_sockets('localhost', 0)
+
+Prior to https://github.com/ruby/net-http/pull/180, this caused a number
+of `TestNetHTTP*` tests to fail, as seen in these Debian bugs:
+
+ https://bugs.debian.org/1069399 (Ruby 3.1)
+ https://bugs.debian.org/1064685 (Ruby 3.2)
+ https://bugs.debian.org/1077462 (Ruby 3.3)
+
+It's easy enough to deduplicate these.
+
+Bug-Debian: https://bugs.debian.org/1069399
+Forwarded: https://github.com/ruby/ruby/pull/11456
+Last-Update: 2024-08-26
+---
+ ext/socket/lib/socket.rb | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/ext/socket/lib/socket.rb b/ext/socket/lib/socket.rb
+index d756a32..19684b3 100644
+--- a/ext/socket/lib/socket.rb
b/ext/socket/lib/socket.rb
+@@ -668,10 +668,16 @@ class Socket < BasicSocket
+ # :stopdoc:
+ def self.ip_sockets_port0(ai_list, reuseaddr)
+ sockets = []
++ai_seen = {}
+ begin
+ sockets.clear
+ port = nil
+ ai_list.each {|ai|
++ai_id = [ai.pfamily, ai.socktype, ai.protocol, ai.ip_address]
++if ai_seen.include?(ai_id)
++ next
++end
++ai_seen[ai_id] = nil
+ begin
+ s = Socket.new(ai.pfamily, ai.socktype, ai.protocol)
+ rescue SystemCallError
diff -Nru ruby3.1-3.1.2/debian/patches/openssl-3.3.patch ruby3.1-3.1.2/debian/patches/openssl-3.3.patch
--- ruby3.1-3.1.2/debian/patches/openssl-3.3.patch 1970-01-01 01:00:00.0 +0100
+++ ruby3.1-3.1.2/debian/patches/openssl-3.3.patch 2024-08-26 01:35:23.0 +0100
@@ -0,0 +1,65 @@
+From: Jun Aruga
+Date: Tue, 12 Mar 2024 14:39:05 +0100
+Subject: test_asn1.rb: Remove the assertions of the time string format
+ without second.
+
+This commit fixes the following errors in the tests.
+Because the OpenSSL project changed the code to make the time string format
+without second invalid. So, we drop the assertions.
+
+```
+1) Error: test_generalizedtime(OpenSSL::TestASN1): OpenSSL::ASN1::ASN1Error: generalizedtime is too short
+/home/runner/work/ruby-openssl/ruby-openssl/test/openssl/test_asn1.rb:698:in `decode'
+/home/runner/work/ruby-openssl/ruby-openssl/test/openssl/test_asn1.rb:698:in `decode_test'
+/home/runner/work/ruby-openssl/ruby-openssl/test/openssl/test_asn1.rb:433:in `test_generalizedtime'
+ 430: OpenSSL::ASN1::GeneralizedTime.new(Time.utc(, 9, 8, 23, 43, 39))
+ 431: # LibreSSL 3.6.0 requires the seconds element
+ 432: return if libressl?
+ => 433: decode_test B(%w{ 18 0D }) + "201612081934Z".b,
+ 434: OpenSSL::ASN1::GeneralizedTime.new(Time.utc(2016, 12, 8, 19, 34, 0))
+ 435: # not implemented
+ 436: # decode_test B(%w{ 18 13 }) + "20161208193439+0930".b,
+
+2) Error: test_utctime(OpenSSL::Tes
Bug#1069399: ruby3.1: FTBFS on arm64: Errno::EADDRINUSE: Address already in use - listen(2)
Control: forwarded 1069399 https://github.com/ruby/ruby/pull/11456 Control: forwarded 1064685 https://github.com/ruby/ruby/pull/11456 Control: forwarded 1077462 https://github.com/ruby/ruby/pull/11456 On Sat, Apr 20, 2024 at 02:12:50PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on arm64. > > > Relevant part (hopefully): > > 13) Error: > > TestNetHTTPS#test_verify_none: > > Errno::EADDRINUSE: Address already in use - listen(2) > > /<>/.ext/common/socket.rb:710:in `listen' > > /<>/.ext/common/socket.rb:710:in `block in > > tcp_server_sockets_port0' > > /<>/.ext/common/socket.rb:709:in `each' > > /<>/.ext/common/socket.rb:709:in `tcp_server_sockets_port0' > > /<>/.ext/common/socket.rb:758:in `tcp_server_sockets' > > /<>/tool/lib/webrick/utils.rb:60:in `create_listeners' > > /<>/tool/lib/webrick/ssl.rb:165:in `listen' > > /<>/tool/lib/webrick/server.rb:111:in `initialize' > > /<>/tool/lib/webrick/httpserver.rb:47:in `initialize' > > /<>/test/net/http/utils.rb:67:in `new' > > /<>/test/net/http/utils.rb:67:in `spawn_server' > > /<>/test/net/http/utils.rb:32:in `setup' This isn't arm64-specific. It happens when /etc/hosts has multiple entries mapping localhost to the same IP address, which is the case in my sbuild environments and apparently also yours. $ cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 [...] 127.0.0.1 localhost ip6-localhost ip6-loopback I haven't tracked down what made it this way. It ought to be harmless, but it causes a few things to break that loop over getaddrinfo output and listen to all the addresses they find there; https://bugs.debian.org/1052788 (python-asyncssh) is essentially the same thing, as are https://bugs.debian.org/1064685 (ruby3.2) and https://bugs.debian.org/1077462 (ruby3.3). I sent https://github.com/ruby/ruby/pull/11456 to upstream Ruby for this. I suggest applying it to the various Ruby versions in Debian. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1067287: sen: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
urwid.widget.monitored_list
if ismodule(module) and hasattr(module, '__file__'):
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:1008: DeprecationWarning:
urwid.monitored_list is moved to urwid.widget.monitored_list
f = module.__file__
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:914: DeprecationWarning:
urwid.monitored_list is moved to urwid.widget.monitored_list
if getattr(object, '__file__', None):
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:915: DeprecationWarning:
urwid.monitored_list is moved to urwid.widget.monitored_list
return object.__file__
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:1007: DeprecationWarning: urwid.treetools is
moved to urwid.widget.treetools
if ismodule(module) and hasattr(module, '__file__'):
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:1008: DeprecationWarning: urwid.treetools is
moved to urwid.widget.treetools
f = module.__file__
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:914: DeprecationWarning: urwid.treetools is
moved to urwid.widget.treetools
if getattr(object, '__file__', None):
.pybuild/cpython3_3.12/build/tests/test_container_info.py::test_short_id
/usr/lib/python3.12/inspect.py:915: DeprecationWarning: urwid.treetools is
moved to urwid.widget.treetools
return object.__file__
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_assemble_rows_long_text
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_assemble_rows_long_text
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_assemble_rows_long_text
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_assemble_rows_long_text
/<>/.pybuild/cpython3_3.12/build/sen/tui/widgets/list/util.py:73:
PendingDeprecationWarning: only for backwards compatibility. You should use the
new standard container `contents`
for w in self.columns.widget_list:
.pybuild/cpython3_3.12/build/tests/test_widgets.py::test_table_random_data
/<>/.pybuild/cpython3_3.12/build/tests/test_widgets.py:101:
PendingDeprecationWarning: only for backwards compatibility. You should use the
new standard container `contents`
assert
text[0].startswith(rows[0].original_widget.widget_list[0].text.encode("utf-8"))
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info
FAILED tests/test_container_info.py::test_short_id - TypeError:
kwargs_from_e...
FAILED tests/test_docker_backend.py::test_images_call - TypeError:
kwargs_fro...
FAILED tests/test_docker_backend.py::test_containers_call - TypeError:
kwargs...
FAILED tests/test_docker_backend.py::test_short_id - TypeError:
kwargs_from_e...
FAILED tests/test_docker_backend.py::test_stats - TypeError:
kwargs_from_env(...
====== 5 failed, 54 passed, 33 warnings in 2.43s
===
E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.12/build; python3.12 -m pytest tests
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.12
returned exit code 13
This is https://github.com/TomasTomecek/sen/issues/175, fixed upstream.
I'll repurpose this bug for that and cherry-pick that upstream PR.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069218: rocketcea ftbfs with Python 3.12
On Thu, Apr 18, 2024 at 07:37:18AM +0200, Matthias Klose wrote: > Traceback (most recent call last): > File "/<>/setup.py", line 21, in > from numpy.distutils.core import Extension, setup > ModuleNotFoundError: No module named 'numpy.distutils' This seems to have been fixed upstream in version 1.2.0 by migrating the build system to meson. https://github.com/sonofeft/RocketCEA/commit/a3da63fae76aa1490f8f9b16b15ab8d7fd9eac67 I think, but presumably it would be much simpler to just pull the latest upstream release (currently 1.2.1). Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079085: libervia-backend: Tests fail with twisted 24.7.0
{self.target_width},"
f"height={self.target_height},framerate=30/1 "
f"! {local_video_sink_elt}"
)
local_video_sink_elt = "compositor.sink_1"
if video_source_elt:
# Video source with an input-selector to switch between normal and
video mute
# (or desktop sharing).
gst_pipe_elements.append(
f"""
input-selector name=video_selector
! videorate drop-only=1 max-rate=30
! video/x-raw,framerate=30/1
! tee name=t
{video_source_elt} name=video_src
! queue max-size-buffers=1 max-size-time=0 max-size-bytes=0
leaky=downstream
! video_selector.
videotestsrc name=muted_src is-live=true pattern=black
! queue leaky=downstream
! video_selector.
t.
! queue max-size-buffers=1 max-size-time=0 max-size-bytes=0
leaky=downstream
! videoscale
! videoconvert
! vp8enc deadline=1 keyframe-max-dist=30
! rtpvp8pay picture-id-mode=15-bit
! application/x-rtp,media=video,encoding-name=VP8,payload={video_pt}
! sendrecv.
"""
)
if local_video_sink_elt:
# Local video feedback.
gst_pipe_elements.append(
f"""
t.
! queue max-size-buffers=1 max-size-time=0 max-size-bytes=0
leaky=downstream
! videoconvert
! {local_video_sink_elt}
"""
)
if audio_source_elt:
# Audio with a valve for muting.
gst_pipe_elements.append(
f"""
{audio_source_elt} name=audio_src
! valve
! queue max-size-buffers=10 max-size-time=0 max-size-bytes=0
leaky=downstream
! audioconvert
! audioresample
! opusenc audio-type=voice
! rtpopuspay
! application/x-rtp,media=audio,encoding-name=OPUS,payload={audio_pt}
! sendrecv.
"""
)
self.gst_pipe_desc = "\n\n".join(gst_pipe_elements)
log.debug(f"Gstreamer pipeline: {self.gst_pipe_desc}")
# Create the pipeline
try:
self.pipeline = Gst.parse_launch(self.gst_pipe_desc)
except Exception:
log.exception("Can't parse pipeline")
self.pipeline = None
if not self.pipeline:
> raise exceptions.InternalError("Failed to create Gstreamer
> pipeline.")
E libervia.backend.core.exceptions.InternalError: Failed to create
Gstreamer pipeline.
../../build.7LB/src/libervia/frontends/tools/webrtc.py:625: InternalError
-- Captured log call ---
ERRORlibervia.frontends.tools.webrtc:webrtc.py:622 Can't parse pipeline
Traceback (most recent call last):
File
"/tmp/autopkgtest.GVSqs4/build.7LB/src/libervia/frontends/tools/webrtc.py",
line 620, in setup_call
self.pipeline = Gst.parse_launch(self.gst_pipe_desc)
^^^^
gi.repository.GLib.GError: gst_parse_error: no element "webrtcbin" (1)
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1079083: matrix-synapse: Tests fail with twisted 24.7.0
Source: matrix-synapse Version: 1.103.0-5 Severity: serious twisted 24.7.0 in unstable causes matrix-synapse's autopkgtests to fail. See: https://ci.debian.net/packages/m/matrix-synapse/testing/amd64/50733513/ I think cherry-picking https://github.com/element-hq/synapse/pull/17502 will probably fix most of this, although I haven't actually tried it. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.9.12-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#965041: [Pkg-openssl-devel] Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed in openssl
On Wed, Aug 14, 2024 at 07:11:08PM +0100, Colin Watson wrote: > Maybe it's worth you filing an issue on > https://github.com/pyca/cryptography/issues to let cryptography upstream > know about the problem? That way you could explain the change and > discuss whether it makes sense to change cryptography to match the > Debian-specific layout here, or whether it makes sense to change Debian > in some other way. I filed https://github.com/pyca/cryptography/issues/11450. I'd appreciate it if somebody from the Debian OpenSSL team could subscribe to that issue so that I don't need to be a go-between. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1052788: python-asyncssh: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 --system=custom "--test-args={interpreter} -m unittest discover -v" returned exit code 13
Control: forwarded -1 https://github.com/ronf/asyncssh/pull/679
On Tue, Sep 26, 2023 at 02:44:18PM +0200, Lucas Nussbaum wrote:
> > ==
> > ERROR: test_bad_auth_big (tests.test_x11._TestX11.test_bad_auth_big)
> > Test sending bad auth data with big-endian connect
> > --
> > Traceback (most recent call last):
> > File "/usr/lib/python3.11/unittest/mock.py", line 1375, in patched
> > return func(*newargs, **newkeywargs)
> >^
> > File "/<>/tests/util.py", line 81, in async_wrapper
> > return self.loop.run_until_complete(coro(self, *args, **kwargs))
> >^
> > File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in
> > run_until_complete
> > return future.result()
> >^^^
> > File "/<>/tests/test_x11.py", line 414, in test_bad_auth_big
> > await self._check_x11('connect BX', exit_status=0)
> > File "/<>/tests/test_x11.py", line 332, in _check_x11
> > proc = await _create_x11_process(conn, command, **kwargs)
> >^^
> > File "/<>/tests/test_x11.py", line 57, in _create_x11_process
> > return await conn.create_process(command, x11_forwarding=x11_forwarding,
> >^
> > File "/<>/asyncssh/connection.py", line 3980, in
> > create_process
> > chan, process = await self.create_session(
> > ^^
> > File "/<>/asyncssh/connection.py", line 3887, in
> > create_session
> > session = await chan.create(session_factory, command, subsystem,
> > ^^
> > File "/<>/asyncssh/channel.py", line 1183, in create
> > raise ChannelOpenError(
> > asyncssh.misc.ChannelOpenError: X11 forwarding request failed
I saw this in my local tests when working on upgrading to 2.15.0, and
after some debugging I found that it's because my /etc/hosts happened to
have multiple entries mapping localhost to 127.0.0.1, which caused
asyncssh.listener.create_tcp_local_listener to attempt to bind the same
address twice.
I've proposed https://github.com/ronf/asyncssh/pull/679 upstream to fix
this, and will cherry-pick that for the time being since it's pretty
harmless.
(The test failures in Helmut's message to this bug are unrelated:
they're a combination of problems already fixed in the new upstream
release and problems introduced by Debian patches that can now be
dropped.)
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073180: Bug#1073393: python-requests-unixsocket: FTBFS: TimeoutError: [Errno 110] Connection timed out
Control: tag 1073393 patch
On Sun, Jun 16, 2024 at 03:09:49PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
[...]
> > E urllib3.exceptions.URLSchemeUnknown: Not supported URL scheme http+unix
I think a minimal viable approach here would be to cherry-pick
https://github.com/msabramo/requests-unixsocket/pull/72. Would you
consider this?
As well as fixing #1073393, this would allow downgrading #1073180 to
non-RC (though you could still leave it open for future consideration of
switching to that fork).
diff -Nru python-requests-unixsocket-0.3.0/debian/patches/requests-2.32.2.patch
python-requests-unixsocket-0.3.0/debian/patches/requests-2.32.2.patch
--- python-requests-unixsocket-0.3.0/debian/patches/requests-2.32.2.patch
1970-01-01 01:00:00.0 +0100
+++ python-requests-unixsocket-0.3.0/debian/patches/requests-2.32.2.patch
2024-08-16 18:08:17.0 +0100
@@ -0,0 +1,21 @@
+Description: adapters: fix for requests 2.32.2+
+Author: Simon Deziel
+Origin: other, https://github.com/msabramo/requests-unixsocket/pull/72
+Bug-Debian: https://bugs.debian.org/1073393
+Last-Update: 2024-08-16
+
+Index: b/requests_unixsocket/adapters.py
+===
+--- a/requests_unixsocket/adapters.py
b/requests_unixsocket/adapters.py
+@@ -58,6 +58,10 @@
+ pool_connections, dispose_func=lambda p: p.close()
+ )
+
++# Fix for requests 2.32.2+: https://github.com/psf/requests/pull/6710
++def get_connection_with_tls_context(self, request, verify, proxies=None,
cert=None):
++return self.get_connection(request.url, proxies)
++
+ def get_connection(self, url, proxies=None):
+ proxies = proxies or {}
+ proxy = proxies.get(urlparse(url.lower()).scheme)
diff -Nru python-requests-unixsocket-0.3.0/debian/patches/series
python-requests-unixsocket-0.3.0/debian/patches/series
--- python-requests-unixsocket-0.3.0/debian/patches/series 2024-04-29
14:10:08.0 +0100
+++ python-requests-unixsocket-0.3.0/debian/patches/series 2024-08-16
18:07:54.0 +0100
@@ -1,2 +1,3 @@
0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
testutils-fix-test-flake-on-HEAD-request.patch
+requests-2.32.2.patch
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064795: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote: > I think it probably was just a coincidence, since it looks like the > change was made in order to fix #1064795 which was reported on > 25 Feb 2024. Ah, good to know, thanks. I didn't notice that since it wasn't mentioned in the iproute2 changelog. > It just strikes me as obvious that removing any long-standing binary > path in Debian is pretty-much bound to break someone's system, and if > you want to do that you really ought to at least check, and preferably > try to work out a way of warning them about it, or fixing the breakage > first. Quite. If nothing else, I think the code actually in the Debian archive that relies on the old path ought to be changed _first_, e.g. via an MBF. I see a bunch of cases that are relatively subtle and might suck a lot of other people's time trying to debug them from cold, such as AppArmor profiles and example scripts, and it's just good manners to give maintainers an explicit heads-up. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1078429: xinetd: sshd won't start from xinetd in OpenSSH 9.8p1-2
On Fri, Aug 16, 2024 at 01:20:51AM +0200, Salvo Tomaselli wrote: > I am a bit hesitant to patch xinetd because you never know what such a change > might break for people and their configurations. Of course the same is true for OpenSSH. But since that's what changed most recently it makes some sense to consider a repairing change there; I'll see what upstream says. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1078721: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
On Thu, Aug 15, 2024 at 11:14:41PM +0530, Nilesh Patra wrote: > On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote: > > At 2024-08-15T13:20:02-0400, Michael Stone wrote: > > > It's just so depressing that this is how debian works now. We used to > > > try to not break things, now the answer is "you should have read the > > > NEWS, and known that unrelated packages were going to break, and > > > reconfigured standard debian network tools to add non-default > > > timeouts". All because the aesthetic preference for not having the > > > same binary appear in two different paths is a higher priority than > > > keeping systems working. > > > > "Move fast and break as much stuff as possible, or Debian will be doomed > > to irrelevance. I'll be SABDFL someday!" > > > > The creed of the _impactful_ developer. > > It looks like a pretty pointless change - breaks several scripts for example. > It was/is common to assume /sbin/ip to be present and usable. > Michael's bug report does make sense to me. Such a change is even causing > systems to not bootup. On 2024-07-14 (five days before the iproute2 change was made), there was this conversation on #debian-devel: 19:14 Is there a reason why iproute2 ships a symlink from /sbin/ip to /bin/ip? I've looked into the packaging repo and it seems to predate the git log. ... 19:52 petn-randall: https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has a pretty non-trivial list of things that would need fixed before removing that (and of course some false positives) I realize it wasn't petn-randall who made this change, but it seems a big coincidence that the symlink was dropped a few days after this IRC conversation; and yet it seems nobody bothered to do the most basic due diligence that I pointed out here, which is kind of sad. (I fixed wireless-tools after this change caused an RC bug there.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#965041: [Pkg-openssl-devel] Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed in openssl
On Wed, Aug 14, 2024 at 07:57:25PM +0200, Sebastian Andrzej Siewior wrote:
> I'm sorry if this is causing trouble. I splitted the legacy provider out
> and added a Recommends: assuming that it is pulled in by default. It did
> not pop on the debci.
Presumably because it mostly affects indirect dependencies.
> Is this causing enough trouble that you would say it needs a Depends:
> until this is resolved?
Well, so far I've had to add the environment variable to openssh,
incremental, and twisted just so that I could get on with other things.
But I have no real idea right now how much else might be affected.
Maybe it's worth you filing an issue on
https://github.com/pyca/cryptography/issues to let cryptography upstream
know about the problem? That way you could explain the change and
discuss whether it makes sense to change cryptography to match the
Debian-specific layout here, or whether it makes sense to change Debian
in some other way.
A minimal reproducer on unstable is to install python3-cryptography and
remove openssl-provider-legacy, then run "python3 -c 'import
cryptography.hazmat.bindings.openssl.binding'". ('import OpenSSL' also
fails, and is probably the most common way that packages will run into
this.)
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1078714: python3-eventlet: eventlet.__version__ == "0.0.0"
Package: python3-eventlet
Version: 0.35.1-3
Severity: normal
eventlet self-reports its version via eventlet.__version__ as "0.0.0".
This probably doesn't matter for many purposes, but it breaks gunicorn's
"geventlet" worker:
https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/geventlet.py
try:
import eventlet
except ImportError:
raise RuntimeError("eventlet worker requires eventlet 0.24.1 or higher")
else:
from packaging.version import parse as parse_version
if parse_version(eventlet.__version__) < parse_version('0.24.1'):
raise RuntimeError("eventlet worker requires eventlet 0.24.1 or
higher")
I gather that this file is normally generated via a hatch build hook
based on VCS information, which wouldn't work during a Debian package
build. Can this be patched to provide a version based on the upstream
part of the Debian package's version number, or something like that?
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-eventlet depends on:
ii netbase 6.4
ii python3 [python3-supported-min] 3.12.4-1
ii python3-dnspython2.6.1-1
ii python3-greenlet 3.0.1-3+b1
ii python3-monotonic1.6-2
python3-eventlet recommends no packages.
Versions of packages python3-eventlet suggests:
pn python-eventlet-doc
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1078429: xinetd: sshd won't start from xinetd in OpenSSH 9.8p1-2
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3717 On Sat, Aug 10, 2024 at 12:00:11PM +0200, Olivier wrote: > I'd run strace to monitor xinetd process, and it's show: > -- > 10887 11:12:02 write(2, "sshd requires execution with an absolute path\r\n", > 47) = 47 Salvo, I'm not sure it's entirely true that nothing can be done with xinetd here. It would be possible to have it pass the full path in argv[0], as the patch in https://bugs.gentoo.org/936041 suggests. It's arguably a bit silly and unnecessary for it to strip the directory part from argv[0]; shells don't do that, for example. Anyway, I've forwarded this to https://bugzilla.mindrot.org/show_bug.cgi?id=3717, since it doesn't look as though anyone had got around to reporting this upstream yet, and since it's not 100% clear to me what the correct fix should be although I have a couple of possible ideas. I've also written an autopkgtest for this, so once we fix it, it shouldn't come back in testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#965041: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#965041: fixed in openssl 3.3.1-5)
On Fri, Aug 09, 2024 at 09:15:20AM +, Debian Bug Tracking System wrote: >* Split the legacy provider into its own package (Closes: #965041). By default, this breaks anything that uses python3-cryptography: https://github.com/pyca/cryptography/blob/43.0.0/src/rust/src/lib.rs#L77 There are two natural options: set CRYPTOGRAPHY_OPENSSL_NO_LEGACY, or depend on openssl-provider-legacy. I guess the former is a reasonable workaround, at least in the short term, but it's going to have to be done in the test suite of the entire reverse-dependency tree of python3-cryptography; or python3-cryptography itself would have to be changed, which ideally would need to be coordinated with upstream since it'd be a semantic change. Given what seems to have been a relatively weak and contested justification for making this change, is this actually worth all the effort? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1075363: pccts: diff for NMU version 1.33MR33-6.4
Control: tags 1075363 + patch
Control: tags 1075363 + pending
Dear maintainer,
I've prepared an NMU for pccts (versioned as 1.33MR33-6.4) and am about
to upload it. I'm not doing a delayed upload in this case since the
maintainer hasn't touched the package since 2010.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru pccts-1.33MR33/debian/changelog pccts-1.33MR33/debian/changelog
--- pccts-1.33MR33/debian/changelog 2022-07-06 11:12:30.0 +0100
+++ pccts-1.33MR33/debian/changelog 2024-08-14 11:24:49.0 +0100
@@ -1,3 +1,10 @@
+pccts (1.33MR33-6.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't rely on implicit declarations (closes: #1075363).
+
+ -- Colin Watson Wed, 14 Aug 2024 11:24:49 +0100
+
pccts (1.33MR33-6.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pccts-1.33MR33/debian/patches/implicit-declarations.patch pccts-1.33MR33/debian/patches/implicit-declarations.patch
--- pccts-1.33MR33/debian/patches/implicit-declarations.patch 1970-01-01 01:00:00.0 +0100
+++ pccts-1.33MR33/debian/patches/implicit-declarations.patch 2024-08-14 11:22:41.0 +0100
@@ -0,0 +1,46 @@
+From: Colin Watson
+Date: Wed, 14 Aug 2024 11:22:38 +0100
+Subject: Don't rely on implicit declarations
+
+These are errors in GCC 14.
+
+Bug-Debian: https://bugs.debian.org/1075363
+Last-Update: 2024-08-14
+---
+ sorcerer/gen.c| 2 +-
+ support/genmk/genmk.c | 3 ++-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/sorcerer/gen.c b/sorcerer/gen.c
+index 4a67a1e..f8fcbd0 100644
+--- a/sorcerer/gen.c
b/sorcerer/gen.c
+@@ -56,7 +56,7 @@
+ #include "sym.h"
+ #include "proto.h"
+
+-static outfile = -1;
++static int outfile = -1;
+ static char *current_rule;
+ static ListNode *labels_for_func = NULL;
+ static AST *whichRule;
+diff --git a/support/genmk/genmk.c b/support/genmk/genmk.c
+index f07c925..7036afe 100644
+--- a/support/genmk/genmk.c
b/support/genmk/genmk.c
+@@ -73,13 +73,14 @@ void mk(char *project, char **files, int n, int argc, char **argv);
+ void pfiles(char **files, int n, char *suffix);
+ void fatal(char *msg);
+ void warn(char *msg);
++void pclasses(char **classes, int n, char *suffix);
+ #else
+ void help();
+ void mk();
+ void pfiles();
+ void fatal();
+ void warn();
+-void pclasses(char **classes, int n, char *suffix);
++void pclasses();
+ #endif
+
+ typedef struct _Opt {
diff -Nru pccts-1.33MR33/debian/patches/series pccts-1.33MR33/debian/patches/series
--- pccts-1.33MR33/debian/patches/series 2022-07-06 11:08:24.0 +0100
+++ pccts-1.33MR33/debian/patches/series 2024-08-14 11:22:41.0 +0100
@@ -1 +1,2 @@
conversion-format-3.0-quilt.patch
+implicit-declarations.patch
Bug#1077903: debusine: flaky autopkgtest: SIGKILL is called but processes were already dead
On Sun, Aug 04, 2024 at 11:24:04AM +0200, Paul Gevers wrote: > 53s == > 53s FAIL: test_execute_cmd_finished_before_killpg_sigkill > (debusine.tasks.tests.test_task.RunCommandTaskTests.test_execute_cmd_finished_before_killpg_sigkill) > 53s Execute script. SIGKILL is called but processes were already dead. > 53s -- > 53s Traceback (most recent call last): > 53s File > "/usr/lib/python3/dist-packages/debusine/tasks/tests/test_task.py", line > 1350, in test_execute_cmd_finished_before_killpg_sigkill > 53s self.assertIn( > 53s AssertionError: 'output (contains stdout and stderr):\n\naborted: > True\nreturncode: -9\n' not found in 'cmd: > /tmp/debusine-tests-i0k_pvrb/signal-logger.sh /tmp/debusine-tests-i0k_pvrb > 2091 2 TERM\noutput (contains stdout and stderr):\n\nFiles in working > directory:\n2235.pid\n2236.pid\nsignal-logger.sh I've proposed https://salsa.debian.org/freexian-team/debusine/-/merge_requests/1054, which I _think_ should fix this one. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077985: python-yalexs: Tests fail with python-aiohttp 3.10.0
Source: python-yalexs Version: 6.4.3-1 Severity: important python-aiohttp 3.10.0 (in experimental) causes this package's autopkgtests to fail. I've filed https://github.com/bdraco/yalexs/pull/134 with upstream to fix this, and I suggest cherry-picking that patch into Debian. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077981: blinkpy: Tests fail with python-aiohttp 3.10.0
Source: blinkpy Version: 0.23.0-1 Severity: important python-aiohttp 3.10.0 (in experimental) causes this package's autopkgtests to fail. I've filed https://github.com/fronzbot/blinkpy/pull/974 with upstream to fix this, and I suggest cherry-picking that patch into Debian. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077926: django-celery-email: Switch upstream to django-celery-email-reboot?
Source: django-celery-email Version: 3.0.0-2 Severity: wishlist django-celery-email seems to have been unmaintained upstream for some time; the last release was in 2019, and the last upstream commit was in 2022. I was looking around and saw that https://pypi.org/project/django-celery-email-reboot/ seems to be a somewhat more active fork. I'm not sure what would make most sense here. Is it worth considering switching this package's upstream to django-celery-email-reboot? Or should django-celery-email-reboot perhaps be packaged separately instead? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#947800: dh-python: pybuild copying of testfiles loses directory structure
On Fri, Aug 19, 2022 at 05:04:40PM +0200, Stefano Rivera wrote: > Hi Scott (2019.12.31_00:47:02_+0200) > > When a file or directory such as a/b/c.txt is listed in > > pybuild.testfiles, when it is copied to the build directory, the > > directory structure portion is lost. Tests expect certain data files to > > exist in certain location so this makes it hard to use the > > pybuild.testfiles feature. It seems that pybuild.testfiles should > > retain the original directory structure of the listed files. > > Not necessarily. It's quite common to have e.g. src/tests and you don't > want the src directory in the temporary build dir. > > I suspect we may need an optional destination path for each entry to > implement this without breaking things. > > I did some review of the archive, most pybuild.testfiles users naming a > top-level directory in the source package, and this seems to give them > what they want. I run into this quite frequently when trying to convert packages to autopkgtest-pkg-pybuild. For packages that use unittest, tests tend not to be in a top-level test/ or tests/ directory; it's also not entirely uncommon for their own directory structure to matter, for example because they import other test files. In such cases I tend to end up using workarounds like https://salsa.debian.org/python-team/packages/py-macaroon-bakery/-/commit/e81e544e776fd853ca396655865a3a859c49a79c, but it's definitely cumbersome. An optional destination path might work, or perhaps instead a separate option that specifies the path from which entries are copied and strips that when constructing the path in the temporary build directory. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"
On Fri, Aug 02, 2024 at 05:16:57PM +0200, Andrea Zagli wrote: > i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny... Perfect, thanks, I see the problem now. Will upload a fix shortly. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"
On Fri, Aug 02, 2024 at 04:57:55PM +0200, Andrea Zagli wrote: > Colin Watson writes: > > In that case I need all the ssh-related log entries you can give me - > > "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on. > > the only log produced > > ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating. > ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure > Shell server... > ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully. > ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell > server. > ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure > Shell server... > ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22. > ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22. > ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell > server. > ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 > (10.0.0.99) Are there any entries matching 10.0.0.99 or related to sshd in /etc/hosts.allow or /etc/hosts.deny? If so, can I please see them (with sensitive details edited out if necessary)? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"
(CCing the bug report again so that this is archived) On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote: > i think it's disabled > > ○ ssh.socket - OpenBSD Secure Shell server socket > Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: > enabled) > Active: inactive (dead) >Triggers: ● ssh.service > Listen: [::]:22 (Stream) > > > the sshd service starts without problems > > i tried with a clean sshd_config file, but same problem > > i downgraded openssh to 9.7 and it works In that case I need all the ssh-related log entries you can give me - "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"
On Fri, Aug 02, 2024 at 03:47:02PM +0200, Andrea Zagli wrote: > *** Reporter, please consider answering these questions, where appropriate *** There isn't enough information in this bug for me to go on as yet. Please tell me any custom configuration that you have. In particular, are you using socket activation (#1077765)? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077765: openssh: can't be started by ssh.socket anymore
On Thu, Aug 01, 2024 at 07:01:28PM +0200, Raphaël Halimi wrote: > Since the latest openssh upgrade, ssh.socket service can't start > ssh.service. > > It fails with the error message "fatal: Cannot bind any address", and gives > up after 5 tries (which is expected), leaving the machine unreachable. > > ssh.service on its own starts normally. > > This is a regression, as previous versions of ssh.socket were able to start > the service without problems. > > A simple workaround is to disable ssh.socket and enable ssh.service, but it > would be nice to have systemd socket activation working again. My best guess is that this has something to do with the refactoring of sshd into a listener binary and a per-session binary, which touched the re-exec path that's also involved in socket activation. I'll try to figure it out, but it may take a little while. I think we should probably also add an autopkgtest for the socket activation case. Since it's not the default and not otherwise automatically tested right now, it's easy for it to break accidentally. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077735: libssh2: FTBFS with OpenSSH 9.8
Source: libssh2
Version: 1.11.0-6
Severity: serious
Tags: ftbfs
OpenSSH 9.8 disabled DSA by default at compile time
(https://www.openssh.com/releasenotes.html#9.8p1). As a result, libssh2
now fails to build with test failures, as follows:
make[6]: Entering directory '/<>/tests'
PASS: test_simple
PASS: mansyntax.sh
FAIL: test_sshd.test 1 - sshd-test_ssh2
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
ERROR: test_sshd.test - exited with status 1
=
libssh2 -: tests/test-suite.log
=
# TOTAL: 5
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 1
.. contents:: :depth: 2
ERROR: test_sshd
/<>/tests/openssh_server/sshd_config line 2: Bad key types
'+ssh-rsa,ssh-dss,ssh-rsa-cert-...@openssh.com'.
Connection to 127.0.0.1:4711 attempt #0 failed: retrying...
Connection to 127.0.0.1:4711 attempt #1 failed: retrying...
Connection to 127.0.0.1:4711 attempt #2 failed: retrying...
Failure establishing SSH session: -43
Fingerprint: ./test_sshd.test: line 131: 2387220 Segmentation fault
"${test}"
Connection to 127.0.0.1:4711 attempt #0 failed: retrying...
Connection to 127.0.0.1:4711 attempt #1 failed: retrying...
Connection to 127.0.0.1:4711 attempt #2 failed: retrying...
Failed to connect to 127.0.0.1:4711
./test_sshd.test: line 1: kill: (2387095) - No such process
# sshd executable: '/usr/sbin/sshd' (OpenSSH_9.8p1 Debian)
# ssh executable: '/usr/bin/ssh' (OpenSSH_9.8p1 Debian-1, OpenSSL 3.2.2 4 Jun
2024)
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
1..2
not ok 1 - sshd-test_ssh2
FAIL: test_sshd.test 1 - sshd-test_ssh2
not ok 2 - sshd-test_auth_pubkey_ok_ed25519
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
ERROR: test_sshd.test - exited with status 1
Testsuite summary for libssh2 -
# TOTAL: 5
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 1
See tests/test-suite.log
Please report to libssh2-de...@lists.haxx.se
make[6]: *** [Makefile:1241: test-suite.log] Error 1
https://github.com/libssh2/libssh2/commit/b7ab0faa70567a789419798fe079f5678ad4e156
seems to have been upstream's approach to this, so I suggest
cherry-picking that.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077554:
On Mon, Jul 29, 2024 at 08:40:02PM -0700, Joshua Hudson wrote: > I've since learned this bug is upstream; and have most of a fix. > Basically I'm bogged down in autoconf; which makes it unsuitable for > upstream but I could provide a debian specific patch without autoconf. I'd probably want this sort of patch to go upstream first. > I don't think the openssh team likes gmail much; the mailing list for > reporting anything upstream doesn't want to let me join or send > anything. You can file upstream bugs with attached patches on bugzilla.mindrot.org, which IME is usually more reliable anyway. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077051: pcmciautils: Add Appstream metainfo announcing HW support
On Thu, Jul 25, 2024 at 06:20:24PM +0200, Petter Reinholdtsen wrote: > [Colin Watson] > > Thanks. Would you mind if I instead put the .metainfo.xml file in the > > debian/ directory? That would save needing to interact with > > debian/patches/ (which I have no problem doing, but if all we need to > > do is to drop in a single file it seems like unnecessary complexity). > > Not at all. The exact location do not matter. > > I placed on the toplevel and prepared for a life in > debian/patches/ to indicate that it should be passed upstream and shared > across all Linux distributions. I find is easier to point upstream to > the 'debian patches' link on the tracking page than to look for single > files in debian, but it is not much simpler than sending an email to > upstream. :) In general yes, but as far as I know upstream for pcmciautils is inactive anyway (last release in 2015, last non-spam post to upstream mailing list 2017), so it's kind of moot. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077051: pcmciautils: Add Appstream metainfo announcing HW support
On Thu, Jul 25, 2024 at 05:21:52PM +0200, Petter Reinholdtsen wrote: > Here is a patch to add Appstream metainfo XML announcing the hardware > handled by this package. > > Including this information in the package will ensure programs mapping > hardware to packages using Appstream information, like the isenkram > package, will know that this package is useful on machines where the > hardware is discovered. > > I was not quite able to figure out the build system used. The patch is > thus untested, but I suspect it will work. Thanks. Would you mind if I instead put the .metainfo.xml file in the debian/ directory? That would save needing to interact with debian/patches/ (which I have no problem doing, but if all we need to do is to drop in a single file it seems like unnecessary complexity). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#650139: /lib/udev/rules.d/19-ifrename.rules: udev rule incorrect with at least udev 175
Source: wireless-tools
Source-Version: 30~pre9-8
On Sat, Nov 26, 2011 at 10:35:58PM +0100, Alban Browaeys wrote:
> /lib/udev/rules.d/19-ifrename.rules uses IMPORT without attribute which fails
> at least with udev 175.
> add {program} as attributes fixes this and prevent random interfaces names at
> boot. From:
> SUBSYSTEM=="net", ACTION=="add", IMPORT="/sbin/ifrename -u -i %k",
> NAME:="$env{INTERFACE}"
> to:
> SUBSYSTEM=="net", ACTION=="add", IMPORT{program}="/sbin/ifrename -u -i %k",
> NAME:="$env{INTERFACE}"
>
> This let my flow rules for openvswitch work . Otherwise with random
> interfaces names the flows are unmanageable.
This seems to have been fixed a long time ago in response to another
similar bug:
wireless-tools (30~pre9-8) unstable; urgency=low
* Add type to IMPORT keyword in ifrename's udev rules file. Closes: #650606
-- Guus Sliepen Fri, 23 Dec 2011 16:02:18 +0100
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1072920: release.debian.org: force-skiptest debusine/0.3.2/riscv64
On Sun, Jul 14, 2024 at 07:21:44AM +0200, Paul Gevers wrote: > On 13-07-2024 12:45 p.m., Jochen Sprickerhof wrote: > > The latest test failures look like timeout problems and we can still > > address them later. > > Why not do that now? Then we don't need to give you an exception without a > good reason. I would just like to say that my time tracker tells me that I've already spent 16.5 hours working on this. I wish it were a quick fix, but it doesn't seem to be. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1076199: www.debian.org: Webpage Debian-Installer add riscv64 other images link
On Fri, Jul 12, 2024 at 04:22:32AM -0700, E Shattow wrote: > Please update to refer to riscv64 under the heading "other images > (netboot, USB stick, etc.)": > > https://www.debian.org/devel/debian-installer/ I suspect this is mostly because debian-installer riscv64 support hasn't been uploaded to unstable yet, so it isn't on https://deb.debian.org/debian/dists/testing/main/installer-riscv64/ or https://deb.debian.org/debian/dists/unstable/main/installer-riscv64/. I'm not sure what the plan for that is; somebody on debian-boot@ probably knows. Once that's done, riscv64 will need to be added to the devel-images-arches tag (and I suppose also trixie-images-arches) in webwml:english/template/debian/installer.wml. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1076123: new upstream 9.8 for experimental, please?
On Thu, Jul 11, 2024 at 07:51:40AM +0200, Harald Dunkel wrote: > Do you think it would be possible to get upstream's current > version 9.8 for experimental, I'm working on this already - I just ran into some difficulties forward-porting one of our patches and it's taking me a while to sort out. > built including the deprecated ciphers? I don't know exactly what you mean by this, but if you mean DSA, then no, I will be disabling support for that in line with upstream's new compile-time default. See also https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/209. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1076036: python3-setuptools: uninstallable in unstable
On Tue, Jul 09, 2024 at 07:57:51PM +0100, Colin Watson wrote:
> Following
> https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/,
> python3-setuptools is uninstallable in unstable:
Indeed, setuptools Build-Depends: dh-python Depends: python3-setuptools,
so unstable's ability to build anything Python-related has been
completely botched and this should have been done in some other order.
I guess it can be fixed with a manual build of setuptools against an
older version of dh-python, although it will also be necessary to deal
with https://bugs.debian.org/1056198 ("src:setuptools: build depends on
dh-python but build conflicts with python3-setuptools").
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1076036: python3-setuptools: uninstallable in unstable
Package: python3-setuptools Version: 68.1.2-2 Severity: grave Justification: renders package unusable Following https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/, python3-setuptools is uninstallable in unstable: # apt install python3-setuptools Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: python3-setuptools : Depends: python3-distutils but it is not installable Error: Unable to correct problems, you have held broken packages. # apt install python3-setuptools python3-distutils Package python3-distutils is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Error: Package 'python3-distutils' has no installation candidate This obviously seems likely to break builds of a large number of other packages - we noticed it in debusine's reprotest CI jobs. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation
On Mon, Jul 08, 2024 at 12:50:42AM +0500, Andrey Rakhmatullin wrote: > On Sun, Jul 07, 2024 at 01:54:59PM -0400, Yogeswaran Umasankar wrote: > > Yes, can use the standard library. This dependency chain starts with > > moarchiving, which itself is a dependency for cma, and so on. I can > > create a patch specifically for moarchiving. > > As reported elsewhere, moarchiving declares a dep on it but doesn't > actually import it. > This needs to be fixed upstream to. I proposed https://github.com/CMA-ES/moarchiving/pull/9 upstream. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074766: openssh-server: upgrading to openssh-server (1:9.2p1-2+deb12u3) resets /etc/ssh/sshd_config file without any prompt
On Tue, Jul 02, 2024 at 03:05:16PM +, John Wellesz wrote: > I used apt upgrade to install the security update available for > openssh-server > >* What was the outcome of this action? > > It overwrote /etc/ssh/sshd_config without promtping, erasing the custom > settings > and almost locking me out as a result (my custom port setting was gone > as well as other changes I've made). > >* What outcome did you expect instead? > > I expected to receive the usual prompt when a configuration file is > modified asking me what I want to do but there was none. We'll need to be able to reproduce this problem before being able to do anything about it. (I have a modified /etc/ssh/sshd_config on my own stable system and it wasn't overwritten on upgrade.) Can you please provide a copy of your modified /etc/ssh/sshd_config, along with the output of the relevant apt run (which should be preserved in /var/log/apt/term.log)? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#939392: please provide kmodsign like Ubuntu does
On Mon, Sep 09, 2019 at 04:46:38PM +0100, Steve McIntyre wrote: > On Mon, Sep 09, 2019 at 04:35:44PM +0100, Steve McIntyre wrote: > >On Wed, Sep 04, 2019 at 03:47:35PM +0300, Dmitry Eremin-Solenikov wrote: > >>Could you please provide kmodsign tool like Ubuntu package does, so that > >>we can sign Linux kernel modules with custom keys. > > > >ACK, that would be a good thing to have. > > > >Steve - would you be happy to push the ubuntu patches up into Debian? > > > >Probably worth us talking to the original kmodsign authors (David > >Howells and David Woodhouse) and the sbsigntool maintainer (James > >Bottomley) about maybe integrating things upstream too. I'll try to > >start a conversation there... > > Hmmm, hang on - it's just the "sign-file" program from the kernel > tree, renamed as "kmodsign" for some reason. Steve: the bug at > > https://bugs.launchpad.net/bugs/1526959 > > named in the patches doesn't seem all that relevant - could you > enlighten us please? :-) https://bugs.launchpad.net/ubuntu/+source/sbsigntool/+bug/1579766 is a more relevant bug report. This was for signing things outside of the context of a kernel build, and Launchpad does that on a specially-secured signing service that ensures that keys are encrypted at rest and such. If memory serves, I asked for this to be added to sbsigntool because the alternative was that we'd have to chase kernel versions: sign-file is packaged as /usr/lib/linux-kbuild-$version/scripts/sign-file in the linux-kbuild-$version package, but that's really a pretty annoying thing for a supposedly non-kernel-version-dependent service to have to depend on! dak has a similar requirement, and it seems that they've just ended up with a dependency on "linux-kbuild-5.10 | linux-kbuild-4.19" that presumably they bump from time to time. Ugh. Now I'm no longer involved with Launchpad, but I have a pretty similar third instance of this requirement in debusine, and I'd really rather not perpetuate the same horribleness there. Is there any chance that these Ubuntu patches could be merged? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059658: jupyter-client autopkgtest situation
Control: block 1059658 by 1071879 Hi, I was looking at the RC bug https://bugs.debian.org/1059658, and I noticed that there've been unreleased commits in https://salsa.debian.org/python-team/packages/jupyter-client for months that seem to fix this. However, when I ran the autopkgtests for that version locally I found that they're a mess, with lots of repeats of this (trimmed for readability): jupyter_client/__init__.py:3: in from .asynchronous import AsyncKernelClient jupyter_client/asynchronous/__init__.py:1: in from .client import AsyncKernelClient # noqa jupyter_client/asynchronous/client.py:12: in from ..client import KernelClient, reqrep jupyter_client/client.py:20: in from .connect import ConnectionFileMixin jupyter_client/connect.py:22: in from jupyter_core.paths import jupyter_data_dir, jupyter_runtime_dir, secure_write /usr/lib/python3/dist-packages/jupyter_core/paths.py:208: in deprecation( /usr/lib/python3/dist-packages/jupyter_core/utils/__init__.py:90: in deprecation warnings.warn(message, DeprecationWarning, stacklevel=stacklevel + 1) E DeprecationWarning: Jupyter is migrating its paths to use standard platformdirs E given by the platformdirs library. To remove this warning and E see the appropriate new directories, set the environment variable E `JUPYTER_PLATFORM_DIRS=1` and then run `jupyter --paths`. E The use of platformdirs will be the default in `jupyter_core` v6 _internal = ['jupyter_core/'] internal = 'jupyter_core/' message= 'Jupyter is migrating its paths to use standard platformdirs\ngiven by the platformdirs library. To remove this warni...TER_PLATFORM_DIRS=1` and then run `jupyter --paths`.\nThe use of platformdirs will be the default in `jupyter_core` v6' stacklevel = 2 Now, tests/conftest.py does in fact set JUPYTER_PLATFORM_DIRS=1, so I think the problem is that the autopkgtests run "$py -m pytest jupyter_client" rather than just "$py -m pytest". But that has a different problem: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 865, in import_plugin __import__(importspec) ModuleNotFoundError: No module named 'pytest_jupyter' And: # apt install python3-pytest-jupyter Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: python3-pytest-jupyter : Depends: python3-jupyter-core (>= 5.7) but 5.3.2-2 is to be installed Error: Unable to correct problems, you have held broken packages. So I guess this is https://bugs.debian.org/1071879, and presumably the easiest way out would be to upgrade jupyter-core to a current upstream version. Any objections to me going ahead and doing that? I'm also a bit confused as to how it got this way. Julian must have been able to build pytest-jupyter in order to construct the upload in https://tracker.debian.org/news/1518227/accepted-pytest-jupyter-091-1-source-all-into-unstable/, but a sufficient version of jupyter-core wasn't in unstable then any more than it is now. Was this hacked up locally in some way? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074420: ITP: python-yubihsm -- Python library for the YubiHSM 2
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-yubihsm Version : 3.0.0 Upstream Contact: Dain Nilsson * URL : https://github.com/Yubico/python-yubihsm * License : Apache-2.0 Programming Lang: Python Description : Python library for the YubiHSM 2 The YubiHSM 2 is a USB-attached device for managing cryptographic keys. This package contains a Python interface to it, communicating via yubihsm-connector. We're in the process of starting to use a YubiHSM in Freexian, and I have hardware that I can use to test this. For some purposes (signing using keys that are already loaded into the HSM) it's possible to just interact with the HSM over PKCS#11, but for others we need finer control over things like capabilities, and to do this from Python code it's more pleasant to have a proper module rather than having to drive yubihsm-shell from Python. This package could reasonably live under either pkg-security-team or the Python team, but I think I'll go with pkg-security-team since it's pretty closely linked with the other YubiHSM packages I've uploaded recently. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074324: Aw: Re: Bug#1074324: openssh-client: double entry of "GSSAPIAuthentication" in /etc/ssh/ssh_config"
On Wed, Jun 26, 2024 at 07:09:59PM +0200, lopiuh wrote: > Not really a problem, just to keep things clear and uncluttered. On > the other hand, someone could alter the first occurrence, and the > uncommented last line gets used instead of the edited first > occurrence. That would be annoying in the best case. ;-) I would hope that people editing configuration files would generally recognize comments! -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074324: openssh-client: double entry of "GSSAPIAuthentication" in /etc/ssh/ssh_config"
On Wed, Jun 26, 2024 at 05:45:53PM +0200, lopiuh wrote: > /etc/ssh/ssh_config: Property "GSSAPIAuthentication" is contained twice (once > active and once commented out.) > > Is that intentionally? Not particularly, but I guess it serves to minimize the diff against upstream in some way. Why does it matter? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1010735: Bug#950598: Chain of Dependencies prevents closing RC bugs
On Fri, Feb 10, 2023 at 11:16:49AM +0100, Andreas Tille wrote: > to fix > > #1030884 python-cogent: FTBFS (ImportError: cannot import name 'float' from > 'numpy') > > and let it migrate to testing it needs to wait for > > #950598 python3-jupyter-sphinx: package relies on unavailable > `ipywidgets.embed` module > > which in turn needs > > #896460 Please package ipywidgets 7 > > which needs another not yet packaged precondition. #896460 has been fixed now for a while, testing has ipywidgets 8.1.1-2, and jupyter_sphinx.execute can be imported. As a result I'm closing this bug, and I think you can revert whatever workarounds you added to python-cogent. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073381: git-build-recipe: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13
Control: reassign -1 python3-testtools 2.7.1-3 Control: affects -1 git-build-recipe Control: forwarded -1 https://github.com/testing-cabal/testtools/issues/372 On Sun, Jun 16, 2024 at 03:21:26PM +0200, Lucas Nussbaum wrote: > Source: git-build-recipe > Version: 0.3.7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240615 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > ERRORS > > > > _ ERROR collecting > > .pybuild/cpython3_3.11/build/gitbuildrecipe/tests/test_deb_version.py _ > > /usr/lib/python3/dist-packages/testtools/testcase.py:241: in __init__ > > test_method = self._get_test_method() > > /usr/lib/python3/dist-packages/testtools/testcase.py:696: in > > _get_test_method > > return getattr(self, method_name) > > E AttributeError: 'GitTestCase' object has no attribute 'runTest' This is https://github.com/testing-cabal/testtools/issues/372, and is fixed by testtools 2.7.2. Thomas, could we upgrade testtools to 2.7.2 in Debian, please? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074215: ITP: yubihsm-shell -- Command-line and interactive tool for the YubiHSM 2
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: yubihsm-shell Version : 2.5.0 Upstream Contact: Yubico Open Source Maintainers * URL : https://developers.yubico.com/yubihsm-shell/ * License : Apache-2.0 Programming Lang: C Description : Command-line and interactive tool for the YubiHSM 2 The YubiHSM 2 is a Hardware Security Module that is within reach of all organizations. It provides advanced cryptography, including hashing, asymmetric and symmetric key cryptography, to protect the cryptographic keys that secure critical applications, identities, and sensitive data in an enterprise for certificate authorities, databases, code signing and more. This package contains a command-line and interactive tool for working with a YubiHSM 2. We're in the process of starting to use a YubiHSM in Freexian. Upstream does provide their own Debian packages, but given that there's no licensing obstacle I'd prefer to have this in Debian. I have the hardware and I intend to maintain this as part of https://salsa.debian.org/pkg-security-team (compare https://bugs.debian.org/1074007). The upstream yubihsm-shell source package builds a number of binary packages (libyubihsm*, libykhsmauth*, yubihsm-pkcs11, yubihsm-shell, yubihsm-wrap, and yubihsm-auth). Their layout looks reasonable to me and I'll try not to be gratuitously incompatible with it. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074211: ITP: python-expandvars -- bash-style environment variable expansion in Python
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-expandvars Version : 0.12.0 Upstream Contact: Arijit Basu * URL : https://github.com/sayanarijit/expandvars * License : MIT Programming Lang: Python Description : bash-style environment variable expansion in Python This module is inspired by GNU bash's variable expansion features. It can be used as an alternative to Python's os.path.expandvars function. A good use case is reading config files with the flexibility of reading values from environment variables using advanced features like returning a default value if some variable is not defined. This is a new build-dependency of frozenlist 1.4.1. I intend to maintain it as part of the Python team. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074121: sub{u,g}id creation
On Sun, Jun 23, 2024 at 01:48:02PM +0200, Chris Hofstaedtler wrote: > A long time ago, Balint added code to login's postinst to create > /etc/subuid, /etc/subgid. This is necessary, because without the > files existing, useradd does not add entries to them. > > However: > > 1) login is not essential anymore. > > 2) people want to use useradd from a 'host environment' (like > outside a chroot). In this case, passwd might also be absent. > > I had the thought that base-passwd might be a better place to create > these files, but didn't want to introduce extra churn. Helmut > independently suggested a similar thought. > > Colin, what do you think? Can/should base-passwd create /etc/subuid, > /etc/subgid on new installs and upgrades? I don't see any obvious problems with this. I'd like to allow a week or so for comment, so I've told my task tracker to remind me about this next week. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074083: create .../man/man/
Control: reassign -1 debian-policy On Sun, Jun 23, 2024 at 01:31:41AM +, Bjarni Ingi Gislason wrote: > The "cat" directories are empty on my computer so there is no saving > there. > > I could use uncompressed man pages for general use, > so I suggest that should be provided if the user wants that. > > Nowadays computers usually have abundant disk place, > and only use a part of the provided software and thus only a part of the > provided man pages by a operation system. Providing uncompressed manual pages would be a matter for Debian policy, not for man-db, so I'm reassigning this there. However, I must say that I am not in favour. Since man-db decompresses pages in-process, there's negligible performance advantage (possibly a performance disadvantage in some cases), and the benefit is unlikely to be worth the effort. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074007: ITP: yubihsm-connector -- USB to HTTP bridge for the YubiHSM
On Fri, Jun 21, 2024 at 06:36:06PM +0200, Simon Josefsson wrote: > Thanks for working on this package. > > > I have the hardware and I intend to maintain this as part of > > https://salsa.debian.org/auth-team, which already has quite a few > > other Yubico-related packages. > > What do you think about using pkg-security-team instead? I haved moved > libntlm and shishi there too, and I see opportunity for more shared > contributions by merging the auth-team into pkg-security-team (or > rather: I don't see a lot of opportunity for team contributions in the > auth-team, and I'm hoping pkg-security-team is better at that). I've > worked on a bunch of auth-team packages at some point in their history, > and I'm not sure there were ever any coherent team. I guess I don't really mind. There is the minor issue that I'm in auth-team and am not in pkg-security-team, but I suppose that would be fixable. :-) A YubiHSM is also less about personal authentication than a YubiKey is. CCing a couple of the other auth-team folks to see what they think. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074007: ITP: yubihsm-connector -- USB to HTTP bridge for the YubiHSM
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: yubihsm-connector Version : 3.0.4 Upstream Contact: Yubico Open Source Maintainers * URL : https://developers.yubico.com/yubihsm-connector/ * License : Apache-2.0 Programming Lang: Go Description : USB to HTTP bridge for the YubiHSM 2 The YubiHSM 2 is a USB-attached device for managing cryptographic keys. The YubiHSM Connector bridges the USB communication to HTTP, allowing applications to use the device without needing direct access to the device node, or needing to be on the same machine. The Connector is not a trusted component. Applications establish cryptographic sessions with the device. We're in the process of starting to use a YubiHSM in Freexian. Upstream does provide their own Debian packages, but given that there's no licensing obstacle I'd prefer to have this in Debian. I have the hardware and I intend to maintain this as part of https://salsa.debian.org/auth-team, which already has quite a few other Yubico-related packages. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069838: khard: Builds fine here.
Control: forwarded -1 https://github.com/lucc/khard/pull/334 On Thu, Jun 20, 2024 at 12:06:27PM +0100, Colin Watson wrote: > On Thu, Jun 20, 2024 at 12:42:17PM +0200, Santiago Vila wrote: > > El 20/6/24 a las 10:13, Colin Watson escribió: > > > Santiago, is khard still failing to build for you? > > > > As of today (version 0.19.1-2 in unstable), yes, all the time. > > In that case I could use some help reproducing it, because > https://salsa.debian.org/python-team/packages/khard/-/pipelines and > https://buildd.debian.org/status/package.php?p=khard show no errors > either. (I know I didn't get very far when you gave me access to a > machine to debug gcr4, but I'm more optimistic about this one.) Thanks to Santiago for help. I've now reproduced this and sent a patch upstream; I'll apply it to the Debian package as well in a moment. I'm still mystified as to why I couldn't reproduce this locally, but oh well. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073929: code-signing: insufficient check that file["file"] doesn't escape package via symlinks
t;file"]))
+file_path = pathlib.PurePath(file["file"])
+assert file_path.parts[0] in {"boot", "lib", "usr"}
+assert ".." not in file_path.parts
+assert not file_path.is_absolute()
# Check that all trusted certificates are whitelisted
trusted_certs = config['keys']['trusted_certs']
if '*' not in trusted_certs:
@@ -367,25 +370,26 @@ def sign_and_log_files(job):
key_config = config['signing-keys'][key_name]
for pkg, metadata in job.bin_pkgs.items():
maybe_interactive_print('Processing', pkg)
+pkg_path = pathlib.Path(job.tempdir, build_pkg_full_name(job,
pkg)).resolve(strict=True)
for n, file in enumerate(metadata['files'], start=1):
-relative_file_path = os.path.join(build_pkg_full_name(job, pkg),
file["file"])
-file_path = os.path.join(job.tempdir, build_pkg_full_name(job,
pkg), file["file"])
-sig_path = os.path.join(job.template_source_dir, 'debian',
'signatures', pkg, file["file"] + ".sig")
+relative_file_path = pathlib.PurePath(build_pkg_full_name(job,
pkg), file["file"])
+file_path = pkg_path / file["file"]
+sig_path = pathlib.Path(job.template_source_dir, 'debian',
'signatures', pkg, file["file"] + ".sig")
+assert file_path.resolve(strict=True).is_relative_to(pkg_path)
with open(file_path, 'rb') as f:
fhash = hash_file(f)
-presign_id = log_presign(relative_file_path, fhash, pkg,
job.version, job.architecture)
+presign_id = log_presign(str(relative_file_path), fhash, pkg,
job.version, job.architecture)
-if not os.path.exists(os.path.dirname(sig_path)):
-os.makedirs(os.path.dirname(sig_path))
+ sig_path.parent.mkdir(parents=True, exist_ok=True)
if file["sig_type"] == "efi":
sig_hash = sign_efi(key_config, file_path, sig_path)
elif file["sig_type"] == "linux-module":
sig_hash = sign_kmod(key_config, file_path, sig_path)
else:
raise ValueError("File Type Unknown")
-log_signature(relative_file_path, sig_hash, pkg, job.version,
presign_id, job.architecture, key_name)
+log_signature(str(relative_file_path), sig_hash, pkg, job.version,
presign_id, job.architecture, key_name)
maybe_interactive_print('\rSigned', n, 'of',
len(metadata['files']), 'files', end='')
maybe_interactive_print()
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069838: khard: Builds fine here.
On Thu, Jun 20, 2024 at 12:42:17PM +0200, Santiago Vila wrote: > El 20/6/24 a las 10:13, Colin Watson escribió: > > Santiago, is khard still failing to build for you? > > As of today (version 0.19.1-2 in unstable), yes, all the time. In that case I could use some help reproducing it, because https://salsa.debian.org/python-team/packages/khard/-/pipelines and https://buildd.debian.org/status/package.php?p=khard show no errors either. (I know I didn't get very far when you gave me access to a machine to debug gcr4, but I'm more optimistic about this one.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069838: khard: Builds fine here.
On Sun, Jun 16, 2024 at 09:42:10PM +, Martin Dosch wrote: > I just built khard locally and it builds fine. I also can't reproduce this, and I wouldn't normally expect circular import issues to be semi-reproducible - in a given codebase they usually either fail or they don't. Santiago, is khard still failing to build for you? If so I'm happy to investigate further (I can see at least one approach that ought to help), but it's worth checking if the problem has gone away due to a change in some dependency or other. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
