Bug#1069986: dublin-traceroute: Manual build-depends on NBS package libtins4.0
Source: dublin-traceroute Version: 0.4.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package has a manual build-depends on libtins4.0, which is NBS. It has been renamed libtins4.5. Once it is decrufted, this package will FTBFS. Scott K
Bug#1069985: python-cobra: Manual build-depends on NBS package libsbml5
Source: python-cobra Version: 0.26.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package build-depends on the NBS package libsbml5. It has been renamed libsbml5t64. Once the package is decrufted, this one will FTBFS. Please update your build-depends. Scott K
Bug#1069984: alire: Build-depends on NBS package libgnatcoll21-dev
Source: alire Version: 1.2.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package libgnatcoll21-dev has been renamed to libgnatcoll-dev. Once libgnatcoll21-dev is decfufted, it will FTBFS. Please update your build depends. Scott K
Bug#1069983: dwarf-fortress: Manual build-depends on NBS package libgtk2.0-0
Source: dwarf-fortress Version: 0.47.04+dfsg1-1 Severity: serious Tags: ftbfs Justification: fails to build from source The package has a manual build-depends on libgtk2.0-0, which has been replaced by libgtk2.0-0t64. Once it has been decrufted, the package will no longer build. Scott K
Bug#1069982: theli: Manual build-depends on NBS package libcurl4
Source: theli Version: 3.1.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Once libcurl4 is decrufted, the package will no longer build. The libcurl4 package has been replaced by libcurl4t64. Scott K
Bug#1069963: python-nbxmpp: Build-depends on NBS package libglib2.0-0
Source: python-nbxmpp Version: 4.5.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source This package has a hard coded build-depends on libglib2.0-0, which is NBS and the package will FTBFS once it is decrufted. It was renamed libglib2.0-0t64 as part of the 64 bit time transition. Please update your build-depends. Scott K
Bug#1069004: casacore-data-services: Hard coded build-depends on decrufted lib libcasa-meas7
Package: casacore-data-services Version: 2-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Will now FTBFS due to missing build-depends. Scott K
Bug#1029735: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Sun, 21 Jan 2024 12:09:30 -0500 Scott Kitterman wrote: > As we approach the first anniversary for this bug, an update: > > 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 has been removed from Trixie, bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063476: the sanesecurity configuration is not suitable for a release
On Fri, 16 Feb 2024 09:17:40 -0500 Scott Kitterman wrote: > On Thu, 8 Feb 2024 19:35:50 +0100 Marco d'Itri wrote: > > Source: fangfrisch > > Version: 1.7.0-1 > > Severity: grave > > Tags: upstream > > > > Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 > > > > The sanesecurity section of default configuration, if enabled, relies on > > an unofficial HTTP mirror which is seriously overloaded and probably > > seriously expensive for their operators, since it is located in > > Australia. > > The only other known HTTP mirror is mentioned on > > https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague > > note about it being available to the public. > > > > Until fangfrisch will implement rsync support, I do not think that it is > > safe to include fangfrisch in a Debian release due to the possible > > effect on unsuspecting third party mirrors. > > > > This has also been discussed upstream: > > https://github.com/rseichter/fangfrisch/issues/30 > > I don't know that I'd call this fixed upstream, since the package is not > directly using rsync, but the fact that he's now rsyncing from sanesecurity > and running his own mirror is progress (that only person he can DoS is > himself) is progress. > > If we update to 1.8.0, I don't think we should mark this bug done, but it > might be reasonable to change the severity to Important. What do you think? Upon further reflection, I'm going to mark this as done in 1.8.0. The specific issue raised in the bug is resolved. Direct support for rsync would be better, but I think we've cleared this particular hurdle for releasability. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063476: the sanesecurity configuration is not suitable for a release
On Thu, 8 Feb 2024 19:35:50 +0100 Marco d'Itri wrote: > Source: fangfrisch > Version: 1.7.0-1 > Severity: grave > Tags: upstream > > Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 > > The sanesecurity section of default configuration, if enabled, relies on > an unofficial HTTP mirror which is seriously overloaded and probably > seriously expensive for their operators, since it is located in > Australia. > The only other known HTTP mirror is mentioned on > https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague > note about it being available to the public. > > Until fangfrisch will implement rsync support, I do not think that it is > safe to include fangfrisch in a Debian release due to the possible > effect on unsuspecting third party mirrors. > > This has also been discussed upstream: > https://github.com/rseichter/fangfrisch/issues/30 I don't know that I'd call this fixed upstream, since the package is not directly using rsync, but the fact that he's now rsyncing from sanesecurity and running his own mirror is progress (that only person he can DoS is himself) is progress. If we update to 1.8.0, I don't think we should mark this bug done, but it might be reasonable to change the severity to Important. What do you think? Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063752: custodian: Inappriate maintainer address
Source: custodian Version: 2024.1.9-2 Severity: serious Justification: Policy 3.3 Policy 3.3 says that maintainer addresses must accept mail from Debian role accounts. This one, apparently, does not: From: debichem-devel-ow...@alioth-lists.debian.net To: ftpmas...@ftp-master.debian.org Sender: Debichem-devel List-Id:Debichem development list Date: 2/11/24 10:10 PM Spam Status:Spamassassin  You are not allowed to post to this mailing list From: a domain which publishes a DMARC policy of reject or quarantine, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at debichem-devel-ow...@alioth-lists.debian.net. Scott K
Bug#1060934: pycountry: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13
It's been a couple of weeks and no action upstream. I'll plan on uploading
this unless you'd rather I hold off for some reason.
Scott K
On Wed, 24 Jan 2024 16:56:30 -0500 Scott Kitterman
wrote:
> On Tue, 16 Jan 2024 20:41:58 +0100 Lucas Nussbaum wrote:
> > Source: pycountry
> > Version: 23.12.11+ds1-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240115 ftbfs-trixie
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
>
> This is due to changes in the recent iso-codes upload. the patch below fixes
> it so it should work with either version:
>
> --- pycountry-23.12.11+ds1.orig/src/pycountry/__init__.py
> +++ pycountry-23.12.11+ds1/src/pycountry/__init__.py
> @@ -169,7 +169,8 @@ class SubdivisionHierarchy(pycountry.db.
> kw["parent_code"] = None
> super().__init__(**kw)
> self.country_code = self.code.split("-")[0]
> -if self.parent_code is not None:
> +if (self.parent_code is not None and
> +self.country_code != self.parent_code.split("-")[0]):
> self.parent_code = f"{self.country_code}-{self.parent_code}"
>
> @property
>
> Please let me know if you don't want an NMU. This will eventually cause
> xml2rfc to be removed, so I'll NMU at some point unless you want to take
care
> of it first (thanks if you do).
>
> Scott K
=<2567281.9CzbHMAgVU@zini-1880>
signature.asc
Description: This is a digitally signed message part.
Bug#1060934: pycountry: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13
On Tue, 16 Jan 2024 20:41:58 +0100 Lucas Nussbaum wrote:
> Source: pycountry
> Version: 23.12.11+ds1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
This is due to changes in the recent iso-codes upload. the patch below fixes
it so it should work with either version:
--- pycountry-23.12.11+ds1.orig/src/pycountry/__init__.py
+++ pycountry-23.12.11+ds1/src/pycountry/__init__.py
@@ -169,7 +169,8 @@ class SubdivisionHierarchy(pycountry.db.
kw["parent_code"] = None
super().__init__(**kw)
self.country_code = self.code.split("-")[0]
-if self.parent_code is not None:
+if (self.parent_code is not None and
+self.country_code != self.parent_code.split("-")[0]):
self.parent_code = f"{self.country_code}-{self.parent_code}"
@property
Please let me know if you don't want an NMU. This will eventually cause
xml2rfc to be removed, so I'll NMU at some point unless you want to take care
of it first (thanks if you do).
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#1060917: closing 1060917
close 1060917 1:10.11.6-0+deb12u1 thanks
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
On Wed, 17 Jan 2024 09:05:47 -0500 Scott Kitterman wrote: > On Wednesday, January 17, 2024 9:03:29 AM EST Richard Rosner wrote: > > I've updated all mariadb packages to 10.11.6 and all postfix packages. > > Everything still working. > > > Excellent news. Thanks for testing. Postfix packages in bookworm-proposed-updates have been rebuilt against the new mariadb, so I think this can be closed now. If anyone runs into this problem with the packages from bookworm-updates/stable-updates, install the rebuilt version from bookworm/stable-proposed-updates. After the next point release, this will be entirely OBE. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1061162: pypdf2: Do not release with Trixie
Source: pypdf2 Version: 2.12.1-4 Severity: serious Tags: upstream Justification: Maintainer opinion PyPDF2 has been replaced by pypdf upstream. We should not release this package with Trixie. Rdepends should be either ported or removed. Scott K
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
On Wednesday, January 17, 2024 9:03:29 AM EST Richard Rosner wrote: > I've updated all mariadb packages to 10.11.6 and all postfix packages. > Everything still working. > Excellent news. Thanks for testing. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
They accepted mariadb 10.11.6 as a proposed update and I rebuilt postfix again. Updated packages (and the first ones also, note the slightly different revision number) at the same location: https://kitterman.com/debian/ I'm not sure if you'll need to upgrade your mariadb packages. If so, they can currently be found in incoming: http://incoming.debian.org/debian-buildd/pool/main/m/mariadb/ After the next dinstall they will be available in the bookworm-proposed updates repository. For incoming, you'll need to wget the binaries and use dpkg to install them. For bookworm-proposed-updates, you can use apt with an appropriate entry in your sources.list. Please test and let me know how it goes: Thanks, Scott K On Tuesday, January 16, 2024 3:39:43 PM EST Richard Rosner wrote: > Good to know. Thanks. > > > Am Dienstag, 16. Januar 2024 21:00 CET, schrieb Scott Kitterman > : So, the magic needed to build the new update > exceeds my grasp, but it's debian/changelog discusses fixing regressions. > On that basis, I think the thing to do is reassign the bug to mariadb and > mark it as affecting postfix. I'll also bring it to the stable release > manager's attention. > > Scott K > > On Tuesday, January 16, 2024 2:36:23 PM EST Scott Kitterman wrote: > > Excellent. On that basis, I think blaming mariadb for the regression is > > appropriate. I see there's another mariadb update pending. If would up for > > another test, I'd like to see if that update solves the problem. I'll > > build another set of packages against that and if that works, then we just > > need to make sure we get that update accepted and rebuild postfix. > > > > Scott K signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
So, the magic needed to build the new update exceeds my grasp, but it's debian/changelog discusses fixing regressions. On that basis, I think the thing to do is reassign the bug to mariadb and mark it as affecting postfix. I'll also bring it to the stable release manager's attention. Scott K On Tuesday, January 16, 2024 2:36:23 PM EST Scott Kitterman wrote: > Excellent. On that basis, I think blaming mariadb for the regression is > appropriate. I see there's another mariadb update pending. If would up for > another test, I'd like to see if that update solves the problem. I'll > build another set of packages against that and if that works, then we just > need to make sure we get that update accepted and rebuild postfix. > > Scott K > > On Tuesday, January 16, 2024 2:25:13 PM EST Richard Rosner wrote: > > These packages do work without a problem. > > > > Am Dienstag, 16. Januar 2024 19:35 CET, schrieb Scott Kitterman > > : Rebuild binaries are available (for the moment) > > at: > > > > https://kitterman.com/debian/ > > > > I'll remove them once we've done testing. That's all the binaries built by > > postfix. You'll need to download and then use dpkg -i to install all the > > ones you have on your system, not just postfix-mysql. At a minimum it will > > be postfix and postfix-mysql. > > > > Let me know how it goes. > > > > Scott K signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
Excellent. On that basis, I think blaming mariadb for the regression is appropriate. I see there's another mariadb update pending. If would up for another test, I'd like to see if that update solves the problem. I'll build another set of packages against that and if that works, then we just need to make sure we get that update accepted and rebuild postfix. Scott K On Tuesday, January 16, 2024 2:25:13 PM EST Richard Rosner wrote: > These packages do work without a problem. > > Am Dienstag, 16. Januar 2024 19:35 CET, schrieb Scott Kitterman > : Rebuild binaries are available (for the moment) at: > > https://kitterman.com/debian/ > > I'll remove them once we've done testing. That's all the binaries built by > postfix. You'll need to download and then use dpkg -i to install all the > ones you have on your system, not just postfix-mysql. At a minimum it will > be postfix and postfix-mysql. > > Let me know how it goes. > > Scott K signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
Rebuild binaries are available (for the moment) at: https://kitterman.com/debian/ I'll remove them once we've done testing. That's all the binaries built by postfix. You'll need to download and then use dpkg -i to install all the ones you have on your system, not just postfix-mysql. At a minimum it will be postfix and postfix-mysql. Let me know how it goes. Scott K On Tuesday, January 16, 2024 1:14:02 PM EST Scott Kitterman wrote: > It's slightly more complicated because you have to make sure you get the old > version of mariadb. I'll build it and send you a link. > > Scott K > > On Tuesday, January 16, 2024 1:08:51 PM EST Richard Rosner wrote: > > Would that be more than > > > > sudo apt build-dep postfix-mysql > > sudo apt install build-essential > > apt source postfix-mysql > > cd postfix-mysql* > > dpkg-buildpackage -us -uc > > > > ? Otherwise, if you want to build it, I can test it, no problem. > > > > > > Am Dienstag, 16. Januar 2024 18:19 CET, schrieb Scott Kitterman > > : I agree it's odd. I don't use postfix with any of > > the external map types, so this isn't something I can really test. > > > > Can you rebuild 3.7.9 against the older mariadb or if not, and I build it, > > will you test it? > > > > Scott K > > > > On January 16, 2024 5:05:54 PM UTC, Richard Rosner > aachen.de> wrote: > > >No Idea when was the last update to mariadb, but the fact that the stable > > >version has problems the stable-updates version doesn't while not > > >changing > > >anything else shows that something is broken. Maybe just the > > >communication > > >with postfix. Maybe the breaking change was in postfix and not > > >postfix-mysql, I can't tell. Just that v3.7.9 refuses to accept mysql as > > >a > > >valid option. Also, for me the logs look like postfix doesn't know what > > >it > > >should do with mysql, not like it can't reach a mysql server= signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
It's slightly more complicated because you have to make sure you get the old version of mariadb. I'll build it and send you a link. Scott K On Tuesday, January 16, 2024 1:08:51 PM EST Richard Rosner wrote: > Would that be more than > > sudo apt build-dep postfix-mysql > sudo apt install build-essential > apt source postfix-mysql > cd postfix-mysql* > dpkg-buildpackage -us -uc > > ? Otherwise, if you want to build it, I can test it, no problem. > > > Am Dienstag, 16. Januar 2024 18:19 CET, schrieb Scott Kitterman > : I agree it's odd. I don't use postfix with any of > the external map types, so this isn't something I can really test. > > Can you rebuild 3.7.9 against the older mariadb or if not, and I build it, > will you test it? > > Scott K > > On January 16, 2024 5:05:54 PM UTC, Richard Rosner wrote: > >No Idea when was the last update to mariadb, but the fact that the stable > >version has problems the stable-updates version doesn't while not changing > >anything else shows that something is broken. Maybe just the communication > >with postfix. Maybe the breaking change was in postfix and not > >postfix-mysql, I can't tell. Just that v3.7.9 refuses to accept mysql as a > >valid option. Also, for me the logs look like postfix doesn't know what it > >should do with mysql, not like it can't reach a mysql server= signature.asc Description: This is a digitally signed message part.
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
I agree it's odd. I don't use postfix with any of the external map types, so this isn't something I can really test. Can you rebuild 3.7.9 against the older mariadb or if not, and I build it, will you test it? Scott K On January 16, 2024 5:05:54 PM UTC, Richard Rosner wrote: > >No Idea when was the last update to mariadb, but the fact that the stable >version has problems the stable-updates version doesn't while not changing >anything else shows that something is broken. Maybe just the communication >with postfix. Maybe the breaking change was in postfix and not postfix-mysql, >I can't tell. Just that v3.7.9 refuses to accept mysql as a valid option. >Also, for me the logs look like postfix doesn't know what it should do with >mysql, not like it can't reach a mysql server=
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
On Tue, 16 Jan 2024 15:09:18 +0100 Richard Rosner wrote: > Package: postfix-mysql > Version: 3.7.9-0+deb12u1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > With the update in stable-updates, this package seems to be no longer working. removing it and going back to 3.7.6 solves the issue. This is what it writes to journal: > > Jan 16 14:58:32 mail postfix/smtpd[14969]: error: unsupported dictionary type: mysql > Jan 16 14:58:32 mail postfix/smtpd[14969]: connect from localhost[127.0.0.1] > Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: error: unsupported dictionary type: mysql > Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: mysql:/etc/ postfix/mysql-forwards.cf is unavailable. unsupported dictionary type: mysql > Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: virtual_alias_domains: mysql:/etc/postfix/mysql-forwards.cf: table lookup problem > Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: mysql:/etc/ postfix/mysql-forwards.cf is unavailable. unsupported dictionary type: mysql > Jan 16 14:58:32 mail postfix/trivial-rewrite[14972]: warning: virtual_alias_domains: mysql:/etc/postfix/mysql-forwards.cf: table lookup problem > Jan 16 14:58:32 mail postfix/smtpd[14969]: warning: mysql:/etc/postfix/mysql- forwards.cf is unavailable. unsupported dictionary type: mysql > Jan 16 14:58:32 mail postfix/smtpd[14969]: warning: mysql:/etc/postfix/mysql- forwards.cf lookup error for "recei...@domain.de" > Jan 16 14:58:32 mail postfix/smtpd[14969]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 : Temporary lookup failure; from= to= proto=ESMTP helo= > > So it simply stops providing the mysql support it was made for, which renders postfix itself unusable unless you where to move away from mysql. > > > -- System Information: > Debian Release: 12.4 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages postfix-mysql depends on: > ii libc62.36-9+deb12u3 > ii libmariadb3 1:10.11.4-1~deb12u1 > ih postfix 3.7.9-0+deb12u1 I'm not sure where this comes from. There are no mysql related changes in this update. I note that the mariadb version is different, so I would think it's more likely the issue is related to a change there. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1060427: python3-appdirs: Do not release with trixie
Package: python3-appdirs Version: 1.4.4-4 Severity: serious Justification: maintainer determination This is dead upstream and easily replacable with platformdirs. Rather than release trixie with appdirs, remaining users should port to platformdirs instead. Scott K
Bug#1056225: marked as pending in aioquic
Control: tag -1 pending Hello, Bug #1056225 in aioquic 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/aioquic/-/commit/9487336e0263f26b8a184b8e92b95903dd99be71 New upstream release (Closes: #1056225) * New upstream release (Closes: #1056225) - Refresh patches (this message was generated automatically) -- Greetings https://bugs.debian.org/1056225
Bug#1056225: marked as pending in aioquic
Control: tag -1 pending Hello, Bug #1056225 in aioquic 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/aioquic/-/commit/9487336e0263f26b8a184b8e92b95903dd99be71 New upstream release (Closes: #1056225) * New upstream release (Closes: #1056225) - Refresh patches (this message was generated automatically) -- Greetings https://bugs.debian.org/1056225
Bug#1054485: postfix: diff for NMU version 3.8.2-1.1
On Monday, December 18, 2023 7:31:47 PM EST Chris Hofstaedtler wrote: > Control: tags 1054485 + patch > Control: tags 1054485 + pending > > Dear maintainer, > > I've prepared an NMU for postfix (versioned as 3.8.2-1.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Better, upload yourself in the meantime. > > Best, > Chris Thank you for preparing this. I've just done a maintainer upload with this change as well as a new upstream release. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1050683: pep517: Should not be released with Trixie
Source: pep517 Severity: serious Justification: Maintainer opinion This package has been replace by python-pyproject-hooks and should not be in Trixie. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Friday, August 18, 2023 9:33:48 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman: > > On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: > > >> In Debian terms, it's not the preferred form for modification, so it's > > >> not source. In this regard DFSG goes farther than some software > > >> licenses.> > > > >I think the point Jeroen wanted to make is that these are actually > > >source file archives which "by chance" are featuring a .whl extension > > >rather than a .zip extension. > > > > A wheel is not the preferred form for modification. They're not wheels by > > chance at all. > Yes, thanks to Jeroen's hint I realised this as well and I agree that > this is a nasty way to hide the fact that the files are actually source > archives. They aren't. > However, you confirmed yourself that future_fstrings is an exception and > comes with source and thus does not violate DFSG. The only difference > I personally can see is that the archives are just hiding what they are. > We could simply add do some >for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done > and we have source archives that are obviously what they are. > > > From a DFSG perspective, > > Hmmm, the only thing where I can draw a violation of the DFSG is that > there are no d/copyright entries for the source code that is hidden > inside these *.whl files. Otherwise its "just" duplicated code (in most > cases) which is definitely not nice but IMHO not a violation of DFSG. > The disagreement here is that Python wheels aren't source. DFSG #2 requires the source be present and these aren't it. If you look at the WAF entry in the FTP team reject FAQ, this is similar. The FTP team view has long been that DFSG #2 means the actual preferred form for modification. > > the most straightforward approach is to build-depend on the relevant > > Debian packages and build any needed wheels from that. > Do avoid source code duplication I'm willing to do that. Yes, I > perfectly agree that its pretty ugly (I'm just a bit unsure about > the DFSG violation). I'm wondering whether a simple > >zip whl.zip /path/to/python/files ; mv whl.zip whl.whl > > will be something that can replace the current packages. I think > we also need to patch the tests to fit the version numbers (if > we do not want to cheat and simply use the version numbers of the > original whl files to avoid patching). Perhaps, but there are nuances to the wheel format. Please use Wheel to generate them. > > It won't necessarily get you the same version as upstream uses, but it's > > definitely DFSG compliant. > We also might symlink our resulting whl files with the version number > pdm upstream might expect in their tests. The question is, whether all > this effort might break the tests in some way and we might end up with > endless patching by at the same time loosing the chance to discuss with > upstream. But it might be time to discuss the issue with upstream > anyway. Perhaps. If it were me, what I'd do is locate the missing tarballs and stash them in debian/missing-sources/ and worry about more complex solutions later. Once you're done that, you've met DSFG #2 and there's no need to strip the wheels from the binary. It's not super maintainable, but it will allow you to focos on getting the tests working as upstream ships them without any Debian customizations that might cause Debian specific failures. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: >Hi Scott, > >Am Tue, Aug 15, 2023 at 02:18:35PM + schrieb Scott Kitterman: >> >They are zip files containing python source code. It is possible to include >> >compiled C extensions in wheels, but I checked and these wheels are all pure >> >python, so no binary blobs are included. >> >> In Debian terms, it's not the preferred form for modification, so it's not >> source. In this regard DFSG goes farther than some software licenses. > >I think the point Jeroen wanted to make is that these are actually >source file archives which "by chance" are featuring a .whl extension >rather than a .zip extension. A wheel is not the preferred form for modification. They're not wheels by chance at all. From a DFSG perspective, the most straightforward approach is to build-depend on the relevant Debian packages and build any needed wheels from that. It won't necessarily get you the same version as upstream uses, but it's definitely DFSG compliant. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
pdm is the last remaining blocker for pep517 removal. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 15, 2023 1:51:54 PM UTC, Jeroen Dekkers wrote: >On Tue, 15 Aug 2023 15:08:11 +0200, >Scott Kitterman wrote: >> >> On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: >> > Hi Scott, >> > >> > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: >> > >> > > those are all binary without source. That's a problem. >> > >> > Given your role as ftpmaster you definitely have more experience than I >> > in this field. I personally was thinking more in the line of binary >> > data we can not avoid in some cases. This is a bit in the line with >> > Rdata decision[1] where those binary data files are documented in >> > debian/README.source. >> > >> > My point is just: If we remove those data files (which are IMHO harmless >> > since these are not executd but used as input in tests - please correct >> > me if I'm wrong) we can not test the package. Removing the files >> > prevents testing and thus we can not know whether the package we deliver >> > will work. I've actually shown that not all tests are working but >> > stopped investigating this further. >> >> Even if they are used as data (I didn't check), they are, in fact, binary >> blobs of code by our definition and that requires the corresponding source. > >They are zip files containing python source code. It is possible to include >compiled C extensions in wheels, but I checked and these wheels are all pure >python, so no binary blobs are included. In Debian terms, it's not the preferred form for modification, so it's not source. In this regard DFSG goes farther than some software licenses. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: > > >Before I upload I'd like to ask for reviewing this patch and opinions > > >about the test suite errors. While these possibly occure in previous > > >versions (which I did not tested) we might consider ignoring just the > > >failing tests. I need to admit that I did not went through the list of > > >single failures - may be there is a chance of easy fixes for some of > > >them. I simply wanted to discuss the reintroduction of the artifacts > > >and my patch first. > > > > With the exception of future_fstrings > > I think there is also the souce for demo included. > > > those are all binary without source. That's a problem. > > Given your role as ftpmaster you definitely have more experience than I > in this field. I personally was thinking more in the line of binary > data we can not avoid in some cases. This is a bit in the line with > Rdata decision[1] where those binary data files are documented in > debian/README.source. > > My point is just: If we remove those data files (which are IMHO harmless > since these are not executd but used as input in tests - please correct > me if I'm wrong) we can not test the package. Removing the files > prevents testing and thus we can not know whether the package we deliver > will work. I've actually shown that not all tests are working but > stopped investigating this further. Even if they are used as data (I didn't check), they are, in fact, binary blobs of code by our definition and that requires the corresponding source. > > It's probably okay if you add the corresponding source somewhere in the > > package. > We probably have some source packages inside Debian - may be in > different versions. I need to admit that I intended to do a "quick fix > of a simple bug that affects some Debian Med packages" but realised that > I'm possibly opening a can of worms. The simplest solution to fulfill > my needs would be probably to revert my change to run the tests and be > done. However, I'm not sure whetherr this is in the interest of the > users of this package. I'm absolutely not able time-wise to povide > sources and reconstruct all those *.whl files *and* in addition track > down the test suite errors. This is a team package and if the team > decides we should go without testing I can do an according upload. > However, my prefered path would to document the issue of some binary > data properly an test what upstream expects to be tested. i think this is definitely more complicated than you want to take on casually. I don't think it's required to actually rebuild the wheels. If you provide the source, the DFSG is happy. You have to be able to rebuild it, but you aren't required to do it. It might, however, be simpler in the long run to just depend on those packages and build wheels from those (a Debian binary package has enough in it generally to build a wheel from it). I agree it'd be better in the long run to run the tests, but that may be more than you want to take on right now. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 14, 2023 12:28:30 PM UTC, Andreas Tille wrote: >Control: tags -1 pending > >Hi, > >I've fixed the issue reported in this bug[1]. > >In addition I've took the chance to upload pdm to its latest upstream >version. When doing so I realised that build time tests are basically >ignored. This was mainly due to the removal of artefacts that are used >for testing. I admit I do not see any reason to remove those data >files - in Debian R team this kind of data files which is just used for >testing is accepted. Thus I took the freedom to re-introduce these >files and was running the tests in d/rules. Unfortunately there is >quite a number of tests failing > > 54 failed, 620 passed, 1 xfailed, 3 rerun in 228.94s (0:03:48) > > >(see Salsa CI[2]) > >I'd like to stress that to run those tests at all I needed a patch[3] >since BaseProvider can't be simply imported from findpython. > >Before I upload I'd like to ask for reviewing this patch and opinions >about the test suite errors. While these possibly occure in previous >versions (which I did not tested) we might consider ignoring just the >failing tests. I need to admit that I did not went through the list of >single failures - may be there is a chance of easy fixes for some of >them. I simply wanted to discuss the reintroduction of the artifacts >and my patch first. > With the exception of future_fstrings those are all binary without source. That's a problem. It's probably okay if you add the corresponding source somewhere in the package. I do think it's odd that pdm would need poetry-core in its test suit. Scott K
Bug#1042191: marked as pending in gtts
Control: tag -1 pending Hello, Bug #1042191 in gtts 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/gtts/-/commit/b33be045ef74ca2b10381aae3ba2815ea8276033 New upstream release (Closes: #1042191) (this message was generated automatically) -- Greetings https://bugs.debian.org/1042191
Bug#1035350: postfix: postinst script modifies configuration files despite local changes
On Tuesday, May 2, 2023 8:35:12 AM EDT Einhard Leichtfuß wrote: > On 02/05/2023 00:56, Scott Kitterman wrote: > > On Monday, May 1, 2023 3:20:19 PM EDT Einhard Leichtfuß wrote: > >> On 01/05/2023 19:47, Scott Kitterman wrote: > >>> On Monday, May 1, 2023 1:01:17 PM EDT Einhard Leichtfuß wrote: > >>>> On 01/05/2023 18:14, Scott Kitterman wrote: > >>>>> On Monday, May 1, 2023 11:06:07 AM EDT Einhard Leichtfuß wrote: > >>>>>> Package: postfix > >>> > >>> ... > >>> > >>>>>> In `main.cf`, the following lines were appended: > >>>>>>> readme_directory = /usr/share/doc/postfix > >>>>>>> html_directory = /usr/share/doc/postfix/html > >>>>>> > >>>>>> If I understand the postinst script correctly, this modification of > >>>>>> `main.cf` should only have happened upon first installation, which > >>>>>> this > >>>>>> was not. I was unable to reproduce this. So maybe this modification > >>>>>> was indeed done earlier. > >>>>>> > >>>>>> However, even upon initial installation (with pre-existing > >>>>>> configuration), this should, in my opinion, not happen. > >>> > >>> ... > >>> > >>>>> Also, note that the message about is about main.cf not being modified. > >>>>> These changes are in master.cf, so I don't understand the concern with > >>>>> the message? > >>>> > >>>> The second modification (readme_directory, html_directory) was to > >>>> `main.cf`. While this modification should only happen for initial > >>>> installations (with pre-existing configuration), the message is > >>>> displayed even then. > >>>> > >>>> Steps to reproduce (assuming postfix is not installed): > >>>> > >>>> $ apt install postfix-doc > >>>> $ echo > /etc/postfix/main.cf > >>>> $ apt install postfix > >>> > >>> To focus in on the main.cf part of this, I believe that's per policy. > >>> > >>> First, it's a change made by postfix-doc, not postifx, so the postfix > >>> package statement that main.cf was not modified by it is correct and > >>> unrelated to the main.cf change. > >> > >> Ah, I did not check the postfix-doc postinst script. It seems that both > >> postfix-doc's and postfix's postinst scripts conditionally run > >> > >> postconf -e readme_directory=/usr/share/doc/postfix > >> > >> html_directory=/usr/share/doc/postfix/html > >> > >> However, postfix's postinst script only does so in the arguably rare > >> case that postfix-doc was installed first. So one might argue that this > >> is still an action performed for postfix-doc falling under Policy 10.7.4. > >> > >>> For the postfix-doc change to main.cf, Policy 10.7.4 is the relevant > >>> portion. Postfix-doc uses the provided interface (postfconf), when > >>> available. > >> > >> It is not clear to me that Policy 10.7.4 overrides Policy 10.7.3 w.r.t. > >> the requirement not to override local changes. While this may very well > >> not be the intention behind these policies, I'd understand them as such > >> that the related package (postfix-doc) must only [be able to] modify the > >> configuration file if it does not contain local changes. > >> > >> I.e., either the provided program (currently postconf) should refuse to > >> modify a locally modified configuration file, or the related package > >> (postfix-doc) should check for local changes itself. > >> > >> I am generally unsure, however, how detection of local modification is > >> supposed to work in practice without using conffiles. I suppose a > >> second configuration file copy that is modified by postinst scripts, but > >> not the local administrator, should work. > > > > Preserve local modifications means don't undo specific changes made by the > > local administrator. It does not mean make no changes to a file that an > > administrator has made changes to. The use of postconf specifically > > enables changing the values relevant to postfix-doc without disturbing > > anything else in the file. I think this is fine. > > I agree that preserving local changes does not generally mean n
Bug#1035350: postfix: postinst script modifies configuration files despite local changes
On Monday, May 1, 2023 3:20:19 PM EDT Einhard Leichtfuß wrote: > On 01/05/2023 19:47, Scott Kitterman wrote: > > On Monday, May 1, 2023 1:01:17 PM EDT Einhard Leichtfuß wrote: > >> On 01/05/2023 18:14, Scott Kitterman wrote: > >>> On Monday, May 1, 2023 11:06:07 AM EDT Einhard Leichtfuß wrote: > >>>> Package: postfix > > > > ... > > > >>>> In `main.cf`, the following lines were appended: > >>>>> readme_directory = /usr/share/doc/postfix > >>>>> html_directory = /usr/share/doc/postfix/html > >>>> > >>>> If I understand the postinst script correctly, this modification of > >>>> `main.cf` should only have happened upon first installation, which this > >>>> was not. I was unable to reproduce this. So maybe this modification > >>>> was indeed done earlier. > >>>> > >>>> However, even upon initial installation (with pre-existing > >>>> configuration), this should, in my opinion, not happen. > > > > ... > > > >>> Also, note that the message about is about main.cf not being modified. > >>> These changes are in master.cf, so I don't understand the concern with > >>> the message? > >> > >> The second modification (readme_directory, html_directory) was to > >> `main.cf`. While this modification should only happen for initial > >> installations (with pre-existing configuration), the message is > >> displayed even then. > >> > >> Steps to reproduce (assuming postfix is not installed): > >> > >> $ apt install postfix-doc > >> $ echo > /etc/postfix/main.cf > >> $ apt install postfix > > > > To focus in on the main.cf part of this, I believe that's per policy. > > > > First, it's a change made by postfix-doc, not postifx, so the postfix > > package statement that main.cf was not modified by it is correct and > > unrelated to the main.cf change. > > Ah, I did not check the postfix-doc postinst script. It seems that both > postfix-doc's and postfix's postinst scripts conditionally run > > postconf -e readme_directory=/usr/share/doc/postfix > html_directory=/usr/share/doc/postfix/html > > However, postfix's postinst script only does so in the arguably rare > case that postfix-doc was installed first. So one might argue that this > is still an action performed for postfix-doc falling under Policy 10.7.4. > > > For the postfix-doc change to main.cf, Policy 10.7.4 is the relevant > > portion. Postfix-doc uses the provided interface (postfconf), when > > available. > It is not clear to me that Policy 10.7.4 overrides Policy 10.7.3 w.r.t. > the requirement not to override local changes. While this may very well > not be the intention behind these policies, I'd understand them as such > that the related package (postfix-doc) must only [be able to] modify the > configuration file if it does not contain local changes. > > I.e., either the provided program (currently postconf) should refuse to > modify a locally modified configuration file, or the related package > (postfix-doc) should check for local changes itself. > > I am generally unsure, however, how detection of local modification is > supposed to work in practice without using conffiles. I suppose a > second configuration file copy that is modified by postinst scripts, but > not the local administrator, should work. Preserve local modifications means don't undo specific changes made by the local administrator. It does not mean make no changes to a file that an administrator has made changes to. The use of postconf specifically enables changing the values relevant to postfix-doc without disturbing anything else in the file. I think this is fine. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1035350: postfix: postinst script modifies configuration files despite local changes
On Monday, May 1, 2023 1:01:17 PM EDT Einhard Leichtfuß wrote: > On 01/05/2023 18:14, Scott Kitterman wrote: > > On Monday, May 1, 2023 11:06:07 AM EDT Einhard Leichtfuß wrote: > >> Package: postfix ... > >> In `main.cf`, the following lines were appended: > >>> readme_directory = /usr/share/doc/postfix > >>> html_directory = /usr/share/doc/postfix/html > >> > >> If I understand the postinst script correctly, this modification of > >> `main.cf` should only have happened upon first installation, which this > >> was not. I was unable to reproduce this. So maybe this modification > >> was indeed done earlier. > >> > >> However, even upon initial installation (with pre-existing > >> configuration), this should, in my opinion, not happen. ... > > Also, note that the message about is about main.cf not being modified. > > These changes are in master.cf, so I don't understand the concern with > > the message? > The second modification (readme_directory, html_directory) was to > `main.cf`. While this modification should only happen for initial > installations (with pre-existing configuration), the message is > displayed even then. > > Steps to reproduce (assuming postfix is not installed): > > $ apt install postfix-doc > $ echo > /etc/postfix/main.cf > $ apt install postfix To focus in on the main.cf part of this, I believe that's per policy. First, it's a change made by postfix-doc, not postifx, so the postfix package statement that main.cf was not modified by it is correct and unrelated to the main.cf change. For the postfix-doc change to main.cf, Policy 10.7.4 is the relevant portion. Postfix-doc uses the provided interface (postfconf), when available. I checked and this goes back at least to when the postfix packaging was first kept in git in 2007. I think this part is not a bug. Please let me know if I'm misunderstanding the issue. I suspect the master.cf fix_master can be removed entirely, but I'm not 100% certain yet. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1035350: postfix: postinst script modifies configuration files despite local changes
On Monday, May 1, 2023 11:06:07 AM EDT Einhard Leichtfuß wrote: > Package: postfix > Version: 3.5.18-0+deb11u1 > Severity: serious > > Upon upgrade of postfix (due to `apt dist-upgrade`), the `master.cf` > [and `main.cf`] configuration files were modified by the postinst > script, despite existing local changes. > > If I understand correctly, this violates Debian Policy 10.7.3 [0]: > "local changes must be preserved during a package upgrade". This is why > I chose Severity "serious". > > I would instead expect a handling similar to that of changed conffiles > (i.e., one is given an option to or is suggested to apply certain > modifications). > > In `master.cf`, the following lines were appended: > > proxymap unix - - n - - proxymap > > verifyunix - - y - 1 verify > > relay unix - - n - - smtp -o > > smtp_fallback_relay= # -o smtp_helo_timeout=5 -o > > smtp_connect_timeout=5 > > See the `fix_master()` function in the postinst script. > > (sidenote: The first two entries are the same as in > `/usr/share/postfix/master.cf.dist`, the last one is different.) > > In `main.cf`, the following lines were appended: > > readme_directory = /usr/share/doc/postfix > > html_directory = /usr/share/doc/postfix/html > > If I understand the postinst script correctly, this modification of > `main.cf` should only have happened upon first installation, which this > was not. I was unable to reproduce this. So maybe this modification > was indeed done earlier. > > However, even upon initial installation (with pre-existing > configuration), this should, in my opinion, not happen. > > The changes were accompanied by the following message: > > Setting up postfix (3.5.18-0+deb11u1) ... > > > > In master.cf: > > adding missing entry for proxymap service > > adding missing entry for verify service > > adding missing entry for relay service > > > > Postfix (main.cf) configuration was untouched. If you need to make > > changes, edit /etc/postfix/main.cf (and others) as needed. To view > > Postfix configuration values, see postconf(1). > > > > After modifying main.cf, be sure to run 'systemctl reload postfix'. > > The message that `main.cf` was untouched is displayed regardless of > whether the above noted modifications of `main.cf` are made. > > > I noticed that many actions in the postinst script are only run if > `[ "$mailer" != "No configuration" ]`. I am unsure whether this case > would warrant the above mentioned modifications. If so, maybe this > condition should be added to these modifications. > > > [0] https://www.debian.org/doc/debian-policy/ch-files.html#behavior fix_master() was added in 2017 to upgrade pre-postfix 3.0 master.cf files to support postfix 3.0 and hasn't been touched since then. What version of Debian were you upgrading from? Also, note that the message about is about main.cf not being modified. These changes are in master.cf, so I don't understand the concern with the message? Scott K signature.asc Description: This is a digitally signed message part.
Bug#1033805: opendmarc: Segmentation fault with 3072-bit key signatures in ARC-Seal headers
I'm not running it myself. I thought people on postfix-users reported the problem with our package. If you're confident it's already addressed, please close the bug and sorry for the noise. Scott K On April 2, 2023 7:43:15 AM UTC, "David Bürgin" wrote: >Also note that we have been shipping the linked patch in Debian’s >opendmarc for a while now. It is included in stable, testing, unstable >as ‘arcseal-segfaults.patch’.
Bug#1033805: opendmarc: Segmentation fault with 3072-bit key signatures in ARC-Seal headers
Package: opendmarc Version: 1.4.0~beta1+dfsg-6+deb11u1 Severity: serious Tags: upstream patch Justification: Maintainer designation Currently opendmarc in Stable, Testing, and Unstable will crash if they key used in an ARC header field is 3072 bit RSA or longer. This really needs to be fixed prior to release since, in normal usage, when a milter crashes it stops all mail flow on the system. Since the key size is an attribute decided by the sending domain, there's no work around on the receiver side to avoid the specific keys at issue. Longer RSA keys are becoming more common and this trend will continue through Bookworm's life, so the impact will only grow. Patch available in the upstream GitHub repository: https://github.com/trusteddomainproject/OpenDMARC/issues/183 Scott K
Bug#1032889: itinerary doesn't start at all
Thank you for testing. It sounds like, at a minimum, there's a missing dependency on qml-module-org-kde-kirigami2. Scott K
Bug#1032889: itinerary doesn't start at all
Is qml-module-org-kde-i18n-localedata installed? Scott K
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
It's too late for a trip through New and Bookworm. We probably should have done it before, but not now. I think setting a minimum version of the current package will be sufficient and about all we can do now anyway. Scott K On February 25, 2023 10:26:50 PM UTC, Sebastian Andrzej Siewior wrote: >On 25 February 2023 16:20:45 UTC, Scott Kitterman wrote: >>True. >> >>I'm not a C programmer, so I may be unduly concerned about the maintenance >>load. I'll defer to your judgement. > >I'm going to throw this on my machine to get more testing - more than just the >test suite. >What about going through NEW with tfm? I would make it provide libtfm1-4k and >clamav would need a binnmu to pick up the change. > >> >>I do wonder if we should make a stab at switching the rust bits to using >>Debian packages instead of the embedded copies. If we could manage it, then >>any security issues in the rust libraries can be fixed in clamav with a >>binNMU, no upload needed. > >That sounds good. I need to educate myself about rust to figure out how that >works. Right now it is all magic. I just hope that they did not adapt any >packages to their needs and that they don't rely on a newer version of >something than what we have in the archive. >> >>Scott K > >
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
True. I'm not a C programmer, so I may be unduly concerned about the maintenance load. I'll defer to your judgement. I do wonder if we should make a stab at switching the rust bits to using Debian packages instead of the embedded copies. If we could manage it, then any security issues in the rust libraries can be fixed in clamav with a binNMU, no upload needed. Scott K On February 25, 2023 4:11:01 PM UTC, Sebastian Andrzej Siewior wrote: >On 25 February 2023 14:57:28 UTC, Scott Kitterman wrote: >>Generally favorably, but I'd rather wait for upstream to agree on it, >>otherwise it may be a patch we have to maintain forever. > >Now we maintain the tfm bits. > >>What's their reaction to the change? > >No reply so far. The first few patches from early January got the response "it >was a chaotic week, we get to it soon" and the tfm patch got no response since >I posted it last week. >Maybe you need to walk around their office and throw a stone with pull request >number written on it :-) > >> >>It's also late in the release cycle to do it (not definitely a problem, but >>calls for caution). >> >>Scott K >
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
Generally favorably, but I'd rather wait for upstream to agree on it, otherwise it may be a patch we have to maintain forever. What's their reaction to the change? It's also late in the release cycle to do it (not definitely a problem, but calls for caution). Scott K On February 25, 2023 2:18:08 PM UTC, Sebastian Andrzej Siewior wrote: >On 2023-02-24 21:00:43 [+], Scott Kitterman wrote: >> I don't know of anything. I'd go ahead and upload the fix. > >how do you feel about replacing libtfm with openssl? > >> Scott K > >Sebastian
Bug#1031896: [Pkg-clamav-devel] Bug#1031896: libclamav11: LibClamAV Error: Can't verify database integrity, breaks amavis
On February 24, 2023 8:50:47 PM UTC, Sebastian Andrzej Siewior wrote: >On 2023-02-24 12:44:49 [-0800], Nye Liu wrote: >> On Fri, Feb 24, 2023 at 09:39:03PM +0100, Sebastian Andrzej Siewior wrote: >> > Can you re-install libtfm1 and ensure that both point to that lib? >> >> libtfm1 0.13-4.1 fixed the problem. Should probably be version bumped in the >> pkg dependency, 0.13.1-1 seems broken. > >Why did I say that you version looks since it clearly did not. >Hmm. This may break upgrades as it seems. > >Scott? Just this tiny change or do we have something else pending? I don't know of anything. I'd go ahead and upload the fix. Scott K
Bug#1030900: gcc-11-cross-ports: FTBFS in Testing due to gcc-9 build-depends
Package: gcc-11-cross-ports Version: 13 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) - broken Build-Depends: gcc-11-cross-ports: lib32gcc1-ppc64-cross lib32gcc1-sparc64-cross lib32gcc1-x32-cross lib64gcc1-powerpc-cross lib64gcc1-x32-cross These packages are NBS by gcc-9-cross-ports and have been removed from Testing. Scott K
Bug#1030899: gcc-10-cross-ports: FTBFS in Testing due to gcc-9 build-depends
Source: gcc-10-cross-ports Version: 21 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) - broken Build-Depends: gcc-10-cross-ports: lib32gcc1-ppc64-cross lib32gcc1-sparc64-cross lib32gcc1-x32-cross lib64gcc1-powerpc-cross lib64gcc1-x32-cross These packages are NBS by gcc-9-cross-ports and have been removed from Testing. Scott K
Bug#1030897: gcc-11-cross: FTBFS in Testing due to gcc-9 build-depends
Package: gcc-11-cross Version: 17 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) - broken Build-Depends: gcc-11-cross: lib32gcc1-amd64-cross lib32gcc1-s390x-cross lib64gcc1-i386-cross libx32gcc1-amd64-cross libx32gcc1-i386-cross These packages are NBS by gcc-9-cross and have been removed from Testing. Scott K
Bug#1030896: gcc-10-cross-base: FTBFS in Testing due to gcc-9 build-depends
Package: gcc-10-cross-base Version: 20 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) - broken Build-Depends: gcc-10-cross: lib32gcc1-amd64-cross lib32gcc1-s390x-cross lib64gcc1-i386-cross libx32gcc1-amd64-cross libx32gcc1-i386-cross These packages are NBS by gcc-9-cross and have been removed from Testing. Scott K -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1030366: rust-tree-magic-mini: Depends/Build-Depends on cruft package librust-petgraph+default-dev
Package: rust-tree-magic-mini Version: 3.0.3-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Source package rust-petgraph version 0.6.2-1 no longer builds librust-petgraph+default-dev: - broken Depends: rust-tree-magic-mini: librust-tree-magic-mini-dev - broken Build-Depends: rust-tree-magic-mini: librust-petgraph+default-dev (0.5-~~ >=) Once this is decrufted, the package will FTBFS and be uninstallable. Scott K
Bug#1030250: elan: Build-depends on cruft package, whill FTBFS when decrufted
Source: elan Version: 1.4.2-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) source package rust-zip version 0.6.3-3 no longer builds ust-zip+flate2-dev librust-zip+time-dev. This is a build-dep for elan, so once it's decrufted, elan will FTBFS. Scott K
Bug#1029906: mdevctl: Build depends on cruft package about to be removed: librust-log+serde-dev
Package: mdevctl Version: 1.2.0-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) librust-log+serde-dev is NBS cruft that is about to be removed, which will cause the package to FTBFS. Scott K
Bug#1029905: pushpin: Build depends on cruft packages to be removed: librust-clap+default-dev
Package: pushpin Version: 1.35.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) librust-clap+default-dev is cruft that is about to be removed makine the package unbuildable. Scott K
Bug#1029015: qtmir-tests: Depends on NBS package python3-mir-perf-framework
Package: qtmir-tests Version: 0.8.0~git20230115.30c2337-1 Severity: serious Justification: Policy 3.5 qtmir-tests depends on python3-mir-perf-framework which is no longer built by the mir package. Once it's decrufted, the package will not be installable. Please either drop the dependency or coordinate with the mir maintainers to get python3-mir-perf-framework restored. Scott K
Bug#1027606: marked as pending in python-resolvelib
Control: tag -1 pending Hello, Bug #1027606 in python-resolvelib 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-resolvelib/-/commit/ea1071bf30f484a7257ef8afc6cdb68bd9b86cce Add d/patch/fix_tests.patch to remediate inappropriate test failures caused by changes in python-packaging (Closes: #1027606) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027606
Bug#1017172: closing 1017172
close 1017172 3.7.3-4 # Builds now. thanks
Bug#1028899: gocr: Build-depends on NBS -dev package libnetpbm11-dev
Source: gocr Version: 0.52-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The libnetpbm11-dev package is no longer built by the netpdm-free package. Once it is decrufted gocr will FTBFS. Scott K
Bug#1027606: python-resolvelib: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.11 3.10" returned exit code 13
On Sun, 1 Jan 2023 15:34:12 +0100 Lucas Nussbaum wrote: > Source: python-resolvelib > Version: 0.9.0-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230101 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This is a result of the recent upgrade of python-packaging from version 21.3 to 22.0. All tests pass if python3-packaging is downgraded to the old version. There is an unpackaged version 23.0. Tests also fail with that, so this is presumably a deliberate design decision in python-packaging and not a bug. No one appears to have filed an upstream issue with python-resolvelib yet. I'll do that and see what they say. It appears that the Python definition of valid version numbers has gotten more strict. It's not clear what the correct solution is for resolvelib. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1028170: maven-doxia-tools: Build-depends on NBS package, will FTBFS soon
Source: maven-doxia-tools Version: 1.4-4 Severity: serious Tags: ftbfs Justification: fails to build from source * source package doxia version 1.11.1-1 no longer builds binary package(s): libdoxia-java-doc - broken Build-Depends: maven-doxia-tools: libdoxia-java-doc Once libdoxia-java-doc is decrufted, then this package will FTBFS. Scott K
Bug#1028169: maven-reporting-impl: Build-depends on NBS package, will soon FTBS
Source: maven-reporting-impl Version: 3.0.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source * source package doxia version 1.11.1-1 no longer builds binary package(s): libdoxia-java-doc - broken Build-Depends: maven-reporting-impl: libdoxia-java-doc Once libdoxia-java-doc is decrufted, this package will start to FTBFS. Scott K
Bug#1028166: commons-configuration: Build-depends on NBS package about to FTBFS
Source: commons-configuration Version: 1.10-5 Severity: serious Tags: ftbfs Justification: fails to build from source * source package commons-vfs version 2.1-4 no longer builds binary package(s): libcommons-vfs-java-doc on all - broken Build-Depends: commons-configuration: libcommons-vfs-java-doc Once libcommons-vfs-java-doc is decrufted, this package will not longer build. Scott K
Bug#1028168: commons-configuration2: Build-depends on NBS package, about to FTBFS
Source: commons-configuration2 Version: 2.8.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source * source package commons-vfs version 2.1-4 no longer builds binary package(s): libcommons-vfs-java-doc on all - broken Build-Depends: commons-configuration2: libcommons-vfs-java-doc Once libcommons-vfs-java-doc is decrufted, this package will not longer build. Scott K
Bug#1028022: libclamunrar9: Not buildable/installable with clamav 1.0/libclamav11
Package: libclamunrar9 Version: 0.102.3-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) It will take some time to update libclamunrar to provide libclamunrar11. This should not block the clamav transition, so libclamunrar will probably need to be (at least temporarily) removed from Testing. This bug is to make sure it doesn't prematurely migrate back. Scott K
Bug#1027948: [Pkg-clamav-devel] Bug#1027948: clamav: Cannot fulfill the build build dependencies on mipsel/mips64el
On Wednesday, January 4, 2023 6:35:52 PM EST Adrian Bunk wrote: > Source: clamav > Version: 1.0.0+dfsg-2 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/package.php?p=clamav=sid > > Dependency installability problem for clamav on mips64el: > clamav build-depends on: > - rust-lldb:mips64el > rust-lldb depends on missing: > - lldb-14:mips64el > > Dependency installability problem for clamav on mipsel: > > clamav build-depends on: > - rust-lldb:mipsel > rust-lldb depends on missing: > - lldb-14:mipsel > > > Is there actually a reason why the build dependency on rust-lldb > is required at all? > > CMakeLists.txt calls find_package(Rust REQUIRED), which is implemented > in the generic cmake/FindRust.cmake (not written for clamav). > > cmake/FindRust.cmake does check for tools like rust-lldb, > but rust-lldb does not seem to be used anywhere. > > Test builds without rust-lldb succeeded for me on amd64 and mipsel, > with no code changes detected in the amd64 build by diffoscope. Same here. I was about to upload a change to drop it when I say the bug. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1027130: closing 1027130
close 1027130 1.0.0+dfsg-1 thanks
Bug#1027130: libclamav9: LibClamAV Error: Can't verify database integrity
On Wed, 28 Dec 2022 10:10:21 +0100 Jan Huijsmans wrote: > Package: libclamav9 > Version: 0.103.7+dfsg-1+b2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Upgrade of package and related clamav packages to 0.103.7+dfsg-1+b2 resulted > in an inability to verify the clamav database daily.cvd (1st it tries). > > Dodngrade of packages clamav-daemon and clamav-freshclam didn't dolve the issue, > libclamav9 needed to be downgraded to 0.103.7+dfsg-0+deb11u1 to be able to start > clamab-daemon again. > > Errors in syslog: > > LibClamAV Error: Can't load /var/lib/clamav/daily.cvd: Can't verify database integrity > LibClamAV Error: cli_loaddbdir(): error loading database /var/lib/clamav/ daily.cvd Verified this works with the clamav 1.0.0 in experimental. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1026605: python-avro: FTBFS: AssertionError: 'reader type: null not compatible with writer type: int' not found in {'reader type: SchemaType.NULL not compatible with writer type: SchemaType.INT'}
On Thursday, December 29, 2022 4:13:20 PM EST Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> I wonder whether someone might suggest a fix for
>
>
> ==
> FAIL: test_schema_compatibility_type_mismatch
> (avro.test.test_compatibility.TestCompatibility.test_schema_compatibility_t
> ype_mismatch)
> --
> Traceback (most recent call last):
> File
> "/build/python-avro-1.11.1+dfsg/.pybuild/cpython3_3.11_avro/build/avro/test
> /test_compatibility.py", line 1039, in
> test_schema_compatibility_type_mismatch self.assertIn(message,
> result.messages)
> AssertionError: 'reader type: null not compatible with writer type: int' not
> found in {'reader type: SchemaType.NULL not compatible with writer type:
> SchemaType.INT'}
>
> --
> Ran 421 tests in 8.358s
>
> FAILED (failures=1, skipped=3)
>
>
> Otherwise I will probably exclude Python3.11 from the build to fix this bug.
That's not an actual solution. If you close the bug on this basis it will
hide the issue and make it appear we are more ready to move to Python 3.11 as
the default (and probably only) Python version for Bookworm.
I didn't look at the actual code. Typically when something comes up Null is
means that something was not found. I would look at the code where SchemaType
is determined to see how it might come up with no SchemaType.
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#1008828: marked as pending in spf-engine
Control: tag -1 pending Hello, Bug #1008828 in spf-engine 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/spf-engine/-/commit/bbb3b8cfa4ffd883d47bfb29b9efb36b9681b369 Add d/p/0002-fix-leftover-import.patch from upstream to fix pyspf-milter failing to start due to an invalid import statement (Closes: #1008828) (this message was generated automatically) -- Greetings https://bugs.debian.org/1008828
Bug#1024713: ansible-core: Fails autopkgtests in unstable due to new resolvelib
Package: ansible-core
Version: 2.13.4-1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
The current ansible-core package fails autopkgtest in unstable and would
fail in testing if python3-resolvelib were to migrate [1]. The issue
has been fixed upstream [2]. I have tested both on unstable and testing
with the upstream fix using the attached debdiff and it corrects the
test failures. It also still works with the older resolvelib.
Using the ftbfs tag for this report since it is the closest thing we
have for test failures.
I do intend to NMU in a week to fix this as it blocks testing migration
for python-resolvelib. Please let me know if you want to take care of
it or your would prefer I go ahead.
Scott K
[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28587311/log.gz
[2] https://github.com/ansible/ansible/pull/79399/files
diff -Nru ansible-core-2.13.4/debian/changelog
ansible-core-2.13.4/debian/changelog
--- ansible-core-2.13.4/debian/changelog2022-09-13 14:41:09.0
+
+++ ansible-core-2.13.4/debian/changelog2022-11-23 15:31:05.0
+
@@ -1,3 +1,11 @@
+ansible-core (2.13.4-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add d/p/resolvelib_0_9_0_compat.patch to fix test failures with
+python3-resolvelib 0.9.0 (backport of upstream commit)
+
+ -- Scott Kitterman Wed, 23 Nov 2022 15:31:05 +
+
ansible-core (2.13.4-1) unstable; urgency=medium
* New upstream release
diff -Nru ansible-core-2.13.4/debian/patches/resolvelib_0_9_0_compat.patch
ansible-core-2.13.4/debian/patches/resolvelib_0_9_0_compat.patch
--- ansible-core-2.13.4/debian/patches/resolvelib_0_9_0_compat.patch
1970-01-01 00:00:00.0 +
+++ ansible-core-2.13.4/debian/patches/resolvelib_0_9_0_compat.patch
2022-11-23 15:30:19.0 +
@@ -0,0 +1,98 @@
+Description: Upstream change for resolvelib 0.9.0 compatibility
+ ansible-galaxy - support ``resolvelib >= 0.5.3, < 0.10.0`` (#79399)
+* Upgrade `resolvelib >= 0.5.3, < 0.10.0`
+https://pypi.org/project/resolvelib/0.9.0/ released on 2022-11-17:
+ *
https://github.com/sarugaku/resolvelib/blob/master/CHANGELOG.rst#090-2022-11-17
+ * https://github.com/sarugaku/resolvelib/releases/tag/0.9.0
+Signed-off-by: Wong Hoi Sing Edison
+ .
+ commit b148fd8dd74c8599f809f71117a86577ccfb0638
+Author: Wong Hoi Sing Edison
+Date: Wed Nov 23 21:57:24 2022 +0800
+Origin: vendor
+Last-Update: 2022-11-23
+
+--- /dev/null
ansible-core-2.13.4/changelogs/fragments/79399-resolvelib_lt_0_10_0.yml
+@@ -0,0 +1,2 @@
++minor_changes:
++ - ansible-galaxy - support ``resolvelib >= 0.5.3, < 0.10.0``.
+---
ansible-core-2.13.4.orig/lib/ansible/galaxy/dependency_resolution/providers.py
ansible-core-2.13.4/lib/ansible/galaxy/dependency_resolution/providers.py
+@@ -41,7 +41,7 @@ except ImportError:
+
+ # TODO: add python requirements to ansible-test's ansible-core distribution
info and remove the hardcoded lowerbound/upperbound fallback
+ RESOLVELIB_LOWERBOUND = SemanticVersion("0.5.3")
+-RESOLVELIB_UPPERBOUND = SemanticVersion("0.9.0")
++RESOLVELIB_UPPERBOUND = SemanticVersion("0.10.0")
+ RESOLVELIB_VERSION =
SemanticVersion.from_loose_version(LooseVersion(resolvelib_version))
+
+
+@@ -219,7 +219,7 @@ class CollectionDependencyProviderBase(A
+ Mapping of identifier, list of named tuple pairs.
+ The named tuples have the entries ``requirement`` and ``parent``.
+
+-resolvelib >=0.8.0, <= 0.8.1
++resolvelib >=0.8.0, <= 0.9.0
+
+ :param identifier: The value returned by ``identify()``.
+
+--- ansible-core-2.13.4.orig/requirements.txt
ansible-core-2.13.4/requirements.txt
+@@ -12,4 +12,4 @@ packaging
+ # NOTE: Ref: https://github.com/sarugaku/resolvelib/issues/69
+ # NOTE: When updating the upper bound, also update the latest version used
+ # NOTE: in the ansible-galaxy-collection test suite.
+-resolvelib >= 0.5.3, < 0.9.0 # dependency resolver used by ansible-galaxy
++resolvelib >= 0.5.3, < 0.10.0 # dependency resolver used by ansible-galaxy
+---
ansible-core-2.13.4.orig/test/lib/ansible_test/_data/requirements/ansible.txt
ansible-core-2.13.4/test/lib/ansible_test/_data/requirements/ansible.txt
+@@ -12,4 +12,4 @@ packaging
+ # NOTE: Ref: https://github.com/sarugaku/resolvelib/issues/69
+ # NOTE: When updating the upper bound, also update the latest version used
+ # NOTE: in the ansible-galaxy-collection test suite.
+-resolvelib >= 0.5.3, < 0.9.0 # dependency resolver used by ansible-galaxy
++resolvelib >= 0.5.3, < 0.10.0 # dependency resolver used by ansible-galaxy
+--- ansible-core-2.13.4.orig/test/sanity/code-smell/docs-build.requirements.in
ansible-core-2.13.4/test/sanity/code-smell/docs-build.requirements.in
+@@ -1,6 +1,6 @@
+ jinja2
+ pyyaml
Bug#1023617: ldc: Build-depends on packages no in testing (llvm-11-dev)
Source: ldc Version: 1:1.30.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: 1000...@bugs.debian.org LLVM 11 is not in Testing and will not be shipped with Bookworm: llvm-11-dev | 1:11.0.1-2 | stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x llvm-11-dev | 1:11.1.0-6+b2 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x ldc needs to build-depend on a newer LLVM or be removed from Testing. Scott K
Bug#1005044: fixed in pysubnettree 0.36-1
On Thu, 03 Nov 2022 20:52:21 + Debian FTP Masters wrote: > Source: pysubnettree > Source-Version: 0.36-1 > Done: Scott Kitterman > > We believe that the bug you reported is fixed in the latest version of > pysubnettree, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1005...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Scott Kitterman (supplier of updated pysubnettree package) Stable PU is in #1023423, for those interested. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1005044: python3-subnettree: package completely broken, module won't load
On Wed, 9 Feb 2022 17:12:27 -0500 Michael Stone wrote: > On Wed, Feb 09, 2022 at 04:32:43PM -0500, Scott Kitterman wrote: > >On Sat, 5 Feb 2022 17:28:04 -0500 Michael Stone wrote: > >> It seems to be some kind of incompatibility in swig. Upstream .cc files > >> are built with swig 3, debian has swig 4. If the package is built with > >> the upstream .cc files (ditching the associated lines in debian/rules) > >> it seems to work fine. > > > >Thanks. I agree. The bad news is that would trade a DFSG issue for a > >technical issue, which might be considered progress (since the generated files > >can't be regenerated within Main anymore). > > I'd argue that's the least-bad option right now for a fix in bullseye. > It's IMO a DFSG-pedantic issue as the files can be regenerated with free > software, just not with anything currently packaged in debian (e.g., > with the buster version of swig). Would definitely be better than a > completely unusable package. (A change to the .i that makes everything > work would be even better obviously, but I have no idea how swig is > supposed to work.) I have it figured out. I'll upload shortly for Unstable and then work on fixing the stable version. If you want to build a local copy that works, delete all the mv's in debian/rules and rebuild. The way that's structured is what caused the problem. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1023299: ganeti-testsuite: yaml.load in testsuite needs to specify loader
Source: ganeti-testsuite Version: 3.0.2-1 Severity: serious Tags: upstream ftbfs Justification: fails to build from source X-Debbugs-Cc: debian-pyt...@lists.debian.org Previously yaml.load did not require a loader to be specified: load(stream, Loader=None) Now it does (starting in pyyaml 6.0): load(stream, Loader) Ganeti-testsuit uses yaml.load without specifying a loader, which now causes a test failure in unstable. Due to ganeti not being buildable currently, it's not possible to fix this at the moment. Note: Using FTBFS as a tag since that's the closest thing we have to a test failure that would prevent migration. Scott K
Bug#1022211: xml2rfc: Test failures with Weasyprint 57.0
On Sat, 22 Oct 2022 00:01:32 -0400 Scott Kitterman wrote: > Package: xml2rfc > Version: 3.13.1-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > > Using FTBFS as it's the closest thing we have to an autopkgtest > regression severity. xml2rfc autopkgtest fails in Unstable with > Weasyprint 57.0: > > == > ERROR: setUpClass (__main__.PdfWriterTests) > -- > Traceback (most recent call last): > File "/tmp/autopkgtest-lxc.48kx6p_4/downtmp/build.obL/src/xxx/test.py", line 495, in setUpClass > cls.elements_pdfxml = xmldoc(None, bytes=elements_pdfdoc) > File "/usr/lib/python3/dist-packages/xml2rfc/walkpdf.py", line 96, in xmldoc > return lxml.etree.fromstring(text) > File "src/lxml/etree.pyx", line 3254, in lxml.etree.fromstring > File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument > File "src/lxml/parser.pxi", line 1793, in lxml.etree._parseDoc > File "src/lxml/parser.pxi", line 1082, in lxml.etree._BaseParser._parseUnicodeDoc > File "src/lxml/parser.pxi", line 615, in lxml.etree._ParserContext._handleParseResultDoc > File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult > File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError > File "", line 14199 > lxml.etree.XMLSyntaxError: PCDATA invalid Char value 23, line 14199, column 11 > > -- > Ran 42 tests in 21.851s > > FAILED (errors=1) > > https://ci.debian.net/data/autopkgtest/testing/amd64/x/xml2rfc/27394437/ log.gz > > Upstream is apparently aware since (I discovered after uploading > Weasyprint) they have recently pinned the Weasyprint dependency to > <57.0. > > I did file an issue upstream: > > https://github.com/ietf-tools/xml2rfc/issues/921 > I narrowed down the Weasyprint commit that leads to the failure and asked for feedback from that upstream: https://github.com/Kozea/WeasyPrint/issues/1752 If that doesn't prove fruitful, I am open to patching Debian's weasyprint to fix the issue. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1022211: xml2rfc: Test failures with Weasyprint 57.0
Package: xml2rfc Version: 3.13.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source Using FTBFS as it's the closest thing we have to an autopkgtest regression severity. xml2rfc autopkgtest fails in Unstable with Weasyprint 57.0: == ERROR: setUpClass (__main__.PdfWriterTests) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.48kx6p_4/downtmp/build.obL/src/xxx/test.py", line 495, in setUpClass cls.elements_pdfxml = xmldoc(None, bytes=elements_pdfdoc) File "/usr/lib/python3/dist-packages/xml2rfc/walkpdf.py", line 96, in xmldoc return lxml.etree.fromstring(text) File "src/lxml/etree.pyx", line 3254, in lxml.etree.fromstring File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument File "src/lxml/parser.pxi", line 1793, in lxml.etree._parseDoc File "src/lxml/parser.pxi", line 1082, in lxml.etree._BaseParser._parseUnicodeDoc File "src/lxml/parser.pxi", line 615, in lxml.etree._ParserContext._handleParseResultDoc File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError File "", line 14199 lxml.etree.XMLSyntaxError: PCDATA invalid Char value 23, line 14199, column 11 -- Ran 42 tests in 21.851s FAILED (errors=1) https://ci.debian.net/data/autopkgtest/testing/amd64/x/xml2rfc/27394437/log.gz Upstream is apparently aware since (I discovered after uploading Weasyprint) they have recently pinned the Weasyprint dependency to <57.0. I did file an issue upstream: https://github.com/ietf-tools/xml2rfc/issues/921 Scott K
Bug#1013510: marked as pending in django-maintenancemode
Control: tag -1 pending Hello, Bug #1013510 in django-maintenancemode 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-maintenancemode/-/commit/4a0af6b90f769d79aab16c0167e9555f17552d43 New upstream git snapshot (Closes: #1013510) * New upstream git snapshot (Closes: #1013510) * Delete debian/patches, 0001-Fix-deprecation-warning-for-django.conf.urls.url.patch and 0002-Adjust-test-setup-to-work-with-Django-3.patch incorporated upstream (this message was generated automatically) -- Greetings https://bugs.debian.org/1013510
Bug#1013510: marked as pending in django-maintenancemode
Control: tag -1 pending Hello, Bug #1013510 in django-maintenancemode 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-maintenancemode/-/commit/4a0af6b90f769d79aab16c0167e9555f17552d43 New upstream git snapshot (Closes: #1013510) * New upstream git snapshot (Closes: #1013510) * Delete debian/patches, 0001-Fix-deprecation-warning-for-django.conf.urls.url.patch and 0002-Adjust-test-setup-to-work-with-Django-3.patch incorporated upstream (this message was generated automatically) -- Greetings https://bugs.debian.org/1013510
Bug#1017313: postfix: FTBFS: unistd.h:363:13: error: conflicting types for ‘closefrom’; have ‘void(int)’
On Saturday, September 24, 2022 5:40:20 AM EDT Christian Göttsche wrote: > control: tags -1 fixed-upstream > > The issue is fixed upstream in version 3.6.5[1]. > > [1]: https://www.postfix.org/announcements/postfix-3.6.5.html Thanks. I'm way behind on updating postfix. I'll try to find the time. Scott K
Bug#1017637: [Pkg-clamav-devel] Bug#1017637: havp: Not working anymore since linux-image-* v5.15.
On August 18, 2022 7:18:27 PM UTC, Sebastian Andrzej Siewior wrote: >Source: havp >Version: 0.93-2 >Severity: grave > >While testing havp before uploading I noticed that starting havp ends >quickly with: >| Starting HAVP Version: 0.93 >| Filesystem not supporting mandatory locks! >| On Linux, you need to mount filesystem with "-o mand" > >The so called "mandatory locks" have been removed from the Linux kernel >in v5.15 [0]. havp is compiled to use it and fails to continue if it is >not working. > >We have to options now: >- Remove havp from unstable. >- Pass --disable-locking to configure and build it without it. This > forces havp to download everything scan it first. > >I'm not a user of havp so I can't tell if disabling locking is an >option. There is a script with loopback mount and everything just to use >the locking without enabling it on the main partition. > >The first 5.15 kernel was uploaded by the end of 2021 and this went >unnoticed until now. Probably even longer if it wasn't for #1016270. > >Given that and the dropping popcon numbers, I lean towards RM. > >Anyone? > >[0] https://git.kernel.org/torvalds/c/f7e33bdbd6d1bdf9c3df8bba5abcf3399f957ac3 I agree. It's been dead upstream for a long time. I think this is a logical point to put an end to trying to keep it alive in Debian. Scott K
Bug#1008828: python3-spf-engine: fails with ImportError: cannot import name 'own_socketfile' from 'spf_engine.util'
This is already fixed in Testing. I plan to do a Stable to address it as well.
Scott K
On April 2, 2022 10:18:28 AM UTC, "Bjørn Mork" wrote:
>Package: python3-spf-engine
>Version: 2.9.2-1
>Severity: grave
>Justification: renders package unusable
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Dear Maintainer,
>
>Installing pyspf-milter with default dependencies and settings results
>in
>
># journalctl -u pyspf-milter
>- -- Journal begins at Sat 2022-03-26 15:26:01 CET, ends at Sat 2022-04-02
>12:11:13 CEST. --
>Apr 02 12:04:07 canardo systemd[1]: Started pySPF Milter.
>Apr 02 12:04:07 canardo pyspf-milter[372481]: Traceback (most recent call
>last):
>Apr 02 12:04:07 canardo pyspf-milter[372481]: Traceback (most recent call
>last):
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File "/usr/bin/pyspf-milter",
>line 11, in
>Apr 02 12:04:07 canardo pyspf-milter[372481]:
>load_entry_point('spf-engine==2.9.2', 'console_scripts', 'pyspf-milter')()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 474, in
>load_entry_point
>Apr 02 12:04:07 canardo pyspf-milter[372481]: return
>get_distribution(dist).load_entry_point(group, name)
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2846, in
>load_entry_point
>Apr 02 12:04:07 canardo pyspf-milter[372481]: return ep.load()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, in load
>Apr 02 12:04:07 canardo pyspf-milter[372481]: return self.resolve()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, in
>resolve
>Apr 02 12:04:07 canardo pyspf-milter[372481]: module =
>__import__(self.module_name, fromlist=['__name__'], level=0)
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/spf_engine/milter_spf.py", line 40, in
>Apr 02 12:04:07 canardo pyspf-milter[372481]: from spf_engine.util import
>own_socketfile
>Apr 02 12:04:07 canardo pyspf-milter[372481]: ImportError: cannot import name
>'own_socketfile' from 'spf_engine.util'
>(/usr/lib/python3/dist-packages/spf_engine/util.py)
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File "/usr/bin/pyspf-milter",
>line 11, in
>
> load_entry_point('spf-engine==2.9.2', 'console_scripts', 'pyspf-milter')()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 474, in
>load_entry_point
> return
> get_distribution(dist).load_entry_point(group, name)
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2846, in
>load_entry_point
> return ep.load()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, in load
> return self.resolve()
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, in
>resolve
> module =
> __import__(self.module_name, fromlist=['__name__'], level=0)
>Apr 02 12:04:07 canardo pyspf-milter[372481]: File
>"/usr/lib/python3/dist-packages/spf_engine/milter_spf.py", line 40, in
> from spf_engine.util import
> own_socketfile
>Apr 02 12:04:07 canardo pyspf-milter[372481]: ImportError: cannot import name
>'own_socketfile' from 'spf_engine.util'
>(/usr/lib/python3/dist-packages/spf_engine/util.py)
>Apr 02 12:04:07 canardo systemd[1]: pyspf-milter.service: Main process exited,
>code=exited, status=1/FAILURE
>Apr 02 12:04:07 canardo systemd[1]: pyspf-milter.service: Failed with result
>'exit-code'.
>
>
>No need to clutter the archive with completely broken and untested packages.
>
>
>- -- System Information:
>Debian Release: 11.3
> APT prefers stable-security
> APT policy: (700, 'stable-security'), (700, 'stable'), (699,
> 'stable-updates')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
>set
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages python3-spf-engine depends on:
>ii python3 3.9.2-3
>ii python3-authres 1.2.0-2
>ii python3-spf 2.0.14-2
>
>python3-spf-engine recommends no packages.
>
>python3-spf-engine suggests no packages.
>
>- -- no debconf information
>
>-BEGIN PGP SIGNATURE-
>
>iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCYkgi8Q4cYmpvcm5AbW9y
Bug#1005044: python3-subnettree: package completely broken, module won't load
On Sat, 5 Feb 2022 17:28:04 -0500 Michael Stone wrote: > It seems to be some kind of incompatibility in swig. Upstream .cc files > are built with swig 3, debian has swig 4. If the package is built with > the upstream .cc files (ditching the associated lines in debian/rules) > it seems to work fine. Thanks. I agree. The bad news is that would trade a DFSG issue for a technical issue, which might be considered progress (since the generated files can't be regenerated within Main anymore). I have experimented with the available knobs provided by swig and not found anything that works. I'll talk with upstream and see if they have any suggestions. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1000980: kubernetes: Please upgrade to golang-1.17
On Thu, 02 Dec 2021 12:29:37 +0800 Shengjing Zhu wrote: > Source: kubernetes > Version: 1.20.5+really1.20.2-1 > Severity: important > X-Debbugs-Cc: z...@debian.org > Control: block 998747 by -1 > > Dear Maintainer, > > As part of the effort to limit the number of Go compiler in the > archive, please upgrade to golang-1.17. golang-1.15 is gone now, so bumped to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1000826: python3-pip: incorrect version comparisons in requirements with Python 3.10
On Sun, 12 Dec 2021 07:29:34 +0100 Andreas Tille wrote: > > stefa...@debian.org wrote: > > We need to update setuptools to fix this (and carry a separate old one > > for 2.7, as long as python2.7 remains in the archive). > > Is there any chance that this upgrade of setuptools will happen soon? Once we update to pip 21.anything, python2 support will be gone anyway, so we'll have to discuss how to handle this. Unfortunately the resolvlib version in the archive now is too new for older pip versions so we'll either need to downgrade it or upgrade pip before we can do an upload to resolve this. I was able to confirm that a newer setuptools does solve this problem. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1003150: python3-wheel: Missing depends on python3-distutils
Package: python3-wheel Version: 0.34.2-1 Severity: serious Justification: Policy 4.5 Attempted to unpack a wheel in a pretty minimal sid chroot and got this error: $ python3 -m wheel unpack setuptools-44.1.1-py2.py3-none-any.whl Traceback (most recent call last): File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/usr/lib/python3/dist-packages/wheel/__main__.py", line 19, in sys.exit(main()) File "/usr/lib/python3/dist-packages/wheel/__main__.py", line 15, in main sys.exit(wheel.cli.main()) File "/usr/lib/python3/dist-packages/wheel/cli/__init__.py", line 83, in main args.func(args) File "/usr/lib/python3/dist-packages/wheel/cli/__init__.py", line 24, in unpack_f from .unpack import unpack File "/usr/lib/python3/dist-packages/wheel/cli/unpack.py", line 6, in from ..wheelfile import WheelFile File "/usr/lib/python3/dist-packages/wheel/wheelfile.py", line 10, in from distutils import log as logger ImportError: cannot import name 'log' from 'distutils' (/usr/lib/python3.9/distutils/__init__.py) Now that distutils is split out, wheel will need to explicitly depend on it. Scott K
Bug#1002497: FTBFS Arch-All with interactive rm
On Saturday, December 25, 2021 3:43:24 PM EST Vincent Lefevre wrote: > Control: severity -1 serious > Control: tags -1 ftbfs > Control: retitle -1 postfix: FTBFS Arch-All as rm on a write-protected file > is interactive > On 2021-12-23 11:12:40 +0100, Daniel Baumann wrote: > > there seems to be 'rm' missing the '-f', which makes the package fail to > > build from source if the building system has rm aliased to 'rm -i'. > > Even without such an alias: > > vinc17 33260 27638 0 21:34 pts/13 00:00:00 rm > debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in > > This is the default behavior of rm on a write-protected file, such as > > -r--r--r-- 1 vinc17 vinc17 12526 2021-12-25 21:34:15 > debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in > > So the -f option is needed *everywhere*. Certainly not a serious bug. I don't think building the package after write protecting the contents is a particularly supported configuration. Scott K P.S. Don't upgrade the severity again. If you think this is such a big deal, go get something in Debian policy. signature.asc Description: This is a digitally signed message part.
Bug#998565: Same issue hit tryton-modules-country
See #1002073. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1002073: src:tryton-modules-country: Tests fail with new iso-codes
Package: src:tryton-modules-country Version: 6.0.1-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using ftbfs since that's the closest thing we have to report an autopkgtest failure. The latest iso-codes made a lot of changes in existing data which caused test failures for multiple packages, including this one. Glancing at the test log, it looks like the tests needs some adaptation similar to what was just done for pycountry. Scott K
Bug#998565: Errors due to changes in iso-codes data
On Thu, 25 Nov 2021 00:54:48 +1100 Stuart Prescott wrote: > On Wednesday, 24 November 2021 18:05:57 AEDT Stuart Prescott wrote: > > I've looked at them and fixed most of the tests locally without issues. I > > guess I should push that somewhere so that it is visible. I'll start a > > draft PR with upstream for it. > > Now done: https://github.com/flyingcircusio/pycountry/pull/86 > > My preference would be to upload a new upstream version of iso-codes with > these improvements included, giving review and acceptance that these changes > are appropriate. If I can't do that in a timely fashion then backporting that > PR is possible. It's almost a month later. What do you think about uploading the fix to Debian? Scott K
Bug#1001824: xml2rfc: Incompatible with current weaseyprint
On Thu, 16 Dec 2021 23:28:26 -0500 Scott Kitterman wrote: > Package: xml2rfc > Version: 3.12.0-1 > Severity: serious > Tags: ftbfs upstream patch > Justification: fails to build from source > > Note: Using ftbfs because that's the closest thing we have to an > autopkgtest failure. > > The new version of weasyprint no longer uses the same PDF generation > libraries and as a result, xml2rfc's detection mechanism for if it is > capable of making a PDF is not working (see attached patch). > > Once the detection mechanism is patched, PDF generation works fine, > which leads me to believe the test failure is bogus: > > == > FAIL: test_text_content (__main__.PdfWriterTests) > -- > Traceback (most recent call last): > File "/home/xml2rfc-3.12.0/test.py", line 510, in test_text_content > self.assertIn(t, text) > AssertionError: 'RFC' not found in 'l- WN –&,ÛžÆ TNDQ&·sX l-%Zñ¢<³ WN P½RÔ > n®>Ø %˜oh l† .µ ¬( .µ=N' > > -- > > If things were really that garbled, I don't see how it could make a PDF. > > Reported upstream: > > https://trac.ietf.org/trac/xml2rfc/ticket/696 > > In the interim, I think it might make sense to apply the attached patch > and get rid of the failing test. If we go down this path, then this > will also need fixing (get rid of HAVE_CAIRO and HAVE_PANGO): > > xml2rfc-3.12.0/test.py", line 513, in test_included_fonts > > if xml2rfc.HAVE_WEASYPRINT and xml2rfc.HAVE_PYCAIRO and > xml2rfc.HAVE_CAIRO and xml2rfc.HAVE_PANGO: dkg, Unless you want to object, I think we should go ahead and make this change. I don't get the impression that since the IETF LLC booted Henrik there's much upstream going on, so I don't see much point in waiting for them. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1001824: xml2rfc: Incompatible with current weaseyprint
Package: xml2rfc
Version: 3.12.0-1
Severity: serious
Tags: ftbfs upstream patch
Justification: fails to build from source
Note: Using ftbfs because that's the closest thing we have to an
autopkgtest failure.
The new version of weasyprint no longer uses the same PDF generation
libraries and as a result, xml2rfc's detection mechanism for if it is
capable of making a PDF is not working (see attached patch).
Once the detection mechanism is patched, PDF generation works fine,
which leads me to believe the test failure is bogus:
==
FAIL: test_text_content (__main__.PdfWriterTests)
--
Traceback (most recent call last):
File "/home/xml2rfc-3.12.0/test.py", line 510, in test_text_content
self.assertIn(t, text)
AssertionError: 'RFC' not found in 'l- WN –&,ÛžÆ TNDQ&·sX l-%Zñ¢<³ WN P½RÔ n®>Ø
%˜oh l† .µ ¬( .µ=N'
--
If things were really that garbled, I don't see how it could make a PDF.
Reported upstream:
https://trac.ietf.org/trac/xml2rfc/ticket/696
In the interim, I think it might make sense to apply the attached patch
and get rid of the failing test. If we go down this path, then this
will also need fixing (get rid of HAVE_CAIRO and HAVE_PANGO):
xml2rfc-3.12.0/test.py", line 513, in test_included_fonts
if xml2rfc.HAVE_WEASYPRINT and xml2rfc.HAVE_PYCAIRO and xml2rfc.HAVE_CAIRO
and xml2rfc.HAVE_PANGO:
Scott K
diff -ruN a/xml2rfc/__init__.py b/xml2rfc/__init__.py
--- a/xml2rfc/__init__.py 2021-12-16 10:31:27.857538775 -0500
+++ b/xml2rfc/__init__.py 2021-12-16 22:56:51.310061387 -0500
@@ -40,21 +40,6 @@
except (ImportError, OSError):
cairo = False
HAVE_PYCAIRO = False
-try:
-from weasyprint.text import cairo
-HAVE_CAIRO = True
-CAIRO_VERSION = cairo.cairo_version()
-except (ImportError, OSError):
-HAVE_CAIRO = False
-CAIRO_VERSION = None
-try:
-from weasyprint.text import pango
-HAVE_PANGO = True
-PANGO_VERSION = pango.pango_version
-except (ImportError, OSError, AttributeError):
-HAVE_PANGO = False
-PANGO_VERSION = None
-
def get_versions():
import sys
diff -ruN a/xml2rfc/run.py b/xml2rfc/run.py
--- a/xml2rfc/run.py2021-12-16 10:31:27.861538832 -0500
+++ b/xml2rfc/run.py2021-12-16 23:00:12.948957766 -0500
@@ -35,10 +35,6 @@
missing += "\nCould not import weasyprint"
if not xml2rfc.HAVE_PYCAIRO:
missing += "\nCould not import pycairo"
-if not xml2rfc.HAVE_CAIRO:
-missing += "\nCould not find the cairo lib"
-if not xml2rfc.HAVE_PANGO:
-missing += "\nCould not find the pango lib"
return missing
@@ -212,7 +208,7 @@
help='outputs formatted HTML to file')
formatgroup.add_argument('--nroff', action='store_true',
help='outputs formatted nroff to file (only v2
input)')
-if xml2rfc.HAVE_CAIRO and xml2rfc.HAVE_PANGO:
+if xml2rfc.HAVE_PYCAIRO and xml2rfc.HAVE_WEASYPRINT:
formatgroup.add_argument('--pdf', action='store_true',
help='outputs formatted PDF to file')
else:
Bug#1000753: poliastro FTBFS: plugin flit failed with: Use [project] table for metadata or [tool.flit.metadata], not both
On Wed, 01 Dec 2021 14:07:52 -0500 Scott Kitterman
wrote:
> On Sun, 28 Nov 2021 14:17:14 + "Rebecca N. Palmer"
> wrote:
> > Package: python3-poliastro
> > Version: 0.15.2-3
> > Severity: serious
> >
> > Fails to build with the error
> >
> > E: pybuild pybuild:354: build: plugin flit failed with: Use [project]
> > table for metadata or [tool.flit.metadata], not both.
>
> this should be pretty trivially resolved by dropping Revert-the-adoption-
> PEP-621-metadata.patch and bumping the minimum flit version in build-depends
to
> 3.2. Now that we have flit 3.3 in the archive, using the PEP 621 metadata is
> not a problem.
Confirmed. NMU diff attached. I'm not going to upload this now, but I may
later. I'd prefer one of the maintainers take care of it.
Scott Kdiff -Nru poliastro-0.15.2/debian/changelog poliastro-0.15.2/debian/changelog
--- poliastro-0.15.2/debian/changelog 2021-08-28 09:09:23.0 -0400
+++ poliastro-0.15.2/debian/changelog 2021-12-01 17:30:34.0 -0500
@@ -1,3 +1,12 @@
+poliastro (0.15.2-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop debian/patches/Revert-the-adoption-PEP-621-metadata.patch and bump
+minimum flit version in build-depends to 3.2 (to ensure PEP 621 support)
+ in order fo fix FTBFS with flit 3.3 (Closes: #1000753)
+
+ -- Scott Kitterman Wed, 01 Dec 2021 17:30:34 -0500
+
poliastro (0.15.2-3) unstable; urgency=medium
* Negate the 32-bit test in xfail: was accidently reversed
diff -Nru poliastro-0.15.2/debian/control poliastro-0.15.2/debian/control
--- poliastro-0.15.2/debian/control 2021-08-24 10:56:53.0 -0400
+++ poliastro-0.15.2/debian/control 2021-12-01 17:30:29.0 -0500
@@ -5,7 +5,7 @@
Uploaders: Ole Streicher
Build-Depends: debhelper-compat (= 13),
dh-python,
- flit,
+ flit (>= 3.2),
python3-all,
python3-astropy (>= 3.2~),
python3-astroquery,
diff -Nru poliastro-0.15.2/debian/patches/Revert-the-adoption-PEP-621-metadata.patch poliastro-0.15.2/debian/patches/Revert-the-adoption-PEP-621-metadata.patch
--- poliastro-0.15.2/debian/patches/Revert-the-adoption-PEP-621-metadata.patch 2021-08-28 08:02:51.0 -0400
+++ poliastro-0.15.2/debian/patches/Revert-the-adoption-PEP-621-metadata.patch 1969-12-31 19:00:00.0 -0500
@@ -1,88 +0,0 @@
-From: =?utf-8?q?Juan_Luis_Cano_Rodr=C3=ADguez?=
-Date: Fri, 23 Apr 2021 12:03:06 +0200
-Subject: Revert the adoption PEP 621 metadata
-
-https://github.com/takluyver/flit/issues/436
- pyproject.toml | 36 +++-
- 1 file changed, 15 insertions(+), 21 deletions(-)
-
-diff --git a/pyproject.toml b/pyproject.toml
-index b6bddd5..3fa7389 100644
a/pyproject.toml
-+++ b/pyproject.toml
-@@ -1,28 +1,18 @@
- [build-system]
- requires = [
--"flit_core >=3.2,<3.3",
-+"flit_core >=2.0,<4",
- "wheel",
- "oldest-supported-numpy",
- ]
- build-backend = "flit_core.buildapi"
-
--[project]
--name = "poliastro"
--readme = "README.md"
--requires-python = ">=3.7,<3.10"
--license = {file = "COPYING"}
--authors = [
--{name = "Juan Luis Cano Rodríguez", email = "hello@juanlu.space"}
--]
--keywords = [
--"aero",
--"aerospace",
--"engineering",
--"astrodynamics",
--"orbits",
--"kepler",
--"orbital mechanics"
--]
-+[tool.flit.metadata]
-+module = "poliastro"
-+author = "Juan Luis Cano Rodríguez"
-+author-email = "hello@juanlu.space"
-+description-file = "README.md"
-+home-page = "https://github.com/poliastro/poliastro/;
-+keywords = "aero,aerospace,engineering,astrodynamics,orbits,kepler,orbital mechanics"
- classifiers = [
- "License :: OSI Approved :: MIT License",
- "Development Status :: 4 - Beta",
-@@ -41,7 +31,8 @@ classifiers = [
- "Topic :: Scientific/Engineering :: Physics",
- "Topic :: Scientific/Engineering :: Astronomy",
- ]
--dependencies = [
-+requires-python = ">=3.7,<3.10"
-+requires = [
- "astropy >=3.2,<5",
- "astroquery >=0.3.9",
- "cached_property ; python_version<'3.8'",
-@@ -55,7 +46,6 @@ dependencies = [
- "pyerfa",
- "scipy >=1.4.0",
- ]
--dynamic = ["version", "description"]
-
- [project.urls]
- Home-Page = "https://www.poliastro.space;
-@@ -64,7 +54,7 @@ Source = "https://github.com/poliastro/poliastro;
- Tracker = "https://github.com/poliastro/poliastro/issues;
- Funding = "https://opencollective.com/poliastro;
-
--[project.optional-dependenc
Bug#1000753: poliastro FTBFS: plugin flit failed with: Use [project] table for metadata or [tool.flit.metadata], not both
On Sun, 28 Nov 2021 14:17:14 + "Rebecca N. Palmer" wrote: > Package: python3-poliastro > Version: 0.15.2-3 > Severity: serious > > Fails to build with the error > > E: pybuild pybuild:354: build: plugin flit failed with: Use [project] > table for metadata or [tool.flit.metadata], not both. this should be pretty trivially resolved by dropping Revert-the-adoption- PEP-621-metadata.patch and bumping the minimum flit version in build-depends to 3.2. Now that we have flit 3.3 in the archive, using the PEP 621 metadata is not a problem. Scott K
Bug#1000833: src:python-license-expression: Package licenses not properly documented in debian/copyright
Package: src:python-license-expression Version: 21.6.14-1 Severity: serious Justification: Policy 4.5 As mentioned during the review in New: I am going to accept this and file a bug because the issue alread exists in the archive from the current package. The package debian/copyright claims that _pyahocorasick.py is public domain. This appears to be incorrect. If you check the source of the code documented in _pyahocorasick.ABOUT, it says the license in BSD 3-Clause. See: https://github.com/WojciechMula/pyahocorasick/blob/master/LICENSE Scott K
Bug#998565: Errors due to changes in iso-codes data
On November 24, 2021 1:54:48 PM UTC, Stuart Prescott wrote: >On Wednesday, 24 November 2021 18:05:57 AEDT Stuart Prescott wrote: >> I've looked at them and fixed most of the tests locally without issues. I >> guess I should push that somewhere so that it is visible. I'll start a >> draft PR with upstream for it. > >Now done: https://github.com/flyingcircusio/pycountry/pull/86 > >My preference would be to upload a new upstream version of iso-codes with >these improvements included, giving review and acceptance that these changes >are appropriate. If I can't do that in a timely fashion then backporting that >PR is possible. Thanks. Now that I look at it, that solution to the flags issue in the tests seems obvious and appropriate. It didn't occur to me when I was looking at the problem. Scott K
Bug#998565: Errors due to changes in iso-codes data
On Tue, 16 Nov 2021 01:30:55 +1100 Stuart Prescott wrote: > Hi Scott & Tobias > > On Monday, 15 November 2021 21:13:09 AEDT Dr. Tobias Quathamer wrote: > > On Sun, 14 Nov 2021 20:30:06 -0500 Scott Kitterman > > > > wrote: > > > I looked at this a bit today and it looks like the test failures are due > > > to > > > updates in the iso-codes data used by the tests, not any real failures. I > > > think disabling the failing tests for now would be a reasonable way to > > > keep > > > this in testing (I'm interested to avoid transitive removal of xml2rfc). > > > > > > Unless there's some objection to this, I will probably NMU later in the > > > week. > > > > > > Scott K > > > > Hi Scott, > > > > iso-codes maintainer here -- I've just seen this bug and your mail. Your > > analysis is correct, from my point of view, you should go ahead with the > > NMU. > > The tests look easy enough to fix, so it's worth trying to do that. (and it's > in the Debian group on salsa to make that easy :) > > I'm a bit surprised by some of the data changes though -- apparently England > is no longer a part of the UK. Yes, that's quite complicated, but the > ISO-3166-2 info does still list ENG and EAW. As the pycountry tests > highlight, > those divisions disappeared from iso_3166-2.json with the switch over to a > different data harvester. > > https://www.iso.org/obp/ui/#iso:code:3166:GB > > Is that correct and intended? Good question. I not sure how to adapt one test to the new data, so I'll leave it on to you to deal with. Please address this before it gets auto-removed. Scott K
Bug#999873: python3-eventlet: Eventlet greendns incompatible with dnspython 2.1.0
Package: python3-eventlet Version: 0.30.2-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, Once again, eventlet is incompatible with dnspython and needs fixing. The specific test that is failing is tests.socket_test.test_dns_methods_are_green. I attempted to trouble shoot it a bit and determined that there is a socket error: [Errno -2] Name or service not known. Note: Used the FTBFS tag since that's the closest thing we have to a autopkgttest regression. Scott K
Bug#998565: Errors due to changes in iso-codes data
I looked at this a bit today and it looks like the test failures are due to updates in the iso-codes data used by the tests, not any real failures. I think disabling the failing tests for now would be a reasonable way to keep this in testing (I'm interested to avoid transitive removal of xml2rfc). Unless there's some objection to this, I will probably NMU later in the week. Scott K
