Bug#1086467: marked as pending in waitress
Control: tag -1 pending Hello, Bug #1086467 in waitress reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/waitress/-/commit/14a0d1cb2ce5faeed0c6ab2ed66f2166267944f7 Update upstream source from tag 'upstream/3.0.1' Update to upstream version '3.0.1' with Debian dir 325de64d7ca048909e162a3a6b031708f35475fe Closes: #1086467, #1086468 (this message was generated automatically) -- Greetings https://bugs.debian.org/1086467
Bug#1086374: marked as pending in python-icalendar
Control: tag -1 pending Hello, Bug #1086374 in python-icalendar reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-icalendar/-/commit/ebc800e71a40473b9c690eb131af88fb80347149 Build-depend on tzdata-legacy Closes: #1086374 (this message was generated automatically) -- Greetings https://bugs.debian.org/1086374
Bug#1082685: marked as pending in mayavi2
Control: tag -1 pending Hello, Bug #1082685 in mayavi2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/mayavi2/-/commit/904532de3cd942e80928ed3d20a30c413f1029f6 Build-depend on python3-configobj, now required for apptools.preferences Closes: #1082685 (this message was generated automatically) -- Greetings https://bugs.debian.org/1082685
Bug#1084240: marked as pending in asyncpg
Control: tag -1 pending Hello, Bug #1084240 in asyncpg reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/asyncpg/-/commit/a9451bfea342f0af0bed80c76767c5297e76e914 Update upstream source from tag 'upstream/0.30.0' Update to upstream version '0.30.0' with Debian dir b0c5262abc5558bf738cdf9513214caa243aec1b Closes: #1081995, #1084240 (this message was generated automatically) -- Greetings https://bugs.debian.org/1084240
Bug#1084649: marked as pending in buildbot
Control: tag -1 pending Hello, Bug #1084649 in buildbot reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/buildbot/-/commit/fb8b9de321066317a26430fd81ce2ac17786b465 Update upstream source from tag 'upstream/4.1.0' Update to upstream version '4.1.0' with Debian dir 581c3672b4aca706e864de3f1221575bdf54ecf1 Closes: #1084649 (this message was generated automatically) -- Greetings https://bugs.debian.org/1084649
Bug#1018588: python-testing.mysqld: build-depends on python3-nose or uses it for autopkgtest
Control: reassign -1 ftp.debian.org Control: affects -1 src:python-testing.mysqld Control: retitle -1 ROM; abandoned upstream, apparently broken with MariaDB and current MySQL, no reverse-dependencies On Thu, Oct 03, 2024 at 09:26:07PM +0100, Colin Watson wrote: > 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. 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#1084247: closed by Debian FTP Masters (reply to Benjamin Drung ) (Bug#1084247: fixed in distro-info 1.10)
Control: reopen -1
On Mon, Oct 07, 2024 at 12:21:07PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:distro-info package:
>
> #1084247: distro-info: FTBFS: FAIL: test_pylint
> (distro_info_test.test_pylint.PylintTestCase.test_pylint)
[...]
>* python: Disable pylint's too-many-positional-arguments (Closes: #1084247)
Unfortunately this fix can't migrate to testing, because the
too-many-positional-arguments check was new in pylint 3.3:
==
FAIL: test_pylint (distro_info_test.test_pylint.PylintTestCase.test_pylint)
Test: Run pylint on Python source code.
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.t3ae9xq_/downtmp/autopkgtest_tmp/distro_info_test/test_pylint.py",
line 70, in test_pylint
self.fail("\n".join(msgs))
AssertionError: pylint found issues:
* Module distro_info
/usr/lib/python3/dist-packages/distro_info.py:56:0: W0012: Unknown option
value for 'disable-next', expected a valid pylint message and got
'too-many-positional-arguments' (unknown-option-value)
And pylint can't migrate to testing because it breaks distro-info's
autopkgtest, so we're stuck.
Maybe the simplest option would be to have the relevant
debian/tests/control stanza depend on pylint (>= 3.3.0)? That should
hint things into understanding that the two packages need to be tested
together.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1084323: nltk: diff for NMU version 3.9.1-1.1
Control: tags 1084323 + pending
Dear maintainer,
I've prepared an NMU for nltk (versioned as 3.9.1-1.1) using the patch I
sent a few days ago, and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru nltk-3.9.1/debian/changelog nltk-3.9.1/debian/changelog
--- nltk-3.9.1/debian/changelog 2024-10-02 07:03:25.0 +0100
+++ nltk-3.9.1/debian/changelog 2024-10-11 15:23:33.0 +0100
@@ -1,3 +1,10 @@
+nltk (3.9.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't read the WordNet corpus before it is needed (closes: #1084323).
+
+ -- Colin Watson Fri, 11 Oct 2024 15:23:33 +0100
+
nltk (3.9.1-1) unstable; urgency=medium
* New upstream version 3.9.1 (Closes: #1074423)
diff -Nru nltk-3.9.1/debian/patches/import-wordnet-corpus-lazily.patch nltk-3.9.1/debian/patches/import-wordnet-corpus-lazily.patch
--- nltk-3.9.1/debian/patches/import-wordnet-corpus-lazily.patch 1970-01-01 01:00:00.0 +0100
+++ nltk-3.9.1/debian/patches/import-wordnet-corpus-lazily.patch 2024-10-11 15:23:33.0 +0100
@@ -0,0 +1,122 @@
+From: Eric Kafe
+Date: Sun, 18 Aug 2024 16:09:01 +0200
+Subject: Fix bug in WordNetLemmatizer
+
+Fix #3308 by not importing WordNet's _morphy and morphy before they are needed.
+
+Origin: upstream, https://github.com/nltk/nltk/pull/3309
+Bug: https://github.com/nltk/nltk/issues/3308
+Bug-Debian: https://bugs.debian.org/1084323
+Last-Update: 2024-10-08
+---
+ nltk/stem/wordnet.py | 71 +---
+ 1 file changed, 39 insertions(+), 32 deletions(-)
+
+diff --git a/nltk/stem/wordnet.py b/nltk/stem/wordnet.py
+index 76caf1b..87d08c7 100644
+--- a/nltk/stem/wordnet.py
b/nltk/stem/wordnet.py
+@@ -7,64 +7,71 @@
+ # URL: <https://www.nltk.org/>
+ # For license information, see LICENSE.TXT
+
+-from nltk.corpus import wordnet as wn
+-
+
+ class WordNetLemmatizer:
+ """
+ WordNet Lemmatizer
+
+-Provides 3 lemmatizer modes:
+-
+-1. _morphy() is an alias to WordNet's _morphy lemmatizer.
+-It returns a list of all lemmas found in WordNet.
+-
+->>> wnl = WordNetLemmatizer()
+->>> print(wnl._morphy('us', 'n'))
+-['us', 'u']
+-
+-2. morphy() is a restrictive wrapper around _morphy().
+-It returns the first lemma found in WordNet,
+-or None if no lemma is found.
++Provides 3 lemmatizer modes: _morphy(), morphy() and lemmatize().
+
+->>> print(wnl.morphy('us', 'n'))
+-us
+-
+->>> print(wnl.morphy('catss'))
+-None
+-
+-3. lemmatize() is a permissive wrapper around _morphy().
++lemmatize() is a permissive wrapper around _morphy().
+ It returns the shortest lemma found in WordNet,
+ or the input string unchanged if nothing is found.
+
+->>> print(wnl.lemmatize('us', 'n'))
++>>> from nltk.stem import WordNetLemmatizer as wnl
++>>> print(wnl().lemmatize('us', 'n'))
+ u
+
+->>> print(wnl.lemmatize('Anythinggoeszxcv'))
++>>> print(wnl().lemmatize('Anythinggoeszxcv'))
+ Anythinggoeszxcv
+
+ """
+
+-morphy = wn.morphy
++def _morphy(self, form, pos, check_exceptions=True):
++"""
++_morphy() is WordNet's _morphy lemmatizer.
++It returns a list of all lemmas found in WordNet.
++
++>>> from nltk.stem import WordNetLemmatizer as wnl
++>>> print(wnl()._morphy('us', 'n'))
++['us', 'u']
++"""
++from nltk.corpus import wordnet as wn
++
++return wn._morphy(form, pos, check_exceptions)
++
++def morphy(self, form, pos=None, check_exceptions=True):
++"""
++morphy() is a restrictive wrapper around _morphy().
++It returns the first lemma found in WordNet,
++or None if no lemma is found.
++
++>>> from nltk.stem import WordNetLemmatizer as wnl
++>>> print(wnl().morphy('us', 'n'))
++us
++
++>>> print(wnl().morphy('catss'))
++None
++"""
++from nltk.corpus import wordnet as wn
+
+-_morphy = wn._morphy
++return wn.morphy(form, pos, check_exceptions)
+
+ def lemmatize(self, word: str, pos: str = "n") -> str:
+ """Lemmatize `word` by picking the shortest of the possible lemmas,
+ using the wordnet corpus reader's built-in _morphy function.
+ Returns the input word unchanged if it cannot be found in WordNet.
+
+->>> from
Bug#1084385: Bug#1084323: pydoctor: FTBFS: Resource wordnet not found.
reassign 1084235 python3-nltk 3.9.1-1
reassign 1084236 python3-nltk 3.9.1-1
reassign 1084237 python3-nltk 3.9.1-1
reassign 1084242 python3-nltk 3.9.1-1
reassign 1084249 python3-nltk 3.9.1-1
reassign 1084250 python3-nltk 3.9.1-1
reassign 1084291 python3-nltk 3.9.1-1
reassign 1084292 python3-nltk 3.9.1-1
reassign 1084294 python3-nltk 3.9.1-1
reassign 1084299 python3-nltk 3.9.1-1
reassign 1084392 python3-nltk 3.9.1-1
reassign 1084300 python3-nltk 3.9.1-1
reassign 1084306 python3-nltk 3.9.1-1
reassign 1084323 python3-nltk 3.9.1-1
reassign 1084332 python3-nltk 3.9.1-1
reassign 1084333 python3-nltk 3.9.1-1
reassign 1084334 python3-nltk 3.9.1-1
reassign 1084337 python3-nltk 3.9.1-1
reassign 1084338 python3-nltk 3.9.1-1
reassign 1084339 python3-nltk 3.9.1-1
reassign 1084341 python3-nltk 3.9.1-1
reassign 1084342 python3-nltk 3.9.1-1
reassign 1084344 python3-nltk 3.9.1-1
reassign 1084345 python3-nltk 3.9.1-1
reassign 1084346 python3-nltk 3.9.1-1
reassign 1084349 python3-nltk 3.9.1-1
reassign 1084385 python3-nltk 3.9.1-1
reassign 1084386 python3-nltk 3.9.1-1
forcemerge 1084235 1084236 1084237 1084242 1084249 1084250 1084291 1084292
1084294 1084299 1084392 1084300 1084306 1084323 1084332 1084333 1084334 1084337
1084338 1084339 1084341 1084342 1084344 1084345 1084346 1084349 1084385 1084386
affects 1084235 src:a2d src:abydos src:aiodogstatsd src:blag
src:djangorestframework-api-key src:djangorestframework src:libspng
src:mailmanclient src:markdown-callouts src:mintpy src:mkdocs-literate-nav
src:mkdocs-section-index src:nlopt src:pydoctor src:python-django-pgtrigger
src:python-djangorestframework-yaml src:python-djantic src:python-igraph
src:python-inline-snapshot src:python-jellyfish src:python-markdown
src:python-mkdocs src:python-opt-einsum src:python-pipx src:python-respx
src:python-uvicorn src:twisted src:typer
thanks
On Mon, Oct 07, 2024 at 11:19:03AM +0100, Colin Watson wrote:
> On Mon, Oct 07, 2024 at 10:38:13AM +0200, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> [...]
> > /usr/lib/python3/dist-packages/nltk/stem/__init__.py:34: in
> > from nltk.stem.wordnet import WordNetLemmatizer
> > /usr/lib/python3/dist-packages/nltk/stem/wordnet.py:13: in
> > class WordNetLemmatizer:
> > /usr/lib/python3/dist-packages/nltk/stem/wordnet.py:48: in WordNetLemmatizer
> > morphy = wn.morphy
> > /usr/lib/python3/dist-packages/nltk/corpus/util.py:120: in __getattr__
> > self.__load()
> > /usr/lib/python3/dist-packages/nltk/corpus/util.py:86: in __load
> > raise e
> > /usr/lib/python3/dist-packages/nltk/corpus/util.py:81: in __load
> > root = nltk.data.find(f"{self.subdir}/{self.__name}")
> > /usr/lib/python3/dist-packages/nltk/data.py:579: in find
> > raise LookupError(resource_not_found)
> > E LookupError:
> > E **
> > E Resource [93mwordnet[0m not found.
> > E Please use the NLTK Downloader to obtain the resource:
> > E
> > E [31m>>> import nltk
> > E >>> nltk.download('wordnet')
> > E [0m
> > E For more information see: https://www.nltk.org/data.html
> > E
> > E Attempted to load [93mcorpora/wordnet[0m
> > E
> > E Searched in:
> > E - '/<>/.pybuild/cpython3_3.12_pydoctor/nltk_data'
> > E - '/usr/nltk_data'
> > E - '/usr/share/nltk_data'
> > E - '/usr/lib/nltk_data'
> > E - '/usr/share/nltk_data'
> > E - '/usr/local/share/nltk_data'
> > E - '/usr/lib/nltk_data'
> > E - '/usr/local/lib/nltk_data'
> > E **
>
> I assume this is because some downloadable data went away, though I'm
> not certain. Still, we obviously shouldn't have an implicit dependency
> on downloaded data during package builds.
>
> Carsten, what would you think of this patch to python-lunr, which fixes
> both pydoctor and twisted (and I suspect probably a bunch of other
> packages, since mkdocs also depends on python3-lunr)?
Cancel this - we don't need to change python-lunr. Sorry to bother you,
Carsten.
I tracked this down to a regression in nltk instead. This is
https://github.com/nltk/nltk/issues/3308, fixed in
https://github.com/nltk/nltk/pull/3309.
Mo, could we please apply the attached patch to nltk? I've test-built
all the affected packages against this. python-igraph has uninstallable
build-dependencies (indirectly due to https://bugs.debian.org/1084781, I
think), while python-uvicorn fails in an unrelated way (it looks as
though it ma
Bug#1084323: pydoctor: FTBFS: Resource wordnet not found.
On Mon, Oct 07, 2024 at 10:38:13AM +0200, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:
[...]
> pydoctor/test/__init__.py:13: in
> from pydoctor.templatewriter import IWriter, TemplateLookup
> pydoctor/templatewriter/__init__.py:423: in
> from pydoctor.templatewriter.writer import TemplateWriter
> pydoctor/templatewriter/writer.py:10: in
> from pydoctor.templatewriter import (
> pydoctor/templatewriter/search.py:16: in
> from lunr import lunr, get_default_builder
> /usr/lib/python3/dist-packages/lunr/__init__.py:1: in
> from lunr.lunr import lunr, get_default_builder
> /usr/lib/python3/dist-packages/lunr/lunr.py:1: in
> from lunr import languages as lang
> /usr/lib/python3/dist-packages/lunr/languages/__init__.py:34: in
> import nltk # type: ignore
> /usr/lib/python3/dist-packages/nltk/__init__.py:156: in
> from nltk.stem import *
> /usr/lib/python3/dist-packages/nltk/stem/__init__.py:34: in
> from nltk.stem.wordnet import WordNetLemmatizer
> /usr/lib/python3/dist-packages/nltk/stem/wordnet.py:13: in
> class WordNetLemmatizer:
> /usr/lib/python3/dist-packages/nltk/stem/wordnet.py:48: in WordNetLemmatizer
> morphy = wn.morphy
> /usr/lib/python3/dist-packages/nltk/corpus/util.py:120: in __getattr__
> self.__load()
> /usr/lib/python3/dist-packages/nltk/corpus/util.py:86: in __load
> raise e
> /usr/lib/python3/dist-packages/nltk/corpus/util.py:81: in __load
> root = nltk.data.find(f"{self.subdir}/{self.__name}")
> /usr/lib/python3/dist-packages/nltk/data.py:579: in find
> raise LookupError(resource_not_found)
> E LookupError:
> E **
> E Resource [93mwordnet[0m not found.
> E Please use the NLTK Downloader to obtain the resource:
> E
> E [31m>>> import nltk
> E >>> nltk.download('wordnet')
> E [0m
> E For more information see: https://www.nltk.org/data.html
> E
> E Attempted to load [93mcorpora/wordnet[0m
> E
> E Searched in:
> E - '/<>/.pybuild/cpython3_3.12_pydoctor/nltk_data'
> E - '/usr/nltk_data'
> E - '/usr/share/nltk_data'
> E - '/usr/lib/nltk_data'
> E - '/usr/share/nltk_data'
> E - '/usr/local/share/nltk_data'
> E - '/usr/lib/nltk_data'
> E - '/usr/local/lib/nltk_data'
> E **
I assume this is because some downloadable data went away, though I'm
not certain. Still, we obviously shouldn't have an implicit dependency
on downloaded data during package builds.
Carsten, what would you think of this patch to python-lunr, which fixes
both pydoctor and twisted (and I suspect probably a bunch of other
packages, since mkdocs also depends on python3-lunr)? nltk is an
optional dependency, so Suggests seems like the right representation of
it.
diff --git a/debian/changelog b/debian/changelog
index 5f97ca6..e3b3bcd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-lunr (0.7.0-2) UNRELEASED; urgency=medium
+
+ * Drop python3-nltk to Suggests.
+
+ -- Colin Watson Mon, 07 Oct 2024 11:10:01 +0100
+
python-lunr (0.7.0-1) unstable; urgency=medium
* [fc4a05d] New upstream version 0.7.0
diff --git a/debian/control b/debian/control
index ebff949..0838508 100644
--- a/debian/control
+++ b/debian/control
@@ -45,10 +45,11 @@ Description: Python implementation of Lunr.js
(Documentation)
Package: python3-lunr
Architecture: all
Depends:
- python3-nltk,
${misc:Depends},
${python3:Depends},
-Suggests: python-lunr-doc
+Suggests:
+ python-lunr-doc,
+ python3-nltk,
Description: Python implementation of Lunr.js (Python3 version)
This package includes the Python version of Lunr.js aims to bring the simple
and powerful full text search capabilities into Python guaranteeing results as
Thanks,
--
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#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#1081419: marked as pending in twisted
Control: tag -1 pending Hello, Bug #1081419 in twisted reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/twisted/-/commit/86749bee2df0120b4926cc1dd7c428279889804c Fix test_manhole on Python 3.12.6/3.13rc2 Closes: #1081419 (this message was generated automatically) -- Greetings https://bugs.debian.org/1081419
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#1080280: marked as pending in python-flask-seeder
Control: tag -1 pending Hello, Bug #1080280 in python-flask-seeder reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-flask-seeder/-/commit/56b8216abd9e9f28badfa23b59b7c5a71fd7bd6e Fix tests following the removal of "setup.py test" Closes: #1080280 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080280
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#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#1080287: marked as pending in straight.plugin
Control: tag -1 pending Hello, Bug #1080287 in straight.plugin reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/straight.plugin/-/commit/6dc61b685f9ed3ee9e9c31810df94ec0e4d185da Run tests using pytest Closes: #1080287 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080287
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#1080232: marked as pending in python-pgpdump
Control: tag -1 pending Hello, Bug #1080232 in python-pgpdump reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-pgpdump/-/commit/bb1652ca21135b6fb96e7ec96211f68df0a9af14 Run tests using pytest Closes: #1080232 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080232
Bug#1080282: marked as pending in python-potr
Control: tag -1 pending Hello, Bug #1080282 in python-potr reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-potr/-/commit/a2215fc7b8947d1d34f81e183ea9c647fde6264b Disable tests This package currently doesn't have any. Closes: #1080282 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080282
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#1080102: marked as pending in django-guardian
Control: tag -1 pending Hello, Bug #1080102 in django-guardian reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/django-guardian/-/commit/bd119de30f4aff144670917eaaf676ec405e03ba Fix tests following the removal of "setup.py test" Closes: #1080102 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080102
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#1079761: marked as pending in python-stopit
Control: tag -1 pending Hello, Bug #1079761 in python-stopit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-stopit/-/commit/39d3350ea7597babcd78ec97f9fc4ad6b5c31ca9 Don't rely on "setup.py test" in autopkgtest Closes: #1079761 (this message was generated automatically) -- Greetings https://bugs.debian.org/1079761
Bug#1080116: marked as pending in manuel
Control: tag -1 pending Hello, Bug #1080116 in manuel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/manuel/-/commit/bd8491022c52c600af08d4cd81e21856ed2c585a Fix build following the removal of "setup.py test" Closes: #1080116 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080116
Bug#1079748: marked as pending in manuel
Control: tag -1 pending Hello, Bug #1079748 in manuel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/manuel/-/commit/25a169baaace7c809b355e3c8c4057e00189d879 Don't rely on "setup.py test" in autopkgtest Closes: #1079748 (this message was generated automatically) -- Greetings https://bugs.debian.org/1079748
Bug#1079767: marked as pending in python-precis-i18n
Control: tag -1 pending Hello, Bug #1079767 in python-precis-i18n reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-precis-i18n/-/commit/9c128f6f94071d08c139af1ff4ebbd86e1d1c1cd Don't rely on "setup.py test" in autopkgtest Closes: #1079767 (this message was generated automatically) -- Greetings https://bugs.debian.org/1079767
Bug#1058236: marked as pending in routes
Control: tag -1 pending Hello, Bug #1058236 in routes reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/routes/-/commit/919e4c38372a08aebc8bce0ea68bc8b0e042e651 Don't use obsolete TestCase.assert_ Closes: #1058236 (this message was generated automatically) -- Greetings https://bugs.debian.org/1058236
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: marked as pending in buildbot
Control: tag -1 pending Hello, Bug #1073001 in buildbot reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/buildbot/-/commit/85a3a35f865359c1f4c490e845469380202e7cfb Add compatibility with SQLAlchemy 2.0 and Twisted 24.7.0 Closes: #1073001 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073001
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#1079757: marked as pending in supervisor
Control: tag -1 pending Hello, Bug #1079757 in supervisor reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/supervisor/-/commit/ea8be48cf0094cc11f38ca110470767a0109ab67 Switch to autopkgtest-pkg-pybuild Closes: #1079757 (this message was generated automatically) -- Greetings https://bugs.debian.org/1079757
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#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#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#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#1067325: marked as pending in python-stdlib-list
Control: tag -1 pending Hello, Bug #1067325 in python-stdlib-list reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-stdlib-list/-/commit/eaacb15a5e8f1c753c2b1feb299d86e6557762c1 Use pybuild-plugin-pyproject Closes: #1067325 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067325
Bug#1067287: marked as pending in sen
Control: tag -1 pending Hello, Bug #1067287 in sen reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/sen/-/commit/02844a7afae26c437c989abee3659ee55487e5cd Cherry-pick upstream patches for python-docker 7.x compatibility Closes: #1067287 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067287
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#1076903: marked as pending in pipenv
Control: tag -1 pending Hello, Bug #1076903 in pipenv reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pipenv/-/commit/9de33b6b9e61b0bc5258aebac0a9e9ac0ba03781 Simplify removal of stray files Some build system versions (probably setuptools, though I'm not certain of that) install files in `/usr/lib/python*/dist-packages/build` for this package. We don't want these, as they're outside our namespace and are duplicates of files in `/usr/lib/python*/dist-packages/pipenv`. The previous attempt to remove some of those files also caused build failures with build system versions that don't install them in the first place. Closes: #1076903 (this message was generated automatically) -- Greetings https://bugs.debian.org/1076903
Bug#1077918: marked as pending in psycopg3
Control: tag -1 pending Hello, Bug #1077918 in psycopg3 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/psycopg3/-/commit/6d817e71e69eaecf84078f522bc6c255c8128115 Fix architecture-dependent-only builds Closes: #1077918 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077918
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#1078411: marked as pending in python-tornado
Control: tag -1 pending Hello, Bug #1078411 in python-tornado reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-tornado/-/commit/fa3ce84627ff9a0b73eb486b3f593e57c19b93f0 Fix tests with Twisted 24.7.0 Closes: #1078411 (this message was generated automatically) -- Greetings https://bugs.debian.org/1078411
Bug#1052788: marked as pending in python-asyncssh
Control: tag -1 pending Hello, Bug #1052788 in python-asyncssh reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-asyncssh/-/commit/279c2e5e3437dd72a51fa874b940de611968f1b2 Deduplicate results from getaddrinfo Closes: #1052788 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052788
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#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#1078721: 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#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#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#1078145: marked as pending in trn4
Control: tag -1 pending Hello, Bug #1078145 in trn4 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/trn4/-/commit/4fc8f4632ee677e35ab7d5da19c7c534b72a111e Don't rely on implicit int types Closes: #1078145 (this message was generated automatically) -- Greetings https://bugs.debian.org/1078145
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#1077765: marked as pending in openssh
Control: tag -1 pending Hello, Bug #1077765 in openssh reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ssh-team/openssh/-/commit/b7f99430d6680677d4ae7ef30acc14ae7ff46dbd Don't close sockets passed by systemd socket activation Closes: #1077765 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077765
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#1074669: marked as pending in python3-simpletal
Control: tag -1 pending Hello, Bug #1074669 in python3-simpletal reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python3-simpletal/-/commit/953ba19a7b38919188dcca03758e3b0116dbab85 Use importlib rather than imp.load_source Closes: #1074669 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074669
Bug#1077118: marked as pending in password-store
Control: tag -1 pending Hello, Bug #1077118 in password-store reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/password-store/-/commit/1746711e2b4d534c610ae5a3af59035a99eb72eb Rebuild against newer dh-elpa Closes: #1077118 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077118
Bug#1074730: marked as pending in python-tenacity
Control: tag -1 pending Hello, Bug #1074730 in python-tenacity reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-tenacity/-/commit/501e253bcb6c17f00095cc29eb7a5c6f3d8b8339 Update upstream source from tag 'upstream/8.4.2+really8.4.1' Update to upstream version '8.4.2+really8.4.1' with Debian dir 674549fbc7ee0b71b8dca2270f5da185e6eea646 Closes: #1074690, #1074730 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074730
Bug#1074690: marked as pending in python-tenacity
Control: tag -1 pending Hello, Bug #1074690 in python-tenacity reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-tenacity/-/commit/501e253bcb6c17f00095cc29eb7a5c6f3d8b8339 Update upstream source from tag 'upstream/8.4.2+really8.4.1' Update to upstream version '8.4.2+really8.4.1' with Debian dir 674549fbc7ee0b71b8dca2270f5da185e6eea646 Closes: #1074690, #1074730 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074690
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#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#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#1057599: marked as pending in python-repoze.sphinx.autointerface
Control: tag -1 pending Hello, Bug #1057599 in python-repoze.sphinx.autointerface reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-repoze.sphinx.autointerface/-/commit/23fd649ca35193891d8b38294463fffc95cf9f0b Fix tests with Sphinx 7.2.x Closes: #1057599 (this message was generated automatically) -- Greetings https://bugs.debian.org/1057599
Bug#1073996: marked as pending in twisted
Control: tag -1 pending Hello, Bug #1073996 in twisted reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/twisted/-/commit/144b7904d2836e46877be780b57707cf3fed590b Patch: fix test_flatten in autopkgtest Closes: #1073996 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073996
Bug#1069838: marked as pending in khard
Control: tag -1 pending Hello, Bug #1069838 in khard reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/khard/-/commit/03c0c75164f51cc49a85dec4d1917d71ba08052a Avoid circular imports Closes: #1069838 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069838
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#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#1070112: marked as pending in ipykernel
Control: tag -1 pending Hello, Bug #1070112 in ipykernel reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/ipykernel/-/commit/09a2d18d16928cd5b4f1fdb07045efb1291ecbc6 Add compat with pytest 8 Closes: #1070112 (this message was generated automatically) -- Greetings https://bugs.debian.org/1070112
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]
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Control: fixed -1 transaction/4.0-2 On Fri, Jun 07, 2024 at 09:39:20PM +0200, Paul Gevers wrote: > Your package is only blocked because the arch:all binary package(s) aren't > built on a buildd. Unfortunately the Debian infrastructure doesn't allow > arch:all packages to be properly binNMU'ed. Hence, I will shortly do a > no-changes source-only upload to DELAYED/15, closing this bug. Please let me > know if I should delay or cancel that upload. This was fixed by transaction 4.0-2, and it looks like either you cancelled your upload or it was automatically dropped from the DELAYED queue. transaction (4.0-2) unstable; urgency=medium * QA upload * Source-only reupload -- Bastian Germann Wed, 12 Jun 2024 20:49:57 +0000 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
Control: severity -1 important On Thu, May 16, 2024 at 12:10:41PM +, Dan Poltawski wrote: > Thanks for your response - I hadn't quite noticed that this was legacy grub > (and > had kinda made the assumption the Debian upgrades had forced the upgrade). > > I have migrated to GRUB 2 and can confirm this resolves the issue. OK, good. I tried reproducing this in a VM and couldn't; I suspect that it's something relatively subtle about the filesystem structure that doesn't happen to everyone. As such I'm downgrading this to just below release-critical, since on its own I don't think it quite justifies removing grub-legacy from testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071893: marked as pending in ipywidgets
Control: tag -1 pending Hello, Bug #1071893 in ipywidgets reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/05c8043c28609207c5e24be1d255f036336a3a17 Fix compatibility with pytest 8 Closes: #1071893 (this message was generated automatically) -- Greetings https://bugs.debian.org/1071893
Bug#1066822: linuxtv-dvb-apps: diff for NMU version 1.1.1+rev1500-1.5
Control: tags 961967 + patch
Control: tags 961967 + pending
Control: tags 1066822 + patch
Control: tags 1066822 + pending
Dear maintainer,
I've prepared an NMU for linuxtv-dvb-apps (versioned as
1.1.1+rev1500-1.5) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
I would have sent these as git merge requests of some form, but
Vcs-Git/Vcs-Browser are still set to the obsolete anonscm.debian.org and
I couldn't find any corresponding repositories on salsa, so this was the
best I could do; you should be able to find more detailed history via
"dgit clone linuxtv-dvb-apps" if you need it.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2020-07-26 19:42:38.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2024-05-23 16:49:59.0 +0100
@@ -1,3 +1,11 @@
+linuxtv-dvb-apps (1.1.1+rev1500-1.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around UAPI break in Linux input events (Closes: #1066822).
+ * Set Architecture to linux-any (Closes: #961967).
+
+ -- Colin Watson Thu, 23 May 2024 16:49:59 +0100
+
linuxtv-dvb-apps (1.1.1+rev1500-1.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/control linuxtv-dvb-apps-1.1.1+rev1500/debian/control
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2016-04-07 17:11:50.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2024-05-23 16:49:59.0 +0100
@@ -11,7 +11,7 @@
Homepage: http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
Package: dvb-apps
-Architecture: any
+Architecture: linux-any
Depends:
${shlibs:Depends},
makedev | udev,
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2020-07-26 19:38:59.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2024-05-23 16:49:59.0 +0100
@@ -11,3 +11,4 @@
dst_test-no-set-id.patch
glibc-stime.patch
gcc-10-sid-redefinition.patch
+work-around-uapi-break-in-linux-input-ev.patch
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 1970-01-01 01:00:00.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 2024-05-23 16:49:59.0 +0100
@@ -0,0 +1,25 @@
+From: Colin Watson
+Date: Thu, 23 May 2024 16:38:37 +0100
+X-Dgit-Generated: 1.1.1+rev1500-1.5 5d2fca4cdce8ddcdf7e13a0681da7b381301
+Subject: Work around UAPI break in Linux input events
+
+See
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f.
+
+Closes: #1066822
+
+---
+
+diff --git a/test/evtest.c b/test/evtest.c
+index a61593e..73fb5af 100644
+--- a/test/evtest.c
b/test/evtest.c
+@@ -241,7 +241,7 @@ int main (int argc, char **argv)
+
+ for (i = 0; i < rd / (int) sizeof(struct input_event); i++)
+ printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %d\n",
+-ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+ events[ev[i].type] ? events[ev[i].type] : "?",
+ ev[i].code,
+ names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
On Wed, May 08, 2024 at 06:31:53AM +0100, Dan Poltawski wrote: > After upgrading to linux-image-5.10.0-29 the system fails to boot with > grub 'Error 16: Inconsistent filesystem structure'. Booting into > linux-image-5.10.0-28-amd64 > and the system is once again bootable > > The console displays: > Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64' > root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 > kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8 > le0f1 ro > [Linux-bzImage, setup=0x3c00, size=0x6b5f40] > Initrd /boot/initrd. img-5.10.0-29-amd64 > Error 16: Inconsistent filesystem structure > Press any key to continue...- If I find time I'll have a look at this (probably just by looking through GRUB 2 for candidate backports and hoping that one of them helps). However, I should warn you that GRUB Legacy is extremely very unmaintained at this point; I've really just been doing last-resort patching for years, and this normally hasn't included debugging its filesystem code. It'd be in your interests to migrate to GRUB 2. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070403: marked as pending in openssh-ssh1
Control: tag -1 pending Hello, Bug #1070403 in openssh-ssh1 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ssh-team/openssh-ssh1/-/commit/237920039b48da3992bd91a16a123e7a9d50e103 Handle OpenSSL >=3 ABI compatibility Closes: #1070403 (this message was generated automatically) -- Greetings https://bugs.debian.org/1070403
Bug#1069756: marked as pending in readability
Control: tag -1 pending Hello, Bug #1069756 in readability reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/readability/-/commit/8c36e8dac6b5aa7b09c55840971a988b36f6f77c Add (build-)dependency on python3-lxml-html-clean Closes: #1069756 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069756
Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean
On Wed, Apr 24, 2024 at 11:16:17AM +0200, Étienne Mollier wrote: > As far as I could witness, replacing the python3-lxml build > dependency by python3-lxml-html-clean resolved the issue at > least for the bulid time test. The package is subject to > autodep8 python3 test, which raises that the binary package will > also need it dependencies adjusted; this suggests the setup.py > would probably need patching so this is addressed appropriately > at a larger scale than Debian's. Based on https://github.com/buriy/python-readability/issues/179, it looks as though upstream intends to switch to bleach; I think we can just patch setup.py in Debian in the meantime though. I'll do that. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069608: marked as pending in topplot
Control: tag -1 pending Hello, Bug #1069608 in topplot reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/topplot/-/commit/3b37e8bd6872c31e18cac5f8fd54039ca9919942 Add python3-all to autopkgtest Depends Closes: #1069608 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069608
Bug#1069360: marked as pending in python-cytoolz
Control: tag -1 pending Hello, Bug #1069360 in python-cytoolz reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-cytoolz/-/commit/3f462fede0bcd4468c9dd27b6b9f23c033fb611b Fix test failure on Python 3.11.9/3.12.3/main Closes: #1069360 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069360
Bug#1069818: marked as pending in toolz
Control: tag -1 pending Hello, Bug #1069818 in toolz reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/toolz/-/commit/59155505e05c393226e55cad4e0e5de690df3d07 Fix test failure on Python 3.11.9/3.12.3/main Closes: #1069818 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069818
Bug#1066788: gyoto: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 check-lorene returned exit code 2
Control: tag -1 patch On Wed, Mar 13, 2024 at 03:56:54PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/yorick' > > Makefile:136: warning: overriding recipe for target 'check-dll' > > ../yorick/Makepkg:158: warning: ignoring old recipe for target 'check-dll' > > make[3]: 'check-lorene' is up to date. > > make[3]: Leaving directory '/<>/yorick' > > make[2]: Leaving directory '/<>' > > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" > > VERBOSE=1 check-lorene returned exit code 2 A more relevant part was: ImportError: /<>/python/gyoto/_std.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE I sent a patch for this upstream as https://github.com/gyoto/Gyoto/pull/17. Here's a patch to fix the Debian package in the meantime. -- Colin Watson (he/him) [cjwat...@debian.org] >From 19e6f4bcdc33cbd7995027bf56ec3b5a7125ea5f Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Wed, 24 Apr 2024 15:25:19 +0100 Subject: [PATCH] Remove undefined operator<< declaration for PolishDoughnut Closes: #1066788 --- debian/changelog | 7 ++ .../patches/remove-polish-doughnut-operator | 25 +++ debian/patches/series | 1 + 3 files changed, 33 insertions(+) create mode 100644 debian/patches/remove-polish-doughnut-operator diff --git a/debian/changelog b/debian/changelog index 8f74908..0188483 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +gyoto (2.0.2-1.2) UNRELEASED; urgency=medium + + * Remove undefined operator<< declaration for PolishDoughnut (closes: +#1066788). + + -- Colin Watson Wed, 24 Apr 2024 14:32:29 +0100 + gyoto (2.0.2-1.1) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/patches/remove-polish-doughnut-operator b/debian/patches/remove-polish-doughnut-operator new file mode 100644 index 000..ead15f5 --- /dev/null +++ b/debian/patches/remove-polish-doughnut-operator @@ -0,0 +1,25 @@ +Description: Remove undefined operator<< declaration for PolishDoughnut + On current Debian systems this resulted in `undefined symbol: + _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE` while running tests. +Bug-Debian: https://bugs.debian.org/1066788 +Forwarded: https://github.com/gyoto/Gyoto/pull/17 +Last-Update: 2024-04-24 + +Index: b/include/GyotoPolishDoughnut.h +=== +--- a/include/GyotoPolishDoughnut.h b/include/GyotoPolishDoughnut.h +@@ -262,13 +262,6 @@ + // Outputs + // --- + public: +- +- /// Display +- friend std::ostream& operator<<(std::ostream& , const PolishDoughnut& ) ; +- +- public: +- +- + }; + + #endif diff --git a/debian/patches/series b/debian/patches/series index b9e8f3b..b8e9081 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ interpreter-path +remove-polish-doughnut-operator # This patch is conditionally applied by debian/rules: # no-fp-ilogb0 -- 2.43.0
Bug#1058888: pyferret FTBSF on several architectures: dh_install: error: missing files, aborting
Control: retitle -1 pyferret FTBFS on several architectures: dh_install: error: missing files, aborting Control: tag -1 patch On Sun, Dec 17, 2023 at 08:24:07PM +0200, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=pyferret&ver=7.6.5-5 > > ... >dh_install -a > dh_install: warning: Cannot find (any matches for) > "debian/tmp/ext_func/pylibs" (tried in ., debian/tmp) > > dh_install: warning: python3-ferret missing files: debian/tmp/ext_func/pylibs > install -m0755 -d debian/python3-ferret//usr/bin > cp --reflink=auto -a ./debian/pyferret3 debian/python3-ferret//usr/bin/ > install -m0755 -d debian/python3-ferret//usr/lib/python3/dist-packages > cp --reflink=auto -a > ./debian/tmp/lib/python3.11/libpyferret.cpython-311-powerpc64le-linux-gnu.so > ./debian/tmp/lib/python3.12/libpyferret.cpython-312-powerpc64le-linux-gnu.so > ./install/local/lib/python3.11/dist-packages/__pycache__ > ./install/local/lib/python3.11/dist-packages/gcircle-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/gcircle.py > ./install/local/lib/python3.11/dist-packages/pipedviewer > ./install/local/lib/python3.11/dist-packages/pipedviewer-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/pyferret > ./install/local/lib/python3.11/dist-packages/pyferret-7.65-py3.11.egg-info > debian/python3-ferret//usr/lib/python3/dist-packages/ > install -m0755 -d > debian/python3-ferret//usr/share/bash-completion/completions/ > cp --reflink=auto -a ./debian/bash_completion.d/pyferret3 > debian/python3-ferret//usr/share/bash-completion/completions// > dh_install: error: missing files, aborting > make: *** [debian/rules:8: binary-arch] Error 25 I've proposed https://salsa.debian.org/science-team/pyferret/-/merge_requests/3 to fix this. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068349: marked as pending in nbconvert
Control: tag -1 pending Hello, Bug #1068349 in nbconvert reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/nbconvert/-/commit/7131b104d389851c2a15996362f2088319ca46ff (Build-)depend on python3-lxml-html-clean Closes: #1068349 (this message was generated automatically) -- Greetings https://bugs.debian.org/1068349
