Bug#1060738: python3-pymodbus: Please update!
Package: python3-pymodbus Version: 3.0.0-7 Severity: normal X-Debbugs-Cc: sm...@smurf.noris.de pymodbus is at version 3.6.3 by now and contains a heap of fixes and enhancements. -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 python3-pymodbus depends on: ii python3 3.11.2-1+b1 Versions of packages python3-pymodbus recommends: ii python3-serial-asyncio 0.6-4 ii python3-typer 0.7.0-1 python3-pymodbus suggests no packages. -- debconf-show failed
Bug#1060739: geophar: Please remove python3-sip from Build-Depends and autopkgtest Depends
Source: geophar Version: 18.10+dfsg1-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. It looks like the sip import is used only in tools/test.py and there it is used for sip.setapi(*, 2) calls. Such calls are not needed at all with PyQt5. They were needed only with PyQt4 and Python 2. So it should be safe to remove them. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060737: clog: outdated homepage URL
Package: clog Version: 1.3.0-1.1 Severity: minor X-Debbugs-Cc: frank.dietr...@gmx.li Dear Maintainer, `apt show clog` and the package site https://packages.debian.org/trixie/clog both mention as homepage http://tasktools.org/projects/clog.html. This webpage does not exist anymore and instead redirect to main page on http://tasktools.org. This website seems to have no relation to the clog tool. An former version of the mentioned package homepage can be seen in the web archive. https://web.archive.org/web/20160429211827/http://tasktools.org/projects/clog.html In the footer of this archived webpage the "Göteborg Bit Factory" is mentioned. Based on that information I believe the current home of clog is https://gothenburgbitfactory.org/clog/docs/ Please consider to update the homepage information of the package. cheers Frank -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clog depends on: ii libc6 2.37-13 ii libgcc-s1 13.2.0-9 ii libstdc++6 13.2.0-9 clog recommends no packages. clog suggests no packages.
Bug#1060742: guidata: Please remove python3-sip from Build-Depends
Source: guidata Version: 3.0.4+dfsg1-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. I briefly looked at the code, and it looks like sip is only referenced in context of py2exe/cx_Freeze, which I believe are not used in Debian packaging. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060747: rear: CVE-2024-23301
Source: rear Version: 2.7+dfsg-1.1 Severity: important Tags: security upstream Forwarded: https://github.com/rear/rear/issues/3122 X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 2.7+dfsg-1 Hi, The following vulnerability was published for rear. CVE-2024-23301[0]: | Relax-and-Recover (aka ReaR) through 2.7 creates a world-readable | initrd when using GRUB_RESCUE=y. This allows local attackers to gain | access to system secrets otherwise only readable by root. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-23301 https://www.cve.org/CVERecord?id=CVE-2024-23301 [1] https://github.com/rear/rear/issues/3122 [2] https://github.com/rear/rear/pull/3123 [3] https://github.com/rear/rear/commit/89b61793d80bc2cb2abe47a7d0549466fb087d16 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1060748: jinja2: CVE-2024-22195: HTML attribute injection when passing user input as keys to xmlattr filter
Source: jinja2 Version: 3.1.2-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for jinja2. CVE-2024-22195[0]: | Jinja is an extensible templating engine. Special placeholders in | the template allow writing code similar to Python syntax. It is | possible to inject arbitrary HTML attributes into the rendered HTML | template, potentially leading to Cross-Site Scripting (XSS). The | Jinja `xmlattr` filter can be abused to inject arbitrary HTML | attribute keys and values, bypassing the auto escaping mechanism and | potentially leading to XSS. It may also be possible to bypass | attribute validation checks if they are blacklist-based. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-22195 https://www.cve.org/CVERecord?id=CVE-2024-22195 [1] https://github.com/pallets/jinja/security/advisories/GHSA-h5c8-rqwp-cp95 [2] https://github.com/pallets/jinja/commit/7dd3680e6eea0d77fde024763657aa4d884ddb23 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1060458: perl-tk: diff for NMU version 1:804.036+dfsg1-1.1
Control: tags 1060458 + pending
Dear maintainer,
I've prepared an NMU for perl-tk (versioned as 1:804.036+dfsg1-1.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.
Sorry for the rush, but this is blocking the perl 5.38 transition …
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
diff -Nru perl-tk-804.036+dfsg1/debian/changelog perl-tk-804.036+dfsg1/debian/changelog
--- perl-tk-804.036+dfsg1/debian/changelog 2023-09-23 14:51:33.0 +0200
+++ perl-tk-804.036+dfsg1/debian/changelog 2024-01-13 19:08:35.0 +0100
@@ -1,3 +1,12 @@
+perl-tk (1:804.036+dfsg1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "FTBFS with Perl 5.38 on big-endian 64-bit: test failures":
+add Niko Tyni's patch to fix STRLEN vs int pointer confusion.
+(Closes: #1060458)
+
+ -- gregor herrmann Sat, 13 Jan 2024 19:08:35 +0100
+
perl-tk (1:804.036+dfsg1-1) unstable; urgency=medium
* replaced the build dependency libfreetype6-dev by libfreetype-dev
diff -Nru perl-tk-804.036+dfsg1/debian/patches/0001-Fix-STRLEN-vs-int-pointer-confusion-in-Tcl_GetByteAr.patch perl-tk-804.036+dfsg1/debian/patches/0001-Fix-STRLEN-vs-int-pointer-confusion-in-Tcl_GetByteAr.patch
--- perl-tk-804.036+dfsg1/debian/patches/0001-Fix-STRLEN-vs-int-pointer-confusion-in-Tcl_GetByteAr.patch 1970-01-01 01:00:00.0 +0100
+++ perl-tk-804.036+dfsg1/debian/patches/0001-Fix-STRLEN-vs-int-pointer-confusion-in-Tcl_GetByteAr.patch 2024-01-13 19:00:28.0 +0100
@@ -0,0 +1,45 @@
+From a26233c844c52f49ef9cca5f88dd9063aac60d0f Mon Sep 17 00:00:00 2001
+From: Niko Tyni
+Date: Thu, 11 Jan 2024 18:28:58 +
+Subject: [PATCH] Fix STRLEN vs int pointer confusion in
+ Tcl_GetByteArrayFromObj()
+
+Perl 5.37.2, more precisely commit
+
+ https://github.com/Perl/perl5/commit/1ef9039bccbfe64f47f201b6cfb7d6d23e0b08a7
+
+changed the implementation of SvPV() et al., breaking t/balloon.t,
+t/canvas2.t and t/photo.t on big-endian 64-bit architectures such as
+ppc64 and s390x because StringMatchGIF() no longer recognized GIF files.
+
+This is because Tcl_GetByteArrayFromObj() was calling SvPV() with an int
+pointer instead of a correct STRLEN pointer, and the new implementation
+is more sensitive to this: it assigns the pointers as-is, resulting in
+the int pointer pointing at the wrong end of the 64-bit length.
+
+Other functions taking a length pointer, at least Tcl_GetStringFromObj()
+already seem to do things correctly, so presumably this is not a
+systematic issue.
+---
+ objGlue.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/objGlue.c b/objGlue.c
+index d4927ea..dbd6a50 100644
+--- a/objGlue.c
b/objGlue.c
+@@ -627,7 +627,10 @@ Tcl_GetByteArrayFromObj(Tcl_Obj * objPtr, int * lengthPtr)
+ sv_utf8_downgrade(objPtr, 0);
+ if (lengthPtr)
+ {
+- return (unsigned char *) SvPV(objPtr, *lengthPtr);
++ STRLEN len;
++ unsigned char *s = SvPV(objPtr, len);
++ *lengthPtr = len;
++ return s;
+ }
+ else
+ {
+--
+2.30.2
+
diff -Nru perl-tk-804.036+dfsg1/debian/patches/series perl-tk-804.036+dfsg1/debian/patches/series
--- perl-tk-804.036+dfsg1/debian/patches/series 2023-09-22 17:49:03.0 +0200
+++ perl-tk-804.036+dfsg1/debian/patches/series 2024-01-13 19:00:28.0 +0100
@@ -1,3 +1,4 @@
20-pngsuite-lic.patch
60-man-name.patch
70-spellings.patch
+0001-Fix-STRLEN-vs-int-pointer-confusion-in-Tcl_GetByteAr.patch
signature.asc
Description: Digital Signature
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
On Saturday, 13 January 2024 20:22:39 CET Arno Lehmann wrote: > Am 13.01.2024 um 17:13 schrieb Diederik de Haas: > > Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy > > access to previous (6.1) kernels uploaded to Debian with which you can > > check if the problem was present in early 6.1 kernels. > > The oldest record of this issue has happened with Linux version > 6.1.0-11-amd64 > > As I usually keep this box updated, and the problems happens only > randomly, I think the best way forward might be to try with a kernel > that did *not* show this problem. > > Does that look reasonable? Yes > So I conclude I should look at something earlier than what was used with > boot 86e1a04baba04a409c34796c0fb079ff, i.e. > > journalctl --boot 86e1a04baba04a409c34796c0fb079ff | head -n 1 > Aug 30 18:16:18 Zwerg kernel: Linux version 6.1.0-11-amd64 > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU > ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian > 6.1.38-4 (2023-08-08) > > correct? > > Via the page you reference, I find a kernel package > linux-image-6.1.0-1-amd64 6.1.4-1 which might be worth a try. > > I'll need some time to sort out how to install such a package... https://snapshot.debian.org/package/linux-signed-amd64/6.1.4%2B1/#linux-image-6.1.0-1-amd64_6.1.4-1 It should be as simple as downloading that .deb file and installing it via ``dpkg -i `` or ``apt install ./`` If you also have custom kernel modules via dkms, then you'd also need the corresponding linux-headers package. https://snapshot.debian.org/package/linux/6.1.4-1/#linux-headers-6.1.0-1-amd64_6.1.4-1 You could also try version 6.1~rc3+1~exp1, but if it's present in 6.1.4-1, then I guess it's safe to say the issue is present in the whole 6.1 series and it probably has never worked (as Salvatore thought). signature.asc Description: This is a digitally signed message part.
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
Hi, Вс 14 янв 2024 @ 04:34 gregor herrmann : > On Sat, 13 Jan 2024 22:04:20 +, Jeremy Sowden wrote: > >> > This package fails its autopkgtest checks with Perl 5.38 >> > (currently in unstable.) > >> I've pushed a fix to Salsa: >> >> https://salsa.debian.org/emacsen-team/dh-make-elpa/-/commit/b6840bdc3b2a02ca07a2a601deff2a3947001368 Cool! Thanks! > Great! (And congratulations on finding out what this smartmatch > operation was supposed to do, which I didn't manage :)) > > In case you have troubles finding someone from the team to upload, > please shout, I'm happy to help. I've just looked into the bug report and commited changes, and uploaded the updated package. Cheers! Lev
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
On Sat, 13 Jan 2024 at 15:21:02 +, Simon McVittie wrote: > I recently uploaded a snapshot of GLib 2.79.x to experimental (in > preparation for NEW processing) and it failed tests on s390x and on > the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means > it's a general problem with 64-bit BE, rather than specifically s390x. git bisect says commit df4aea76 "gdatetime: Add support for %E modifier to g_date_time_format()" is the first bad commit, which would be consistent with it being... > instead > of segfaulting, the test failed with an assertion error involving dates with > a Japanese era marker: ... something to do with Japanese and Thai eras, and the %E modifier. smcv
Bug#1060758: texinfo: please allow-stderr for debian/tests/test-suite
Package: texinfo Version: 7.1-2 X-Debbugs-Cc: Sebastian Ramacher Hi, the perl_5.38.2-3 migration checks for texinfo are currently failing on ci.debian.net. https://ci.debian.net/packages/t/texinfo/testing/amd64/41788013/ 160s autopkgtest [07:52:27]: summary 160s test-suite FAIL stderr: In file included from ../system.h:53, What happens here is that the package build (as requested with build-needed) gets done with both perl and linux-libc-dev from unstable, but the actual tests are run with perl from unstable and linux-libc-dev from testing. This leads to 'make check' noticing that dependencies have changed and rebuilding (at least part) of the source. The rebuild produces compiler warnings on stderr, making the test fail. Please consider adding 'allow-stderr' to the test definition to make it survive this corner case. The root cause here is presumably the autopkgtest fallback to install more things from unstable than strictly needed in case of installability problems, but 'allow-stderr' would help as a workaround. Sebastian (cc'd) said he'd ignore the test for Perl 5.38 migration but asked me to file this. Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1053348: atop gets a segmentation fault
On Mon, Oct 02, 2023 at 12:50:04PM +0200, Tiger!P wrote: > I ran `atop 2` for some time and then it got a segmentation fault. Because it > didn't create a core file, I changed settings to get a core file and started > atop in the same way. Does this still happen with the new atop version in sid? Greeting Marc
Bug#1060744: stimfit: Please port from sip4 to sip6
Source: stimfit Version: 0.16.0-1.2 Severity: important Usertags: sip6 Dear Maintainer, Your package currently builds with sip4, which is a deprecated version of SIP. The modern version of SIP is packaged as sip6. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. It looks like stimfit only uses SIP by including . In SIP 6, it needs to be generated on the fly, by running a command like: sip-module PyQt5.sip --sip-h Where PyQt5.sip is the name of the run-time SIP module that you want to use, and sip-module(1) is provided by sip-tools package. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. Please port this package to SIP 6, and after that is done, remove the build- dependency on python3-sip-dev. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
On Saturday, 13 January 2024 16:39:51 CET Arno Lehmann wrote: > > Just to be clear, can you confirm this is or is not a regression from > > a previous running 6.1.y kernel? > > On this hardware, the network issues appeared right from the start. > ... > Actually I don't even know which was the first kernel version I had on > this host, but it's been on Bookworm for all its lifetime. Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy access to previous (6.1) kernels uploaded to Debian with which you can check if the problem was present in early 6.1 kernels. signature.asc Description: This is a digitally signed message part.
Bug#1060751: atril: CVE-2023-51698
Source: atril Version: 1.26.1-3 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for atril. CVE-2023-51698[0]: | Atril is a simple multi-page document viewer. Atril is vulnerable to | a critical Command Injection Vulnerability. This vulnerability gives | the attacker immediate access to the target system when the target | user opens a crafted document or clicks on a crafted link/URL using | a maliciously crafted CBT document which is a TAR archive. A patch | is available at commit ce41df6. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-51698 https://www.cve.org/CVERecord?id=CVE-2023-51698 [1] https://github.com/mate-desktop/atril/security/advisories/GHSA-34rr-j8v9-v4p2 [2] https://github.com/mate-desktop/atril/commit/ce41df6467521ff9fd4f16514ae7d6ebb62eb1ed Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1058501: rust-ansi-parser: Stop using rust-nom-4
I wrote a patch to upgrade to nom 7, and it was somewhat non-trivial. I would like to run this by upstream before we pull this into Debian https://gitlab.com/davidbittner/ansi-parser/-/merge_requests/14 //Alex
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/3225 Control: tags -1 + help On Sat, 13 Jan 2024 at 16:21:46 +, Simon McVittie wrote: > On Sat, 13 Jan 2024 at 15:21:02 +, Simon McVittie wrote: > > I recently uploaded a snapshot of GLib 2.79.x to experimental (in > > preparation for NEW processing) and it failed tests on s390x and on > > the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means > > it's a general problem with 64-bit BE, rather than specifically s390x. > > git bisect says commit df4aea76 "gdatetime: Add support for %E modifier > to g_date_time_format()" is the first bad commit, which would be consistent > with it being... > > > instead > > of segfaulting, the test failed with an assertion error involving dates with > > a Japanese era marker: > > ... something to do with Japanese and Thai eras, and the %E modifier. I can't see anything in the relevant commit[1] that looks like it would be affected by endianness. Could there be an endianness problem in one of the glibc APIs that it's calling into, or something like that? smcv [1] https://gitlab.gnome.org/GNOME/glib/-/commit/df4aea76204090f770a8fd90c2b68b51c2cfc2a3
Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?
Hi, Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34) > Quoting Helmut Grohne (2024-01-12 21:58:00) > > > What can cause mkfs.ext4 to fail with a "Permission denied" error? > > I think this is our typical problem when dealing with user namespaces. I > > guess that the thing that fails here is mkfs.ext4 opening the target image > > file (to be formatted). That file has earlier been chowned to the root uid > > inside the namespace, so permission should be there, but you need more. You > > also need execute permission (to the first uid of your namespace) for the > > containing directory up until the root. I guess that none of those are > > world-executable and not by chanced owned by your first subuid nor owned by > > the first group in your subgid range. > > I'm not yet convinced that this is it. The problem occurs for Francesco when > using either /tmp or /dev/shm as a temporary directly. By default, those two > locations should have the desired permission bits set. Lets check whether > world-execute permissions are set for all directories up until root. I have > this: > > $ stat -c "%a %n" / /dev /dev/shm /tmp > 755 / > 755 /dev > 1777 /dev/shm > 1777 /tmp > > Francesco, what are the world execute permissions on all path components up > to /tmp and /devv/shm in your case? scratch what I said in your last mail. Your problem is with the creation of the image and not with the temporary chroot directory. What Helmut said is likely correct and exactly the problem you are facing. To verify, you could run the command you posted initially inside your $HOME directory and show us the permission bits of your $HOME. Mine are these: stat -c "%a %n" $HOME 711 /home/josch I assume in your case, you have a 0 at the end of the octal permissions? Thanks! cheers, josch signature.asc Description: signature
Bug#1060769: foo2zjs: mitigate empty directory loss for usrmerge (DEP17 P6)
Source: foo2zjs Version: 20200505dfsg0-2 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17p6 For the currently ongoing UsrMerge effort [1], paths installed into /lib should move to /usr/lib. printer-driver-foo2zjs installs the empty directory /lib/firmware/hp. On a naive move to /usr, this directory would be lost on upgrades (the "DEP17 P6" problem). Please find a patch attached to install the relevant paths into /usr, and a mitigation for the lost directory. I've chosen the postinst way, as your package already had a postinst dealing with this path. Note: this should not be backported to bookworm. If you intend to backport, please revert the entire patch for the backport. If your package will change for the t64 transition or otherwise rename/split/move its binaries (packages) during trixie, please then upload to experimental and get in touch with the UsrMerge driver, please see the wiki [1]. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru foo2zjs-20200505dfsg0/debian/changelog foo2zjs-20200505dfsg0/debian/changelog --- foo2zjs-20200505dfsg0/debian/changelog 2021-09-02 14:45:45.0 +0200 +++ foo2zjs-20200505dfsg0/debian/changelog 2024-01-13 23:36:22.0 +0100 @@ -1,3 +1,12 @@ +foo2zjs (20200505dfsg0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install into UsrMerged-layout (udev files, firmware directory). +Restore /usr/lib/firmware/hp as an empty directory in postinst if it +is lost on upgrades. (DEP17 P6) (Closes: #-1) + + -- Chris Hofstaedtler Sat, 13 Jan 2024 23:36:22 +0100 + foo2zjs (20200505dfsg0-2) unstable; urgency=medium * Remove myself from Uploaders diff -Nru foo2zjs-20200505dfsg0/debian/NEWS foo2zjs-20200505dfsg0/debian/NEWS --- foo2zjs-20200505dfsg0/debian/NEWS 2021-09-02 14:45:45.0 +0200 +++ foo2zjs-20200505dfsg0/debian/NEWS 2024-01-13 23:36:22.0 +0100 @@ -1,7 +1,7 @@ foo2zjs (20090908dfsg-2) unstable; urgency=low Starting with this version all HP firmwares are looked for into - /lib/firmware/hp/ instead of upstream /usr/share/foo2zjs/firmware/ + /usr/lib/firmware/hp/ instead of upstream /usr/share/foo2zjs/firmware/ (thus solving bug #517957). The upstream /usr/bin/getweb and /lib/udev/hplj1000 scripts have diff -Nru foo2zjs-20200505dfsg0/debian/patches/0012-Use-the-same-firmware-folder-for-all-HP-LJ-printers.patch foo2zjs-20200505dfsg0/debian/patches/0012-Use-the-same-firmware-folder-for-all-HP-LJ-printers.patch --- foo2zjs-20200505dfsg0/debian/patches/0012-Use-the-same-firmware-folder-for-all-HP-LJ-printers.patch 2021-09-02 14:45:45.0 +0200 +++ foo2zjs-20200505dfsg0/debian/patches/0012-Use-the-same-firmware-folder-for-all-HP-LJ-printers.patch 2024-01-13 23:36:22.0 +0100 @@ -2,6 +2,8 @@ Date: Tue, 4 Oct 2016 11:43:55 +0200 Subject: Use the same firmware folder for all HP LJ printers +[zeha@d.o 2024-01-13: changed to /usr/ for UsrMerge layout] + --- hplj1000 | 6 -- hplj10xx.conf | 10 +- @@ -58,7 +60,7 @@ match "vendor" "0x03f0"; match "product" "0x3d17"; -action "cat /usr/share/foo2xqx/firmware/sihpP1005.dl > /dev/$device-name"; -+action "cat /lib/firmware/hp/sihpP1005.dl > /dev/$device-name"; ++action "cat /usr/lib/firmware/hp/sihpP1005.dl > /dev/$device-name"; }; # Firmware download HP LaserJet P1006 printer @@ -66,7 +68,7 @@ match "vendor" "0x03f0"; match "product" "0x3e17"; -action "cat /usr/share/foo2xqx/firmware/sihpP1006.dl > /dev/$device-name"; -+action "cat /lib/firmware/hp/sihpP1006.dl > /dev/$device-name"; ++action "cat /usr/lib/firmware/hp/sihpP1006.dl > /dev/$device-name"; }; # Firmware download HP LaserJet P1007 printer @@ -74,7 +76,7 @@ match "vendor" "0x03f0"; match "product" "0x4817"; -action "cat /usr/share/foo2xqx/firmware/sihpP1005.dl > /dev/$device-name"; -+action "cat /lib/firmware/hp/sihpP1005.dl > /dev/$device-name"; ++action "cat /usr/lib/firmware/hp/sihpP1005.dl > /dev/$device-name"; }; # Firmware download HP LaserJet P1008 printer @@ -82,7 +84,7 @@ match "vendor" "0x03f0"; match "product" "0x4917"; -action "cat /usr/share/foo2xqx/firmware/sihpP1006.dl > /dev/$device-name"; -+action "cat /lib/firmware/hp/sihpP1006.dl > /dev/$device-name"; ++action "cat /usr/lib/firmware/hp/sihpP1006.dl > /dev/$device-name"; }; # Firmware download HP LaserJet P1505 printer @@ -90,7 +92,7 @@ match "vendor" "0x03f0"; match "product" "0x3f17"; -action "cat /usr/share/foo2xqx/firmware/sihpP1505.dl > /dev/$device-name"; -+action "cat /lib/firmware/hp/sihpP1505.dl > /dev/$device-name"; ++action "cat /usr/lib/firmware/hp/sihpP1505.dl > /dev/$device-name"; }; # Firmware download HP LaserJet 1000 printer diff -Nru foo2zjs-20200505dfsg0/debian/patches/0013-Firmware-directory-is-lib-firmware-hp-Closes-517957.patch
Bug#1058441: python-docx: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi, I created a patch to fix this auto test issue with Python 3.12. I am attaching the debdiff file for you to checkout. I have created a branch too in the salsa [0], if it looks ok, you can MR. [0] https://salsa.debian.org/python-team/packages/python-docx/-/tree/fix-for-auto-test-error-Py312?ref_type=heads Cheers! diff -Nru python-docx-1.1.0+dfsg/debian/changelog python-docx-1.1.0+dfsg/debian/changelog --- python-docx-1.1.0+dfsg/debian/changelog 2023-11-22 06:24:08.0 + +++ python-docx-1.1.0+dfsg/debian/changelog 2024-01-13 20:00:00.0 + @@ -1,3 +1,11 @@ +python-docx (1.1.0+dfsg-2) UNRELEASED; urgency=medium + + * Team upload. + * Patch for dh_auto_test datetime DeprecationWarning with +Python 3.12. (Closes: #1058441) + + -- Yogeswaran Umasankar Sat, 13 Jan 2024 20:00:00 + + python-docx (1.1.0+dfsg-1) unstable; urgency=medium * New upstream version 1.1.0+dfsg diff -Nru python-docx-1.1.0+dfsg/debian/patches/fix-DescribeCorePropertiesPart-py312.patch python-docx-1.1.0+dfsg/debian/patches/fix-DescribeCorePropertiesPart-py312.patch --- python-docx-1.1.0+dfsg/debian/patches/fix-DescribeCorePropertiesPart-py312.patch 1970-01-01 00:00:00.0 + +++ python-docx-1.1.0+dfsg/debian/patches/fix-DescribeCorePropertiesPart-py312.patch 2024-01-13 20:00:00.0 + @@ -0,0 +1,56 @@ +Description: Fixed datetime DeprecationWarning in Python 3.12. + Issue caused because modified_datetime returns None. +Author: Yogeswaran Umasankar +Last-Update: 2024-01-08 + +--- a/src/docx/opc/parts/coreprops.py b/src/docx/opc/parts/coreprops.py +@@ -1,6 +1,6 @@ + """Core properties part, corresponds to ``/docProps/core.xml`` part in package.""" + +-from datetime import datetime ++from datetime import datetime, timezone + + from docx.opc.constants import CONTENT_TYPE as CT + from docx.opc.coreprops import CoreProperties +@@ -22,7 +22,7 @@ class CorePropertiesPart(XmlPart): + core_properties.title = "Word Document" + core_properties.last_modified_by = "python-docx" + core_properties.revision = 1 +-core_properties.modified = datetime.utcnow() ++core_properties.modified = datetime.now(timezone.utc) + return core_properties_part + + @property +--- a/tests/opc/parts/test_coreprops.py b/tests/opc/parts/test_coreprops.py +@@ -1,6 +1,6 @@ + """Unit test suite for the docx.opc.parts.coreprops module.""" + +-from datetime import datetime, timedelta ++from datetime import datetime, timedelta, timezone + + import pytest + +@@ -25,7 +25,8 @@ class DescribeCorePropertiesPart: + assert core_properties.title == "Word Document" + assert core_properties.last_modified_by == "python-docx" + assert core_properties.revision == 1 +-delta = datetime.utcnow() - core_properties.modified ++# Handles if modified_datetime is None ++delta = datetime.now(timezone.utc) - (core_properties.modified.replace(tzinfo=timezone.utc) if core_properties.modified else None) + max_expected_delta = timedelta(seconds=2) + assert delta < max_expected_delta + +--- a/src/docx/opc/coreprops.py b/src/docx/opc/coreprops.py +@@ -93,7 +93,8 @@ class CoreProperties: + + @property + def modified(self): +-return self._element.modified_datetime ++# Handles if modified_datetime is None ++return self._element.modified_datetime if self._element.modified_datetime is not None else None + + @modified.setter + def modified(self, value): diff -Nru python-docx-1.1.0+dfsg/debian/patches/series python-docx-1.1.0+dfsg/debian/patches/series --- python-docx-1.1.0+dfsg/debian/patches/series2023-11-22 06:21:09.0 + +++ python-docx-1.1.0+dfsg/debian/patches/series2024-01-13 20:00:00.0 + @@ -1 +1,2 @@ +fix-DescribeCorePropertiesPart-py312.patch adjust-to-image-removals.patch
Bug#1060770: FTBFS: Missing dependency on libevdev-dev
Package: gnome-control-center Version: 1:46~alpha-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: Jararh Gosbell Dear Maintainer, In attempting to rebuild gnome-control-center for Mobian I noticed that the 46-alpha-2 version fails to build without adding a build-dep on libevdev-dev. I've reproduced this with `sbuild` with a fresh Debian Unstable chroot against debian/1%46_alpha-2. A patch is attached that fixes the issue for me. Thanks, Jarrah. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.2-1.qubes.fc37.x86_64 (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 gnome-control-center depends on: pn accountsservice pn apg ii colord1.4.6-2.2 pn desktop-base ii desktop-file-utils0.26-1 pn gnome-control-center-data ii gnome-desktop3-data 43.2-2 pn gnome-settings-daemon ii gsettings-desktop-schemas 43.0-1 pn libaccountsservice0 ii libadwaita-1-01.2.2-1 ii libc6 2.36-9+deb12u3 ii libcairo2 1.16.0-7 pn libcolord-gtk4-1 ii libcolord21.4.6-2.2 ii libcups2 2.4.2-3+deb12u5 ii libepoxy0 1.5.10-1 ii libfontconfig12.14.1-4 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 pn libgnome-bg-4-2 pn libgnome-bluetooth-ui-3.0-13 ii libgnome-desktop-4-2 43.2-2 pn libgnome-rr-4-2 ii libgnutls30 3.7.9-2+deb12u1 ii libgoa-1.0-0b 3.46.0-1 pn libgoa-backend-1.0-1 pn libgsound0 ii libgtk-3-03.24.38-2~deb12u1 ii libgtk-4-14.8.3+ds-2+deb12u1 pn libgtop-2.0-11 ii libgudev-1.0-0237-2 pn libibus-1.0-5 ii libkrb5-3 1.20.1-2+deb12u1 pn libmalcontent-0-0 ii libmm-glib0 1.20.4-1 ii libnm01.42.4-1 pn libnma-gtk4-0 ii libpango-1.0-01.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-gobject-1-0 122-3 pn libpulse-mainloop-glib0 ii libpulse0 16.1+dfsg1-2+b1 pn libpwquality1 ii libsecret-1-0 0.20.5-3 ii libsmbclient 2:4.17.12+dfsg-0+deb12u1 pn libsnapd-glib-2-1 ii libudisks2-0 2.9.4-4 ii libupower-glib3 0.99.20-2 ii libwacom9 2.6.0-1 ii libx11-6 2:1.8.4-2+deb12u2 ii libxi62:1.8-1+b1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 pn webp-pixbuf-loader Versions of packages gnome-control-center recommends: pn cracklib-runtime ii cups-pk-helper 0.2.6-1+b1 pn gkbd-capplet pn gnome-bluetooth-sendto pn gnome-online-accounts pn gnome-remote-desktop pn gnome-user-docs pn gnome-user-share ii iso-codes 4.15.0-1 pn libcanberra-pulse ii libnss-myhostname 252.19-1~deb12u1 pn libspa-0.2-bluetooth | pulseaudio-module-bluetooth pn malcontent-gui ii network-manager-gnome 1.30.0-2 ii polkitd 122-3 pn power-profiles-daemon pn realmd pn rygel | rygel-tracker ii system-config-printer-common1.5.18-1 Versions of packages gnome-control-center suggests: pn gnome-software | gnome-packagekit pn gstreamer1.0-pulseaudio ii pkexec 122-3 ii x11-xserver-utils 7.7+9+b1 >From 83c57e32bd527feae9d540f16c930444cfc3dd3e Mon Sep 17 00:00:00 2001 From: Jarrah Gosbell Date: Sun, 14 Jan 2024 02:03:09 + Subject: [PATCH] d/control: Add build-dep on libevdev-dev This fixes a build failure in dh_auto_configure. --- debian/control | 1 +
Bug#1060741: ball: Please port from sip4 to sip6
Package: ball Version: 1.5.0+git20180813.37fc53c-11 Severity: important Usertags: sip6 Dear Maintainer, Your package currently builds with sip4, which is a deprecated version of SIP. The modern version of SIP is packaged as sip6. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. The recommended approach is using SIP's own PEP 517-compliant build system (i.e. pyproject.toml and project.py files), however some projects (e.g. krita upstream) have successfully integrated SIP 6 into their CMake-based build systems. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. Please port this package to SIP 6, and after that is done, remove the build- dependency on python3-sip-dev. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
Am 13.01.2024 um 12:48 schrieb Diederik de Haas: On Saturday, 13 January 2024 11:45:29 CET Arno Lehmann wrote: Hardware name: ASUS System Product Name/ROG STRIX X670E-A GAMING WIFI, BIOS 1410 04/28/2023 Possibly not related, but there's BIOS 1807 available. I'll definitely give that a try -- when I'm physically close to the box! Thanks for reminding me! Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Bug#1060749: qemu: CVE-2023-6683: ui/clipboard: avoid crash upon request when clipboard peer is no
Source: qemu Version: 1:8.2.0+ds-4 Severity: important Tags: security upstream Forwarded: https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for qemu. CVE-2023-6683[0]: | A flaw was found in the QEMU built-in VNC server while processing | ClientCutText messages. The qemu_clipboard_request() function can be | reached before vnc_server_cut_text_caps() was called and had the | chance to initialize the clipboard peer, leading to a NULL pointer | dereference. This could allow a malicious authenticated VNC client | to crash QEMU and trigger a denial of service. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-6683 https://www.cve.org/CVERecord?id=CVE-2023-6683 [1] https://lists.nongnu.org/archive/html/qemu-devel/2024-01/msg02382.html Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1060750: pgzero: update d/watch file and new upstream version 1.2.1
Source: pgzero Version: 1.2.post4+dfsg-2 Followup-For: Bug #1060750 And with the attachment. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff --git a/pgzero-1.2.post4+dfsg/debian/watch b/pgzero/debian/watch index d0e551e..b3fd617 100644 --- a/pgzero-1.2.post4+dfsg/debian/watch +++ b/pgzero/debian/watch @@ -4,4 +4,4 @@ opts=dversionmangle=s/\+dfsg\.\d+$//,\ filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/pgzero-$1\.tar\.gz/,\ repacksuffix=+dfsg,\ repack,compression=xz \ - https://github.com/lordmauve/pgzero/releases .*/v?(\d\S+)\.tar\.gz + https://github.com/lordmauve/pgzero/tags .*/v?(\d\S+)\.tar\.gz
Bug#1060755: calibre: Cant execute calibre. Error: cannot import name QNetworkProxyFactory from qt.core
Package: calibre Version: 7.3.0+ds-1 Severity: grave Justification: renders package unusable Dear Maintainer, I cant open calibre anymore. opening from terminal gives the following log error: Failed to import PyQt module: PyQt6.QtNetwork with error: /lib/x86_64-linux-gnu/libQt6Network.so.6: undefined symbol: _Z12qt_safe_pollP6pollfdmPK8timespec, version Qt_6 Traceback (most recent call last): File "/usr/bin/calibre", line 21, in sys.exit(calibre()) ^ File "/usr/lib/calibre/calibre/gui_launch.py", line 72, in calibre from calibre.gui2.main import main File "/usr/lib/calibre/calibre/gui2/__init__.py", line 13, in from qt.core import ( ImportError: cannot import name 'QNetworkProxyFactory' from 'qt.core' (/usr/lib/calibre/qt/core.py) I think the issue starts after I installed a package (krita) with: sudo apt update, then sudo apt install krita the last time i updated was last week or so. I think this is the cause of error because i opened calibre yesterday night and it worked as expected and this is the first meaningful thing i do in the computer after that. I think it might be dependency error or something. after installing krita and noting the calibre error i tried sudo apt upgrade and sudo apt autoremove and restart my computer but calibre still cant open. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calibre depends on: ii ca-certificates20230311 ii calibre-bin7.3.0+ds-1 ii fonts-liberation 1:2.1.5-3 ii libjpeg-turbo-progs1:2.1.5-2+b2 ii libjxr-tools 1.2~git20170615.f752187-5 ii libqt6webenginecore6-bin 6.4.2-final+dfsg-12 ii optipng0.7.7-3 ii poppler-utils 22.12.0-2+b1 ii pyqt6-dev-tools6.6.1-2 ii python33.11.4-5+b1 ii python3-apsw 3.43.0.0-1+b1 ii python3-bs44.12.2-2 ii python3-chm0.8.6-3+b5 ii python3-css-parser 1.0.10-1 ii python3-cssselect 1.2.0-2 ii python3-dateutil 2.8.2-3 ii python3-feedparser 6.0.10-1 ii python3-fonttools 4.46.0-1 ii python3-html2text 2020.1.16-2 ii python3-html5-parser 0.4.12+ds-1+b1 ii python3-html5lib 1.1-3 ii python3-jeepney0.8.0-3 ii python3-lxml 4.9.4-1 ii python3-markdown 3.4.4-1 ii python3-mechanize 1:0.4.9+ds-2 ii python3-msgpack1.0.3-3+b1 ii python3-netifaces 0.11.0-2+b2 ii python3-pil10.1.0-1+b1 ii python3-pkg-resources 68.1.2-2 ii python3-py7zr 0.11.3+dfsg-6 ii python3-pycryptodome 3.11.0+dfsg1-4 ii python3-pygments 2.15.1+dfsg-1 ii python3-pyparsing 3.1.1-1 ii python3-pyqt6 6.6.1-2 ii python3-pyqt6.qtquick 6.6.1-2 ii python3-pyqt6.qtsvg6.6.1-2 ii python3-pyqt6.qtwebengine 6.6.0-1 ii python3-pyqt6.sip 13.6.0-1+b1 ii python3-regex 0.1.20221031-1+b2 ii python3-routes 2.5.1-3 ii python3-speechd0.11.5-2 ii python3-xxhash 3.2.0-1+b2 ii python3-zeroconf 0.131.0-1 ii python3.11 3.11.7-2 ii webp 1.3.2-0.3 ii xdg-utils 1.1.3-4.1 Versions of packages calibre recommends: ii python3-dnspython 2.4.2-1 ii python3-ipython8.14.0-2 ii qt6-wayland6.4.2-5 ii udisks22.10.1-4 Versions of packages calibre suggests: pn python3-unrardll -- no debconf information
Bug#1060756: developer.php: search by email not shows correct data
Package: qa.debian.org Severity: normal Hi there! On tracker.debian.org when I click on the Maintainer name, a request is made to https://qa.debian.org/developer.php?email=, but the page does not show correct information, at least in my case. I made several uploads using the address ta...@debian.org, but these are shown in another address, ta...@users.sourceforge.net, an address I last used many years ago. This occurred to all items of type "Sponsored/other uploads", and for some NMUs, and QAs. To leave no doubt about the issue: When I access [1] it shows all "Sponsored/other uploads", some NMUs, and QAs, that I upload with the address ta...@debian.org, and they aren't shown in right place [2]. [1] https://qa.debian.org/developer.php?email=talau%40users.sourceforge.net [2] https://qa.debian.org/developer.php?email=talau%40debian.org Best Regards, mt
Bug#1060076: Fixed in Alberta 3.1.0
This is the according upstram bug issue: https://gitlab.com/alberta-fem/alberta3/-/issues/16 Was fixed in Alberta release 3.1.0.
Bug#1060740: regripper: autopkgtest failure with Perl 5.38: changed diagnostics
Control: tag -1 + confirmed upstream fixed-upstream patch On Sat, 13 Jan 2024 17:33:07 +0200, Niko Tyni wrote: > Presumably the best fix is to correct the (longstanding) syntax error > in the plugin. % perl -c ./plugins/clsid_tln.pl syntax error at ./plugins/clsid_tln.pl line 112, near "$scriptlet)" Already found & fixed upstream: https://github.com/keydet89/RegRipper3.0/pull/55 Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1060766: dumpasn1: FTBFS with stack-clash-protection on armhf due to valgrind segfault
Source: dumpasn1 Version: 20210212-3 Severity: serious Tags: patch User: debian-...@lists.debian.org Usertags: 32bit-stackclash Hi, dumpasn1 currently fails to build from source on armhf. The failure is due to an incompatibility between valgrind and stack-clash-protection on 32bit arm reported upstream at: https://bugs.kde.org/show_bug.cgi?id=479699 While waiting for valgrind to get updated, please cosider addressing the immediate issue by disabling stack-clash-protection on armhf with the following snippet in d/rules: ifeq ($(DEB_TARGET_ARCH),armhf) export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash else export DEB_BUILD_MAINT_OPTIONS = hardening=+all endif The build error looks like this: 1052468 | base64 -d 1052469 Segmentation fault | valgrind --error-exitcode=17 -- "$DUMPASN1" - make[1]: *** [debian/rules:24: override_dh_auto_test] Error 139 You can find the full build logs at: http://qa-logs.debian.net/2024/01/11/armhf/dumpasn1_20210212-3_unstable-armhf.log Thanks, Emanuele
Bug#999989: planning to NMU poco to orphan it
Hello Jochen. What I want to do is orphan the Poco package as an NMU and then do an NMU of a new version -- in that order. It seems to be the right thing to do for this situation. I had a brief discussion with [debian-qa] and was given feedback that the plan seems reasonable: https://lists.debian.org/debian-qa/2024/01/msg6.html The NMU uploads will go to a -delayed queue to allow stopping it or increasing delay if there is an objection. On 1/5/24 07:30, Jochen Sprickerhof wrote: * Chris Knadle [2024-01-02 16:53]: The way to orphan a package is to do an upload and setting the maintainer to be . Until that's done the package ends up in maintainership limbo. See the bottom of Policy 3.3, and Developer's Reference section 5.9.4. Agreed but I think that is something for the Maintainer: to do, who seems to be active in Debian, otherwise. Unfortunately that's not what I see. Feel free to add additional information. The last activity I've been able to find from Krzysztof was an upload of clamfs 2020-01-10. For Poco the last activity from him is 2009. The Git repository for Poco shows one commit 2009-08-30 and one package upload 2009-09-01. I find no email in [debian-devel] from him as far back as 2014. The Debian bug tracker last activity was January 2011 with one email in Bug #500134. Looking at his website, the first thing on the main page mentions ClamFS. The clamfs package in Debian has him as the only listed maintainer and the package has dropped out of Testing because of the Poco library dropped and there as has been no response. Bug #679125 for clamfs from 2012 has had no response. I sent email to the Debian MIA team but have not yet heard back from them. Assuming I can get contact with the MIA team and they start their process, that will take about six months. -- Chris -- Chris Knadle chris.kna...@coredump.us Debian Developer
Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes
Source: glib2.0 Version: 2.79.0+git20240110~g38f5ba3c-1 Severity: serious Tags: ftbfs experimental X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powe...@lists.debian.org User: debian-s...@lists.debian.org Usertags: s390x I recently uploaded a snapshot of GLib 2.79.x to experimental (in preparation for NEW processing) and it failed tests on s390x and on the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means it's a general problem with 64-bit BE, rather than specifically s390x. The 32-bit big-endian powerpc and hppa ports seem to pass this test fine, although hppa had an unrelated failure in a different test. On the s390x buildd, the test crashed: https://buildd.debian.org/status/fetch.php?pkg=glib2.0=s390x=2.79.0%2Bgit20240110%7Eg38f5ba3c-1=1705088035=0 > 21/369 glib:glib+core+slow / gdatetime > RUNNING > >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 > >>> MALLOC_PERTURB_=168 > >>> G_TEST_BUILDDIR='/<>/debian/build/deb/glib/tests' > >>> G_ENABLE_DIAGNOSTIC=1 G_DEBUG=gc-friendly MALLOC_CHECK_=2 > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 > >>> G_TEST_SRCDIR='/<>/glib/tests' > >>> LD_LIBRARY_PATH='/<>/debian/build/deb/glib' > >>> '/<>/debian/build/deb/glib/tests/gdatetime' > ▶ 21/369 /GDateTime/invalid > OK > ▶ 21/369 /GDateTime/add_days > OK > ▶ 21/369 /GDateTime/add_full > OK > ▶ 21/369 /GDateTime/add_hours > OK > ▶ 21/369 /GDateTime/add_minutes > OK > ▶ 21/369 /GDateTime/add_months > OK > ▶ 21/369 /GDateTime/add_seconds > OK > ▶ 21/369 /GDateTime/add_weeks > OK > ▶ 21/369 /GDateTime/add_years > OK > ▶ 21/369 /GDateTime/compare > OK > ▶ 21/369 /GDateTime/diff > OK > ▶ 21/369 /GDateTime/equal > OK > ▶ 21/369 /GDateTime/get_day_of_week > OK > ▶ 21/369 /GDateTime/get_day_of_month > OK > ▶ 21/369 /GDateTime/get_day_of_year > OK > ▶ 21/369 /GDateTime/get_hour > OK > ▶ 21/369 /GDateTime/get_microsecond > OK > ▶ 21/369 /GDateTime/get_minute > OK > ▶ 21/369 /GDateTime/get_month > OK > ▶ 21/369 /GDateTime/get_second > OK > ▶ 21/369 /GDateTime/get_utc_offset > OK > ▶ 21/369 /GDateTime/get_year > OK > ▶ 21/369 /GDateTime/hash > OK > ▶ 21/369 /GDateTime/new_from_unix > OK > ▶ 21/369 /GDateTime/new_from_unix_utc > OK > ▶ 21/369 /GDateTime/new_from_timeval > OK > ▶ 21/369 /GDateTime/new_from_timeval_utc > OK > ▶ 21/369 /GDateTime/new_from_iso8601 > OK > ▶ 21/369 /GDateTime/new_full > OK > ▶ 21/369 /GDateTime/now > OK > ▶ 21/369 /GDateTime/test-6-days-until-end-of-the-month > OK > ▶ 21/369 /GDateTime/printf > OK > ▶ 21/369 /GDateTime/non_utf8_printf > SKIP > ▶ 21/369 /GDateTime/format_unrepresentable > OK > ▶ 21/369 /GDateTime/format_iso8601 > OK > ▶ 21/369 /GDateTime/strftime > OK > 21/369 glib:glib+core+slow / gdatetime > ERROR
Bug#1060736: eric: Please remove python3-sip-dev from Build-Depends-Indep
Source: eric Version: 23.2+ds1-2 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. As eric uses PyQt6, it should not need python3-sip-dev for build. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060743: RFP: node-pug3-cli -- Pug 3 CLI with many fixes and improvements
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org, werdah...@riseup.net Control: block 1018865 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: node-pug3-cli Version : 3.0.1 Upstream Contact: Tokilabs * URL : https://github.com/tokilabs/pug3-cli * License : MIT Programming Lang: JS Description : Pug 3 CLI with many fixes and improvements pug3-cli is a maintained fork of the pug3 CLI which allows interfacing with Pug. This is needed as dependency for libredirect. best, werdahias -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWitWEVHHdlcmRhaGlh c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1oVoP/1/S/puO1RdIyGn3D8ZKfdVFbHR8 CXYRzzH8Y/K3Xm6jagSH9td6j+FPOcgJh88NzSvswBks53SSHe5preEy27aO7xUN jJckVQqj9btPSumGDg/QjWhiFCbs0Xl7TaUZ+bHfXZ9CY4iIPMrcWqW0uZDjIeoA Z2f1NjH2aREbje7wR2TwW+y7DkdkcB/Cc6qTnsjGixiLQz3jUU1Dg+84YKrNVSc3 oZX3p4RDC65hZnUgrhMLwx6te1DQDxlHlFJRmE0JHYFk4tRz00LnA7Lv/QgciYHG W1cmh0Q6wlKvC9OE1XfASWfK7v3JjDHh+FoXjcyPzQBO19Bhj7SbLqk3lYZmqWu9 FsvCBuOPfv41NF2Zql/BcYOGyg3s2MMWp7S7cYaSAg/SusONd9LVRJPOCY7xvZd4 Xci7LmDaJMmWBtEe0n9MiiCUaHST8uMLkmtnMOv/buT6PAID5CpL5S/7VIB0repY FiDSZlK+xnj61eeh/gztNoWK032Fdc489Ykg5CJ+UIFKIXp6TG2/I8JTcs3HtjiJ RA5OAtYffOyp6aMSwCT9NNwHkQT6gFXKjYLK1hZzTfDVijBbdp9JVilDXhI30XwT 8S+h3ZfYsZ7tQ+7O6Q6ufu78E7jlQi6OoidDIC56NoyASgfBmsZ6hVdYxqqk0gmW basn3YUdTSp9S5Dr =LIfJ -END PGP SIGNATURE-
Bug#1060757: ITP: libdata-find-perl -- Find data in arbitrary data structures
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libdata-find-perl Version : 0.03 Upstream Contact: Andy Armstrong * URL : https://github.com/AndyA/Data--Find * License : Perl Programming Lang: Perl Description : Find data in arbitrary data structures A simple module to navigate a Perl data structure with three exported subroutines (diter, dfind and dwith) and find data occurrences. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#788922:
Hi, On Wed, 28 Mar 2018 12:29:03 + (UTC) Jack Underwood wrote: > On Mon, 26 Jun 2017 16:03:56 +0200 Alex ARNAUD wrote: > > I believe you could hijack the package due to the very long delay. > > > This package has already been orphaned since 4 Mar 2017 see [1], do you still intend to adopt > this package Vincent Bernat? Please say yes :). > > Best, > Jack > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856736 > > If nobody is interested to adopt this packages and if this package has still interest to some people, I might plan to adopt it and will reply to #856736 if confirmed. New upstream version does not requires Skype, moreover API is not supported anymore and this plugin now only support Skype Web. Best regards, -- Patrick ZAJDA OpenPGP_0x9D4AD35BEA273DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Source: lomiri-ui-toolkit
Version: 1.3.5010+dfsg-3
Severity: important
Tags: ftbfs upstream
Dear Maintainer,
lomiri-ui-toolkit fails to build with Qt ≥ 5.15.11. Currently there is version
5.15.12 available in experimental, but I would like to upload it to unstable
soon.
The first error is:
ucstylehints.cpp: In member function ‘void
UCStyleHintsParser::verifyProperty(const
QQmlRefPointer&, const
QV4::CompiledData::Binding*)’:
ucstylehints.cpp:54:23: error: invalid use of non-static member function
‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
54 | if (binding->type == QV4::CompiledData::Binding::Type_Object) {
| ~~^~
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4executablecompilationunit_p.h:54,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcontext_p.h:69,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlproperty_p.h:60,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlbinding_p.h:59,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcustomparser_p.h:55,
from ucstylehints_p.h:25,
from ucstylehints.cpp:19:
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4compileddata_p.h:544:10:
note: declared here
544 | Type type() const { return Type(flagsAndType.get()); }
| ^~~~
This error is fixed by upstream pull request [1], however there is another
issue with tst_UCUnits::gridUnitEnvironmentVariable() test which is not yet
fixed upstream. Perhaps it can be disabled until upstream figures out what to
do with it.
[1]:
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/merge_requests/63
[2]: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?
Hi, Quoting Helmut Grohne (2024-01-12 21:58:00) > > What can cause mkfs.ext4 to fail with a "Permission denied" error? > I think this is our typical problem when dealing with user namespaces. I > guess that the thing that fails here is mkfs.ext4 opening the target image > file (to be formatted). That file has earlier been chowned to the root uid > inside the namespace, so permission should be there, but you need more. You > also need execute permission (to the first uid of your namespace) for the > containing directory up until the root. I guess that none of those are > world-executable and not by chanced owned by your first subuid nor owned by > the first group in your subgid range. I'm not yet convinced that this is it. The problem occurs for Francesco when using either /tmp or /dev/shm as a temporary directly. By default, those two locations should have the desired permission bits set. Lets check whether world-execute permissions are set for all directories up until root. I have this: $ stat -c "%a %n" / /dev /dev/shm /tmp 755 / 755 /dev 1777 /dev/shm 1777 /tmp Francesco, what are the world execute permissions on all path components up to /tmp and /devv/shm in your case? Arguably, mmdebstrap maybe should do this check at start-up. To have a real-world test-case for such a feature, I'm eager to see how Francesco's system looks like. Thanks! cheers, josch signature.asc Description: signature
Bug#1060762: oxigraph - upcoming rust-clap-lex update
Package: oxigraph
I am currently working on updating rust-clap, clap itself is not
semver breaking, but clap_lex is. The upstream changes seem
fairly minimal and I was able to build your package successfully
with the new version after adjusting the dependencies.
The new versions of clap_lex and clap have been uploaded to
experimental if you want to test further. I intend
to upload them to unstable in a week or so.
diff -Nru oxigraph-0.3.22/debian/changelog oxigraph-0.3.22/debian/changelog
--- oxigraph-0.3.22/debian/changelog2023-12-30 12:11:38.0 +
+++ oxigraph-0.3.22/debian/changelog2024-01-13 18:31:47.0 +
@@ -1,3 +1,10 @@
+oxigraph (0.3.22-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update for clap-lex 0.6
+
+ -- Peter Michael Green Sat, 13 Jan 2024 18:31:47 +
+
oxigraph (0.3.22-3) unstable; urgency=medium
* tighten resolving binary package versions
diff -Nru oxigraph-0.3.22/debian/control oxigraph-0.3.22/debian/control
--- oxigraph-0.3.22/debian/control 2023-12-30 11:29:47.0 +
+++ oxigraph-0.3.22/debian/control 2024-01-13 18:31:33.0 +
@@ -15,7 +15,7 @@
librust-cc-1+parallel-dev ,
librust-clap-4+default-dev ,
librust-clap-4+derive-dev ,
- librust-clap-lex-0.5+default-dev ,
+ librust-clap-lex-0.6+default-dev ,
librust-console-error-panic-hook-0.1+default-dev,
librust-criterion-0.5+default-dev ,
librust-digest-0.10+default-dev,
diff -Nru oxigraph-0.3.22/debian/patches/1001_clap.patch
oxigraph-0.3.22/debian/patches/1001_clap.patch
--- oxigraph-0.3.22/debian/patches/1001_clap.patch 2023-12-30
11:40:23.0 +
+++ oxigraph-0.3.22/debian/patches/1001_clap.patch 2024-01-13
18:31:11.0 +
@@ -1,6 +1,6 @@
Description: accept newer releases of crate clap and newer branches of crate
clap_lex
Author: Jonas Smedegaard
-Last-Update: 2023-12-02
+Last-Update: 2024-01-13 by Peter Michael Green.
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/server/Cargo.toml
@@ -12,7 +12,7 @@
-clap = { version = "=4.0", features = ["derive"] }
-clap_lex = "=0.3.0"
+clap = { version = "4", features = ["derive"] }
-+clap_lex = ">= 0.3, <= 0.5"
++clap_lex = ">= 0.3, <= 0.6"
oxigraph = { version = "0.3.22", path = "../lib", features = ["http_client"] }
sparesults = { version = "0.1.8", path = "../lib/sparesults", features =
["rdf-star"] }
rand = "0.8"
Bug#1060693: Accepted qt6-base 6.4.2+dfsg-21 (source) into unstable
Source: qt6-base Source-Version: 6.4.2+dfsg-21 On Sat, Jan 13, 2024 at 02:37:52PM +, Debian FTP Masters wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Sat, 13 Jan 2024 14:53:25 +0100 > Source: qt6-base > Architecture: source > Version: 6.4.2+dfsg-21 > Distribution: unstable > Urgency: medium > Maintainer: Debian Qt/KDE Maintainers > Changed-By: Patrick Franz > Changes: > qt6-base (6.4.2+dfsg-21) unstable; urgency=medium > . >[ Patrick Franz ] >* Add patch to fix CVE-2023-51714. > Checksums-Sha1: > 0b79f91facc70ff2c8372b5c8cdc04a11b75032f 5074 qt6-base_6.4.2+dfsg-21.dsc > ae643df52b95dde7b50df35170f22cc88c0f98dc 191336 > qt6-base_6.4.2+dfsg-21.debian.tar.xz > 3ff1fbc0f52abf5df663850fb861019b0c07ae98 9914 > qt6-base_6.4.2+dfsg-21_source.buildinfo > Checksums-Sha256: > 8b157fff163ce358b7bef601b34f76fc9c8355e3e2d2f9b775c1ede14c394d30 5074 > qt6-base_6.4.2+dfsg-21.dsc > 488f844e6401f7abbbec9c441ab14a6d5551884575334035c159ca2525b60bee 191336 > qt6-base_6.4.2+dfsg-21.debian.tar.xz > 0ce2b7615e075ae1a2ab2185a34a30692189341c6202a188ca8bce8536b5c4aa 9914 > qt6-base_6.4.2+dfsg-21_source.buildinfo > Files: > ad899a600ed30c68847c4fb2c13f5d5c 5074 libs optional > qt6-base_6.4.2+dfsg-21.dsc > 03c4f298d4059de4fb7ec27ffa1070fa 191336 libs optional > qt6-base_6.4.2+dfsg-21.debian.tar.xz > 21d86d79bf7e33fda531d318d5d0483d 9914 libs optional > qt6-base_6.4.2+dfsg-21_source.buildinfo > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEYodBXDR68cxZHu3Knp96YDB3/lYFAmWimg4ACgkQnp96YDB3 > /lYf1hAAmd946X+IWG72//eJxbvO+HTMMm1mz5xzkQ2OCPhd6x5QGlV8EA0FkqEF > HLwYhoKcFdhHzmlq4jlcC7IGWY7hLWrBZdEKGaiIQ1Y9b2tqICw/FO4KNoFDR467 > bonRIIM9+g8oxq1fPAfiY+j2Rc8609W6SvMQPT1dRslQtYRf9W72V6e61VGXapy7 > /POAqt1cYh1U8GYTszzffQqkcmGTGbBG/bj9JjsAL6BJ4wCOVaymDg6qWMaijw1P > oOaFWjJ0wh16fQuOK2H63P9nI5jkH2EDbYfmFzY98U4sqB1fLdpCr3P0mTN2bz5U > 4WBmnxFqGq067zg9y8qaiZV/Is2gd6jzyxSkv/fz54sJAxnieY4RNTvZPGDpOv3Y > rHP+Z+txeNIh0DIT4RSq28M4vEpnCogh426a6cV9iWflzN2VR36WNVl5W6HCGBQf > Owf04xPxRniqajmwIktZEELLIgCf+N9nKRhUNapRgwFMl4mPsSWGaI4iDHRiWI/H > 8NNlEKtsuYBYOJNTq6wW/lHgqh39rkbEjwdUJjR7fCY1KV4lEd9MzDeERUU/vVZ5 > WwU/fYkjlueJZBRCFU8U6ARbnv1xuB0TOwV2R/OcHvdGtZJtwo7JT8X/2YfhjeFv > 3BED/PE4+biaDK6V6aWv29kYF9sp2L2YM6mqBdl9A0i5yYMckW0= > =j512 > -END PGP SIGNATURE- >
Bug#1060765: libapreq2-3: Apache2::Upload v2.17 clobbering remaining CGI parameters
Package: libapreq2-3
Version: 2.17-3~bpo12+1
Severity: important
X-Debbugs-Cc: randolf+deb...@richardson.tw
Has anyone else encountered this problem? If so, did you find a
solution? (If so, what got it working for you?)
Dear Maintainer,
I just recently upgraded my systems to Debian 12, and along with it
came modperl_2.17. Overall, this release is working very well,
except for one thing...
Handling CGI parameters in HTML forms that support file attachments,
which results all CGI parameters after the file (whether a user
attaches a file or not makes no difference) are missing.
For any HTML input fields that I move before the file attachment
input element, then then their CGI parameters come through, while all
CGI parameters after the first file input field remain missing.
Any HTML forms that don't have any file input fiels are working
correctly.
Text:
File:
More:
In my handling code, using $R->param('one') always functions as
expected, but $R->param('more') returns undef.
The solution was to download the source code for APREQ2 v2.18, and
compile and install it. This resolved the problem.
If the libapreq2-3 package was to be upgraded from v2.17 to v2.18,
this would resolve this problem for everyone who relies on this
package, particularly when they use any code that processes file
uploads from web site users, or introduces new code that processes
file uploads.
Thanks!
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libapreq2-3 depends on:
ii libapr1 1.7.2-3
ii libaprutil1 1.6.3-1
ii libc62.36-9+deb12u3
Versions of packages libapreq2-3 recommends:
ii libapache2-mod-apreq2 2.17-3~bpo12+1
libapreq2-3 suggests no packages.
-- no debconf information
Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64
Hello First, sorry for the latency. I tried to upload it but two tests are failing. Does it ring a bell ? (they are regressions from the patch) Error: test_diff(SourceFileTest): NoMethodError: undefined method `language' for nil:NilClass assert_equal "shell", deltas.first.language ^ /build/ohcount-4.0.0/test/unit/ruby/source_file_test.rb:12:in `test_diff' 9: assert_equal optimer, new.contents 10: deltas = old.diff(new).loc_deltas 11: assert_not_nil deltas => 12: assert_equal "shell", deltas.first.language 13: end 14: 15: def test_empty_diff E Error: test_empty_diff(SourceFileTest): NoMethodError: undefined method `language' for nil:NilClass assert_equal "perl", deltas.first.language ^ /build/ohcount-4.0.0/test/unit/ruby/source_file_test.rb:23:in `test_empty_diff' 20: assert_equal c, new.contents 21: deltas = old.diff(new).loc_deltas 22: assert_not_nil deltas => 23: assert_equal "perl", deltas.first.language 24: end 25: end . Thanks Sylvestre
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
On Sat, 13 Jan 2024 22:04:20 +, Jeremy Sowden wrote: > > This package fails its autopkgtest checks with Perl 5.38 > > (currently in unstable.) > I've pushed a fix to Salsa: > > https://salsa.debian.org/emacsen-team/dh-make-elpa/-/commit/b6840bdc3b2a02ca07a2a601deff2a3947001368 Great! (And congratulations on finding out what this smartmatch operation was supposed to do, which I didn't manage :)) In case you have troubles finding someone from the team to upload, please shout, I'm happy to help. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1060753: exiftags: CVE-2023-50671
Source: exiftags Version: 1.01-7 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi Laszlo, The following vulnerability was published for exiftags. CVE-2023-50671[0]: | In exiftags 1.01, nikon_prop1 in nikon.c has a heap-based buffer | overflow (write of size 28) because snprintf can write to an | unexpected address. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-50671 https://www.cve.org/CVERecord?id=CVE-2023-50671 [1] https://blog.yulun.ac.cn/posts/2023/fuzzing-exiftags/ Regards, Salvatore
Bug#1014058: Closed as duplicate by error
Control: reopen 1014058 Control: retitle 1014058 exim4-daemon-heavy: please compile with DMARC support On 2023-03-23 Jämes Ménétrey wrote: > Dear Marc, > I am reaching out to you back regarding the wishlist item that was > mistakenly flagged as a duplicate and subsequently closed. > Indeed, this bug, which requested SPF and DMARC support for Debian > packages, has been erroneously identified as a duplicate of itself. > I kindly request that you consider reopening this matter. reopening. SPF is already included, retitling. Regarding linking against OpenDMARC: That is unlikely to happen. libopendmarc has a history (https://bugs.exim.org/show_bug.cgi?id=2783 https://bugs.exim.org/show_bug.cgi?id=2728) of breaking its ABI and seems to be dead upstream, too (Last commit two years ago). cu Andreas
Bug#1036824: po4a: Describe how to create/maintain pot file from man page
Hello Martin, Am Fri, Jan 05, 2024 at 05:32:37PM +0100 schrieb Martin Quinson: > I just revamped the po4a(7) documentation to better explain the workflow using > po4a only, without po4a-translate and po4a-updatepo. The result is unreleased > for now, but already viewable here: > https://github.com/mquinson/po4a/blob/master/doc/po4a.7.pod#using-po4a > > This text refers to the documentation of po4a(1) itself, available from: > https://po4a.org/man/man1/po4a.1.php > > In particular, I added a paragraph about the deprecation of the individual > scripts that you may find useful: > https://github.com/mquinson/po4a/blob/master/doc/po4a.7.pod#why-are-the-individual-scripts-deprecated > > I think that this closes the current bug (once the fix is integrated to > Debian). Please comment if you think otherwise. > > Thanks for your feedback and support, Thanks for the update. Based on what is in git now (I just updated the German translation) this is now described quite well for the standard package. And yes, so this bug can be closed when 0.70 (?) hits unstable. Not related to this bug, but the basis for my bug report: The workflow using po4a is appears quite orthogonal to manpage-l10n needs. I could roughty conceive how (parts of) such an implemenation could look like. So if 2030 comes closer and the depreciation is not lifted, I might need to work this out and hope that it both works and the runtime is not too bad. Greetings and thanks for maintaining po4a Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
Hi Diederik, Am 13.01.2024 um 17:13 schrieb Diederik de Haas: ... Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy access to previous (6.1) kernels uploaded to Debian with which you can check if the problem was present in early 6.1 kernels. The oldest record of this issue has happened with Linux version 6.1.0-11-amd64 As I usually keep this box updated, and the problems happens only randomly, I think the best way forward might be to try with a kernel that did *not* show this problem. Does that look reasonable? So, I have: # journalctl --grep PCIe\ link\ lost -- Boot 86e1a04baba04a409c34796c0fb079ff -- Sep 20 14:21:17 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot da6a00d9278a422686ca46d80e2f3ca6 -- -- Boot 28fcdfe079c446c6b184bb5b6407da73 -- Okt 06 05:44:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached Okt 07 16:39:10 Zwerg kernel: igc :0a:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached -- Boot 51e3605887764b60b6d0130d4f6356c0 -- -- Boot ce944a4bbffc45b38c1357d3e822cd46 -- Okt 23 18:31:25 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot e6d80407cab74d0b9e28b74642b544c0 -- Okt 30 11:16:06 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached Okt 31 13:50:06 Zwerg kernel: igc :0a:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached -- Boot 452f25ce23fe4d569490fbc42683ecd6 -- Nov 22 18:59:11 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot f1add031e2fa495aba569ab9c374ce65 -- Nov 23 15:45:49 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot f766dabb981e4aa49f0922d7794dea76 -- -- Boot 6d7c91a86ab44da1973f5ca716dad105 -- -- Boot 3ba3df042e0648a1aebfa4fcea5499bf -- Dez 19 07:33:02 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot a4aea30bb33747e7853abec194a2a395 -- Jan 01 09:57:40 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot 377a326561dc4909b45c55cffcd1a94d -- Jan 10 16:15:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot 50c5a6a9cc34496984fe3cde6ba8b72a -- Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now detached -- Boot a3c69838cab4426992a2f518a72a5e2b -- So I conclude I should look at something earlier than what was used with boot 86e1a04baba04a409c34796c0fb079ff, i.e. journalctl --boot 86e1a04baba04a409c34796c0fb079ff | head -n 1 Aug 30 18:16:18 Zwerg kernel: Linux version 6.1.0-11-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) correct? Via the page you reference, I find a kernel package linux-image-6.1.0-1-amd64 6.1.4-1 which might be worth a try. I'll need some time to sort out how to install such a package... Thanks for your suggestion, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Bug#1060763: Package "linux-headers-6.6.9-amd64" on sid depends on non-existing version of "linux-image-6.6.9-amd64"
Package: linux-headers-6.6.9-amd64 Version: 6.6.9-1+b1 Package "linux-headers-6.6.9-amd64" on sid has the following dependencies: > Depends: linux-headers-6.6.9-common (= 6.6.9-1), linux-image-6.6.9-amd64 (= > 6.6.9-1+b1) | linux-image-6.6.9-amd64-unsigned (= 6.6.9-1+b1), > linux-kbuild-6.6.9, gcc-13 However, the package "linux-image-6.6.9-amd64" has only version "6.6.9-1" available, not "6.6.9-1+b1": > Package: linux-image-6.6.9-amd64 > Version: 6.6.9-1 This leads to the headers currently being uninstallable for 6.6.9 (signed). The headers can be installed together with the unsigned version, because that has the "b1" version available. The changelog for "linux-headers-6.6.9-amd64" does not list this "b1" version.
Bug#1060764: gulkan FTCBFS: passes host compiler flags to the build architecture compiler
Source: gulkan Version: 0.15.1-2.1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs gulkan fails to cross build from source, because it passes host compiler flags to the build architecture compiler. For instance cross building on amd64 for arm64 passes -mbranch-protection=standard and the amd64 gcc doesn't like that. This is due to a recent change in dpkg's default build flags. Looking closer this happens during the documentation build, not while building the library. This build pass is only required for the -doc package, so rather than fixing this, I suggest excluding this build pass from an arch-only build (and cross builds always are arch-only). Using reproducible builds, I verified that this change does not affect package contents (compared a native full build to a native arch-only build) and yes, this fixes the cross build. I note that this also speeds up building on buildds, so that's a nice side effect. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru gulkan-0.15.1/debian/changelog gulkan-0.15.1/debian/changelog --- gulkan-0.15.1/debian/changelog 2022-01-06 13:39:04.0 +0100 +++ gulkan-0.15.1/debian/changelog 2024-01-13 10:35:25.0 +0100 @@ -1,3 +1,10 @@ +gulkan (0.15.1-2.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Properly split documentation build. (Closes: #-1) + + -- Helmut Grohne Sat, 13 Jan 2024 10:35:25 +0100 + gulkan (0.15.1-2.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru gulkan-0.15.1/debian/rules gulkan-0.15.1/debian/rules --- gulkan-0.15.1/debian/rules 2020-07-18 02:04:33.0 +0200 +++ gulkan-0.15.1/debian/rules 2024-01-13 10:35:23.0 +0100 @@ -6,8 +6,7 @@ override_dh_auto_test: # Skip test due to required a vulkan driver or it failures. -override_dh_auto_build: - dh_auto_build +override_dh_auto_build-indep: meson build -Dapi_doc=true ninja -C build gulkan-doc
Bug#238687: popularity-contest: popularity contest should provide subarch info.
It's been quite a while since this bug was discussed, but I have another use case where it might be interesting... There has been some recent discussion about "Architecture Variants" and in particular amd64 variants. Fedora and Ubuntu are both working on experiments with the goal of being able to optimize for newer versions of the amd64 architecture (and potentially dropping older variants at some point as well). Here is a page that gathers info on this idea for Debian https://wiki.debian.org/ArchitectureVariants Knowing information about which variants our installed base is using would help make these decisions easier. The past i386 decisions were a little easier because there were particular packages we could look at to get those numbers. Side note In addition to this bug, it seems there are some other cases where people would like to press popcon into service to gather other things: kernel modules https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202675 report arch only https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545000 report foreign architectures https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931764 Package versions https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97045 aptitude auto flag https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313194 package config file data https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816281 We can understand why it is tempting to want to do so. But there are also privacy and scope implications. So maybe the first step is a clear policy of what is appropriate for popcon to do, and the things that aren't should be WONTFIX. Thanks, -- Matt Taggart m...@lackof.org
Bug#1060768: pdudaemon: Missing dependency on python3-aiohttp
Package: pdudaemon
Version: 0.0.8.58.g597052b-1
Severity: serious
Attempting to use pdudaemon without python3-aiohttp installed results in
a traceback:
# pdudaemon
Traceback (most recent call last):
File "/usr/sbin/pdudaemon", line 33, in
sys.exit(load_entry_point('pdudaemon==0.1', 'console_scripts',
'pdudaemon')())
^^
File "/usr/sbin/pdudaemon", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/pdudaemon/__init__.py", line 32, in
from pdudaemon.httplistener import HTTPListener
File "/usr/lib/python3/dist-packages/pdudaemon/httplistener.py", line 24, in
from aiohttp import web
ModuleNotFoundError: No module named 'aiohttp'
but there is no dependency declared in the package. Installing the
python3-aiohttp resolves this issue.
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pdudaemon depends on:
ii python3 3.11.2-1+b1
pn python3-hid
pn python3-paramiko
ii python3-pexpect 4.8.0-4
ii python3-pyasn10.4.8-3
ii python3-pysnmp4 4.4.12-2
ii python3-requests 2.28.1+dfsg-1
ii python3-serial3.5-1.1
pn python3-systemd
pn python3-usb
Versions of packages pdudaemon recommends:
ii inetutils-telnet [telnet] 2:2.4-2
ii openssh-client 1:9.2p1-2
pdudaemon suggests no packages.
Bug#1060181: Please consider supporting configuration via both /usr/share/apt/verify.d and /etc/apt/verify.d
On Mon, 08 Jan 2024 10:30:02 +0100 Simon Josefsson wrote: > Josh Triplett writes: > > Many tools that use .d configuration directories support multiple such > > directories, to make it easy to separate local sysadmin configuration > > from distribution configuration. For instance, a hypothetical > > apt-verify-myplugin package could install > > /usr/share/apt/verify.d/50myplugin so that it automatically works when > > installed, and then the sysadmin could change that with > > /etc/apt/verify.d/50myplugin . One of several advantages of this is that > > a sysadmin can, themselves, *package* their configuration very easily, > > without having to divert files or similar. > > Thanks for feedback -- this makes sense, and I've opened an upstream bug > about it: > > https://gitlab.com/debdistutils/apt-verify/-/issues/6 > > What do you think about processing identically named scripts in both > paths vs only the /etc/ script? Replied there: Having identically named files in /etc override the ones in /usr/share is exactly what I had in mind; I should have been more explicit about that. > > (Also, in the process of this, you might consider refusing to run if no > > configuration exists, to avoid effectively disabling verification. If a > > user really wants to *disable* verification they should use the apt > > configuration for *that* rather than installing apt-verify as a hook and > > then giving apt-verify nothing to do.) > > There is no way verification can be disabled -- apt will yell. Or can > you explain more what you mean? Just dug into apt-verify's documentation more, and realized that apt is checking gpgv output rather than exit code, so this isn't actually a concern. Nevermind then. If, at some point in the future, apt adds a verification mechanism that uses exit codes rather than the output of GPG, then it'd be important to make sure that an empty .d directory or one where all the scripts have been masked by empty ones (or symlinks to /dev/null) in /etc causes a failure.
Bug#1060740: regripper: autopkgtest failure with Perl 5.38: changed diagnostics
Package: regripper Version: 3.0~git20221205.d588019+dfsg-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) https://ci.debian.net/packages/r/regripper/testing/amd64/41787955/ 27s autopkgtest [07:40:54]: test listplugins: [--- 28s autopkgtest [07:40:55]: test listplugins: ---] 28s autopkgtest [07:40:55]: test listplugins: - - - - - - - - - - results - - - - - - - - - - 28s listplugins FAIL non-zero exit status 1 This is unfortunately terse, but looking into it, it boils down to a changed diagnostic when calling require() on a plugin with a syntax error: trixie# perl -E 'say $^V; eval "require q(/usr/lib/regripper/plugins/clsid_tln.pl)"; die $@' v5.36.0 syntax error at /usr/lib/regripper/plugins/clsid_tln.pl line 112, near "$scriptlet)" Compilation failed in require at (eval 1) line 1. vs. sid# perl -E 'say $^V; eval "require q(/usr/lib/regripper/plugins/clsid_tln.pl)"; die $@' v5.38.2 syntax error at /usr/lib/regripper/plugins/clsid_tln.pl line 112, near "$scriptlet)" Execution of /usr/lib/regripper/plugins/clsid_tln.pl aborted due to compilation errors. Compilation failed in require at (eval 1) line 1. Presumably the best fix is to correct the (longstanding) syntax error in the plugin. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060052: looks good: patched kernel doesn't Oops
Hi, On Sat, Jan 13, 2024 at 10:38:43AM +0100, Salvatore Bonaccorso wrote: > > […] > > If someone additionally might or want to test testbuilds please have a > look at: > > https://people.debian.org/~carnil/tmp/linux/1060005/ > > The builds are signed with my key in the Debian keyring. I can confirm that the provided kernel does not show the Oops in our setup. Many thanks and best regards, Andi
Bug#1060750: pgzero: update d/watch file and new upstream version 1.2.1
Source: pgzero Version: 1.2.post4+dfsg-2 Severity: wishlist Dear Maintainer, Here is a patch attached. As it is, it will catch 1.2.post5 (October, 18th 2018) and not the more recent 1.2.1 version (March, 3rd 2021) because uscan sorting is biased by those postX: uscan info: Found the following matching hrefs on the web page (newest first): https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post5.tar.gz (1.2.post5) index=1.2.post5-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post5.tar.gz (1.2.post5) index=1.2.post5-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post4.tar.gz (1.2.post4) index=1.2.post4-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post4.tar.gz (1.2.post4) index=1.2.post4-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post3.tar.gz (1.2.post3) index=1.2.post3-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post3.tar.gz (1.2.post3) index=1.2.post3-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post2.tar.gz (1.2.post2) index=1.2.post2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post2.tar.gz (1.2.post2) index=1.2.post2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post1.tar.gz (1.2.post1) index=1.2.post1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.post1.tar.gz (1.2.post1) index=1.2.post1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.1.tar.gz (1.2.1) index=1.2.1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.1.tar.gz (1.2.1) index=1.2.1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.tar.gz (1.2) index=1.2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.2.tar.gz (1.2) index=1.2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.1.tar.gz (1.1) index=1.1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.1.tar.gz (1.1) index=1.1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.0.2.tar.gz (1.0.2) index=1.0.2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.0.2.tar.gz (1.0.2) index=1.0.2-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.0.1.tar.gz (1.0.1) index=1.0.1-1 https://github.com/lordmauve/pgzero/archive/refs/tags/1.0.1.tar.gz (1.0.1) index=1.0.1-1 May be this could be forced? Or the d/watch regex changed? Don't know what the best to do facing that. Regards, Patrice -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059648: sip4: autopkgtest failure with Python 3.12
On Sun, Jan 07, 2024 at 06:34:24PM +0300, Dmitry Shachnev wrote: > krita and pyqwt3d have open bugs to move to sip6, but I will need to file > bugs for the other packages too. All the missing bugs are filed now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=mity...@debian.org;tag=sip6 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060752: u-boot-sunxi: Reboot failing on Olimex A20-Olinuxino Micro (patch available)
Package: u-boot-sunxi Version: 2023.01+dfsg-3ubuntu0~rzr0+jammy01 Severity: wishlist Dear Maintainer, Using latest debian-12, on Olimex A20 I noticed that system get stuck on reboot, (it was also a problem on other similar products some were fixed) I think I've found a solution, which I am trying to upstream, track progress at: https://github.com/rzr/u-boot/issues/2 Until it gets merged, I plan to integrate a patch to debian, to replace my custom built version of u-boot. More to come soon at: https://salsa.debian.org/debian/u-boot/-/merge_requests?scope=all=all_username=rzr Regards -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 6.1.0-17-armmp-lpae (SMP w/2 CPU threads) Kernel taint flags: TAINT_CRAP 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 -- no debconf information
Bug#1060754: shiro: CVE-2023-46749
Source: shiro Version: 1.3.2-5 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for shiro. CVE-2023-46749[0]: | path traversal attack If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-46749 https://www.cve.org/CVERecord?id=CVE-2023-46749 [1] https://www.openwall.com/lists/oss-security/2024/01/12/2 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#808074: RFA: fbreader -- e-book reader
On 2015-12-15 "Eugene V. Lyubimkin" wrote: > Package: wnpp > Severity: normal > Hello, > I request an adopter for the fbreader package, since I don't use it > actively anymore. [...] fbreader upstream has switched their business/mainainance model ages ago, it not free software, not even open source anymore. cu Andreas
Bug#1060755: calibre: Cant execute calibre. Error: cannot import name QNetworkProxyFactory from qt.core
I think I found the source of the problem here, I removed the libQt* libraries from usr/local/lib and calibre started working again. I think this is because I was studying Qt and Cmake and made an cmake --install and didnt notice it, so this had an effect on calibre. Thank you for all your help and sorry it was my fault. -- Gabriel B Chuede
Bug#1060771: ITP: python-pyproject-examples -- example pyproject.toml configs for testing
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-pyproject-examples Version : 2023.6.30 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/repo-helper/pyproject-examples * License : MIT/expat Programming Lang: Python Description : example pyproject.toml configs for testing pyproject-examples was developed with the aim of being used by developers who want to manually test their pyproject.toml configurations. The module serves as a test suite for pyproject.toml analysis tools. . Key Features: - Examples of valid and invalid settings: Provides a series of example files that adhere to the PEP 621 and PEP 517 specifications. Containing example files that demonstrate common configuration errors. - API to access examples: It has functions to retrieve example configurations as strings. - Utilities Module: It has helper functions for creating regular expressions and testing for file not found errors. Nota: module necessary to enable testing of the "whey" package ITP: #1021204
Bug#1060772: python3-jupyterlab: Using node-corepack downloads yarnpkg from Internet
Package: python3-jupyterlab Version: 4.0.9+ds1-1 Severity: important X-Debbugs-Cc: y...@debian.org Hi, the patch 0003-Use-system-provided-yarn.js.patch replaces missing yarn.js by node-corepack. Please keep in mind that node-corepack/../yarn.js is a wrapper that downloads yarnpkg from Internet instead of using Debian's one. Cheers, Yadd
Bug#964126: fixed in krita 1:5.2.2+dfsg-2
On Sat, Jan 13, 2024 at 01:36:54PM +, Debian FTP Masters wrote: > Source: krita > Source-Version: 1:5.2.2+dfsg-2 > Done: Pino Toscano > > We believe that the bug you reported is fixed in the latest version of > krita, which is due to be installed in the Debian FTP archive. > [...] That was fast! Appreciated. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#857003: ncurses: Build x32 packages
X-Debbugs-CC: d...@debian.org On Sat, 10 Feb 2018 13:25:57 +0100 Sven Joachim wrote: > Control: tags -1 = wontfix > > On 2017-03-06 23:38 -0300, Tiago Daitx wrote: > > > On Mon, Mar 6, 2017 at 11:30 PM, Adam Borowski wrote: > >>> Please consider applying the attached patch to add x32 packages to > >>> ncurses. This patch has been a part of Ubuntu since late 2012 [1]. > >> > >> ncurses work fine on x32, natively and/or via multiarch. Is there a real > >> reason to add multi_lib_ packages? > > > > Sorry, I forgot to add an extra comment about this particular patch. > > > > I'm simply trying to reduce the diff between Ubuntu and Debian and > > these patches have been carried on for a long while and these extra > > pieces cause constant merge failures on the Ubuntu side. > > > > In the case of x32 I'm really not sure if the patches are still > > required, they have been added long ago. I'm actually interested in > > your point of view as a maintainer - and this is the part I forgot to > > ask you about: do you believe the x32 patches add any value to the > > package nowadays? They seem to be no longer required. > > I guess this boils down to the question to what extent Canonical/Ubuntu > want to support x32. Unlike Debian, they don't have an x32 port but > instead added libx32 multilib packages for the most popular libraries > (zlib, ncurses, readline). Although this effort seems to have mostly > stopped for now, since there is no libx32readline7 package while there > used to be libx32readline6 in trusty and xenial. > > From my POV these packages are a huge maintenance burden for very > little gain, and I am neither willing nor able to support them. From what I read from https://launchpad.net/ubuntu/+source/ncurses , currently Ubuntu is no longer carrying patches for src:ncurses after 2022. Obviously this bug report ( https://bugs.debian.org/857003 ) is no longer useful. Probably it's time to close it? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable
Hi Salvatore, Am 13.01.2024 um 13:47 schrieb Salvatore Bonaccorso: Just to be clear, can you confirm this is or is not a regression from a previous running 6.1.y kernel? On this hardware, the network issues appeared right from the start. First time I encountered it was with the Debian installation sime time last year, and that's where my research led me to turn off PCIe power management. Actually I don't even know which was the first kernel version I had on this host, but it's been on Bookworm for all its lifetime. I'm asking because I suspect that this similar to https://lore.kernel.org/intel-wired-lan/20221031170535.77be0...@kernel.org/ and did not ever worked reliably with your hardware? The symptoms sound quite different to me. But I can't claim to know anything interesting about the different functionalities of PCIe or the Linux way to use them... Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Bug#1060759: resource-agents: autopkgtest failure: MailTo hanging
Package: resource-agents Version: 1:4.13.0-1 Hi, the perl_5.38.2-3 migration checks for resource-agents are currently failing on ci.debian.net. https://ci.debian.net/data/autopkgtest/testing/amd64/r/resource-agents/41787962/log.gz 250s Running: ocft test -v MailTo 250s Starting '[33mMailTo[0m' case 0 '[33mcheck base env[0m': 250s Setting agent environment:export OCF_RESKEY_email=root@localhost 251s Running agent:./MailTo start 274s ERROR: The agent was hanging, killed it, maybe you damaged the agent or system's environment, see details below: 274s (No further details are provided AFAICS.) I cannot reproduce this, but I *think* what happens is that autopkgtest is choosing sendmail over exim4 when mixing packages from testing and unstable, and sendmail tries to connect to localhost:25 and hangs due to firewall settings. This is a guess based on my tests in a chroot where the mails ended up in /var/mail with exim4 but actually got sent to the root alias of the underlying host with sendmail. Not sure what to do about this. Perhaps make the test depend on exim4 or something even simpler that can be relied to deliver locally? Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1060760: python-s3transfer: please update to 0.10.0
Source: python-s3transfer Severity: wishlist Newer versions of python-boto3 will require python-s3transfer >= 0.10.0, so in order to unblock those I'd like to request that python-s3transfer be updated soon. I'm happy to perform the upload myself with the maintainer's acknowledgement. Thank you! noah -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 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
Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Control: user -1 debian-...@lists.debian.org Control: usertag -1 + 32bit-stackclash Hi, On Fri, Jan 05, 2024 at 11:45:28PM +0100, Sebastian Ramacher wrote: > /tmp/ccm0eYhx.s: Assembler messages: > /tmp/ccm0eYhx.s:537: Error: bad immediate value for offset (4100) This is caused by stack-clash-protection on armel and a workaround is in version 3.6.8-3 currently in experimental, see: https://tracker.debian.org/news/1494233/accepted-dcmtk-368-3-source-into-experimental/ We should downgrade the severity to minor once the fix enters unstable, but keep the bug open as this seems to be an interesting case of stack-clash-protection malfunctioning on 32bit arm to further look into. Thanks, Emanuele
Bug#1060746: Wrong text for resource tab
I found the similar issue on upstream repo (https://github.com/mate-desktop/mate-system-monitor/issues/257), so I've opened another one (https://github.com/mate-desktop/mate-system-monitor/issues/258) since it looks like it doesn't depend on the packaging itself. Regards, Sergio
Bug#1060767: bookworm-pu: package proftpd-mod-proxy/0.9.2-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: proftpd-mod-pr...@packages.debian.org Control: affects -1 + src:proftpd-mod-proxy [ Reason ] The version currently in Debian stable suffers from the CVE-2023-48795 (Terrapin attack) security issue. [ Impact ] Proftp further suffers from the described security issues. [ Tests ] The current change is directly copied from the upstream git repo. They have a test suite for that package, it is not yet activated in Debian. [ 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 ] Patch for CVE-2023-48795 (copied from upstream's repo) [ Other info ] The debdiff is available here: https://release.debian.org/proposed-updates/bookworm_diffs/proftpd-mod-proxy_0.9.2-1+deb12u1.debdiff signature.asc Description: PGP signature
Bug#1060755: calibre: Cant execute calibre. Error: cannot import name QNetworkProxyFactory from qt.core
Hello, Gabriel Sorry, I can't reproduce this error on my Sid (unstable) machine even I installs Krita. > opening from terminal gives the following log error: Failed to import PyQt module: PyQt6.QtNetwork with error: /lib/x86_64-linux-gnu/libQt6Network.so.6: undefined symbol: _Z12qt_safe_pollP6pollfdmPK8timespec, version Qt_6 It seems PyQt6 fails to load libQt6Network.so.6 because it fails to find "_Z12qt_safe_pollP6pollfdmPK8timespec" symbol. Symbol "_Z12qt_safe_pollP6pollfdmPK8timespec" (version Qt_6) is defined in /lib/x86_64-linux-gnu/libQt6Core.so.6 , so something is wrong in libQt6Core.so.6 . And libQt6Core.so.6 is in "libqt6core6" package. Please try to re-install those libraries to recover this error. You can re-install "libqt6core6" and "libqt6network6" packages with this command. > sudo apt reinstall libqt6core6 libqt6network6 -- YOKOTA
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
On 2024-01-13, at 13:12:20 +0200, Niko Tyni wrote: > Package: dh-make-elpa > Version: 0.19.2 > Severity: serious > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > > This package fails its autopkgtest checks with Perl 5.38 > (currently in unstable.) > > autopkgtest [11:06:58]: test test-dh-make-elpa: ---] > autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - > results - - - - - - - - - - > test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at > /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. > autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - stderr > - - - - - - - - - - > Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm > line 99. > autopkgtest [11:06:58]: summary > test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at > /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. I've pushed a fix to Salsa: https://salsa.debian.org/emacsen-team/dh-make-elpa/-/commit/b6840bdc3b2a02ca07a2a601deff2a3947001368 J. signature.asc Description: PGP signature
Bug#1039607: libjansi-java: causes maven to always output escape character
On Wed, Jan 10, 2024 at 10:13:38AM +0100, Clemens Ballarin wrote: > Am 08.01.2024 um 07:03 schrieb tony mancill: > > > I am preparing an upload of maven to experimental (version 3.8.7-2~exp1) > > that implements the changes described above. I will push the packaging > > changes to the debian/experimental branch in the Salsa repo. The patch > > for mvn can be found here: > > > > [...] > > > > I believe this will address the issues reported in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039607 and > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 > > > > Feedback welcome. We can coordinate here before any migrations from > > experimental to unstable. > > Thank you for the fix. To test we created a chroot environment with the > following upgrades: > > apt install libjansi-java/experimental > apt install maven/experimental libmaven3-core-java/experimental > libcommons-cli-java/unstable libcommons-lang3-java/unstable > > The issue reported in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 as well as our > original issue are resolved. Thank you for your testing. Are there any concerns before I upload maven and jansi to unstable? We can always revisit the changes if we discover any issues. signature.asc Description: PGP signature
Bug#1060773: CVE-2022-22995: afpd daemon vulnerable to symlink redirection
Package: netatalk Version: 3.1.12~ds-8+deb11u1 Severity: normal Tags: security X-Debbugs-Cc: t...@security.debian.org, pkg-netatalk-de...@alioth-lists.debian.net, Debian Security Team This is for tracking the fix for security vulnerability CVE-2022-22995 in Debian Oldstable (Bullseye) Upstream advisory at: https://netatalk.sourceforge.io/CVE-2022-22995.php Note that this has already been patched in oldoldstable (by the security team) and in unstable (by the package maintainers.) -- System Information: Debian Release: 11.7 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages netatalk depends on: ii init-system-helpers 1.60 ii libacl1 2.2.53-10 ii libavahi-client3 0.8-5+deb11u2 ii libavahi-common3 0.8-5+deb11u2 ii libc62.31-13+deb11u6 ii libcrack22.9.6-3.4 ii libcrypt11:4.4.18-4 ii libdb5.3 5.3.28+dfsg1-0.8 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libgcrypt20 1.8.7-6 ii libglib2.0-0 2.66.8-1 ii libgssapi-krb5-2 1.18.3-6+deb11u3 ii libkrb5-31.18.3-6+deb11u3 ii libldap-2.4-22.4.57+dfsg-3+deb11u1 ii libmariadb3 1:10.5.19-0+deb11u2 ii libpam-modules 1.4.0-9+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.11.1.1n-0+deb11u4 ii libtalloc2 2.3.1-2+b1 ii libtdb1 1.4.3-1+b1 ii libtracker-sparql-2.0-0 2.3.6-2 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii netbase 6.3 ii perl 5.32.1-4+deb11u2 Versions of packages netatalk recommends: ii avahi-daemon 0.8-5+deb11u2 ii cracklib-runtime 2.9.6-3.4 ii dbus 1.12.24-0+deb11u1 ii lsof 4.93.2+dfsg-1.1 ii procps2:3.3.17-5 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii tracker 2.3.6-2 Versions of packages netatalk suggests: pn quota -- no debconf information
Bug#1060745: openstructure: Please remove sip-dev from Build-Depends
Source: openstructure Version: 2.5.0-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. It looks like openstructure already uses SIP 6, so the left-over build- dependency on sip-dev can be dropped. I tried building without it, and the build succeeded. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060746: Wrong text for resource tab
Package: mate-system-monitor-common Version: 1.26.2-1 Severity: minor Dear Maintainer, With the latest update (1.26.2-1) on Debian testing, the text of the Resources tab in the Italian localization is clearly wrong since it says "Do not hesitate to contribute and have fun by improving MATE!" instead of "Resources" (see attached screenshots). Reverting to 1.26.0-1 or just replacing /usr/share/locale/it/LC_MESSAGES/mate-system-monitor.mo with the previous version brings back the correct text "Resources". Regards, Sergio
Bug#1060421: python3-botocore: botocore as a (useless) undeclared dependency on python3-six
On Fri, Jan 12, 2024 at 08:00:48AM +0100, Alexandre Detiste wrote: > >> Or should the Debian package depend on python3-six? > > > > That s the fast solution > > Yes please do that, I've checked awscli upstream and it's a bit of a mess > with so many pull request; I'll check again later. Here's the upstream change responsible for six being present in botocore's compat.py: https://github.com/boto/botocore/pull/2814 So it seems that adding the dependency is the right thing for now, and I will take care of that. noah
Bug#1060755: calibre: Cant execute calibre. Error: cannot import name QNetworkProxyFactory from qt.core
Hello yokota, > Please try to re-install those libraries to recover this error. > You can re-install "libqt6core6" and "libqt6network6" packages with > this command. > >> sudo apt reinstall libqt6core6 libqt6network6 I tried that and even restart my computer again but no sucess, the same result. thinking now it is related to Qt which Im studying in the moment so it might really be something by my fault but the weird thing is that I remember using calibre yesterday... maybe it was already opened when I messed up with Qt. -- Gabriel B Chuede
Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el
Source: mesa Version: 23.2.1-1 Severity: serious Control: close -1 23.3.3-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1056116 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:mesa has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable build depends on binaries from llvm-toolchain-17, which haven't been built on mips64el yet (reported in bug 1056116). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=mesa OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060782: src:i2pd: fails to migrate to testing for too long: FTBFS on armel
Source: i2pd Version: 2.45.1-1 Severity: serious Control: close -1 2.49.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:i2pd has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armel. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=i2pd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jo...@jones.dk
Upstream netatalk has patched a CVE security vulnerability; CVE-2022-22995
Ref. advisory: https://netatalk.sourceforge.io/CVE-2022-22995.php
The attached patch can be applied to Debian oldstable to address the
vulnerability.
I'm proposing an oldstable out-of-release-cycle upload: 3.1.12~ds-8+deb11u2
Sincerely,
Daniel MarkstedtFrom 3bf8b9032afcdbb5547abf420697a78c9d9b35a5 Mon Sep 17 00:00:00 2001
From: Daniel Markstedt
Date: Sun, 14 Jan 2024 14:26:19 +0900
Subject: [PATCH] Netatalk CVE-2022-22995 patch
---
debian/patches/CVE-2022-22995.patch | 63 +
debian/patches/series | 1 +
2 files changed, 64 insertions(+)
create mode 100644 debian/patches/CVE-2022-22995.patch
diff --git a/debian/patches/CVE-2022-22995.patch b/debian/patches/CVE-2022-22995.patch
new file mode 100644
index ..63101426
--- /dev/null
+++ b/debian/patches/CVE-2022-22995.patch
@@ -0,0 +1,63 @@
+Description: CVE-2022-22995
+Author: Daniel Markstedt
+Origin: https://github.com/Netatalk/netatalk/commit/9eb6d9d0ac17dca210ccbf05476a925a6b379dfb.diff
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/etc/afpd/desktop.c
b/etc/afpd/desktop.c
+@@ -12,8 +12,10 @@
+ #endif /* HAVE_CONFIG_H */
+
+ #include
++#include
+ #include
+ #include
++#include
+
+ #include
+
+@@ -212,7 +214,6 @@
+ {
+ bstring olddtpath = NULL, dtpath = NULL;
+ struct stat st;
+-char *cmd_argv[4];
+
+ olddtpath = bfromcstr(vol->v_path);
+ bcatcstr(olddtpath, "/" APPLEDESKTOP);
+@@ -220,27 +221,24 @@
+ dtpath = bfromcstr(vol->v_dbpath);
+ bcatcstr(dtpath, "/" APPLEDESKTOP);
+
+-if (lstat(cfrombstr(dtpath), ) != 0) {
+-
+-become_root();
++become_root();
+
+-if (lstat(cfrombstr(olddtpath), ) == 0) {
+-cmd_argv[0] = "mv";
+-cmd_argv[1] = bdata(olddtpath);
+-cmd_argv[2] = bdata(dtpath);
+-cmd_argv[3] = NULL;
+-if (run_cmd("mv", cmd_argv) != 0) {
+-LOG(log_error, logtype_afpd, "moving .AppleDesktop from \"%s\" to \"%s\" failed",
++if (lstat(cfrombstr(dtpath), ) != 0) {
++if ((lstat(cfrombstr(olddtpath), ) == 0) && (S_ISDIR(st.st_mode) != 0)) {
++ if (rename(bdata(olddtpath), bdata(dtpath)) != 0) {
++LOG(log_error, logtype_afpd, "moving .AppleDesktop from \"%s\" failed; creating new dir \"%s\"",
+ bdata(olddtpath), bdata(dtpath));
+ mkdir(cfrombstr(dtpath), 0777);
+ }
+ } else {
++LOG(log_debug, logtype_afpd, "no valid .AppleDesktop dir found; creating new dir \"%s\"",
++bdata(dtpath));
+ mkdir(cfrombstr(dtpath), 0777);
+ }
+-
+-unbecome_root();
+ }
+
++unbecome_root();
++
+ bdestroy(dtpath);
+ bdestroy(olddtpath);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 3f69b779..70f4bce8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -28,3 +28,4 @@ CVE-2022-23123_part5.patch
CVE-2022-23121_regression.patch
CVE-2022-23123_part6.patch
CVE-2023-42464.patch
+CVE-2022-22995.patch
--
2.39.2
Bug#1059553: fixed in minicoredumper 2.0.7-3
Hurray, On 13-01-2024 21:39, Debian Bug Tracking System wrote: minicoredumper (2.0.7-3) unstable; urgency=medium . * Fix autopackage test due to stderr output (Closes: #1059553) That worked. The test now passes nicely. Thank you. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060775: tmuxp: flaky autopkgtest: assert pane.capture_pane()[1] -> IndexError
Source: tmuxp
Version: 1.31.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails. I'm seeing a pattern that it happens more often
on our amd64 host ci-worker13 and often on our s390x which are rather
powerful hosts. The test fails in different locations, but as far as I
saw always on a line that asserts capture_pane (see example below).
Could it be that the code (either the real code or the test code) should
wait a bit until the "pane" has been substantiated? Or maybe that
comment earlier is of interest: Give slow shells some time to settle as
otherwise tests might fail.
Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
From
https://ci.debian.net/packages/t/tmuxp/testing/s390x/41364351/
59s @pytest.mark.skipif(
59s has_lt_version("3.0"),
59s reason="needs -e flag for new-window and split-window
introduced in tmux 3.0",
59s )
59s def test_environment_variables(session: Session) -> None:
59s workspace = ConfigReader._from_file(
59s
test_utils.get_workspace_file("workspace/builder/environment_vars.yaml")
59s )
59s workspace = loader.expand(workspace)
59s
59s builder = WorkspaceBuilder(session_config=workspace,
server=session.server)
59s builder.build(session)
59s # Give slow shells some time to settle as otherwise tests
might fail.
59s time.sleep(0.3)
59s
59s assert session.getenv("FOO") == "SESSION"
59s assert session.getenv("PATH") == "/tmp"
59s
59s no_overrides_win = session.windows[0]
59s pane = no_overrides_win.panes[0]
59s pane.send_keys("echo $FOO")
59s assert pane.capture_pane()[1] == "SESSION"
59s
59s window_overrides_win = session.windows[1]
59s pane = window_overrides_win.panes[0]
59s pane.send_keys("echo $FOO")
59s assert pane.capture_pane()[1] == "WINDOW"
59s
59s pane_overrides_win = session.windows[2]
59s pane = pane_overrides_win.panes[0]
59s pane.send_keys("echo $FOO")
59s assert pane.capture_pane()[1] == "PANE"
59s
59s both_overrides_win = session.windows[3]
59s pane = both_overrides_win.panes[0]
59s pane.send_keys("echo $FOO")
59s > assert pane.capture_pane()[1] == "WINDOW"
59s E IndexError: list index out of range
59s
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1060776: collectd: build dependency missing in testing: libvarnishapi-dev
Source: collectd Version: 5.12.0-15 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertag: edos-uninstallable Dear maintainer(s), Dose [1] is reporting issues with your packages. Normally your build dependencies shouldn't be removed from testing without removal all reverse build dependencies too, nor should a package be allowed to migrate unless all build dependencies are candidate for migration too. However, somehow we ended up in the current state and your source package is missing some Build-Depends for some while now. Not being able to build from source in a suite is an RC bug in that suite. Can you please solve the situation by either helping the maintainer of your Build-Depends to enable migration to testing, or by working around the lack of this build dependency? Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060777: django-filter: build dependency missing in testing: python3-django-crispy-forms
Source: django-filter Version: 23.5-1 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertag: edos-uninstallable Dear maintainer(s), Dose [1] is reporting issues with your packages. Normally your build dependencies shouldn't be removed from testing without removal all reverse build dependencies too, nor should a package be allowed to migrate unless all build dependencies are candidate for migration too. However, somehow we ended up in the current state and your source package is missing some Build-Depends for some while now. Not being able to build from source in a suite is an RC bug in that suite. Can you please solve the situation by either helping the maintainer of your Build-Depends to enable migration to testing, or by working around the lack of this build dependency? Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060778: ITP: pulsar-edit -- A Community-led Hyper-Hackable Text Editor (formerly Atom)
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pulsar-edit Version : 1.112.1 Upstream Contact: ad...@pulsar-edit.dev * URL : https://pulsar-edit.dev/ * License : MIT Programming Lang: JavaScript Description : A Community-led Hyper-Hackable Text Editor Anyone can test the app using upstream package https://download.pulsar-edit.dev/?os=linux=linux_deb which installs everything in /opt/Pulsar/. This is an Electron app and I am looking for advice from other NodeJS and Electron app maintainers on how to package this properly in Debian.
Bug#1060781: src:gitlab-shell: fails to migrate to testing for too long: Build-Depends not ready to migrate
Source: gitlab-shell Version: 14.20.0+ds1-2 Severity: serious Control: close -1 14.23.0+ds1-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gitlab-shell has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on binaries from src:gitaly, which isn't ready to migrate at this moment. The version in unstable also fails its piuparts tests. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gitlab-shell OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060780: src:terminado: fails to migrate to testing for too long: autopkgtest regression
Source: terminado Version: 0.17.1-1 Severity: serious Control: close -1 0.18.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:terminado has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=terminado OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060708: python3-wxgtk4.0: Package doesn't import
Package: python3-wxgtk4.0 Version: 4.2.0+dfsg-3 Severity: important X-Debbugs-Cc: sm...@smurf.noris.de /usr/lib/python3/dist-packages/wx/__init__.py contains: from wx.core import * del core del wx This doesn't work on my system. "wx.core" does *not* export a symbol named "core", thus the "del core" fails. Deleting the "del core" part fixes the problem. -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 python3-wxgtk4.0 depends on: ii libc62.36-9+deb12u3 ii libgcc-s112.2.0-14 ii libstdc++6 13.2.0-9 ii libwxbase3.2-1 3.2.4+dfsg-1 ii libwxgtk-gl3.2-1 3.2.4+dfsg-1 ii libwxgtk3.2-13.2.2+dfsg-2 ii python3 [python3-supported-min] 3.11.2-1+b1 ii python3-numpy1:1.24.2-1 ii python3-pil 9.4.0-1.1+b1 ii python3-six 1.16.0-4 python3-wxgtk4.0 recommends no packages. Versions of packages python3-wxgtk4.0 suggests: pn wx3.2-doc -- debconf-show failed
Bug#1060709: dh-runit: autopkgtest failure with Perl 5.38: given is deprecated
Package: dh-runit Version: 2.15.2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) autopkgtest [21:33:45]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL stderr: given is deprecated at /usr/bin/dh_runit line 50. autopkgtest [21:33:45]: test command1: - - - - - - - - - - stderr - - - - - - - - - - Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
Package: dh-make-elpa Version: 0.19.2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) autopkgtest [11:06:58]: test test-dh-make-elpa: ---] autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - results - - - - - - - - - - test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - stderr - - - - - - - - - - Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. autopkgtest [11:06:58]: summary test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060710: dnsenum: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Package: dnsenum Version: 1.3.1-1 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) 28s autopkgtest [21:35:23]: test command1: - - - - - - - - - - results - - - - - - - - - - 28s command1 FAIL stderr: Smartmatch is deprecated at /usr/bin/dnsenum line 749. 29s autopkgtest [21:35:24]: test command1: - - - - - - - - - - stderr - - - - - - - - - - 29s Smartmatch is deprecated at /usr/bin/dnsenum line 749. 29s Smartmatch is deprecated at /usr/bin/dnsenum line 751. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060711: python3-wxgtk4.0: Library dependency too lenient
Package: python3-wxgtk4.0 Version: 4.2.1+dfsg-3 Severity: normal X-Debbugs-Cc: sm...@smurf.noris.de Installing the version from Testing says >>> import wx.core Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib/python3/dist-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib/python3/dist-packages/wx/_core.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN13wxRadioButtonD2Ev, version WXU_3.2 >>> due to its dependency on libwxgtk3.2-1, which apparently needs to be >= 3.2.4 instead of 3.2.2. Semantic versioning appears to be overrated. :-( -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 python3-wxgtk4.0 depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++613.2.0-9 ii libwxbase3.2-13.2.4+dfsg-1 ii libwxgtk-gl3.2-1 3.2.4+dfsg-1 ii libwxgtk3.2-1 3.2.2+dfsg-2 ii python3 3.11.2-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-pil 9.4.0-1.1+b1 ii python3-six 1.16.0-4 python3-wxgtk4.0 recommends no packages. Versions of packages python3-wxgtk4.0 suggests: pn wx3.2-doc -- debconf-show failed
Bug#1060713: libhttp-tiny-perl: current version superseded by Perl 5.38
Package: libhttp-tiny-perl Version: 0.082-2 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition The version of this separate package in unstable is older than the one bundled with Perl 5.38, so they are uninstallable together. The separate package should be either updated to a newer version or removed as unnecessary. -- Niko Tyni nt...@debian.org
Bug#1060712: libextutils-cbuilder-perl: current version superseded by Perl 5.38
Package: libextutils-cbuilder-perl Version: 0.280236-2 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition The version of this separate package in unstable is older than the one bundled with Perl 5.38, so they are uninstallable together. The separate package should be either updated to a newer version or removed as unnecessary. -- Niko Tyni nt...@debian.org
Bug#1060714: rust-async-trait: please update to v0.1.77
Source: rust-async-trait Version: 0.1.74-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please upgrade to at least v0.1.77. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWidZIACgkQLHwxRsGg ASGk3A/9HlhGS2AEW1sxy9YOP76lHsUUQv4QlhmNaPjiylsqCmTNZp4rgD4NYCVP tBsBmHlFaI30FpvqwHgZwmhnUbJfoOpg/sLmxoE5f2998HxOTjLYK9aYtYbujk4t 2EJ81knofJ7pNDkMoAoiZiIH+yyuYmdg6OOblg6JtqrBi33GJHU07m4nEIAC/w49 CGdoaYmo1Vq+Y/loaPPtF8lPOsHpTSO4fDg3u6oMEoXFmO33Bm5nH2dJef/OR4S9 wLnWmEx/V/uosPXptUuUBmeRZBFkxR5xxXefIsKeLcy6xSd3bcC4Uz38ASkPE+km kp7V9wR3tHPadlAuvSudbzcFhOFiBrEvrC0jsU1n7OzBtnXknbdrC+2GU0JP9o5R xUu/ElVrmEW31O4r4NTtZrmgZMoH/ngl2bulYbc2EbAvpiv3FfuATqOsWxwd9qd9 yATAOpoDma7wtM9LkJwRkaOee8dmWBVdFkIcXE1TLU0vuNTHfXzJnBmTJWgIUopj JnY4AIHiuuUbX8v/bQr8hzBFbX4YgFokI9o4pNoVrf7l70r1keb/fqmR9jYIaSpY +NtzTQvO19i5eLNwYIQoM+AW8k9SDOapOPTsT9EcfQZa82Hk2YQFaH/3gIMtZF3z QwhmTPaloktiepfQY3DwznYiYted7AG4blIcFGhv8Knk8UFmmCM= =f+Fv -END PGP SIGNATURE-
Bug#1060717: rust-clap-complete: please update to v4.4.6
Source: rust-clap-complete Version: 4.4.3-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to at least v4.4.6. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWidukACgkQLHwxRsGg ASGLQQ/9GioU1JwGSELve7EpCtjU5pu7x/eG/PCmMY6ka/jCJWNEDWngIw6HLRqU uEP0FyLd/GQeByi6xoYPEAjmOUGJnSTCPW7ujUKp4gJBz1wLkbXHMmdoyWat/qS5 fDl5yrLtKy4eaDs7/ZJq4ezqNZUA/BGpyrg1BKSi7b3UBS1RLnPDzKnYbFlTIEhk TMTn+2Opy101+w334E4/fgU+eiIY85dp3rbeDnMmW3mXliMAlsh5i7hrydb4q4VU 9WL4EWBocCR91NH4ZlOk5wX09H5u9hBFmmRV2XGwOoIMj+djorQduutYXMxFnG0Z DhguQIdO079UwDGnE8hRIkwrWZfykxoRbCR5X9ozBha3QKYdnZ3JHKv4naOp85/O JLKQAY/BmWG6KxYnkCTYxn7kssOl0X5LlT9dRipW6+lhjCKIQVI1AzD7jWYxJLpc fdNK0O5PeotatIrajqAY7UWprL4oOrHod3dNDO/Y4ILgdNvwqFcoCTOxw5swzjmJ TdU7vo5cHj4wOkSHKtVTTPCKhuB7c+QEbHMH3LuqULTpohUTVsje12mSJhwcrC4H ivLlncsa2Hu4g2C8DYvHiDF4ceLuAl3/YT8DOBA7qgRn7f1hGbzKgb2epskivnWq qoDaShHz1I6A4fRyju8lE5fWDcSTxGynwDy/1ld47jVy48BlPMM= =eEK4 -END PGP SIGNATURE-
Bug#1060718: rust-ctrlc: please update to v3.4.2
Source: rust-ctrlc Version: 3.4.0-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to at least v3.4.2. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWidyYACgkQLHwxRsGg ASGZYA/9Erw6F0xj45ntY9HoSRRjvElAhwR/EcTMHe5UPLuUR0M3k++Jpwvikt7N MPzq5e20gjaUbI4rwjZvO0zMMKv9tj7BzpAMRsf3QORScw3eG6kn6HFZ62Ih5KRr cfnoKmYgDi1VAhA9egCOKj7WeNbaPJcvgmzyCiakUzzisCJ0ER2Zk94yA+340J5Y 5mRlknPHKtDIc9AsrVz7vn8r4XQWi1v7JF8gxoslJsVUcxq82RfutlUJfEvtDg6k Dh3vEKo8QwQR5F3JwOyCXOj3Ew+vLZMqccoFzix/+SzI3sRP/J/lAdNSRILcsA8/ PrIbsRrV15+f6GtWqpEz+bKDgutawhOA/LP6PS+rLRvldhoIGVG+i+jiaQ//x5TP 4lto/1YjW64eFRPgpCv9nqJYwrZWQWOCsTdpZO1HGJAkGAW/+l35lKsf/sQYZRN1 v/SGq47qZ4yEDMIKPhbIR0bALm1Iv/a9HsEsLX8mDTenaSnuFabdQxg/mxVMr0FL VJVgluAyKm8YgTwNZPnytQj+BEwLNJN+WWixPDVKuzVZMacwlCW18HmcrfhzEEyl MbiurZ966FvUyyUlxdIXXQfogYnKmx8tjTjAzF1j4Ia+qIH4zKddC0vO5iU7Z6Q4 WysJBzcOhlvfPLlBb/3EIO7gex1Cwd3PAt2pnyWWIfXqj0euHbk= =g6nL -END PGP SIGNATURE-
Bug#1060719: rust-once-cell: please update to v1.19.0
Source: rust-once-cell Version: 1.18.0-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to at least v1.19.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWid1MACgkQLHwxRsGg ASHh9Q//X4p+Shjc4svlhVo5Ll7+UVwJ28hznEak6lT/QV7OENmjDhZFDg5j8e7B IPVPiJJevPDPbUxiVM7UD6z2LoKvoUH6DusxkWTYtfp7MIkrThU41GLQ/rLULu8g O3i4Az66pGURrkqV5aln6pGnJTrE+MB0LuGdTLJdrN/LayFq26b82+t4G96iiukI 4GLS8xM3JrPkvCQuFUV7UdCweI4mP5SoQ4FiG4g5R3wPZ54NKykB22qId9kQp+UU cxkZPYGox7nOG35RzIPX5OK8hHQvyPLf3nc7BCN2KIoWHvjCGpknMy2hzlErUiFl 7ZuQUd7CJYdrB5oByxZNNylM3yzCcRK3DvlElPBINvkol6AbKAt9pABKIwK09AkY BYz2W58AK+4vdwTk0JHFpfupmQBFBoyaHuhlJLryXC6/OZ2FXbvpVm8u6tbtmO5d 65rje1UHUozeQYBgLGoSYG+3lOQpwU7p31TZkwodSFK+qYn3AK4bVaheHutb8ysJ jAGmySqAgsnfaBx+aunekduJppe8aszhvAUEfQWbCv2zsZR+XyodU7qAlAxt0zNK LJ/DminuU2FfCEACuagxfvVgjC42BGMzOL9hpBCa7XcylkDfwZblo9/0GY7AxFB+ IhdUNTgL2UoB5rda+ffPCDukjevlJ25KcOIFuXuxvgNPr7F+6kA= =k5o0 -END PGP SIGNATURE-
Bug#1060720: rust-tempfile: please update to v3.9.0
Source: rust-tempfile Version: 3.8.1-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to at least v3.9.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWid4EACgkQLHwxRsGg ASHhzRAAqlPxOhbXQG61F2qTuTxrtHv2jeV19E8TS91JsKtUPvJg1U3n5Rest9wg b4bIwcqlPf0i3/i2EYs/rSw8U0U3HakViBM02K/EN/h/loa072+NO5aOkJ+be0ty MZPVM5VeEPxsmbARY28z5bwS35K5qdckZTxIe1bQwPCL2PMoSn27drQ6P49/j5+R 3+/MKDWgrbJkzvOHwaZjyjV56tEsAbL0PJlJNF4STMnzZULPxVc9mhoSrSQ4EjzZ S6pNSXUtKB8L6lGPEO4o/sZFz0LAAqyq9IwycBRr3Ial2d6oxecLyjS7XmRPx0zH AOlDZv7S5EX6W0Zt9HuKOqXU21LJxQ42DPTINbUIt+jt0pHMhLBaTlNEIR6AqdR8 xNdknJ99GVQ6ifOVZSkV+cnpq4YSQU5o0WjtJacgElAlr4nAcz/BKP4X4+MQSmoi 0FN2xr28C9ot/XydeaYpbmPib+aVhZiKMwFUOQ5iCX/CbSX4PnJzNYgC5hvuZmQr 6tWfp33u13/qj38BKsiwHCfQiTBTipi4SsiWyWCh5C/xd4FEDuutRKl0jTawurQV X0ms5D/nApGVb+3rP0sktZ0ZrkbvZ4El/D3y235/Q8I7GOnF3NlLdnfyOe5//pGO w1sLEJyN4f7jocCq1e7fSfZhKObG8dAzKgXqg/TG01Z0ppJBC1U= =6XDg -END PGP SIGNATURE-
