Bug#1070659: transition: re2
Package: release.debian.org Severity: normal X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:re2 User: release.debian@packages.debian.org Usertags: transition Control: block -1 with 1070649 1053409 It has taken a while to prepare the next re2 transition, because it included a new dependency on abseil. This broke most of the reverse-dependencies. It also means that transitions will get more frequent, as every abseil transition will change re2's ABI. I think the state of the reverse-dependencies is reasonable, now. I just did a rebuild of them all, and got these failures: yaramod FTBFS (#1037908): https://debusine.debian.net/artifact/66513/yaramod_3.6.0-1.1_amd64-2024-05-06T14:59:09Z.build clickhouse FTBFS (#1070658): https://debusine.debian.net/artifact/66521/clickhouse_18.16.1+ds-7.4_amd64-2024-05-06T14:59:16Z.build libvmod-re2 FTBFS Looks like a libre2-11 regression, but simple: #1070649: https://debusine.debian.net/artifact/66531/libvmod-re2_2.0.0-2_amd64-2024-05-06T15:18:37Z.build qtwebengine-opensource-src FTBFS libre2-11 regression, patch pending: #1053409: https://debusine.debian.net/artifact/66545/qtwebengine-opensource-src_5.15.15+dfsg-3_amd64-2024-05-06T15:31:32Z.build Ben file: title = "re2"; is_affected = .depends ~ "libre2-10" | .depends ~ "libre2-11"; is_good = .depends ~ "libre2-11"; is_bad = .depends ~ "libre2-10"; Stefano
Bug#1070658: FTBFS: error: expected ‘)’ before ‘maxLength’
Source: clickhouse Version: 18.16.1+ds-7.4 Severity: serious Tags: ftbfs Justification: ftbfs clickhouse FTBFS in unstable: [ 87%] Building CXX object dbms/CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o cd /<>/obj-x86_64-linux-gnu/dbms && /usr/bin/c++ -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -Ddbms_EXPORTS -I/<>/contrib/cityhash102/include -I/<>/libs/libpocoext/include -I/<>/libs/libmysqlxx/include -I/<>/contrib/libbtrie/include -isystem /<>/contrib/libdivide -isystem /<>/dbms/src -isystem /<>/obj-x86_64-linux-gnu/dbms/src -isystem /<>/contrib/libpcg-random/include -isystem /<>/libs/libcommon/include -isystem /<>/obj-x86_64-linux-gnu/libs/libcommon/include -isystem /usr/include/metrohash -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -fno-omit-frame-pointer -Wall -Wnon-virtual-dtor -Wextra -O2 -g -DNDEBUG -O3 -std=c++17 -flto=auto -fno-fat-lto-objects -fPIC -fno-tree-loop-distribute-patterns -MD -MT dbms/CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o -MF CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o.d -o CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o -c /<>/dbms/src/Storages/MergeTree/LevelMergeSelector.cpp In file included from /<>/dbms/src/Interpreters/InterserverIOHandler.h:8, from /<>/dbms/src/Storages/MergeTree/DataPartsExchange.h:3, from /<>/dbms/src/Storages/MergeTree/DataPartsExchange.cpp:1: /usr/include/Poco/BinaryWriter.h:137:14: error: expected ‘)’ before ‘maxLength’ 137 | void writeCString(const char* cString, std::streamsize maxLength = DEFAULT_MAX_CSTR_LENGTH); | ^~~~ /usr/include/Poco/BinaryWriter.h:137:14: note: to match this ‘(’ 137 | void writeCString(const char* cString, std::streamsize maxLength = DEFAULT_MAX_CSTR_LENGTH); | ^~~~ Full build log: https://debusine.debian.net/artifact/66597/clickhouse_18.16.1+ds-7.4_amd64-2024-05-06T16:48:46Z.build Stefano
Bug#1070649: libvmod-re2: FTBFS with libre2-11 (experimental)
Source: libvmod-re2 Version: 2.0.0-2 Severity: important Tags: ftbfs Control: affects -1 src:re2 libvmod-re2 fails to build with re2 from experimental: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/varnish -Wall -Werror -Wextra -std=c99 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -pthread -fstack-protector -c vmod_re2.c -fPIC -DPIC -o .libs/vmod_re2.o In file included from /usr/include/absl/base/config.h:86, from /usr/include/absl/base/internal/invoke.h:40, from /usr/include/absl/base/call_once.h:34, from /usr/include/re2/re2.h:222, from vre2/vre2set.h:43, from vre2/vre2set.cpp:34: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported." Full build log: https://debusine.debian.net/artifact/66531/libvmod-re2_2.0.0-2_amd64-2024-05-06T15:18:37Z.build It looks like it needs to set a higher C++ std version. Stefano
Bug#1053411: sra-sdk: FTBFS with re2 >= 20230601 (which requires abseil)
Control: severity -1 important 6 months later, raising the severity. Pinning an ancient upstream version of a library is a problem. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1070286: pipx: The ‘list’ command falsely claims “nothing has been installed with pipx ”
Hi Manny (2024.05.03_09:47:23_+)
> $ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin
> pipx install --verbose argostranslate
...
> The argostranslate app runs fine. So it’s unclear why pipx would lose
> track of it right away.
Maybe something to do with setting a weird PIPX_HOME ?
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command
Hi Manny (2024.05.03_09:01:10_+) > I would report upstream if the bug tracker were hosted in a more open > and neutral place. Microsoft venues are places I will not go to > interact, apart from searching to see if a report already exists. > Github in particular has access problems. I can understand and respect that. But at the same time, I am not your bug proxy. So this bug will just sit here, and not be much use to anyone. BTW, there is a #pip on the PyPA discord, if you want to interact with Pip upstream, off GitHub. > Debian shelters users with this bug reporting policy¹: > > “Don't file bugs upstream > >If you file a bug in Debian, don't send a copy to the upstream >software maintainers yourself, as it is possible that the bug >exists only in Debian. If necessary, the maintainer of the package >will forward the bug upstream.” I generally think that's a bad policy. There are situations where that makes sense. But in most cases, filing the bug upstream is the best way to get it fixed. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)
Hi Manny (2024.05.02_19:34:03_+) > I’m a bit confused because “pip3 list” shows a list of 146 packages, > but not argostranslation. Why did all those other packages survive the > upgrade? I wonder if some of them are somehow managed by apt. Yes, probably. > > So, I'm afraid you're well out of the supported area of pip. > > Sorry. > > Is it necessary for aptitude full-upgrade to withhold information from > the user about package destruction or removal? Ideally users would > get a loud warning when actions are taken that are expected to impact > an installed package. If it’s a mission critical tool, users need to > be able to back out of the upgrade and assess the consequences. Anything you install without apt, in /usr/local, /opt, etc. is outside of apt's area of responsibility. It's up to you to manage these yourself. > I would also like to mention a fifth defect I just discovered: > > ⑤ argostranslate was only /partially/ removed. > > There are some big language files that were originally installed by > argostranslate. The argostranslate executable survived the upgrade but > not some of the modules it relies on, leaving it in a broken partially > existent state with no information given to the user. The language > packs remained in tact. I don’t know where on the filesystem they > live, but when I installed argostranslate again the previous language > packs were found and automatically available for use. They're probably there, just not importable in your new python. Have a look around in /usr/local. > The pip package manager has an uninstall procedure and since pip is > the manager of the argostranslate package, users rely on it to keep > track of the objects associated to the application. Pip is a far less expansive package manager than apt. It's only responsible for installing libraries and applications *within* a particular Python install. It doesn't try to do anything beyond that. Stefano -- Stefano Rivera http://tumbleweed.org.za/
Bug#1070133: Patches for these two bugs
Control: tag 1070133 +pending Control: tag 1070135 +pending Hi Steve (2024.05.01_06:07:10_-0400) Thanks for the patches, backported some more security patches and filed a bookworm-pu request (#1070232). Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command
Hi Manny (2024.05.01_19:47:09_+) Please report this upstream to https://github.com/pypa/pip This does not sound Debian-specific at all. I can't reproduce the bug, without writing a proxy that causes a failure like you had, which is far beyond the effort I'm willing to put in here. You're in a much better position to advocate for this bug upstream than I am. Stefano -- Stefano Rivera http://tumbleweed.org.za/
Bug#1070158: bullseye-pu: package distro-info-data/0.51+deb11u6
Package: release.debian.org Severity: normal Tags: bullseye X-Debbugs-Cc: distro-info-d...@packages.debian.org Control: affects -1 + src:distro-info-data User: release.debian@packages.debian.org Usertags: pu This is a regular distro-info-data update. [ Reason ] This update adds: 1. bullseye and bookworm LTS & ELTS. 2. Ubuntu 24.10 Oracular Oriole [ Impact ] $ ubuntu-distro-info -d ubuntu-distro-info: Distribution data outdated. $ debian-distro-info --lts -f --date=2024-09-01 $ [ Tests ] We have automated tests that check the basic CSV data structure. Manually verified the affected Debian & Ubuntu releases. [ Risks ] Minimal, this is a data-only package, and there are no schema changes. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] * Update data to 0.61: - Declare LTS and ELTS intentions for bullseye and bookworm - debian: Fix LTS EOL date for bullseye - debian.csv: Fix EOL date for 2.2 - Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136) diff -Nru distro-info-data-0.51+deb11u5/debian/changelog distro-info-data-0.51+deb11u6/debian/changelog --- distro-info-data-0.51+deb11u5/debian/changelog 2023-10-29 08:57:15.0 -0400 +++ distro-info-data-0.51+deb11u6/debian/changelog 2024-04-30 20:54:51.0 -0400 @@ -1,3 +1,13 @@ +distro-info-data (0.51+deb11u6) bullseye; urgency=medium + + * Update data to 0.61: +- Declare LTS and ELTS intentions for bullseye and bookworm +- debian: Fix LTS EOL date for bullseye +- debian.csv: Fix EOL date for 2.2 +- Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136) + + -- Stefano Rivera Tue, 30 Apr 2024 20:54:51 -0400 + distro-info-data (0.51+deb11u5) bullseye; urgency=medium * Update data to 0.59: diff -Nru distro-info-data-0.51+deb11u5/debian.csv distro-info-data-0.51+deb11u6/debian.csv --- distro-info-data-0.51+deb11u5/debian.csv2023-10-29 08:57:15.0 -0400 +++ distro-info-data-0.51+deb11u6/debian.csv2024-04-30 20:54:51.0 -0400 @@ -4,7 +4,7 @@ 1.3,Bo,bo,1996-12-12,1997-06-05,1999-03-09 2.0,Hamm,hamm,1997-06-05,1998-07-24,2000-03-09 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30 -2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30 +2.2,Potato,potato,1999-03-09,2000-08-15,2003-06-30 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30 3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 @@ -14,8 +14,8 @@ 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30 9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30 10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30 -11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14 -12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10 +11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14,2026-08-31,2031-06-30 +12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10,2028-06-30,2033-06-30 13,Trixie,trixie,2023-06-10 14,Forky,forky,2025-08-01 ,Sid,sid,1993-08-16 diff -Nru distro-info-data-0.51+deb11u5/ubuntu.csv distro-info-data-0.51+deb11u6/ubuntu.csv --- distro-info-data-0.51+deb11u5/ubuntu.csv2023-10-29 08:57:15.0 -0400 +++ distro-info-data-0.51+deb11u6/ubuntu.csv2024-04-30 20:54:51.0 -0400 @@ -39,3 +39,4 @@ 23.04,Lunar Lobster,lunar,2022-10-20,2023-04-20,2024-01-25 23.10,Mantic Minotaur,mantic,2023-04-20,2023-10-12,2024-07-11 24.04 LTS,Noble Numbat,noble,2023-10-12,2024-04-25,2029-05-31,2029-05-31,2034-04-25 +24.10,Oracular Oriole,oracular,2024-04-25,2024-10-10,2025-07-10
Bug#1070157: bookworm-pu: package distro-info-data/0.58+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: distro-info-d...@packages.debian.org Control: affects -1 + src:distro-info-data User: release.debian@packages.debian.org Usertags: pu This is a regular distro-info-data update. [ Reason ] This update adds: 1. bullseye and bookworm LTS & ELTS. 2. Ubuntu 24.10 Oracular Oriole [ Impact ] $ ubuntu-distro-info -d ubuntu-distro-info: Distribution data outdated. $ debian-distro-info --lts -f --date=2024-09-01 $ [ Tests ] We have automated tests that check the basic CSV data structure. Manually verified the affected Debian & Ubuntu releases. [ Risks ] Minimal, this is a data-only package, and there are no schema changes. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] * Update data to 0.61: - Declare LTS and ELTS intentions for bullseye and bookworm - debian: Fix LTS EOL date for bullseye - debian.csv: Fix EOL date for 2.2 - Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136) diff -Nru distro-info-data-0.58+deb12u1/debian/changelog distro-info-data-0.58+deb12u2/debian/changelog --- distro-info-data-0.58+deb12u1/debian/changelog 2023-10-29 06:12:45.0 -0400 +++ distro-info-data-0.58+deb12u2/debian/changelog 2024-04-30 20:41:56.0 -0400 @@ -1,3 +1,13 @@ +distro-info-data (0.58+deb12u2) bookworm; urgency=medium + + * Update data to 0.61: +- Declare LTS and ELTS intentions for bullseye and bookworm +- debian: Fix LTS EOL date for bullseye +- debian.csv: Fix EOL date for 2.2 +- Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136) + + -- Stefano Rivera Tue, 30 Apr 2024 20:41:56 -0400 + distro-info-data (0.58+deb12u1) bookworm; urgency=medium * Update data to 0.59: diff -Nru distro-info-data-0.58+deb12u1/debian.csv distro-info-data-0.58+deb12u2/debian.csv --- distro-info-data-0.58+deb12u1/debian.csv2023-10-29 06:12:45.0 -0400 +++ distro-info-data-0.58+deb12u2/debian.csv2024-04-30 20:41:56.0 -0400 @@ -4,7 +4,7 @@ 1.3,Bo,bo,1996-12-12,1997-06-05,1999-03-09 2.0,Hamm,hamm,1997-06-05,1998-07-24,2000-03-09 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30 -2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30 +2.2,Potato,potato,1999-03-09,2000-08-15,2003-06-30 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30 3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 @@ -14,8 +14,8 @@ 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30 9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30 10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30 -11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14 -12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10 +11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14,2026-08-31,2031-06-30 +12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10,2028-06-30,2033-06-30 13,Trixie,trixie,2023-06-10 14,Forky,forky,2025-08-01 ,Sid,sid,1993-08-16 diff -Nru distro-info-data-0.58+deb12u1/ubuntu.csv distro-info-data-0.58+deb12u2/ubuntu.csv --- distro-info-data-0.58+deb12u1/ubuntu.csv2023-10-29 06:12:45.0 -0400 +++ distro-info-data-0.58+deb12u2/ubuntu.csv2024-04-30 20:41:56.0 -0400 @@ -39,3 +39,4 @@ 23.04,Lunar Lobster,lunar,2022-10-20,2023-04-20,2024-01-25 23.10,Mantic Minotaur,mantic,2023-04-20,2023-10-12,2024-07-11 24.04 LTS,Noble Numbat,noble,2023-10-12,2024-04-25,2029-05-31,2029-05-31,2034-04-25 +24.10,Oracular Oriole,oracular,2024-04-25,2024-10-10,2025-07-10
Bug#1069890: Resignation & call for votes to elect the Chair
Hi Helmut (2024.04.29_06:33:40_-0400) > > I am happy to continue to volunteer for the role, if the committee agrees. > > > > The ballot: > > > > ===BEGIN > > > > A: Christoph Berg > > B: Matthew Garrett > > C: Helmut Grohne > > D: Stefano Rivera > > E: Timo Röhling > > F: Craig Small > > G: Matthew Vernon > > H: Sean Whitton > > > > ===END I vote: H > ABG > CDE > F Helmut's rationale makes sense to me. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Bug#1067785: pipx : modifies the wrong zsh init files.
Control: reassign -1 python3-userpath Control: found -1 python3-userpath/1.9.1-1 Control: affects -1 pipx Control: tag -1 + upstream Hi Erwan (2024.03.26_14:55:30_-0400) Thanks for the bug report. This sounds like an upstream bug in userpath. Would you mind filing it there? I'm not a zsh user, so I can't advocate for correct zsh configuration as well as you can. https://github.com/ofek/userpath/issues The relevant line is: https://github.com/ofek/userpath/blob/981085be7669815a186420e1211ed9944ab928ba/userpath/shells.py#L98 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1067635: RM: hdmi2usb-mode-switch -- ROM; unmaintained upstream, supporting old hardware
Package: ftp.debian.org Severity: normal Tags: ftbfs X-Debbugs-Cc: hdmi2usb-mode-swi...@packages.debian.org, debconf-vi...@lists.debian.org Control: affects -1 + src:hdmi2usb-mode-switch User: ftp.debian@packages.debian.org Usertags: remove ixo-usb-jtag and hdmi2usb-fx2-firmware FTBFS due to sdcc 4.4 (changed syntax in sbit). I could possibly fix it, but I can't test it. I have some devices, but they're in storage, not at hand. Without them, I don't see any point in keeping hdmi2usb-mode-switch in Debian. This hardware is all long EoL, and the DebConf video team doesn't use it any more. Stefano
Bug#1067633: RM: hdmi2usb-fx2-firmware -- ROM; FTBFS, unmaintained upstream, supporting old hardware
Package: ftp.debian.org Severity: normal Tags: ftbfs X-Debbugs-Cc: hdmi2usb-fx2-firmw...@packages.debian.org, debconf-vi...@lists.debian.org Control: affects -1 + src:hdmi2usb-fx2-firmware User: ftp.debian@packages.debian.org Usertags: remove hdmi2usb-fx2-firmware FTBFS due to sdcc 4.4 (changed syntax in sbit). I could possibly fix it, but I can't test it. I have some devices, but they're in storage, not at hand. This hardware is all long EoL, and the DebConf video team doesn't use it any more. Stefano
Bug#1067632: RM: ixo-usb-jtag -- ROM; FTBFS, unmaintained upstream, supporting old hardware
Package: ftp.debian.org Severity: normal Tags: ftbfs X-Debbugs-Cc: ixo-usb-j...@packages.debian.org, debconf-vi...@lists.debian.org Control: affects -1 + src:ixo-usb-jtag User: ftp.debian@packages.debian.org Usertags: remove ixo-usb-jtag FTBFS due to sdcc 4.4 (changed syntax in sbit). I could possibly fix it, but I can't test it. I have some devices, but they're in storage, not at hand. This hardware is all long EoL, and the DebConf video team doesn't use it any more. Stefano
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Hi Sean (2024.03.09_22:06:42_-0400) > ===BEGIN > The Technical Committee recommends that Craig Small be > appointed by the Debian Project Leader to the Technical Committee. > > C: Recommend to Appoint Craig Small > F: Further Discussion > ===END I vote: C > F Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Bug#1065326: bookworm-pu: package python3.11/3.11.2-6+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: python3...@packages.debian.org, d...@debian.org
Control: affects -1 + src:python3.11
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
A use-after-free causing a SEGV was found in python 3.11, affecting the
the Zulip chat server.
The bug is known to affect python 3.11.0 - 3.11.4. And since being fixed
upstream, there have been no known related regressions.
[ Impact ]
Potential SEGV in python3. Known to be triggered by zulip's CI when
running under coverage.
[ Tests ]
The Python stdlib testsuite is extensive and passes with this patch.
There is a stand-alone reproducer that I've manually reproduced the bug
with and verified that it's fixed.
[ Risks ]
The code is pretty straight-forward. It asserts that the f_frame hasn't
already been freed before freeing.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
diff -Nru python3.11-3.11.2/debian/changelog python3.11-3.11.2/debian/changelog
--- python3.11-3.11.2/debian/changelog 2023-03-13 08:18:29.0 -0400
+++ python3.11-3.11.2/debian/changelog 2024-03-02 16:28:50.0 -0400
@@ -1,3 +1,11 @@
+python3.11 (3.11.2-6+deb12u1) bookworm; urgency=medium
+
+ [ Anders Kaseorg ]
+ * Fix a use-after-free crash when deallocating a frame object
+(closes: #1050843).
+
+ -- Stefano Rivera Sat, 02 Mar 2024 16:28:50 -0400
+
python3.11 (3.11.2-6) unstable; urgency=high
[ Stefano Rivera ]
diff -Nru python3.11-3.11.2/debian/patches/frame_dealloc-crash.diff
python3.11-3.11.2/debian/patches/frame_dealloc-crash.diff
--- python3.11-3.11.2/debian/patches/frame_dealloc-crash.diff 1969-12-31
20:00:00.0 -0400
+++ python3.11-3.11.2/debian/patches/frame_dealloc-crash.diff 2024-03-02
16:28:50.0 -0400
@@ -0,0 +1,54 @@
+Description: Fix use-after-free crash in frame_dealloc
+ It was possible for the trashcan to delay the deallocation of a
+ PyFrameObject until after its corresponding _PyInterpreterFrame has
+ already been freed. So frame_dealloc needs to avoid dereferencing the
+ f_frame pointer unless it first checks that the pointer still points
+ to the interpreter frame within the frame object.
+Origin:
https://github.com/python/cpython/commit/46cae02085311481dc8b1ea9a5110969d9325bc7
+Bug-upstream: https://github.com/python/cpython/issues/106092
+Bug-Debian: https://bugs.debian.org/1050843
+Author: Anders Kaseorg
+Last-Update: 2023-08-29
+Applied-Upstream: 3.11.5
+
+---
+ .../2023-07-18-16-13-51.gh-issue-106092.bObgRM.rst | 2 ++
+ Objects/frameobject.c | 13 +++--
+ 2 files changed, 9 insertions(+), 6 deletions(-)
+ create mode 100644 Misc/NEWS.d/next/Core and
Builtins/2023-07-18-16-13-51.gh-issue-106092.bObgRM.rst
+
+--- /dev/null
b/Misc/NEWS.d/next/Core and
Builtins/2023-07-18-16-13-51.gh-issue-106092.bObgRM.rst
+@@ -0,0 +1,2 @@
++Fix a segmentation fault caused by a use-after-free bug in ``frame_dealloc``
++when the trashcan delays the deallocation of a ``PyFrameObject``.
+--- a/Objects/frameobject.c
b/Objects/frameobject.c
+@@ -851,9 +851,6 @@
+ /* It is the responsibility of the owning generator/coroutine
+ * to have cleared the generator pointer */
+
+-assert(f->f_frame->owner != FRAME_OWNED_BY_GENERATOR ||
+-_PyFrame_GetGenerator(f->f_frame)->gi_frame_state == FRAME_CLEARED);
+-
+ if (_PyObject_GC_IS_TRACKED(f)) {
+ _PyObject_GC_UNTRACK(f);
+ }
+@@ -861,10 +858,14 @@
+ Py_TRASHCAN_BEGIN(f, frame_dealloc);
+ PyCodeObject *co = NULL;
+
++/* GH-106092: If f->f_frame was on the stack and we reached the maximum
++ * nesting depth for deallocations, the trashcan may have delayed this
++ * deallocation until after f->f_frame is freed. Avoid dereferencing
++ * f->f_frame unless we know it still points to valid memory. */
++_PyInterpreterFrame *frame = (_PyInterpreterFrame *)f->_f_frame_data;
++
+ /* Kill all local variables including specials, if we own them */
+-if (f->f_frame->owner == FRAME_OWNED_BY_FRAME_OBJECT) {
+-assert(f->f_frame == (_PyInterpreterFrame *)f->_f_frame_data);
+-_PyInterpreterFrame *frame = (_PyInterpreterFrame *)f->_f_frame_data;
++if (f->f_frame == frame && frame->owner == FRAME_OWNED_BY_FRAME_OBJECT) {
+ /* Don't clear code object until the end */
+ co = frame->f_code;
+ frame->f_code = NULL;
diff -Nru python3.11-3.11.2/debian/patches/series
python3.11-3.11.2/debian/patches/series
--- python3.11-3.11.2/debian/patches/series 2023-03-01 05:58:01.0
-0400
+++ python3.11-3.11.2/debian/patches/series 2024-03-02 16:28:50.0
-0400
@@ -39,3 +39,4 @@
fix-py_compile.diff
ntpath-import.diff
shutdown-deadlock.diff
+frame_dealloc-crash.diff
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Hi Helmut (2024.03.01_14:58:10_+) > For this one (but not gschemas.compiled), I am wondering whether > installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright > might work. That is a file that is going away and therefore, removal of > libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a > triggered argument after libglib2.0-0.postrm having done the damage. One concern I have here: It's possible to configure dpkg to skip installing /usr/share/doc/* with --path-exclude. I don't know what effect that has on such triggers, but I assume they wouldn't be triggered. > While removing the postrm is a policy violation, we also understand its > effects quite well. If we have a choice between having all of unstable > (and later trixie) users crash their user sessions and violate policy, > the pragmatic voice in me wants to say yes. Yeah, agreed on that. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1059529: pybuild-autopkgtest: before-pybuild-autopkgtest target presence breaks autopkgtest
Hi Antonio, Any thoughts on this bug? It seems dh doesn't like our hacks... > I have a package where I used a before-pybuild-autopkgtest in the > debian/rules file, but when I run autopkgtest, it fails with the error > message (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059334): > > dh before-pybuild-autopkgtest --buildsystem=pybuild > dh: error: Unknown sequence before-pybuild-autopkgtest (choose from: binary > binary-arch binary-indep build build-arch build-indep clean install > install-arch install-indep) > make: *** [debian/rules:13: before-pybuild-autopkgtest] Error 25 > pybuild-autopkgtest: error: /tmp/pJ8OcCInAE/run before-pybuild-autopkgtest > returned exit code 2 > > That's clearly wrong! It appears that that "%:" recipe overrides > every other recipe in debian/rules, and is called when "debian/rules > before-pybuild-autopkgtest" is called. I don't know if there's any > way to override this behaviour. > > Best wishes, > >Julian -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1063567: dh-python: documentation is unclear for setting env variables to control python version
Hi Drew (2024.02.09_12:12:39_-0400) > The control I want to apply is run the build only for the default python > (adios2, for instance is built via cmake which only detects the default > python version) Why do you need pybuild at all then? The goal of pybuild is to enable you to build for all supported versions. > It's not clear how to use pybuild's environment variables to do this. > The pybuild man page discusses PYBUILD_DISABLE=python3.9 for excluding > a particular python version. But this is the opposite of want I need. > I want something like Sounds like you want something like: --pyver $(py3versions -d) But again, not sure how useful pybuild is in that situation, you could just call cmake directly... Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1061309: pybuild-plugin-pyproject: Unconditionally tries to use "flit" plugin
Hi Matthias (2024.01.22_09:14:49_-0400) > Installing "flit" breaks builds which do not use it. Oh, yeah. That's a bug in this commit: https://salsa.debian.org/python-team/tools/dh-python/-/commit/34242fba41e114ca1b22723127460d82e150 Thanks! I guess I should see if we're ready to retire the flit plugin entirely. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1064842: piuparts: fails to bind-mount enough of /dev/, runnnig as root in a VM
Package: piuparts Version: 1.3 Severity: normal When running piuparts (as root) in an Incus VM (orchestrated by Debusine), it seems to miss some /dev/* bind-mounts and then everything fails. VM: trixie Base tarball: trixie (without /dev/ nodes) Command line: /usr/sbin/piuparts --distribution=trixie --allow-database --warn-on-leftovers-after-purge --tmpdir=/var/cache/piuparts/tmp --basetgz=/tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar /tmp/debusine-fetch-exec-upload-yw5d6btv/python3-anosql_1.0.1-4_all.deb 0m1.1s DEBUG: Starting command: ['chroot', '/var/cache/piuparts/tmp/tmp_nj7ktk5', 'apt-get', 'update'] 0m1.9s DUMP: Get:1 http://10.233.1.1:3142/debian trixie InRelease [157 kB] /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied /usr/bin/apt-key: 95: cannot create /dev/null: Permission denied E: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed Sub-process apt-key returned an error code (29)Err:1 http://10.233.1.1:3142/debian trixie InRelease Full log attached. Stefano cmd: /usr/sbin/piuparts --distribution=trixie --allow-database --warn-on-leftovers-after-purge --tmpdir=/var/cache/piuparts/tmp --basetgz=/tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar /tmp/debusine-fetch-exec-upload-yw5d6btv/python3-anosql_1.0.1-4_all.deb output (contains stdout and stderr): 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts is wrong. 0m0.0s INFO: -- 0m0.0s INFO: piuparts version 1.3 starting up. 0m0.0s INFO: Command line arguments: /usr/sbin/piuparts --distribution=trixie --allow-database --warn-on-leftovers-after-purge --tmpdir=/var/cache/piuparts/tmp --basetgz=/tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar /tmp/debusine-fetch-exec-upload-yw5d6btv/python3-anosql_1.0.1-4_all.deb 0m0.0s INFO: Running on: Linux debusine-kukzsw 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 0m0.0s DEBUG: Starting command: ['dpkg', '--info', '/tmp/debusine-fetch-exec-upload-yw5d6btv/python3-anosql_1.0.1-4_all.deb'] 0m0.0s DUMP: new Debian package, version 2.0. size 10140 bytes: control archive=1424 bytes. 668 bytes,19 lines control 1139 bytes,13 lines md5sums 263 bytes,12 lines * postinst #!/bin/sh 376 bytes,12 lines * prerm#!/bin/sh Package: python3-anosql Source: anosql Version: 1.0.1-4 Architecture: all Maintainer: Debian Python Team Installed-Size: 45 Depends: python3:any Section: python Priority: optional Homepage: https://github.com/honza/anosql Description: Manage your raw SQL Queries in an elegant manner Inspired by Yesql library by Kris Jenkins, anosql provides an interface to manage your SQL queries against PostgreSQL and SQLite engine. . The interface gives the full flexibility and features of raw SQL to the developer. . Anosql can be seen as an alternative to ORM(s), and can be installed and used at the same time as other ORM libraries. 0m0.0s DEBUG: Command ok: ['dpkg', '--info', '/tmp/debusine-fetch-exec-upload-yw5d6btv/python3-anosql_1.0.1-4_all.deb'] 0m0.0s DEBUG: Created temporary directory /var/cache/piuparts/tmp/tmp_nj7ktk5 0m0.0s DEBUG: Unpacking /tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar into /var/cache/piuparts/tmp/tmp_nj7ktk5 0m0.0s DEBUG: Starting command: ['tar', '-C', '/var/cache/piuparts/tmp/tmp_nj7ktk5', '--auto-compress', '-xf', '/tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar'] 0m1.1s DUMP: tar: Ignoring unknown extended header keyword 'hdrcharset' 0m1.1s DEBUG: Command ok: ['tar', '-C', '/var/cache/piuparts/tmp/tmp_nj7ktk5', '--auto-compress', '-xf', '/tmp/debusine-fetch-exec-upload-yw5d6btv/base_tar/system.tar'] 0m1.1s DEBUG: Starting command: ['mount', '-t', 'proc', 'proc', '/var/cache/piuparts/tmp/tmp_nj7ktk5/proc'] 0m1.1s DEBUG: Command ok: ['mount', '-t', 'proc', 'proc', '/var/cache/piuparts/tmp/tmp_nj7ktk5/proc'] 0m1.1s DEBUG: Starting command: ['mount', '-t', 'devpts', '-o', 'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', '/var/cache/piuparts/tmp/tmp_nj7ktk5/dev/pts'] 0m1.1s DEBUG: Command ok: ['mount', '-t', 'devpts', '-o', 'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', '/var/cache/piuparts/tmp/tmp_nj7ktk5/dev/pts'] 0m1.1s DEBUG: Starting command: ['mount', '-t', 'tmpfs', '-o', 'size=65536k', 'tmpfs', '/var/cache/piuparts/tmp/tmp_nj7ktk5/dev/shm'] 0m1.1s DEBUG: Command ok: ['mount', '-t', 'tmpfs', '-o',
Bug#1064213: incus-agent: Incus Agent never starts due to ConditionPathExists
Package: incus-agent Version: 0.5.1-3 Severity: serious ... Feb 18 14:31:55 debian systemd[1]: incus-agent.service - Incus - agent was skipped because of an unmet condition check (ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.incus). ... Feb 18 14:31:55 debian systemd[1]: Starting systemd-udevd.service - Rule-based Manager for Device Events and Files... Feb 18 14:31:55 debian systemd[1]: Started systemd-udevd.service - Rule-based Manager for Device Events and Files. ... Because the systemd unit declares DefaultDependencies=no, it attempts to start incus-agent before systemd-udevd has started, and so the path doesn't exist yet. I can't see any obvious way to delay the condition check, I think it's best to just remove it, and allow the unit to quietly fail. Stefano
Bug#1063253: python3 illegal opcode in Raspi 3B+
Hi Marco (2024.02.05_21:18:04_+) > Running python3 gives an "illegal opcode" error. Core dump is attached. │ > 0x510d48sturq0, [x2, #-252] Maybe alignment? My understanding is that STUR is not supposed to require aligned access, though. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1062660: bookworm-pu: package pypy3/7.3.11+dfsg-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: py...@packages.debian.org
Control: affects -1 + src:pypy3
[ Reason ]
A user ran into a JIT bug in pypy3 in bookworm that has been resolved
upstream. It's a simple bug and trivial to backport the fix for.
[ Impact ]
More users may run into this particular JIT bug.
[ Tests ]
The bug comes with a regression test, that passes.
[ Risks ]
The change is very simple. The patch applied cleanly and that code
hasn't been modified upstream, since this patch.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
An assert that crashes the interpreter is replaced by an exception that
will drop back out of the JIT.
diff -Nru pypy3-7.3.11+dfsg/debian/changelog pypy3-7.3.11+dfsg/debian/changelog
--- pypy3-7.3.11+dfsg/debian/changelog 2023-02-06 10:12:43.0 -0400
+++ pypy3-7.3.11+dfsg/debian/changelog 2024-02-01 20:41:13.0 -0400
@@ -1,3 +1,10 @@
+pypy3 (7.3.11+dfsg-2+deb12u1) bookworm; urgency=medium
+
+ * Avoid an rpython assertion error in the JIT if integer ranges don't
+overlap in a loop. (Closes: #1062460)
+
+ -- Stefano Rivera Thu, 01 Feb 2024 20:41:13 -0400
+
pypy3 (7.3.11+dfsg-2) unstable; urgency=medium
* Mark pypy3 as being EXTERNALLY-MANAGED.
diff -Nru pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch
pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch
--- pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch 1969-12-31
20:00:00.0 -0400
+++ pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch 2024-02-01
20:41:13.0 -0400
@@ -0,0 +1,100 @@
+From: Carl Friedrich Bolz-Tereick
+Date: Fri, 3 Mar 2023 14:15:42 +0100
+Subject: Upstream: #3892: fix wrong assert in intutils,
+ it should be an InvalidLoop instead
+
+I introduced the assert in 5909f5e0a75c. before that, inconsistent intersects
+would just do nothing, which I am not sure is a better solution than raising
+InvalidLoop
+
+Bug-Debian: https://bugs.debian.org/1062460
+Origin: upstream,
https://github.com/pypy/pypy/commit/ba8a3c45b9afe068c06780b4c34709c852ae20ea
+---
+ rpython/jit/metainterp/optimizeopt/intutils.py | 8 +-
+ .../metainterp/optimizeopt/test/test_intbound.py | 5 ++--
+ rpython/jit/metainterp/test/test_ajit.py | 33 ++
+ 3 files changed, 42 insertions(+), 4 deletions(-)
+
+diff --git a/rpython/jit/metainterp/optimizeopt/intutils.py
b/rpython/jit/metainterp/optimizeopt/intutils.py
+index 381d0a2..e9ba7f7 100644
+--- a/rpython/jit/metainterp/optimizeopt/intutils.py
b/rpython/jit/metainterp/optimizeopt/intutils.py
+@@ -129,7 +129,13 @@ class IntBound(AbstractInfo):
+ return 0 <= self.lower
+
+ def intersect(self, other):
+-assert not self.known_gt(other) and not self.known_lt(other)
++from rpython.jit.metainterp.optimize import InvalidLoop
++if self.known_gt(other) or self.known_lt(other):
++# they don't overlap, which makes the loop invalid
++# this never happens in regular linear traces, but it can happen
in
++# combination with unrolling/loop peeling
++raise InvalidLoop("two integer ranges don't overlap")
++
+ r = False
+ if self.make_ge_const(other.lower):
+ r = True
+diff --git a/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
b/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
+index d4a0db4..ea9b74c 100644
+--- a/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
b/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
+@@ -225,13 +225,12 @@ def test_intersect():
+ assert not b.contains(n)
+
+ def test_intersect_bug():
++from rpython.jit.metainterp.optimize import InvalidLoop
+ b1 = bound(17, 17)
+ b2 = bound(1, 1)
+-with pytest.raises(AssertionError):
++with pytest.raises(InvalidLoop):
+ b1.intersect(b2)
+
+-
+-
+ def test_add_bound():
+ for _, _, b1 in some_bounds():
+ for _, _, b2 in some_bounds():
+diff --git a/rpython/jit/metainterp/test/test_ajit.py
b/rpython/jit/metainterp/test/test_ajit.py
+index 29a8bf8..68e7d60 100644
+--- a/rpython/jit/metainterp/test/test_ajit.py
b/rpython/jit/metainterp/test/test_ajit.py
+@@ -3256,6 +3256,39 @@ class BasicTests:
+ res = self.interp_operations(f, [127 - 256 * 29])
+ assert res == 127
+
++def
test_bug_inline_short_preamble_can_be_inconsistent_in_optimizeopt(self):
++myjitdriver = JitDriver(greens = [], reds = "auto")
++class Str(object):
++_immutable_fields_ = ['s']
++def __init__(self, s):
++self.s = s
++
++empty = Str("")
++space =
Bug#1061388: sbuild doesn't support autotpkgest-virt-incus: Error: mkdir /sbuild-nonexistent: permission denied
Package: sbuild Version: 0.85.4 Severity: normal I have been successfully using sbuild with lxd (installed from snap) for a couple of years now, via the autopkgtest build backend. Migrating to incus broke sbuild, resulting in: D: Running command: incus exec autopkgtest-lxd-ltsezo -- strace -f -A -o /tmp/strace.log env LC_ALL=C.UTF-8 LANG=en_US.UTF-8 HOME=/sbuild-nonexistent DEB_BUILD_OPTIONS=parallel=16 SHELL=/bin/sh sh -c cd / && exec "$@" exec perl -e ... Error: mkdir /sbuild-nonexistent: permission denied D: Error run_chroot_session(): Error locking chroot session: skipping beautifulsoup4Keeping session: /tmp/autopkgtest.f2BSkb D: Setting Session=undef D: Error run_chroot(): Error locking chroot session: skipping beautifulsoup4E: Error locking chroot session: skipping beautifulsoup4 D: Setting Pkg Status=failed D: Setting Pkg Fail Stage=lock-session This seems to be because "incus exec" is trying to write ~/.config/incus, but HOME has been set to /sbuild-nonexistent outside it. https://github.com/lxc/incus/blob/e5690705e842d3961d8a1d18c0ec002c25345af8/cmd/incus/main_aliases.go#L162-L175 I think Sbuild could not set HOME as part of the environment when calling the autopkgtest backend. It is explicitly set via the env command in the arguments to the backend, so it souldn't be set outside it too. There are also other ways this could be hacked around... Locally, I'll set INCUS_CONF, to override the HOME. Stefano -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 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 sbuild depends on: ii adduser 3.137 ii libsbuild-perl 0.85.4 ii perl5.38.2-3 Versions of packages sbuild recommends: ii autopkgtest 5.32 ii debootstrap 1.0.134 ii schroot 1.6.13-3+b3 ii uidmap 1:4.13+dfsg1-3+b1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.47.0-2+b1 ii kmod 31-1 ii wget 1.21.4-1+b1 -- no debconf information
Bug#1058172: unattended-upgrades: diff for NMU version 2.9.1+nmu4
Control: tags 1058172 + patch
Control: tags 1058172 + pending
Dear maintainer,
I've prepared an NMU for unattended-upgrades (versioned as 2.9.1+nmu4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
Stefano
diff -Nru unattended-upgrades-2.9.1+nmu3/debian/changelog unattended-upgrades-2.9.1+nmu4/debian/changelog
--- unattended-upgrades-2.9.1+nmu3/debian/changelog 2022-12-31 16:59:00.0 -0400
+++ unattended-upgrades-2.9.1+nmu4/debian/changelog 2024-01-22 16:11:59.0 -0400
@@ -1,3 +1,11 @@
+unattended-upgrades (2.9.1+nmu4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't run pyflakes, it dropped support for type comments.
+(Closes: #1058172)
+
+ -- Stefano Rivera Mon, 22 Jan 2024 16:11:59 -0400
+
unattended-upgrades (2.9.1+nmu3) unstable; urgency=medium
* test: don't confuse -dbg and -unsigned with current running kernel
diff -Nru unattended-upgrades-2.9.1+nmu3/test/test_pyflakes.py unattended-upgrades-2.9.1+nmu4/test/test_pyflakes.py
--- unattended-upgrades-2.9.1+nmu3/test/test_pyflakes.py 2022-12-31 16:59:00.0 -0400
+++ unattended-upgrades-2.9.1+nmu4/test/test_pyflakes.py 2024-01-22 16:11:59.0 -0400
@@ -7,6 +7,8 @@
""" ensure that the tree is pyflakes clean """
def test_pyflakes_clean(self):
+# https://github.com/PyCQA/pyflakes/issues/683
+self.skipTest("not clean, pyflakes no longer supports type comments")
top_src_dir = os.path.join(os.path.dirname(__file__), "..")
targets = [
top_src_dir,
Bug#1058089: multiprocess: FTBFS: KeyError: '/psm_00befb89'
Hi 1058089 (2024.01.21_17:19:38_-0400) > This package ships a separate version of the source for each python 3.X > version. So, this requires a new upstream release, git snapshot, or > a patch with the 3.12 tree. Oh, no, it does have the py3.12 dir. Never mind. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1058089: multiprocess: FTBFS: KeyError: '/psm_00befb89'
This package ships a separate version of the source for each python 3.X version. So, this requires a new upstream release, git snapshot, or a patch with the 3.12 tree. https://github.com/uqfoundation/multiprocess/commits/master/py3.12 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1061224: python-launchpadlib: Add systemd user unit to clean up cache files
Hi Steve (2024.01.20_22:55:24_+) > Now that systemd units are a thing, we can reasonably provide support by > default in the packaging to expire out the contents of these per-user cache > directories. It would be great if launchpadlib managed its own cache. But this looks like a reasonable pragmatic thing to do in the meantime. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1056483: python-memory-profiler's autopkg tests fail with Python 3.12
Note: This package is no longer maintained upstream: https://github.com/pythonprofilers/memory_profiler/issues/383 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1052849: [Help] Re: python-pkginfo: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi Andreas (2024.01.11_17:48:43_+) > I've fixed the two other bugs in python-pkginfo and upgraded to latest > upstream. Unfortunately I have no clue about this issue. The test is expecting the module to be installed in the test environment. Either we could try harder to emulate that, or skip the tests. I committed a patch to run the test inside tox, which will install it in a virtualenv before running the test. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1060030: xsar: Please drop python-setuptools-scm-git-archive from b-deps
Source: xsar Severity: normal Control: block 1060027 with -1 Forwarded: https://github.com/umr-lops/xsar/issues/191 Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7 has everything, so I would like to get it out of Debian. Upstream doesn't have a patch yet. But you should just be able to patch it out of setup.py and remove it from build-deps. Stefano
Bug#1060029: satpy: Please drop python-setuptools-scm-git-archive from b-deps
Source: satpy Severity: normal Control: block 1060027 with -1 Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7 has everything, so I would like to get it out of Debian. It doesn't look like it's being used any more, so you can just drop it from debian/control. Stefano
Bug#1060028: python-cheroot: Please drop python-setuptools-scm-git-archive from b-deps
Source: python-cheroot Severity: normal Tags: upstream, patch Control: block 1060027 with -1 Upstream setuptools-scm-git-archive is obsolete -- setuptools-scm >= 7 has everything, so I would like to get it out of Debian. Upstream has applied a patch in https://github.com/cherrypy/cheroot/pull/628 Stefano
Bug#1060027: RM: setuptools-scm-git-archive -- ROM; obsoleted by setuptools-scm 7
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: setuptools-scm-git-arch...@packages.debian.org, jpu...@debian.org Control: affects -1 + src:setuptools-scm-git-archive setuptools-scm-git-archive is broken by setuptools-scm 8. It was obsoleted by setuptools-scm 7, so there is no reason to keep it in the archive. Stefano
Bug#1059881: autopkgtest: Automatically parsing the summary file in error conditions
Package: autopkgtest Version: 5.31.2 Severity: wishlist Tags: upstream While implementing support for autopkgtest in Debusine [0], we initially started with very simplistic parsing of the summary file [1]: [0]: https://freexian-team.pages.debian.net/debusine/ [1]: https://salsa.debian.org/freexian-team/debusine/-/blob/d4781041c80dcd78e1cc6dfead6e5e349b11fb1c/debusine/tasks/autopkgtest.py#L195-236 In error conditions, it turns out to be more complex, the summary file doesn't just contain test names and status results, but can also contain somewhat arbitrary error messages. We added support for them by looking for lines beginning with "[a-z ]+: " [2] [2]: https://salsa.debian.org/freexian-team/debusine/-/merge_requests/410 It would be great if you could provide a specification for this file format, so tools like Debusine can have some confidence that they're parsing it correctly. We'd obviously also appreciate any input you have on our approaches here. Thank you, Stefano
Bug#1059444: LXD: cython3 autopkgtest hangs forever due to stall in copyup
Package: autopkgtest Version: 5.31.1 Severity: normal This reproduces reliably, but I haven't got to the bottom of it. It looks like a stalled pipeline somewhere. Run autopkgtest on the current cython in unstable (3.0.6-2) with lxd, and it'll hang forever. Eventually failing: pep526_variable_annotations.cpp: In function ‘PyObject* __pyx_pw_27pep526_variable_annotations_11test_tuple(PyObject*, PyObject* const*, Py_ssize_t, PyObject*)’: pep526_variable_annotations.cpp:13880:33: note: ‘result’ declared here 13880 | __pyx_ctuple_int__and_float result; | ^~ autopkgtest [13:03:43]: test testsuite: ---] Error: Failed to retrieve PID of executing child process autopkgtest-virt-lxd [13:03:43]: copyup source failed, status 255 Error: Failed to retrieve PID of executing child process autopkgtest [13:03:44]: ERROR: testbed failure: sent `auxverb_debug_fail', got `copy-failed', expected `ok...' autopkgtest-virt-lxd is sitting in sys.stdin.readline.strip() waiting for instructions. autopkgtest is waiting for lxc to finish. Stefano -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 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 autopkgtest depends on: ii apt-utils 2.7.6 ii libdpkg-perl1.22.2 ii mawk1.3.4.20231126-1 ii procps 2:4.0.4-2 ii python3 3.11.6-1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.32.2-1 Versions of packages autopkgtest suggests: pn docker.io ii fakemachine 0.0.7-2 pn lxc pn lxd ii ovmf 2023.05-2 pn ovmf-ia32 pn podman ii python3-distro-info 1.7 pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils 1:8.1.2+ds-1 ii schroot 1.6.13-3+b3 ii util-linux 2.39.3-2 ii vmdb20.28-1 ii zerofree 1.1.1-1 -- no debconf information
Bug#1057360: python-pyscss: PCRE support missing due to incomplete migration
Hi Boyuan (2023.12.03_23:15:02_+) > The packaged python-pyscss/1.4.0-3 claimed to migrate from PCRE to PCRE2. > However, > the project has not supported PCRE2 yet [1]. The current migration [2] > effectively > disabled the PCRE support as shown in build logs. > > As a result, we should not claim to have migrated from old PCRE to PCRE2, and > we > should enable PCRE2 support in the future once upstream has made the switch. It's not clear to me what the next steps you're asking for entail. Can you provide patches? Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5
Hi David (2023.11.03_18:59:13_+0200) > Short version: > Would you consider modifying this bullseye-pu for > distro-info-data/0.51+deb11u5 into a bullseye-pu for a > distro-info-data/0.59~deb11u1 instead? That may make more sense in the future. But in the past, it wasn't really an option, and consistency is useful. We have had some format changes in the last few years that have made new versions not as backportable as one would have hoped. And data changes that broke test suites in other packages. Both of these were addressed in the most recent round of updates. So, the data should be fully backportable right now (provided sufficient Breaks). > I recently independently discovered Debian bug #711238[2] with > devscripts and I would would like to see it fixed in unstable and > my desired fix of adding to it a Build-Depends on > ``` > distro-info-data (>= 0.58~) > ``` I don't really see the point in bumping Build-Depends like that. You aren't requiring any format change or anything like that, just a version that has the *current* stable (or development, not sure of the specifics of that bug) versions. We ensure that distro-info-data is kept up to date in all supported releases. Probably devscripts should become a little more tolerant about outdated data? Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1055381: neomutt: segfault on new message arrival (suspected)
Package: neomutt
Version: 20220429+dfsg1-4.1
Severity: normal
Tags: upstream
I get the same backtrace as
https://github.com/neomutt/neomutt/issues/3520
This regularly hits me when replying to messages in a List maildir, that
has my replies arriving in it while I'm navigating.
Stefano
-- Package-specific info:
NeoMutt 20220429
Copyright (C) 1996-2022 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 6.1.0-9-amd64 (x86_64)
ncurses: ncurses 6.4.20221231 (compiled with 6.3.20220423)
libidn: 1.41 (compiled with 1.41)
GPGME: 1.18.0
GnuTLS: 3.7.8
libnotmuch: 5.6.0
storage: tokyocabinet
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
{--libdir=${prefix}/lib/x86_64-linux-gnu} --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man
--libexecdir=/usr/libexec --with-mailpath=/var/mail --gpgme --lua --notmuch
--with-ui --gsasl --gnutls --gss --idn --mixmaster --tokyocabinet --sqlite
--autocrypt --pkgconf
Compilation CFLAGS: -g -O2
-ffile-prefix-map=/build/neomutt-n0Dmud/neomutt-20220429+dfsg1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include/lua5.4
-I/usr/include -DNCURSES_WIDECHAR -I/usr/include/p11-kit-1 -isystem
/usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+autocrypt +fcntl -flock -fmemopen +futimens +getaddrinfo +gnutls +gpgme
+gsasl +gss +hcache -homespool +idn +inotify -locales_hack +lua +mixmaster
+nls +notmuch -openssl +pgp +regex -sasl +smime +sqlite +sun_attachment
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.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 neomutt depends on:
ii libc6 2.36-9+deb12u3
ii libgnutls30 3.7.9-2
ii libgpg-error0 1.46-1
ii libgpgme111.18.0-3+b1
ii libgsasl182.2.0-1
ii libgssapi-krb5-2 1.20.1-2+deb12u1
ii libidn12 1.41-1
ii liblua5.4-0 5.4.4-3
ii libncursesw6 6.4-4
ii libnotmuch5 0.37-1+b1
ii libsqlite3-0 3.40.1-2
ii libtinfo6 6.4-4
ii libtokyocabinet9 1.4.48-15
ii sensible-utils0.0.17+nmu1
Versions of packages neomutt recommends:
ii locales 2.36-9+deb12u3
ii mailcap 3.70+nmu1
Versions of packages neomutt suggests:
pn aspell | ispell
ii ca-certificates 20230311
ii gnupg 2.2.40-1.1
pn mixmaster
ii openssl 3.0.11-1~deb12u2
ii postfix [mail-transport-agent] 3.7.6-0+deb12u2
pn urlview
Versions of packages neomutt is related to:
ii neomutt 20220429+dfsg1-4.1
-- no debconf information
Bug#1055321: pipx: shell completions are not installed
Hi Ilya (2023.11.04_16:20:53_+) > > I had a look at this and decided that fixing #944469 is probably the > > better way to go. > > That makes sense, thanks for looking into it! > > My only reservation is that the bug you referenced seems to be focused > on bash only, whereas I tend to use `fish`. Yeah, fish doesn't seem to have any global completion mechanism. https://github.com/fish-shell/fish-shell/issues/1217 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1055337: python-cffi fails autopkg tests with Python 3.12
Hi Matthias (2023.11.04_14:19:12_+)
> WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None,
> status=None)) after connection broken by 'ProxyError('Cannot connect to
> proxy.', NewConnectionError(' object at 0x7f344bf33f80>: Failed to establish a new connection: [Errno 111]
> Connection refused'))': /simple/setuptools/
That just looks like no Internet access during the tests. Broken proxy
on the host?
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#944469: Using bash-completion with python-argcomplete
Hi Marc (2022.09.21_06:10:13_+0200) I just had a look at this (following breadcrumbs from #1055321), and staged a new upstream version in git, as well as a change to fix this bug. I don't think bash_completion provides any mechanism to install a global plugin like this, except for /etc/bash_completion.d See: https://github.com/scop/bash-completion/issues/1055 for a related discussion. So, /etc/bash_completion.d is the logical installation place. I updated the package to put a thin loading shim into /etc/bash_completion.d. That should be safe to have as a conffile. I first went down the road of a symlink, but I think that could be problematic if a package is left in the conffiles state. Haven't uploaded it yet. Have a look, I'll probably upload next week. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1055321: pipx: shell completions are not installed
Hi Ilya (2023.11.04_08:12:30_+0200) I had a look at this and decided that fixing #944469 is probably the better way to go. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5, distro-info/1.0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: distro-info-d...@packages.debian.org Control: affects -1 + src:distro-info-data Bullseye version of #1055009. [ Reason ] This is a regular distro-info-data update, adding Ubuntu 24.04 LTS. It includes some corrections to historical data, one of which affects the distro-info test-suite. So, included is a coupled update of distro-info to expect the new values in its test-suite. In unstable, I updated Build-Depends and Depends on distro-info-data to help autopkgtests. For stable I just updated the Build-Depends. In addition to the changes backported in bullseye is a set of patches to ensure distro-info's Python packaging metadata version PEP-440 compliant. [ Impact ] Stable systems would be unaware of the new Ubuntu LTS. [ Tests ] distro-info-data is just CSV data, with some automated tests to verify the structure and sanity-check the values. distro-info has a more complex test suite that covers real-world tests with old stable releases. This needed to be updated for the data changes. Build tests and autopkgtests pass in both packages. Manually verified that the Python package has valid PEP-440 metadata. [ Risks ] Trivial, low risk. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] distro-info-data (0.51+deb11u5) bullseye; urgency=medium * Update data to 0.59: - Add Ubuntu 24.04 LTS Noble Numbat (LP: #2041662). - Correct Ubuntu 6.10 EOL date to 2008-04-25 - Correct Ubuntu 16.04 ESM begin to 2021-04-30 - Move Ubuntu 12.04 ESM end date back to Friday, 2019-04-26 - Correct Debian 3.1 EOL date to 2008-03-31 - Correct Debian 7 EOL date to 2016-04-25 - Move Debian 9 EOL to the 9.13 release date 2020-07-18 - Move Debian 10 EOL to the 10.13 release date 2022-09-10 distro-info (1.0+deb11u1) bullseye; urgency=medium * python: - Assert that Python version is PEP440 compliant - Handle more Debian versions correctly in make_pep440_compliant * Update tests for distro-info-data 0.51+deb11u5, which adjusted Debian 7's EoL (Closes: #1054946) diff --git a/debian.csv b/debian.csv index 8272895..2646246 100644 --- a/debian.csv +++ b/debian.csv @@ -6,14 +6,14 @@ version,codename,series,created,release,eol,eol-lts,eol-elts 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30 2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30 -3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-30 +3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 5.0,Lenny,lenny,2007-04-08,2009-02-14,2012-02-06 6.0,Squeeze,squeeze,2009-02-14,2011-02-06,2014-05-31,2016-02-29 -7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-26,2018-05-31,2020-06-30 +7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-25,2018-05-31,2020-06-30 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30 -9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-06,2022-06-30,2027-06-30 -10,Buster,buster,2017-06-17,2019-07-06,2022-08-14,2024-06-30,2029-06-30 +9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30 +10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30 11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14 12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10 13,Trixie,trixie,2023-06-10 diff --git a/debian/changelog b/debian/changelog index ea4f4da..aee8df2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,17 @@ +distro-info-data (0.51+deb11u5) bullseye; urgency=medium + + * Update data to 0.59: +- Add Ubuntu 24.04 LTS Noble Numbat (LP: #2041662). +- Correct Ubuntu 6.10 EOL date to 2008-04-25 +- Correct Ubuntu 16.04 ESM begin to 2021-04-30 +- Move Ubuntu 12.04 ESM end date back to Friday, 2019-04-26 +- Correct Debian 3.1 EOL date to 2008-03-31 +- Correct Debian 7 EOL date to 2016-04-25 +- Move Debian 9 EOL to the 9.13 release date 2020-07-18 +- Move Debian 10 EOL to the 10.13 release date 2022-09-10 + + -- Stefano Rivera Sun, 29 Oct 2023 14:57:15 +0200 + distro-info-data (0.51+deb11u4) bullseye; urgency=medium * Update data to 0.58: diff --git a/ubuntu.csv b/ubuntu.csv index 14ef832..3667f04 100644 --- a/ubuntu.csv +++ b/ubuntu.csv @@ -3,7 +3,7 @@ version,codename,series,created,release,eol,eol-server,eol-esm 5.04,Hoary Hedgehog,hoary,2004-10-20,2005-04-08,2006-10-31 5.10,Breezy Badger,breezy,2005-04-08,2005-10-12,2007-04-13 6.06 LTS,Dapper Drake,dapper,2005-10-12,2006-06-01,2009-07-14,2011-06-01 -6.10,Edgy Eft,edgy,2006-06-01,2006-10-26,2008-04-26 +6.10,Edgy Eft,edgy,2006-06-01,2006-10-26,2008-04-25 7.04,Feisty Fawn,feisty,2006-10-26,2007-04-19,2008-10-19 7.10,Gutsy Gibbon,gutsy,2007-04-19,2007-10
Bug#1055009: bookworm-pu: package distro-info-data/0.58+deb12u1, distro-info/1.5+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: distro-info-d...@packages.debian.org Control: affects -1 + src:distro-info-data [ Reason ] This is a regular distro-info-data update, adding Ubuntu 24.04 LTS. It includes some corrections to historical data, one of which affects the distro-info test-suite. So, included is a coupled update of distro-info to expect the new values in its test-suite. In unstable, I updated Build-Depends and Depends on distro-info-data to help autopkgtests. For stable I just updated the Build-Depends. [ Impact ] Stable systems would be unaware of the new Ubuntu LTS. [ Tests ] distro-info-data is just CSV data, with some automated tests to verify the structure and sanity-check the values. distro-info has a more complex test suite that covers real-world tests with old stable releases. This needed to be updated for the data changes. Build tests and autopkgtests pass in both packages. [ Risks ] Trivial, low risk. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] distro-info-data (0.58+deb12u1) bookworm; urgency=medium * Update data to 0.59: - Add Ubuntu 24.04 LTS Noble Numbat (LP: #2041662). - Correct Ubuntu 6.10 EOL date to 2008-04-25 - Correct Ubuntu 16.04 ESM begin to 2021-04-30 - Move Ubuntu 12.04 ESM end date back to Friday, 2019-04-26 - Correct Debian 3.1 EOL date to 2008-03-31 - Correct Debian 7 EOL date to 2016-04-25 - Move Debian 9 EOL to the 9.13 release date 2020-07-18 - Move Debian 10 EOL to the 10.13 release date 2022-09-10 distro-info (1.5+deb12u1) bookworm; urgency=medium * Update tests for distro-info-data 0.58+deb12u1, which adjusted Debian 7's EoL (Closes: #1054946) diff --git a/debian.csv b/debian.csv index 8272895..2646246 100644 --- a/debian.csv +++ b/debian.csv @@ -6,14 +6,14 @@ version,codename,series,created,release,eol,eol-lts,eol-elts 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30 2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30 -3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-30 +3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 5.0,Lenny,lenny,2007-04-08,2009-02-14,2012-02-06 6.0,Squeeze,squeeze,2009-02-14,2011-02-06,2014-05-31,2016-02-29 -7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-26,2018-05-31,2020-06-30 +7,Wheezy,wheezy,2011-02-06,2013-05-04,2016-04-25,2018-05-31,2020-06-30 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30 -9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-06,2022-06-30,2027-06-30 -10,Buster,buster,2017-06-17,2019-07-06,2022-08-14,2024-06-30,2029-06-30 +9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30 +10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30 11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14 12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10 13,Trixie,trixie,2023-06-10 diff --git a/debian/changelog b/debian/changelog index 7550d74..c01e3fc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,17 @@ +distro-info-data (0.58+deb12u1) bookworm; urgency=medium + + * Update data to 0.59: +- Add Ubuntu 24.04 LTS Noble Numbat (LP: #2041662). +- Correct Ubuntu 6.10 EOL date to 2008-04-25 +- Correct Ubuntu 16.04 ESM begin to 2021-04-30 +- Move Ubuntu 12.04 ESM end date back to Friday, 2019-04-26 +- Correct Debian 3.1 EOL date to 2008-03-31 +- Correct Debian 7 EOL date to 2016-04-25 +- Move Debian 9 EOL to the 9.13 release date 2020-07-18 +- Move Debian 10 EOL to the 10.13 release date 2022-09-10 + + -- Stefano Rivera Sun, 29 Oct 2023 12:12:45 +0200 + distro-info-data (0.58) unstable; urgency=medium * Add Ubuntu 23.10 Mantic Minotaur (LP: #2018028) diff --git a/ubuntu.csv b/ubuntu.csv index 14ef832..3667f04 100644 --- a/ubuntu.csv +++ b/ubuntu.csv @@ -3,7 +3,7 @@ version,codename,series,created,release,eol,eol-server,eol-esm 5.04,Hoary Hedgehog,hoary,2004-10-20,2005-04-08,2006-10-31 5.10,Breezy Badger,breezy,2005-04-08,2005-10-12,2007-04-13 6.06 LTS,Dapper Drake,dapper,2005-10-12,2006-06-01,2009-07-14,2011-06-01 -6.10,Edgy Eft,edgy,2006-06-01,2006-10-26,2008-04-26 +6.10,Edgy Eft,edgy,2006-06-01,2006-10-26,2008-04-25 7.04,Feisty Fawn,feisty,2006-10-26,2007-04-19,2008-10-19 7.10,Gutsy Gibbon,gutsy,2007-04-19,2007-10-18,2009-04-18 8.04 LTS,Hardy Heron,hardy,2007-10-18,2008-04-24,2011-05-12,2013-05-09 @@ -14,7 +14,7 @@ version,codename,series,created,release,eol,eol-server,eol-esm 10.10,Maverick Meerkat,maverick,2010-04-29,2010-10-10,2012-04-10 11.04,Natty Narwhal,natty,2010-10-10,2011-04-28,2012-10-28 11.10,Oneiric Ocelot,oneiric,2011-04-28,2011-10-13,2013-05-09 -12.04 LTS
Bug#1054591: python3-pyflow: ${VERSION} not expanded in package metadata, causing PEP-440 validation failures
Package: python3-pyflow
Version: 1.1.20-4
Severity: serious
Filing this as serious severity, because it has the risk of breaking
unrelated software.
The background here is that setuptools since 66 has required PEP-440
valid versions for all packages installed on a system. Pip makes a noise
about this since 23.3 in preparation for completely rejecting them in
pip 24.
https://github.com/pypa/setuptools/issues/3772#issuecomment-1384342813
https://github.com/pypa/pip/issues/12063
It looks like ${VERSION} is never expanded in setup.py. I suspect this
is because you are grabbing source from GitHub, and not using tarballs
from "scratch/make_release_tarball.bash"
Please provide a valid version in the package metadata.
$ python3 -c 'import pkg_resources; pkg_resources.require("pyFlow")'
This affects bookworm too, if a virtualenv has --system-site-packages
(less common) and upgraded setuptools (very common).
Stefano
Bug#1054589: unblock: libapache2-mod-python/3.5.0+git20211031.e6458ec-1+b1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libapache2-mod-pyt...@packages.debian.org
Control: affects -1 + src:libapache2-mod-python
Please unblock package libapache2-mod-python
[ Reason ]
* In 03_debian-version.patch, strip the debian part of the version. BinNMUs
were resulting in invalid PEP-440 versions. (Closes: #1054587)
* Patch: Fix segfaults when releasing threads. (Closes: #1019299)
[ Impact ]
The segfault issue seems rather serious.
The PEP-440 issue breaks any attempt to enumerate installed packages on
the system with pkg_resources.
[ Tests ]
Manually tested that mod_python runs and serves content.
[ Risks ]
Segfault patch is trivial and taken from upstream.
Version patch is trivial, and Debian-specific.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock libapache2-mod-python/3.5.0+git20211031.e6458ec-1+b1
diff -Nru libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
--- libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
2022-04-18 06:22:40.0 +0200
+++ libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
2023-10-26 15:07:51.0 +0200
@@ -1,3 +1,12 @@
+libapache2-mod-python (3.5.0+git20211031.e6458ec-1+deb12u1) bookworm;
urgency=medium
+
+ * Team upload.
+ * In 03_debian-version.patch, strip the debian part of the version. BinNMUs
+were resulting in invalid PEP-440 versions. (Closes: #1054587)
+ * Patch: Fix segfaults when releasing threads. (Closes: #1019299)
+
+ -- Stefano Rivera Thu, 26 Oct 2023 15:07:51 +0200
+
libapache2-mod-python (3.5.0+git20211031.e6458ec-1) unstable; urgency=medium
* Team upload.
diff -Nru
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
---
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
2022-04-18 06:22:40.0 +0200
+++
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
2023-10-26 15:07:51.0 +0200
@@ -9,7 +9,7 @@
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/dist/version.sh b/dist/version.sh
-index e5d..9ee18ac 100755
+index e5d..f97084a 100755
--- a/dist/version.sh
+++ b/dist/version.sh
@@ -1,21 +1,4 @@
@@ -35,4 +35,4 @@
-
-echo $MAJ.$MIN.$PCH$GIT
+cd $(dirname $0)/..
-+exec dpkg-parsechangelog -S Version
++dpkg-parsechangelog -S Version | cut -d - -f 1
diff -Nru
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
---
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
1970-01-01 02:00:00.0 +0200
+++
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
2023-10-26 15:07:51.0 +0200
@@ -0,0 +1,27 @@
+From: Gregory Trubetskoy
+Date: Fri, 16 Jun 2023 18:29:50 -0400
+Subject: 3.10 and up do not need a PyThreadState_Clear()
+
+Closes #100
+
+Bug-Upstream: https://github.com/grisha/mod_python/issues/100
+Bug-Debian: https://bugs.debian.org/1019299
+Origin: upstream,
https://github.com/grisha/mod_python/commit/7e863bb4652ca4edeb158bf42eb26120e0e54040
+---
+ src/mod_python.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/mod_python.c b/src/mod_python.c
+index 6259c1b..11af968 100644
+--- a/src/mod_python.c
b/src/mod_python.c
+@@ -303,7 +303,9 @@ static void release_interpreter(interpreterdata *idata)
+ {
+ PyThreadState *tstate = PyThreadState_Get();
+ #ifdef WITH_THREAD
++#if PY_MAJOR_VERSION <= 3 && PY_MINOR_VERSION < 10
+ PyThreadState_Clear(tstate);
++#endif
+ if (idata)
+ APR_ARRAY_PUSH(idata->tstates, PyThreadState *) = tstate;
+ else
diff -Nru libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series
--- libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series
2022-04-18 06:22:40.0 +0200
+++ libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series
2023-10-26 15:07:51.0 +0200
@@ -6,3 +6,4 @@
12_py310_collections_import.patch
13_py310_minor_version.patch
14_sphinx_py3.patch
+15_py310_threadstate_clear.patch
Bug#1054587: libapache2-mod-python: PEP-440 incompatible version (breaks pkg_resources & soon pip)
Package: libapache2-mod-python
Version: 3.5.0+git20211031.e6458ec-1
Severity: normal
My git snapshot included this version as the Python version, which makes
pkg_resources unhappy
More recent setuptools (often installed in virtualenvs) breaks with this
version:
$ ve/bin/python3 -c 'import pkg_resources; pkg_resources.require("mod_python")'
:1: DeprecationWarning: pkg_resources is deprecated as an API. See
https://setuptools.pypa.io/en/latest/pkg_resources.html
Traceback (most recent call last):
File "", line 1, in
File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line
968, in require
needed = self.resolve(parse_requirements(requirements))
^^
File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line
829, in resolve
dist = self._resolve_dist(
^^^
File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line
854, in _resolve_dist
if dist is None or (dist not in req and replace_conflicting):
^^^
File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line
3205, in __contains__
return self.specifier.contains(item, prereleases=True)
^^^
File
"/root/ve/lib/python3.11/site-packages/pkg_resources/_vendor/packaging/specifiers.py",
line 905, in contains
item = Version(item)
^
File
"/root/ve/lib/python3.11/site-packages/pkg_resources/_vendor/packaging/version.py",
line 198, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version:
'3.5.0-git20211031.e6458ec-1-b1'
Stefano
Bug#1054581: asdf: Missing dependency on asdf-unit-schemas (breaks pkg_resources)
Package: asdf
Version: 2.14.3-1
Severity: serious
asdf's upstream requirements declare a dependency on asdf-unit-schemas,
but this doesn't exist in Debian, and isn't a dependency.
The relevant upstream change is https://github.com/asdf-format/asdf/pull/1210
It seems this used to be part of asdf-standard, but got moved into its
own module.
I see the relevant schemas still exist in asdf-standard in Debian.
However, missing this dependency this breaks Python pkg_resources, that
attempts to validate Python requirements.
Filing this as serious, because it breaks unrelated software when asdf
is installed.
In bookworm:
$ python3 -c 'import pkg_resources; pkg_resources.require("asdf")'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 956, in
require
needed = self.resolve(parse_requirements(requirements))
^^
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 815, in
resolve
dist = self._resolve_dist(
^^^
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 856, in
_resolve_dist
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'asdf-unit-schemas>=0.1.0' distribution
was not found and is required by asdf
The same thing happens in unstable.
If you are certain that you don't need a (non-optional) Python
dependency, the best thing to do is to patch it out of the requirements
in pyproject.toml.
Stefano
Bug#1051837: dh-python: Cannot exclude deliberately embedded .egg-info from the clean step
Hi Simon (2023.09.13_11:53:34_+0200) I think I've fixed the majority of the fallout from cleaning egg-info in https://salsa.debian.org/python-team/tools/dh-python/-/commit/7970b4d559da66858f0ae7a25e03aef40013c5da This particular case is harder, because we need to have a cleaning blocklist and pass it through to the build module. I'll come back to this one, later. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1027927: bug 1027927 is forwarded to https://github.com/pypa/pipx/issues/835
Version: 1.2.0-1 This should have been fixed in 1.2.0. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1054212: python-urllib3: Drop 02_require-cert-verification.patch (no longer needed)
Source: python-urllib3
Version: 1.26.17-1
Severity: normal
X-Debbugs-Cc: jdstr...@ubuntu.com, secur...@ubuntu.com
Hi,
In the process of packaging a library, I ran into a test failure caused
by urllib3's 02_require-cert-verification.patch
It looks like this patch is no longer required, but given the security
implications, I'm not just going to commit to git, but rather ask for
input.
Several relevant changes were made in urllib3 since the authoring of
this patch:
1. urllib3.contrib.pyopenssl now uses the operating system's default CA
certificates on inject.
https://github.com/urllib3/urllib3/pull/332
2. When ca_certs is given, cert_reqs defaults to 'CERT_REQUIRED'.
https://github.com/urllib3/urllib3/pull/650
With unpatched upstream urllib3 1.26.18 (not even 2.x):
>>> import urllib3
>>> http = urllib3.PoolManager()
>>> http.request("GET", "https://expired.badssl.com/;)
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed: certificate has expired (_ssl.c:1006)
>>> http.request("GET", "https://wrong.host.badssl.com/;)
urllib3.exceptions.MaxRetryError:
HTTPSConnectionPool(host='wrong.host.badssl.com', port=443): Max retries
exceeded with url: / (Caused by SSLError(CertificateError("hostname
'wrong.host.badssl.com' doesn't match either of '*.badssl.com', 'badssl.com'")))
>>> http.request("GET", "https://untrusted-root.badssl.com/;)
urllib3.exceptions.MaxRetryError:
HTTPSConnectionPool(host='untrusted-root.badssl.com', port=443): Max retries
exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate
in certificate chain (_ssl.c:1006)')))
>>> http.request("GET", "https://self-signed.badssl.com/;)
urllib3.exceptions.MaxRetryError:
HTTPSConnectionPool(host='self-signed.badssl.com', port=443): Max retries
exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate
(_ssl.c:1006)')))
>>> http.request("GET", "https://revoked.badssl.com/;)
urllib3.exceptions.MaxRetryError:
HTTPSConnectionPool(host='revoked.badssl.com', port=443): Max retries exceeded
with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired
(_ssl.c:1006)')))
How do you feel about dropping it?
Stefano
Bug#1053106: please create a debian-za list for our Debian local user group in South Africa
Hi Cord (2023.10.12_23:31:25_+0200) > It would be also very much appreciated if several other people > interested in the new list would send a mail to the bug, in order to > record their interest. Til now there is none. o/ I think this would be useful. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium
Hi Sean (2023.10.13_22:59:56_+0200) > === BEGIN > > OPTION A: > > The Technical Committee formally repeals its moratorium recommending > that maintainers of individual packages should not proactively move > files from the root filesystem to corresponding locations under /usr in > the data.tar.* of packages (see #1035831). > > Under Constitution 6.1.5, the Technical Committee now recommends that > maintainers consult with those driving the merged-/usr transition before > moving files from the root filesystem to corresponding locations under > /usr in the data.tar.* of packages. > > The transition driver, which at the time of writing is Helmut Grohne, is > using a phased approach, in which the moratorium is rolled back for only > certain classes of packages, and changes, at a time. In addition, > restructuring uploads should be targeted at experimental, and left for > three days. This is in order that automated testing by dumat can occur. > > We recommend following <https://wiki.debian.org/UsrMerge>, as edited by > the transition driver(s). If there is any doubt as to whether a change > you wish to make is appropriate, please seek explicit approval from the > transition driver(s). > > OPTION N: > > None of the above. > > === END I vote A > N Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Bug#1041692: python3-mesonpy: could the build be verbose by default
Hi Simon (2023.09.15_11:10:20_+0200) > I think this might be more appropriate to be done in pybuild than in > meson-python. meson-python has its upstream behaviour (detailed output > only when requested) similar to Meson, but if I patched the meson-python > source package to make verbose output the default, that would affect > *all* builds done on Debian - not just Debian packages, but also users' > local builds. Of course this could be done in a way that detects a Debian build environment via environment variables, but... not pretty. > dh-python maintainers: would it make sense for pybuild to detect > "[build-system] build-backend = 'mesonpy'" in pyproject.toml, and if found, > make it behave more like what happens in non-Python Meson packages? > (configure with --wrap-mode=nodownload --buildtype=plain etc., > build with --verbose, and so on) That probably makes sense, yes. I expect dh-python to end up with some quirks for driving various build backends. We already set environment variables for flit, for example. Not knowing much about meson, I could use help verifying that we're getting this stuff right: How does this look? https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/48 > Another way to achieve this in packages like python-fabio and pyfai > would be to bypass pyproject and meson-python to run Meson directly, > either manually per-package via "export PYBUILD_SYSTEM=meson", or maybe > automatically in pybuild when build-backend = 'mesonpy' is found (but > perhaps that would be too much magic). Also an option. Means duplicating less of debhelper in dh-python. Yeah, having the pyproject backend do non-pyproject builds would be a bit unexpected, I agree. Not sure I'd want to go there. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1051586: dh-python: build fails with DEB_BUILD_OPTIONS="check parallel=1"
Control: tag -1 + unreproducible moreinfo Sorry, can't reproduce this. Could you provide some logs or something to help understand what the problem is? A bare-bones bug report template that hasn't been filled in isn't very helpful to anyone. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1052854: python-vulndb: FTBFS: FileNotFoundError: [Errno 2] No such file or directory: '/<>/.pybuild/cpython3_3.11/build/vulndb/db'
Hi Gianfranco (2023.09.26_16:55:49_+0200) > hello, I see a TON of FTBFS bugs for python failures > I suspect the reason for them to fail is > * Remove *.egg-info directories in clean step, as part of Debian's wider > effort to improve clean targets. Thanks Stuart Prescott for the patch. I haven't seen that many of these. A few, yes, maybe 3? On balance, it still seems like the right change to have made. There is the risk of silent breakage from missing files, but I haven't heard of any of those, yet. I'm coming around to making cleaning .egg-info configurable. Right now you have to skip pybuild cleaning entirely, which is not complex. But it's more than the one line instruction to skip egg-info cleaning. I think configuration makes sense. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Bug#1053411: sra-sdk: FTBFS with re2 >= 20230601 (which requires abseil)
Source: sra-sdk
Version: 3.0.3+dfsg-6
Severity: normal
Tags: upstream
Control: affects -1 + src:re2
The next RE2 transition is waiting for sra-sdk to support libre2-11
(re2 >= 20230601), available in experimental.
Upstream, RE2 added a dependency on Abseil, changing its API a little.
It looks like only sharq in sra-tools requires re2, and it currently
expects 2021-09-01:
https://github.com/ncbi/sra-tools/blob/6d1e74850ad399f671da13e8aee39bcef926e551/tools/loaders/sharq/CMakeLists.txt#L89
[ 78%] Linking CXX static library ../../../lib/libncbi-ngs-c++.a
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu/ngs/ncbi/ngs-c++ && /usr/bin/cmake -P
CMakeFiles/ncbi
-ngs-c++.dir/cmake_clean_target.cmake
In file included from /<>/test/loaders/sharq/test-regexpr.cpp:30:
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp:
In member functi
on ‘bool CRegExprMatcher::Matches(const std::string_view&)’:
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp:56:40:
error: cannot convert ‘const std::string_view’ {aka ‘const
std::basic_string_view’} to ‘absl::debian3::string_view’
56 | return re2::RE2::PartialMatchN(input, *re, args.empty() ?
nullptr : [0], (int)args.size());
|^
||
|const std::string_view {aka
const std::basic_string_view}
In file included from
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp:13:
/usr/include/re2/re2.h:343:47: note: initializing argument 1 of ‘static bool
re2::RE2::PartialMatchN(absl::debian3::string_view, const re2::RE2&, const Arg*
const*, int)’
343 | static bool PartialMatchN(absl::string_view text, const RE2& re,
| ~~^~~~
Stefano
sra-sdk_3.0.3+dfsg-6_amd64.build.xz
Description: application/xz
Bug#1053408: qt6-webengine: FTBFS with re2 >= 20230601 (which requires abseil)
Source: qt6-webengine Version: 6.4.2-final+dfsg-11 Severity: normal Tags: upstream Affects: src:re2 The next RE2 transition is waiting for qt6-webengine to support libre2-11 (re2 >= 20230601), available in experimental. Upstream, RE2 added a dependency on Abseil, changing its API a little. Chromium has supported this since around 116. (Debian's chromium currently builds with the bundled re2). The relevant commits are by https://chromium-review.googlesource.com/q/owner:jun...@chromium.org and reference bug 1447090 Stefano
Bug#1052986: apt-listchanges: When a source package is renamed, the entire old changelog is re-displayed
Package: apt-listchanges Version: 3.27 Severity: normal As discussed in #1052697. When a source package is renamed (e.g. gcc-* and python3.*), often we carry across the old changelog. apt-listchanges then includes the full history in its list of new changelog entries. In these particular cases, the old history maintains the old source package name and version, so it should be possible to check the database and see that these changelog entries have been displayed. One can argue that it's correct to re-display the full history, but this has the effect of drowning out other changelog entries. When I hit these situation, I just mark-as-read and continue. If there was anything important in other changelogs, I'd miss it. Stefano -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager which=both email_address=root email_format=text confirm=true headers=false reverse=false save_seen=/var/lib/apt/listchanges.db no_network=false -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 apt-listchanges depends on: ii apt2.7.3 ii debconf [debconf-2.0] 1.5.82 ii python33.11.4-5+b1 ii python3-apt2.6.0 ii python3-debconf1.5.82 ii sensible-utils 0.0.20 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser]116.0.5845.140-1 ii firefox [www-browser] 117.0.1-1 ii gnome-terminal [x-terminal-emulator] 3.50.0-1 ii lynx [www-browser]2.9.0dev.12-1 ii mate-terminal [x-terminal-emulator] 1.26.1-1 ii postfix [mail-transport-agent]3.8.2-1 ii python3-gi3.46.0-1 ii w3m [www-browser] 0.5.3+git20230121-2 ii xterm [x-terminal-emulator] 384-1 -- debconf information excluded
Bug#1052697: tech-ctte: proposed change to apt-listchanges algorithm needs expert consideration
Hi Jonathan (2023.09.26_10:11:01_+) > I am hoping that this is an acceptable request to make of the > technical committee Absolutely. In this case, I doubt the committee needs to offer any formal advice. These are my personal views, after only a few minutes of thought. > That bug prompted me to do a deep dive into the algorithm that > apt-listchanges uses to determine which changelog and NEWS entries to > display to the user. After doing that, I don't tihnk the current > algorithm is accurate enough, and I want to revamp it. Thanks for taking on a much bigger job than you probably expected to have signed up for :) > For an example of where these assumptions break down, look at the > dmsetup package: > > - The source package for dmsetup is lvm2. > - The version number for the dmsetup package is lower, but with a > higher epoch than, the version number for the lvm2 package. > - The entries in changelog.Debian.gz use lvm2 version numbers, while > the ones in changelog.Debian.devmapper.gz use dmsetup version > numbers. > > This approach was also limited in that it only looked at > NEWS.Debian[.gz], changelog.Debian[.gz], changlog.Debian.arch[.gz], > and changelog[.gz]. For an example of where this fails, again look at > dmsetup, which has changelog.Debian.devmapper.gz. I wasn't aware of this particular bit of unusual packaging. changelog.Debian.*.gz doesn't look like something that is described in Debian Policy. From what I can see, I presume this is a legacy changelog from when devmapper was imported into lvm2. I wouldn't expect it to ever get new entries. So, continuing to ignore it would probably be reasonable. Is this a pattern that we see in other binary packages, where new entries do appear? > We remove the header line of each entry in the second set of checksums > because sometimes a package version uploaded to stable and a different > version uploaded to unstable use different header lines for the same > changelog entry. I can see the logic for that. You could also argue that when a package is uploaded to multiple releases (with different versions, of course), these are forks. And when jumping from one fork to another it's reasonable to include the repeated changelog content. But yes, in most cases hiding text that a user has already seen is probably correct. Unless they need to take some action that's specific to the version of the package that this text appears in (e.g. introduce versioned Depends in their own packages), which is very rare. Please correct me if I'm wrong in any of my analysis. BTW, this issue does remind me of a bug I think I've seen in apt-listchanges where it isn't ignoring changelog entries copied over from a previous versioned source package (something like gcc-* or python3.*). I can't reproduce it right now to file it, though :( Does that sound familiar? Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1052692: bookworm-pu: package spamprobe/1.4d-16+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: spampr...@packages.debian.org
Control: affects -1 + src:spamprobe
[ Reason ]
Spamprobe is unmaintained upstream and in Debian.
In bookworm it has been crashing a lot when parsing images (#1037422)
The solution is relatively simple, add missing return statements to bool
functions, even though the return is ignored.
[ Impact ]
Spamprobe crashes enough in bookworm to not be useable.
[ Tests ]
Manually tested it on 600 odd spam emails that previously crashed it,
and it didn't crash.
[ Risks ]
Changes are very simple. The return values don't even matter, because
they are ignored.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Add missing return values to bool functions.
diff -Nru spamprobe-1.4d/debian/changelog spamprobe-1.4d/debian/changelog
--- spamprobe-1.4d/debian/changelog 2023-02-20 18:12:05.0 +0530
+++ spamprobe-1.4d/debian/changelog 2023-09-26 12:15:17.0 +0530
@@ -1,3 +1,11 @@
+spamprobe (1.4d-16+deb12u1) bookworm; urgency=medium
+
+ * QA Upload.
+ * Patch: Add missing return statements, fixing crashes parsing JPEG
+attachments. (Closes: #1037422)
+
+ -- Stefano Rivera Tue, 26 Sep 2023 12:15:17 +0530
+
spamprobe (1.4d-16) unstable; urgency=medium
* QA upload.
diff -Nru spamprobe-1.4d/debian/patches/missing-returns.patch
spamprobe-1.4d/debian/patches/missing-returns.patch
--- spamprobe-1.4d/debian/patches/missing-returns.patch 1970-01-01
05:30:00.0 +0530
+++ spamprobe-1.4d/debian/patches/missing-returns.patch 2023-09-26
12:15:17.0 +0530
@@ -0,0 +1,47 @@
+Description: spamprobe crashes when parsing jpeg mime attachment
+Author: Torsten Hilbrich
+
+Bug-Debian: https://bugs.debian.org/1037422
+Bug-Upstream: https://sourceforge.net/p/spamprobe/bugs/39/
+Forwarded: https://sourceforge.net/p/spamprobe/bugs/39/
+
+--- a/src/parser/GifParser.cc
b/src/parser/GifParser.cc
+@@ -91,6 +91,7 @@
+ openImage();
+ digestImage();
+ parseImageRecords();
++return true;
+ } catch (runtime_error ) {
+ return false;
+ }
+--- a/src/parser/JpegParser.cc
b/src/parser/JpegParser.cc
+@@ -61,6 +61,7 @@
+ initializeSource();
+ digestImage();
+ tokenizeImage();
++return true;
+ } catch (runtime_error ) {
+ return false;
+ }
+--- a/src/parser/MbxMailMessageReader.cc
b/src/parser/MbxMailMessageReader.cc
+@@ -86,6 +86,7 @@
+ cerr << "MBX: SKIPPED DELETED MESSAGE" << endl;
+ }
+ }
++ return true;
+ }
+
+ OWNED MailMessage *MbxMailMessageReader::readMessage()
+--- a/src/parser/PngParser.cc
b/src/parser/PngParser.cc
+@@ -73,6 +73,7 @@
+ try {
+ digestImage();
+ initializeImage();
++return true;
+ } catch (runtime_error ) {
+ return false;
+ }
diff -Nru spamprobe-1.4d/debian/patches/series
spamprobe-1.4d/debian/patches/series
--- spamprobe-1.4d/debian/patches/series2023-02-20 18:12:05.0
+0530
+++ spamprobe-1.4d/debian/patches/series2023-09-26 12:15:17.0
+0530
@@ -7,3 +7,4 @@
giflib5.diff
gcc-11.patch
fix-typos.patch
+missing-returns.patch
Bug#1050668: python3: Fails to import/work with SSL module due to ImportError
python3.11 has now fully migrated. I didn't read the bug properly before, but the issue was that you had part of your python3.11 installation from unstable, and part from testing. libpython3.11-minimal was a newer version than your python3.11-minimal I think. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1050668: python3: Fails to import/work with SSL module due to ImportError
Hi Jonathan (2023.08.27_20:35:12_+) Install python3.11 from debian unstable. The module was built with 3.11.5 and won't import with 3.11.4. Dependencies *should* capture that, but I'm guessing we missed listing a symbol in 3.11.5-1 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1049950: dh-python: Pybuild runs tests with tox but fails to clean up
Control: tag -1 -moreinfo Hi Arto (2023.08.26_06:24:29_+0100) > > It has code to do this, can you point to an example of it not happening? > > > > https://salsa.debian.org/python-team/tools/dh-python/-/blob/a5068b6de912dee00415e3ed8af13b75ef29994c/dhpython/build/base.py#L164-172 Aha, I figured out the obvious: The logic that automatically configures which test runner is in use is only run for the test step, not the clean step. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1049950: dh-python: Pybuild runs tests with tox but fails to clean up
Control: tag -1 + moreinfo Hi Arto (2023.08.17_11:33:51_+0200) > Pybuild uses tox to run the upstream test suite of the package, but > fails to clean up the created .tox directory during debian/rules clean. It has code to do this, can you point to an example of it not happening? https://salsa.debian.org/python-team/tools/dh-python/-/blob/a5068b6de912dee00415e3ed8af13b75ef29994c/dhpython/build/base.py#L164-172 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1050163: dh-python is confused about the name for wheels on armel and armhf
Control: forwarded -1 https://github.com/tox-dev/tox/issues/3100 Control: reassign -1 tox Control: found -1 tox/4.9.0-1 Control: close -1 4.9.0-2 Control: affects -1 dh-python This should already be fixed in tox. This should be fixed by tox 4.9.0-2. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1049962: closed by Stefano Rivera (Re: Bug#1049962: python3-pip: Misleading error message on "pip install --user")
Hi Ralf (2023.08.17_17:50:18_+)
> I still think the text and definitely the README.venv could be written in a
> less confusing way. For instance, README.venv starts out saying
Patches welcome :)
It's tricky to try to keep something short enough that people read it,
while still getting critical information across. I did my best, but...
:)
> > It is recommended to let Debian's package managers manage Python packages in
> > /usr/lib/ and /usr/share/.
>
> So for my case ("pip install --user"), obviously this document is not
> relevant, since indeed I do want to let Debian manage the packages in /usr.
> Nothing in that file even mentions ~/.local.
That's a fair point. How's this?
https://salsa.debian.org/cpython-team/python3/-/merge_requests/31
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#1035694: python-bottle: diff for NMU version 0.12.23-1.2
Control: tags 1035694 + patch Control: tags 1035694 + pending Dear maintainer, I've prepared an NMU for python-bottle (versioned as 0.12.23-1.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Stefano diff -Nru python-bottle-0.12.23/debian/changelog python-bottle-0.12.23/debian/changelog --- python-bottle-0.12.23/debian/changelog 2023-02-26 22:59:44.0 +0200 +++ python-bottle-0.12.23/debian/changelog 2023-08-11 17:42:13.0 +0200 @@ -1,3 +1,10 @@ +python-bottle (0.12.23-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Build-Depend on python3-wheel, for tox 4 support. (Closes: #1035694) + + -- Stefano Rivera Fri, 11 Aug 2023 17:42:13 +0200 + python-bottle (0.12.23-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru python-bottle-0.12.23/debian/control python-bottle-0.12.23/debian/control --- python-bottle-0.12.23/debian/control 2023-02-26 22:48:33.0 +0200 +++ python-bottle-0.12.23/debian/control 2023-08-11 17:42:13.0 +0200 @@ -13,6 +13,7 @@ python3-paste, python3-tornado, python3-werkzeug, + python3-wheel, tox Standards-Version: 4.6.1 Homepage: https://bottlepy.org
Bug#1023512: Naming of python binary packages
Hi debian-python (2023.08.11_14:49:00_+) > I don't think the solution here is for your packages to use > distribution-derived names while everyone else's use the policy-defined > names. Can we rather come to a consensus on what we should be using? I should say, of course, that we have a history of groups of packages that diverge from this policy. e.g. the Django app packages, and some sphinx things (I think). Sometimes it makes sense to not name things python3-foo, but rather something more descriptive to the sub-community that the package is a part of. But this example was a run of the mill Python module, as far as I can tell. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1023512: Naming of python binary packages
Bringing bug 1023512 [0] to the Debian Python list: [0] https://bugs.debian.org/1023512 > > According to the Debian Python Policy Section 4.3, binary package > > names should be named after the *import* name of the module, not the > > PyPI distribution name. > Unfortunately, I do not agree at all with this policy. The import name has > no importance, and IMO, we should change that policy so that the package > name matches the egg-name rather than the import name. I wouldn't quite say it has no importance. It describes which part of the filesystem the package owns. I don't know the history of this policy offhand, but I presume it's also because not all Python modules come from PyPI, and we needed a standard way to address them. Also, we sometimes break PyPI distributions up into separate binary packages. They are closer to a source package than a Debian binary package. FIWIW: I am not convinced that Python made the right decision in allowing distribution names to diverge from import names, it tends to just create confusion. But that's neither here nor there. > In many places, that would make our life of package maintainer better. A > good example is all the oslo libraries in OpenStack, that all have a dot in > their egg-name, but an underscore in the import path (so that it works > better under python3). In this specific case, using the dash instead of the > dot would be really stupid and break many things, like automation for > dependencies. Presumably that can be solved with a few automated adjustments, (like the . -> _ transformation you describe). Having a straightforward distribution name -> package name mapping would make automating dependencies simpler, I agree. But we have tooling that handles that already: dh-python and its' pydist data. > In fact, this extend to all of the Debian Python module archive. > > If you want to discuss this further, please open a thread in the list. I don't think the solution here is for your packages to use distribution-derived names while everyone else's use the policy-defined names. Can we rather come to a consensus on what we should be using? My vote would be strongly towards maintaining the status quo of the policy-defined names. I don't see any strong argument for changing this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1043324: pybuild-plugin-pyproject: always copy pytest.ini (if present)
Control: -1 tags + moreinfo Hi Sandro (2023.08.09_06:28:28_+) > Hello, > pybuild-plugin-pyproject already copies the directory `tests` or `test`; > probably it should also copy by default the file `pytest.ini` if present. Looking at this, it already should be. Do we have examples where it isn't? https://salsa.debian.org/python-team/tools/dh-python/-/blob/4ae1f8962c2cbe85a8fbc6e1bbba2268c6384579/dhpython/build/base.py#L51 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1041091: python3-virtualenv: re-execution of virtualenv command removes python-debian's debian directory
Hi Michael (2023.07.16_01:22:37_+0300) Forwarded that patch to https://github.com/pypa/setuptools/pull/4001 And one to apply the same behaviour to other packages building with setuptools. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1042918: reprotest: FTBFS with tox 4
Source: reprotest
Version: 0.7.25
Severity: serious
Justification: ftbfs
I thought we'd managed to avoid this, in #1035645, but we just did the
transition, and I see reprotest is FTBFS:
I: pybuild base:275: cd
/<>/.pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini --sitepackages --installpkg
/<>/.pybuild/cpython3_3.11_reprote
st/reprotest-0.7.25-py3-none-any.whl -e py311
py311: install_deps .pybuild/cpython3_3.11_reprotest/build> python -I -m pip
install coverage
diffoscope pytest
py311: install_package_deps .pybuild/cpython3_3.11_reprotest/build> python -I
-m pip install d
istro rstr
py311: install_package .pybuild/cpython3_3.11_reprotest/build> python -I -m pip
install --forc
e-reinstall --no-deps
/<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-n
one-any.whl
py311: commands[0] .pybuild/cpython3_3.11_reprotest/build>
.tox/py311/bin/python -m coverage r
un --omit '.tox/*' --parallel -m py.test tests/
__path__ attribute not found on 'py' while trying to find 'py.test'
py311: exit 1 (0.09 seconds) /<>> .tox/py311/bin/python -m
coverage run --omit '.
tox/*' --parallel -m py.test tests/ pid=7370
py311: FAIL code 1 (2.31=setup[2.22]+cmd[0.09] seconds)
evaluation failed :( (2.36 seconds)
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd
/<>/.
pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini
--sitepackages --instal
lpkg
/<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-none-any.whl
-e py311
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11
--test-tox returned exit code 13
I'm guessing you want to replace py.test there with pytest.
Stefano
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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#1042917: rdflib-sqlalchemy: FTBFS with tox 4
Source: rdflib-sqlalchemy
Version: 0.5.4-1
Severity: serious
Tags: upstream
Justification: ftbfs
With tox 4, rdflib-sqlalchemy FTBFS with:
dh_auto_test -O--buildsystem=pybuild
E: pybuild pybuild:388: test: plugin distutils failed with: wheel is required
to build wheels for distutils/setuptools packages. Build-Depend on
python3-wheel.
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11
returned exit code 13
I committed the fix for that to git, but the next issue is:
I: pybuild base:275: cd
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build; tox -c
/<>/tox.ini --sitepackages --installpkg
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
-e py311
py311: install_deps .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> python -I
-m pip install mysqlclient psycopg2 'pytest-cov>=2.5.1' 'pytest>=3.4.0'
py311: install_package_deps .pybuild/cpython3_3.11_rdflib_sqlalchemy/build>
python -I -m pip install 'SQLAlchemy<2.0.0,>=1.1.4' 'alembic>=0.8.8'
'rdflib>=4.0' 'six>=1.10.0'
py311: install_package .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> python
-I -m pip install --force-reinstall --no-deps
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
py311: commands[0] .pybuild/cpython3_3.11_rdflib_sqlalchemy/build>
.tox/py311/bin/python setup.py clean --all
running clean
removing '/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build' (and
everything under it)
removing 'build/bdist.linux-x86_64' (and everything under it)
'build/scripts-3.11' does not exist -- can't clean it
removing 'build'
py311: commands[1] .pybuild/cpython3_3.11_rdflib_sqlalchemy/build> pytest
--cov=rdflib_sqlalchemy
py311: failed with pytest is not allowed, use allowlist_externals to allow it
py311: FAIL code 1 (3.06 seconds)
evaluation failed :( (3.12 seconds)
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/build; tox -c
/<>/tox.ini --sitepackages --installpkg
/<>/.pybuild/cpython3_3.11_rdflib_sqlalchemy/rdflib_sqlalchemy-0.5.4-py3-none-any.whl
-e py311
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11
returned exit code 13
The fix here should be as simple as replacing "pytest" with "{envpython} -m
pytest" in tox.ini
Stefano
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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#1041721: nageru: ThemeMenu items all share the same checked state
Package: nageru
Version: 2.2.2-1
Severity: minor
Tags: upstream
Hi Steinar,
You don't have any kind of upstream bug tracker, do you?
In playing around with ThemeMenu, I see the final checked state in the
menu applies to all entries:
function callback()
end
ThemeMenu.set(
{"Checked", callback, Nageru.CHECKED},
{"Unchecked", callback, Nageru.CHECKABLE},
{"Checked", callback, Nageru.CHECKED}
)
Shows 3 checked items. Without the 3rd option, it shows 2 unchecked
items.
Submenus seem to behave correctly.
A quick inspection of the code didn't show the bug, so no patch, sorry.
Stefano
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 nageru depends on:
ii libasound2 1.2.9-1
ii libavcodec597:5.1.3-1
ii libavformat59 7:5.1.3-1
ii libavutil57 7:5.1.3-1
ii libbmusb6 0.7.5-1
ii libc6 2.37-5
ii libepoxy0 1.5.10-1
ii libgcc-s1 13.1.0-6
ii libjpeg62-turbo 1:2.1.5-2
ii libluajit-5.1-2 2.1.0~beta3+git20220320+dfsg-4.1
ii libmicrohttpd12 0.9.77-3
ii libmovit8 1.6.3-5
ii libprotobuf32 3.21.12-6
ii libqt5core5a5.15.8+dfsg-12
ii libqt5gui5 5.15.8+dfsg-12
ii libqt5opengl5 5.15.8+dfsg-12
ii libqt5widgets5 5.15.8+dfsg-12
ii libsrt1.5-gnutls1.5.2-1
ii libstdc++6 13.1.0-6
ii libswresample4 7:5.1.3-1
ii libswscale6 7:5.1.3-1
ii libusb-1.0-02:1.0.26-1
ii libva-drm2 2.19.0-1
ii libva-x11-2 2.19.0-1
ii libva2 2.19.0-1
ii libx11-62:1.8.6-1
ii libx264-164 2:0.164.3095+gitbaee400-3
ii libzita-resampler1 1.10.1-1
nageru recommends no packages.
nageru suggests no packages.
-- no debconf information
Bug#1041711: libmovit8: nageru fails to compile a shader on startup
Package: libmovit8 Version: 1.7.0-1 Severity: important Control: affects -1 nageru I get this crash on nageru startup (AMD box, VA-API doesn't work, but that's another issue). Rolling back libmovit8 to 1.6.3-5 gets it working again. $ nageru --no-srt --record-x264-video --recording-dir /tmp/nageru-recordings/ x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x264 [info]: profile Constrained Baseline, level 3.1, 4:2:0, 8-bit libva info: VA-API version 1.19.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 Could not initialize VA-API for MJPEG encoding: Can't find entry points for suitable codec profile. JPEGs will be encoded in software if needed. Shader compile log: 0:812(14): preprocessor error: syntax error, unexpected HASH_TOKEN, expecting NEWLINE Failed to compile shader: /* 1 */ #version 150 /* 2 */ #extension GL_ARB_compute_shader : enable /* 3 */ #extension GL_ARB_shader_image_load_store : enable /* 4 */ #extension GL_ARB_shader_image_size : enable /* 5 */ /* 6 */ // The texture the compute shader is writing to. /* 7 */ uniform restrict writeonly image2D tex_outbuf; /* 8 */ /* 9 */ // Defined in footer.comp. /* 10 */ vec4 tex2D(sampler2D s, vec2 coord); /* 11 */ void cs_output(uvec2 coord, vec4 val); /* 12 */ void cs_output(ivec2 coord, vec4 val); /* 13 */ /* 14 */ // Used if there are any steps used to postprocess compute shader output. /* 15 */ // Initialized due to https://bugs.freedesktop.org/show_bug.cgi?id=103895. /* 16 */ vec4 CS_OUTPUT_VAL = vec4(0.0); /* 17 */ /* 18 */ #define OUTPUT(tc, val) cs_output(tc, val) /* 19 */ uniform sampler2D eff0_tex_y; /* 20 */ uniform sampler2D eff0_tex_cbcr; /* 21 */ uniform int eff0_needs_mipmaps; /* 22 */ uniform vec2 eff0_cb_offset; /* 23 */ uniform vec2 eff0_cr_offset; /* 24 */ uniform vec3 eff0_offset; /* 25 */ uniform mat3 eff0_inv_ycbcr_matrix; /* 26 */ uniform int eff1_source_curve; /* 27 */ uniform float eff1_linear_scale; /* 28 */ uniform float eff1_beta; /* 29 */ uniform float eff1_c[5]; /* 30 */ uniform int eff2_source_space; /* 31 */ uniform int eff2_destination_space; /* 32 */ uniform sampler2D eff3_tex_y; /* 33 */ uniform sampler2D eff3_tex_cbcr; /* 34 */ uniform int eff3_needs_mipmaps; /* 35 */ uniform vec2 eff3_cb_offset; /* 36 */ uniform vec2 eff3_cr_offset; /* 37 */ uniform vec3 eff3_offset; /* 38 */ uniform mat3 eff3_inv_ycbcr_matrix; /* 39 */ uniform int eff4_source_curve; /* 40 */ uniform float eff4_linear_scale; /* 41 */ uniform float eff4_beta; /* 42 */ uniform float eff4_c[5]; /* 43 */ uniform int eff5_source_space; /* 44 */ uniform int eff5_destination_space; /* 45 */ uniform sampler2D eff6_tex_y; /* 46 */ uniform sampler2D eff6_tex_cbcr; /* 47 */ uniform int eff6_needs_mipmaps; /* 48 */ uniform vec2 eff6_cb_offset; /* 49 */ uniform vec2 eff6_cr_offset; /* 50 */ uniform vec3 eff6_offset; /* 51 */ uniform mat3 eff6_inv_ycbcr_matrix; /* 52 */ uniform int eff7_source_curve; /* 53 */ uniform float eff7_linear_scale; /* 54 */ uniform float eff7_beta; /* 55 */ uniform float eff7_c[5]; /* 56 */ uniform int eff8_source_space; /* 57 */ uniform int eff8_destination_space; /* 58 */ uniform sampler2D eff9_tex_y; /* 59 */ uniform sampler2D eff9_tex_cbcr; /* 60 */ uniform int eff9_needs_mipmaps; /* 61 */ uniform vec2 eff9_cb_offset; /* 62 */ uniform vec2 eff9_cr_offset; /* 63 */ uniform vec3 eff9_offset; /* 64 */ uniform mat3 eff9_inv_ycbcr_matrix; /* 65 */ uniform int eff10_source_curve; /* 66 */ uniform float eff10_linear_scale; /* 67 */ uniform float eff10_beta; /* 68 */ uniform float eff10_c[5]; /* 69 */ uniform int eff11_source_space; /* 70 */ uniform int eff11_destination_space; /* 71 */ uniform sampler2D eff12_tex_y; /* 72 */ uniform sampler2D eff12_tex_cbcr; /* 73 */ uniform int eff12_needs_mipmaps; /* 74 */ uniform vec2 eff12_cb_offset; /* 75 */ uniform vec2 eff12_cr_offset; /* 76 */ uniform vec3 eff12_offset; /* 77 */ uniform mat3 eff12_inv_ycbcr_matrix; /* 78 */ uniform int eff13_source_curve; /* 79 */ uniform float eff13_linear_scale; /* 80 */ uniform float eff13_beta; /* 81 */ uniform float eff13_c[5]; /* 82 */ uniform int eff14_source_space; /* 83 */ uniform int eff14_destination_space; /* 84 */ uniform int eff15_enable_spatial_interlacing_check; /* 85 */ uniform int eff15_current_field_position; /* 86 */ uniform ivec2 eff15_output_size; /* 87 */ uniform float eff15_inv_width; /* 88 */ uniform float eff15_inv_height; /* 89 */ uniform float eff15_current_field_vertical_offset; /* 90 */ uniform vec2 eff15_inv_output_size; /* 91 */ uniform vec2 eff15_output_texcoord_adjust; /* 92 */ /* 93 */ #define FUNCNAME eff0 /* 94 */ #define Y_CB_CR_SAME_TEXTURE 0 /* 95 */ #define CB_CR_SAME_TEXTURE 1 /* 96 */ #define CB_CR_OFFSETS_EQUAL 1 /* 97 */ // Implicit uniforms: /* 98
Bug#1035546: python3-pip: pip install ignores explicit --prefix=/usr (even with --root)
Control: forwarded -1 https://github.com/pypa/pip/issues/10978
Hi Martin (2023.05.05_13:03:43_+0200)
> I also tried --prefix=/opt which then gets me /opt/local/{bin,lib}. So this
> behaviour directly contradicts the --help documentation:
...
> So this "/local" thing is both sticky and hard to avoid..
Yeah, the cause of this is our posix_local sysconfig scheme.
Ideally pip should have a --scheme argument. At least in Debian, where
we have multiple schemes interacting with each other, that could make
sense.
Or pip could use some knowledge of Debian's schemes to select
posix_prefix / posix_local as appropriate...
This all gets messy, I'm afraid.
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Bug#932501: BTS housekeeping and severity adjustments
Hi Adrian (2021.05.30_21:44:58_+0200) > severity 932501 serious I'm wondering if this bug should really be serious. Squid's apparmor config is shipped disabled, so one has to manually enable it to trigger this bug. I would have gone for normal/important. I don't know what the correct solution to this bug is. Presumably one has to get the squid profile to include the abstraction that squid-deb-proxy provides. I don't know how this is usually done in a Debian package. Maybe one of the apparmor team can comment. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends
Hi Piotr (2023.07.20_14:58:03_+) > can you show me how poetry / pyproject / whatever parsed this file > interpreted it? I.e. what's in installed requires.txt > > (I suspect it's a hard dependency there) Yep, that's the issue, METEDATA contains: Requires-Dist: httpcore (>=0.17.3) ; python_version >= "3.8" Requires-Dist: sniffio (>=1.1,<2.0) I'd call this an upstream poetry issue. It shouldn't declare optional dependencies as required. It should rather create an extra to encapsulate any optional dependencies that aren't part of a defined extra. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1041091: python3-virtualenv: re-execution of virtualenv command removes python-debian's debian directory
Control: reassign -1 setuptools Control: found -1 setuptools/51.3.3-1 Control: affects -1 virtualenv Control: tag -1 + patch Hi Michael (2023.07.14_19:18:51_+) This is a subtle bug. I can reproduce it from upstream sources, from https://github.com/pypa/virtualenv/commit/b4564569171628ee839e14853a00f296686cae6a to https://github.com/pypa/virtualenv/commit/94f3cf581bc00eae81eca8bfd545fc3bec6d4bb6 The issue is with re-installing setuptools. It seems that: setuptools-*.dist-info/top_level.txt contains "debian". That started to happen around setuptools 51.3.0, with this commit: https://github.com/pypa/setuptools/commit/0df40810ec54590c888ae0e4073d73f731c91f4a And the solution is to exclude "debian*" from options.packages.find Trivial workaround: build the virtualenv with --no-setuptools. That's the future, anyway. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 Exclude "debian" from top_level.txt. It gets discovered because it's a top-level directory in the source tree, but it isn't a module we install. Author: Stefano Rivera Bug-Debian: https://bugs.debian.org/1041091 Forwarded: not-needed --- a/setup.cfg +++ b/setup.cfg @@ -35,6 +35,7 @@ *.tests *.tests.* tools* + debian* [options.extras_require] testing =
Bug#1040544: breezy: Unnecessary Build-Depends on cython3-dbg
Source: breezy Version: 4.0.0~bzr7759-1 Severity: normal Breezy is the last package that Build-Depends on cython3-dbg. This binary package doesn't need to exist any more, you should be able to just drop the Build-Depend, without any changes. Stefano
Bug#1040228: Resignation & call for votes to elect the Chair
Hi Sean (2023.07.03_12:55:12_-0400) > I would like to continue in the role, if the committee agrees. From what I've seen, I support that. > ===BEGIN > > A: Christoph Berg > B: Matthew Garrett > C: Helmut Grohne > D: Simon McVittie > E: Stefano Rivera > F: Timo Röhling > G: Matthew Vernon > H: Sean Whitton > > ===END My Vote: H > A = B = C = D = G > E = F Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Bug#1037931: transition: platformdirs
Hi Simon (2023.06.14_13:49:15_+) > python3-platformdirs 3.x makes python3-virtualenv and python3-poetry > uninstallable; reporting this as a transition to get it on the release > team's radar. Uploaded both of those to unstick it. They were both staged in experimental, but I'd forgotten that they were needed :) Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1035635: tox: Upgrading to tox 4
Hi Release Team! For the tox 4 transition, I have changes in dh-python staged (and in experimental) but the autopkgtests require tox 4, so I can't upload them until we're ready to pull the trigger on the transition. All the fallout I could find is documented in blocking bugs of this bug and the dh-python bug (1035675). Some of the fixes were staged in experimental, because we were in freeze at the time. Some of the packages need upstream work, and would have to be removed from testing for the transition. Please let me know when we should go ahead with this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1037079: unblock: configobj/5.0.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: config...@packages.debian.org
Control: affects -1 + src:configobj
Please unblock package configobj
[ Reason ]
Resolves a (minor) security issue. The patch only became available
recently.
It resolves a ReDoS attack (regular expression denial of service)
potentially caused by parsing untrusted configuration files.
[ Impact ]
Ship with an outstanding (very minor) security issue.
[ Tests ]
The patch includes a regression test.
The package test suite passes.
[ Risks ]
Trivial change to a regex, which looks reasonable.
The upstream hasn't reviewed it, yet.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock configobj/5.0.8-2
diff -Nru configobj-5.0.8/debian/changelog configobj-5.0.8/debian/changelog
--- configobj-5.0.8/debian/changelog2023-01-26 18:57:36.0 -0400
+++ configobj-5.0.8/debian/changelog2023-06-03 16:23:41.0 -0400
@@ -1,3 +1,11 @@
+configobj (5.0.8-2) unstable; urgency=medium
+
+ * Patch: Resolve CVE-2023-26112, a Regular Expression Denial of Service
+attack. (Closes: #1034152)
+ * Clean correctly.
+
+ -- Stefano Rivera Sat, 03 Jun 2023 16:23:41 -0400
+
configobj (5.0.8-1) unstable; urgency=medium
* New upstream release!
diff -Nru configobj-5.0.8/debian/clean configobj-5.0.8/debian/clean
--- configobj-5.0.8/debian/clean1969-12-31 20:00:00.0 -0400
+++ configobj-5.0.8/debian/clean2023-06-03 16:23:41.0 -0400
@@ -0,0 +1 @@
+src/configobj.egg-info/*
diff -Nru configobj-5.0.8/debian/patches/CVE-2023-26112
configobj-5.0.8/debian/patches/CVE-2023-26112
--- configobj-5.0.8/debian/patches/CVE-2023-26112 1969-12-31
20:00:00.0 -0400
+++ configobj-5.0.8/debian/patches/CVE-2023-26112 2023-06-03
16:23:41.0 -0400
@@ -0,0 +1,48 @@
+From: cdcadman
+Date: Wed, 17 May 2023 03:57:08 -0700
+Subject: Address CVE-2023-26112 ReDoS
+
+Origin: https://github.com/DiffSK/configobj/pull/236
+---
+ src/configobj/validate.py | 2 +-
+ src/tests/test_validate_errors.py | 10 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/src/configobj/validate.py b/src/configobj/validate.py
+index 9267a3f..98d879f 100644
+--- a/src/configobj/validate.py
b/src/configobj/validate.py
+@@ -541,7 +541,7 @@ class Validator(object):
+ """
+
+ # this regex does the initial parsing of the checks
+-_func_re = re.compile(r'(.+?)\((.*)\)', re.DOTALL)
++_func_re = re.compile(r'([^\(\)]+?)\((.*)\)', re.DOTALL)
+
+ # this regex takes apart keyword arguments
+ _key_arg = re.compile(r'^([a-zA-Z_][a-zA-Z0-9_]*)\s*=\s*(.*)$',
re.DOTALL)
+diff --git a/src/tests/test_validate_errors.py
b/src/tests/test_validate_errors.py
+index 399daa8..f7d6c27 100644
+--- a/src/tests/test_validate_errors.py
b/src/tests/test_validate_errors.py
+@@ -3,7 +3,7 @@ import os
+ import pytest
+
+ from configobj import ConfigObj, get_extra_values, ParseError, NestingError
+-from configobj.validate import Validator
++from configobj.validate import Validator, VdtUnknownCheckError
+
+ @pytest.fixture()
+ def thisdir():
+@@ -77,3 +77,11 @@ def test_no_parent(tmpdir, specpath):
+ ini.write('[[haha]]')
+ with pytest.raises(NestingError):
+ conf = ConfigObj(str(ini), configspec=specpath, file_error=True)
++
++
++def test_re_dos(val):
++value = "aaa"
++i = 165100
++attack = '\x00'*i + ')' + '('*i
++with pytest.raises(VdtUnknownCheckError):
++val.check(attack, value)
diff -Nru configobj-5.0.8/debian/patches/series
configobj-5.0.8/debian/patches/series
--- configobj-5.0.8/debian/patches/series 1969-12-31 20:00:00.0
-0400
+++ configobj-5.0.8/debian/patches/series 2023-06-03 16:23:41.0
-0400
@@ -0,0 +1 @@
+CVE-2023-26112
Bug#1037078: unblock: dh-python/5.20230603
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: dh-pyt...@packages.debian.org, pi...@debian.org Control: affects -1 + src:dh-python Please unblock package dh-python [ Reason ] Re-adds some Breaks+Replaces to help upgrade scenarios that Andreas Beckmann discovered through piuparts (bug #1036943). [ Impact ] Upgrades buster -> bullseye -> bookworm will be broken, if the user didn't manually uninstall the old python2 package. [ Tests ] It's just Breaks+Replaces. Manually verified that it works in a manual scenario where buster's python2 package was still installed. [ Risks ] Trivial change. Present in bullseye, but reverted after it. This re-introduces the change. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock dh-python/5.20230603 diff -Nru dh-python-5.20230130/debian/changelog dh-python-5.20230603/debian/changelog --- dh-python-5.20230130/debian/changelog 2023-01-30 12:30:45.0 -0400 +++ dh-python-5.20230603/debian/changelog 2023-06-03 10:49:36.0 -0400 @@ -1,3 +1,10 @@ +dh-python (5.20230603) unstable; urgency=medium + + * Reintroduce Breaks+Replaces on python2 needed to help apt in some upgrade +scenarios. (Closes: #1036943) + + -- Stefano Rivera Sat, 03 Jun 2023 10:49:36 -0400 + dh-python (5.20230130) unstable; urgency=medium * pybuild.pm: Export SETUPTOOLS_SCM_PRETEND_VERSION for packages using diff -Nru dh-python-5.20230130/debian/control dh-python-5.20230603/debian/control --- dh-python-5.20230130/debian/control 2023-01-30 12:30:45.0 -0400 +++ dh-python-5.20230603/debian/control 2023-06-03 10:49:36.0 -0400 @@ -29,6 +29,9 @@ Breaks: # due to /usr/bin/dh_python3 and debhelper files python3 (<< 3.3.2-4~), +# due to debhelper files + python2 (<< 2.7.18-2) +Replaces: python2 (<< 2.7.18-2) Description: Debian helper tools for packaging Python libraries and applications This package contains: * pybuild - invokes various build systems for requested Python versions in
Bug#1036031: unblock: python-mitogen/0.3.3-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: python-mito...@packages.debian.org Control: affects -1 + src:python-mitogen Please unblock package python-mitogen [ Reason ] This resolves bug 1036018. Apparently ansible has grown the number of open file handles over time, causing select() to become unusable. Use poll() instead of select. python-mitogen development is somewhat sporadic at the moment. We patched it to support Ansible 6, even though upstream hadn't declared support, yet. That probably contributed to this bug appearing. Upstream hasn't picked up this patch, yet. But it's been sitting on GitHub since early Feb, and resolves the issue. [ Impact ] Some users will hit "filedescriptor out of range in select()" errors when using ansible with miteogen. [ Tests ] I've manually tested ansible with mitogen, and it seems to work. The automated test suite passes. Some of the GitHub actions tests for this PR failed. But the affected platforms don't seem relevant to us. [ Risks ] Patch is relatively straightforward. Replacing one drop-in class in place of another. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock python-mitogen/0.3.3-9 diff -Nru python-mitogen-0.3.3/debian/changelog python-mitogen-0.3.3/debian/changelog --- python-mitogen-0.3.3/debian/changelog 2022-12-13 22:43:51.0 -0400 +++ python-mitogen-0.3.3/debian/changelog 2023-05-13 09:45:14.0 -0400 @@ -1,3 +1,10 @@ +python-mitogen (0.3.3-9) unstable; urgency=medium + + * Patch: Use poll() in the broker to handle more file descriptors. +(Closes: #1036018) + + -- Stefano Rivera Sat, 13 May 2023 09:45:14 -0400 + python-mitogen (0.3.3-8) unstable; urgency=medium * Team upload. diff -Nru python-mitogen-0.3.3/debian/patches/poll-poller python-mitogen-0.3.3/debian/patches/poll-poller --- python-mitogen-0.3.3/debian/patches/poll-poller 1969-12-31 20:00:00.0 -0400 +++ python-mitogen-0.3.3/debian/patches/poll-poller 2023-05-13 09:45:14.0 -0400 @@ -0,0 +1,28 @@ +From: Luca Berruti +Date: Wed, 8 Feb 2023 14:05:25 +0100 +Subject: Fix: filedescriptor out of range in select() + +Bug-Debian: https://bugs.debian.org/1036018 +Bug-Upstream: https://github.com/mitogen-hq/mitogen/issues/957 +Origin: https://github.com/mitogen-hq/mitogen/pull/984 +--- + ansible_mitogen/process.py | 6 -- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/ansible_mitogen/process.py b/ansible_mitogen/process.py +index 63caa88..8c19c37 100644 +--- a/ansible_mitogen/process.py b/ansible_mitogen/process.py +@@ -285,8 +285,10 @@ class Broker(mitogen.master.Broker): + the exuberant syscall expense of EpollPoller, so override it and restore + the poll() poller. + """ +-poller_class = mitogen.core.Poller +- ++if mitogen.parent.PollPoller.SUPPORTED: ++poller_class = mitogen.parent.PollPoller ++else: ++poller_class = mitogen.core.Poller + + class Binding(object): + """ diff -Nru python-mitogen-0.3.3/debian/patches/series python-mitogen-0.3.3/debian/patches/series --- python-mitogen-0.3.3/debian/patches/series 2022-12-13 20:24:51.0 -0400 +++ python-mitogen-0.3.3/debian/patches/series 2023-05-13 09:45:14.0 -0400 @@ -6,3 +6,4 @@ skip-python2.7-test ansible-6 hack-remove-cleanup +poll-poller
Bug#1036018: ansible-mitogen: filedescriptor out of range in select()
Control: forwarded -1 https://github.com/mitogen-hq/mitogen/issues/957 Control: tag -1 + patch > File "/usr/lib/python3/dist-packages/mitogen/core.py", line 2465, in _poll > (rfds, wfds, _), _ = io_op(select.select, > > File "/usr/lib/python3/dist-packages/mitogen/core.py", line 567, in io_op > return func(*args), None >^^^ > ValueError: filedescriptor out of range in select() Good news, this has been reported upstream, and there's a proposed patch. I'll apply it, because it looks sane. https://github.com/mitogen-hq/mitogen/pull/984 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1035639: git-imerge: FTBFS with tox 4
Hi Paul (2023.05.07_18:28:34_-0400) > For the dh-python side, to allow tox 4 to work with packages that have > install_requires set, I've had to change the way we drive tox a little. > https://salsa.debian.org/python-team/tools/dh-python/-/commit/d86475ab1097fa91d2332eb1bc65e123192ea14d > > This will require an additional Build-Depends on python3-wheel for > git-imerge. > > I'll upload that new dh-python to experimental, in a day or two. That's uploaded as dh-python 5.20230510. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1035644: python-pyvmomi: FTBFS with tox 4
Hi Debian (2023.05.06_19:19:54_-0400) > ERROR: No matching distribution found for cachetools>=5.3 This is going to require a new upload of python3-cachetools. That plus the other changes in dh-python, and a B-D on python3-wheel get it to build. Stefano signature.asc Description: PGP signature
Bug#1035775: python-prettylog: Dead upstream?
Source: python-prettylog Version: 0.1.0-4 Severity: normal I see no upstream git activity since 2019. And they ignored the maintainers query about missing git tags. https://github.com/mosquito/prettylog/issues/2 Time to think about migrating packages off it and removing it from the archive? Stefano
Bug#1035694: python-bottle: tox 4 support: Build-Depend on python3-wheel
Source: python-bottle Version: 0.12.23-1.1 Severity: normal Control: block 1035675 with -1 Hi, With the tox 4 support in dh-python (bug 1035675), python-bottle will need to Build-Depend on python3-wheel, to continue to build successfully. Stefano
Bug#1035639: git-imerge: FTBFS with tox 4
Hi Paul (2023.05.07_02:28:26_-0400) > I have confirmed this issue and that the fix is to use the config > option allowlist_externals to allow tox to use /bin/sh. > > I have sent upstream the patch at the URL above. Thanks! For the dh-python side, to allow tox 4 to work with packages that have install_requires set, I've had to change the way we drive tox a little. https://salsa.debian.org/python-team/tools/dh-python/-/commit/d86475ab1097fa91d2332eb1bc65e123192ea14d This will require an additional Build-Depends on python3-wheel for git-imerge. I'll upload that new dh-python to experimental, in a day or two. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1035638: enlighten: FTBFS with tox 4
Control: forcemerge 1035675 1035638 Control: affects 1035675 + src:enlighten The changes I've made in dh-python will resolve the FTBFS for enlighten. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1035647: tox-delay: FTBFS with tox 4
Source: tox-delay Version: 0.1.2-1 Severity: normal Control: block 1035635 with -1 tox 4 is now available in experimental, but it causes tox-delay to FTBFS. See bug 1035635 for a discussion of the general issues around tox 4. Log snippet: Making sure Tox itself works Running tox for fou$rth.,second,first,third without output capturing main() File "/<>/tests/functional.py", line 338, in main test_real_tox(cfg, tempd) File "/<>/tests/functional.py", line 275, in test_real_tox check_tox_output(cfg, tempd, "tox", TOX_ENVLIST) File "/<>/tests/functional.py", line 255, in check_tox_output subprocess.run( File "/usr/lib/python3.11/subprocess.py", line 571, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'tox', '-e', 'fou$rth.,second,first,third']' returned non-zero exit status 1. make[1]: *** [debian/rules:7: override_dh_auto_test] Error 1 Full log attached. Stefano sbuild (Debian sbuild) 0.85.0 (04 January 2023) on haydn.kardiogramm.net +==+ | tox-delay (amd64)Sat, 06 May 2023 22:20:27 + | +==+ Package: tox-delay Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'autopkgtest-virt-dummy-location' with '<>' I: NOTICE: Log filtering will replace 'build/tox-delay-SROI4t/resolver-RwVr9X' with '<>' +--+ | Update chroot| +--+ Get:1 http://deb.debian.org/debian unstable InRelease [188 kB] Get:2 http://deb.debian.org/debian experimental InRelease [101 kB] Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB] Get:4 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index [63.3 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB] Get:6 http://deb.debian.org/debian unstable/main Sources T-2023-05-06-2002.46-F-2023-04-30-2005.36.pdiff [50.8 kB] Get:7 http://deb.debian.org/debian unstable/contrib amd64 Packages T-2023-05-05-0202.38-F-2023-04-30-2005.36.pdiff [581 B] Get:6 http://deb.debian.org/debian unstable/main Sources T-2023-05-06-2002.46-F-2023-04-30-2005.36.pdiff [50.8 kB] Get:7 http://deb.debian.org/debian unstable/contrib amd64 Packages T-2023-05-05-0202.38-F-2023-04-30-2005.36.pdiff [581 B] Get:8 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-05-06-2002.46-F-2023-04-30-2005.36.pdiff [75.0 kB] Get:8 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-05-06-2002.46-F-2023-04-30-2005.36.pdiff [75.0 kB] Get:9 http://deb.debian.org/debian experimental/main amd64 Packages [869 kB] Fetched 1475 kB in 3s (442 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages were automatically installed and are no longer required: dbus-user-session isc-dhcp-common krb5-locales libatm1 libgpm2 libnss-systemd libpam-cap libpam-systemd libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxmuu1 psmisc xauth Use 'apt autoremove' to remove them. The following packages will be upgraded: isc-dhcp-client isc-dhcp-common libncursesw6 libtinfo6 ncurses-base ncurses-bin 6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 2361 kB of archives. After this operation, 7168 B of additional disk space will be used. Get:1 http://deb.debian.org/debian unstable/main amd64 ncurses-bin amd64 6.4-3 [421 kB] Get:2 http://deb.debian.org/debian unstable/main amd64 ncurses-base all 6.4-3 [261 kB] Get:3 http://deb.debian.org/debian unstable/main amd64 libncursesw6 amd64 6.4-3 [134 kB] Get:4 http://deb.debian.org/debian unstable/main amd64 libtinfo6 amd64 6.4-3 [332 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 isc-dhcp-client amd64 4.4.3-P1-2 [1096 kB] Get:6 http://deb.debian.org/debian unstable/main amd64 isc-dhcp-common amd64 4.4.3-P1-2 [117 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 2361 kB in 0s (164 MB/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ...
Bug#1035645: reprotest: FTBFS with tox 4
Source: reprotest
Version: 0.7.23
Severity: normal
Control: block 1035635 with -1
tox 4 is now available in experimental, but it causes reprotest to
FTBFS. See bug 1035635 for a discussion of the general issues around tox
4.
Log snippet:
dh_auto_test -- --test-tox
I: pybuild base:240: cd
/<>/.pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini --sitepackages -e py311
py311: failed with pass_env values cannot contain whitespace, use comma to have
multiple value
s in a single line, invalid values found 'REPROTEST_TEST_* VIRTUALENV_DOWNLOAD
*_proxy TERM'
py311: FAIL code 1 (0.00 seconds)
evaluation failed :( (0.06 seconds)
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd
/<>/.
pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini
--sitepackages -e py311
dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11
--test-tox returned exit code 13
Full log attached.
Stefano
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on haydn.kardiogramm.net
+==+
| reprotest (amd64)Sat, 06 May 2023 19:24:29 + |
+==+
Package: reprotest
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
I: NOTICE: Log filtering will replace 'autopkgtest-virt-dummy-location' with
'<>'
I: NOTICE: Log filtering will replace 'build/reprotest-mxoGJh/resolver-zu9at2'
with '<>'
+--+
| Update chroot|
+--+
Get:1 http://deb.debian.org/debian unstable InRelease [188 kB]
Get:2 http://deb.debian.org/debian experimental InRelease [101 kB]
Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index
[63.6 kB]
Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index
[63.3 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources
T-2023-05-06-1402.39-F-2023-04-30-2005.36.pdiff [44.0 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages
T-2023-05-06-1402.39-F-2023-04-30-2005.36.pdiff [67.4 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources
T-2023-05-06-1402.39-F-2023-04-30-2005.36.pdiff [44.0 kB]
Get:8 http://deb.debian.org/debian unstable/contrib amd64 Packages
T-2023-05-05-0202.38-F-2023-04-30-2005.36.pdiff [581 B]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages
T-2023-05-06-1402.39-F-2023-04-30-2005.36.pdiff [67.4 kB]
Get:8 http://deb.debian.org/debian unstable/contrib amd64 Packages
T-2023-05-05-0202.38-F-2023-04-30-2005.36.pdiff [581 B]
Get:9 http://deb.debian.org/debian experimental/main amd64 Packages [870 kB]
Fetched 1461 kB in 2s (765 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
dbus-user-session isc-dhcp-common krb5-locales libatm1 libgpm2
libnss-systemd libpam-cap libpam-systemd libx11-6 libx11-data libxau6
libxcb1 libxdmcp6 libxext6 libxmuu1 psmisc xauth
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
isc-dhcp-client isc-dhcp-common
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1213 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 isc-dhcp-client amd64
4.4.3-P1-2 [1096 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 isc-dhcp-common amd64
4.4.3-P1-2 [117 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 1213 kB in 0s (63.0 MB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 12897 files and directories currently installed.)
Preparing to unpack .../isc-dhcp-client_4.4.3-P1-2_amd64.deb ...
Unpacking isc-dhcp-client (4.4.3-P1-2) over (4.4.3-P1-1.1) ...
Preparing to unpack .../isc-dhcp-common_4.4.3-P1-2_amd64.deb ...
Unpacking isc-dhcp-common (4.4.3-P1-2) over (4.4.3-P1-1.1) ...
Setting up isc-dhcp-client (4.4.3-P1-2) ...
Setting up isc-dhcp-common (4.4.3-P1-2) ...
