Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > I'm pretty sure that we can, at some point in the future, drop the > > offending > > > patch from the RPM package and all of this will be redundant. It > > just requires a > > > bit of work to make sure that older use cases (mostly alien) don't > > break due to > > > this, which might require a bit of development on RPM itself. It's > > on my TODO > > > list for very rainy and boring days, but unfortunately there's > > almost always a > > > truckload of other things to do, so I keep dragging it out. > > > > > > > > > > > > Mihai > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > on packages depending on it. If needed, I'm willing to be part of > > reviewing what would be the impact of returning to a standard RPM > > package on Debian and to help into solving those issues. Don't > > hesitate to ping me for that. > > I think the time has come to drop the RPM Debian-specific patches and > avoid these workarounds altogether. > > Once upon a time it made sense to redirect the RPM DB, and to go out of > our way to stop users installing RPMs locally, when RPMs were popular > as a way to distribute upstream applications. > > Nowadays, the most common way to distribute upstream apps is via > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > very low. > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > with Alien or so, but it's to be able to do cross-distribution > bootstraps and image building using native tools, like we do in mkosi > (and in other tools as well). > > So these patches to print warnings and divert the database and so on > are a hindrance. > > Hence, for Trixie I think we should just drop them all. > > It should also make it easier to maintain the RPM stack, which has > languished. We are trying to move everything under the RPM Team Salsa > org, which should also help. > > If there are any objections please speak up. I've thought about making this change at least once a year, but I have always been, hm, should I say "too careful" (when of course I actually mean "too scared")... so if you feel the time has come, yeah, go ahead! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1066629: ucspi-tcp: FTBFS: tcpserver.c:143:29: error: implicit declaration of function ‘getpid’ [-Werror=implicit-function-declaration]
On Fri, Apr 12, 2024 at 02:56:02PM -0600, Zixing Liu wrote: > Package: ucspi-tcp > Followup-For: Bug #1066629 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu noble ubuntu-patch > Control: tags -1 patch > > Dear Maintainer, > > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/0006-implicit-declarations.patch: Add missing > includes and prototypes. Closes LP: #2061188. > * debian/ipv6-support.patch: Refresh deferred patch. OK, this is a little creepy :) I am staring at my work-in-progress update of the ucspi-tcp package and I see a patch named 0006-implicit-declarations.patch and an update to the ipv6-support one :) But mine was not completely done yet, while yours seems to be. (and yes, of course, the patch naming is logical) > Thanks for considering the patch. Thanks! I will probably upload a new ucspi-tcp version in a couple of days. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1068106: bookworm-pu: package libarchive/3.6.2-1+deb12u1
On Sat, Mar 30, 2024 at 08:51:10PM +0200, Peter Pentchev wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > X-Debbugs-Cc: libarch...@packages.debian.org, r...@debian.org > Control: affects -1 + src:libarchive > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > Revert a change made by the same person that smuggled > the backdoor into xz. See #1068047 for more details. > > [ Impact ] > In the discussion in the upstream bugtracker, the consensus is that > the reverted change may not really introduce any vulnerability, but > still some concerns were expressed regarding some unlikely scenarios. > It might be a safer bet to revert it, just in case. Right, so it seems that I was a bit impatient filing this bug, right after I got the "processing" e-mail from the archive for libarchive-3.7.2-2 in unstable, but before I got the "accepted" one... and before I had noticed the d-d-a e-mail about the paused archive processing. So yeah, this is still a pre-upload approval request, but it will apparently need to wait until 3.7.2-2 makes it into unstable :) Thanks in advance, and sorry for the bother! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1068106: bookworm-pu: package libarchive/3.6.2-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: libarch...@packages.debian.org, r...@debian.org
Control: affects -1 + src:libarchive
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Revert a change made by the same person that smuggled
the backdoor into xz. See #1068047 for more details.
[ Impact ]
In the discussion in the upstream bugtracker, the consensus is that
the reverted change may not really introduce any vulnerability, but
still some concerns were expressed regarding some unlikely scenarios.
It might be a safer bet to revert it, just in case.
[ Tests ]
None yet.
[ Risks ]
The change reverting the previous one is straightforward, limited to
a specific piece of code (specific error logging in
the bsdtar(1) command-line tool), and changes the source code back to
using the same error reporting functions that are used elsewhere
throughout the bsdtar and libarchive source code. Thus, IMHO the risks
are negligible, if any.
[ 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 ]
Introduce a patch that uses libarchive's own error reporting functions
instead of unchecked fprintf().
diff -Nru libarchive-3.6.2/debian/changelog libarchive-3.6.2/debian/changelog
--- libarchive-3.6.2/debian/changelog 2022-12-24 23:17:29.0 +0200
+++ libarchive-3.6.2/debian/changelog 2024-03-30 20:36:47.0 +0200
@@ -1,3 +1,9 @@
+libarchive (3.6.2-1+deb12u1) bookworm; urgency=medium
+
+ * Add the robust-error-reporting upstream patch. Closes: #1068047
+
+ -- Peter Pentchev Sat, 30 Mar 2024 20:36:47 +0200
+
libarchive (3.6.2-1) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru libarchive-3.6.2/debian/patches/robust-error-reporting.patch
libarchive-3.6.2/debian/patches/robust-error-reporting.patch
--- libarchive-3.6.2/debian/patches/robust-error-reporting.patch
1970-01-01 02:00:00.0 +0200
+++ libarchive-3.6.2/debian/patches/robust-error-reporting.patch
2024-03-30 20:31:38.0 +0200
@@ -0,0 +1,20 @@
+Description: tar: make error reporting more robust and use correct errno
+Debian-Bug: https://bugs.debian.org/1068047
+Origin: upstream,
https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c
+Author: Ed Maste
+Last-Update: 2024-03-30
+
+--- a/tar/read.c
b/tar/read.c
+@@ -372,8 +372,9 @@
+ if (r != ARCHIVE_OK) {
+ if (!bsdtar->verbose)
+ safe_fprintf(stderr, "%s",
archive_entry_pathname(entry));
+- fprintf(stderr, ": %s: ",
archive_error_string(a));
+- fprintf(stderr, "%s", strerror(errno));
++ safe_fprintf(stderr, ": %s: %s",
++ archive_error_string(a),
++ strerror(archive_errno(a)));
+ if (!bsdtar->verbose)
+ fprintf(stderr, "\n");
+ bsdtar->return_value = 1;
diff -Nru libarchive-3.6.2/debian/patches/series
libarchive-3.6.2/debian/patches/series
--- libarchive-3.6.2/debian/patches/series 2022-12-24 23:17:29.0
+0200
+++ libarchive-3.6.2/debian/patches/series 2024-03-30 20:31:52.0
+0200
@@ -1,2 +1,3 @@
typos.patch
iconv-pkgconfig.patch
+robust-error-reporting.patch
signature.asc
Description: PGP signature
Bug#1067709: FTBFS in armel/armhf: some symbols disappeared
Control: tag -1 + confirmed On Tue, Mar 26, 2024 at 01:29:08AM +0500, Andrey Rakhmatullin wrote: > Source: dante > Version: 1.4.3+dfsg-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=dante=armhf=1.4.3%2Bdfsg-1=1710761774=0 Thanks for reporting this. I noticed it as soon as I uploaded this version of dante, and I started looking into it; it is, at least partly, fallout from the new "implicit function declarations are errors" GCC option setting. FTR, I believe this is a good idea, no complaints here. However, it turns out to be a bit more complicated than sprinkling a couple of #include directives here and there; I will hopefully be able to upload a fixed version within the next couple of days. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Wed, Mar 13, 2024 at 10:40:51AM +, Traut Manuel LCPF-CH wrote: > > On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > >> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > >>> On 7 Feb 2024, at 18:27, Dima Kogan wrote: > >>> > >>> Hi. Thanks for your contribution. I looked at the upstream code a tiny > >>> bit, and it looks like it might have portability bug, at least on > >>> big-endian architectures. For instance: > >>> > >>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > >>> > >>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be > >>> nice to fix. Are you upstream or do you know upstream? Can yall fix > >>> these? > >>> > >> The kernel expects a 4 byte write here, since unsigned long is defined as > >> at least 32 bit this shall work on all architectures. > >> > >> If your concern is about endianess this is not in the current scope of > >> libuio and needs to be addressed by a higher layer. > >> > >> I am very familiar with library and in close contact with upstream. > >> > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > > that tmp is guaranteed to be all-zeroes. However, consider the previous > > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > > then the "tmp" variable's value of 1 will be encoded in memory as > > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > > When uio_enable_irq() calls write(..., , 4), it will only send > > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > > So it turns out that uio_disable_irq() and uio_enable_irq() do > > exactly the same - send a 32-bit zero value to the kernel. > > > > ...of course, this will only happen on a big-endian system, as > > Dima Kogan was concerned about. On a little-endian system, this > > will work by chance. > > > > Is this the expected behavior indeed? > > No it is not :) Thanks for the detailed explanation. > > Looks this fix sane to you? > https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55 Yeah, after I sent the e-mails I realized that I forgot to mention that using uint32_t would be one of the best ways to fix that. Thanks for the fast reaction! > I am not sure if users also expect an automatic conversion for the read/write > functions: > https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e > > It will be somehow inconsistent since a user could also access the device > memory by pointer: > https://github.com/manut/libuio/blob/add-ci/mem.c#L93 > and than needs to take care on the endianess by its own anyway. ...and this part I have no opinion about. I don't have any realistic idea about how people actually use libuio (or how they will use it), and I do not think that I will use it soon, so this should be left for others to decide. Thanks again for paying attention to the comments! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1065669: ITP: raven -- A lightweight http file upload service used for penetration testing and incident response.
On Sat, Mar 09, 2024 at 01:12:06PM +0100, Salvo Tomaselli wrote: > > In data venerdì 8 marzo 2024 18:08:11 CET, aquilamac...@riseup.net ha scritto: > > Package: wnpp > > X-Debbugs-Cc: debian-de...@lists.debian.org > > Owner: Aquila Macedo Costa > > Severity: wishlist > > > > * Package name: raven > > Version : 1.0.1 > > Upstream Contact: Tristram > > * URL : https://github.com/gh0x0st/raven > > * License : MIT > > Programming Lang: Python3 > > Description : A lightweight http file upload service used for > > penetration testing and incident response. > > > > This package contains a Python tool that extends the capabilities of the > > http.server Python module by offering a self-contained file upload web > > server. > > While the common practice is to use python3 -m http.server 80 to serve > > files > > for remote client downloads, Raven addresses the need for a similar > > solution > > when you need the ability to receive files from remote clients. This > > becomes > > especially valuable in scenarios such as penetration testing and > > incident > > response procedures when protocols such as SMB may not be a viable > > option. > > > > I'm writing to submit an Intention to Package (ITP) for raven > > under the pkg-security team's umbrella. > > What's the problem with > > nc -lp 80 > file > > ? > > Does this provide some sort of browser interface? To start with, raven seems to allow uploading more than one file :) The description on the project homepage lists several features such as access control, organizing the uploaded files into subdirectories, etc. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > Hi Dima, > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > bit, and it looks like it might have portability bug, at least on > > big-endian architectures. For instance: > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > these? > > The kernel expects a 4 byte write here, since unsigned long is defined as at > least 32 bit this shall work on all architectures. > > If your concern is about endianess this is not in the current scope of libuio > and needs to be addressed by a higher layer. > > I am very familiar with library and in close contact with upstream. In the case of uio_disable_irq() the bug is nicely hidden by the fact that tmp is guaranteed to be all-zeroes. However, consider the previous function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, then the "tmp" variable's value of 1 will be encoded in memory as 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. When uio_enable_irq() calls write(..., , 4), it will only send the first four bytes to the kernel - and they are 0, 0, 0, and... 0. So it turns out that uio_disable_irq() and uio_enable_irq() do exactly the same - send a 32-bit zero value to the kernel. Is this the expected behavior indeed? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > > Hi Dima, > > > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > > bit, and it looks like it might have portability bug, at least on > > > big-endian architectures. For instance: > > > > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > > these? > > > > The kernel expects a 4 byte write here, since unsigned long is defined as > > at least 32 bit this shall work on all architectures. > > > > If your concern is about endianess this is not in the current scope of > > libuio and needs to be addressed by a higher layer. > > > > I am very familiar with library and in close contact with upstream. > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > that tmp is guaranteed to be all-zeroes. However, consider the previous > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > then the "tmp" variable's value of 1 will be encoded in memory as > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > When uio_enable_irq() calls write(..., , 4), it will only send > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > So it turns out that uio_disable_irq() and uio_enable_irq() do > exactly the same - send a 32-bit zero value to the kernel. ...of course, this will only happen on a big-endian system, as Dima Kogan was concerned about. On a little-endian system, this will work by chance. > Is this the expected behavior indeed? -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1065230: ITA three more Python packages
package wnpp retitle 1065150 ITA: pymdown-extensions -- Extension pack for Python Markdown owner 1065150 ! retitle 1065230 ITA: python-regex -- alternative regular expression module (Python 3) owner 1065230 ! retitle 1065251 ITA: python-click -- Wrapper around optparse for command line utilities - documentation owner 1065251 ! thanks I intend to maintain these packages within the Debian Python packaging team. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1065039: ITA mkdocs-material
package wnpp retitle 1065039 ITA: mkdocs-material -- Material Design theme for MkDocs owner 1065039 ! bye Hi, Thanks for your work on mkdocs-material over the years! I intend to adopt this package within the Debian Python team. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1061487: bookworm-pu: package rpm/4.18.0+dfsg-1+deb12u1
On Mon, Jan 29, 2024 at 09:51:45PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2024-01-25 at 14:39 +0200, Peter Pentchev wrote: > > Version 4.18 of RPM changed the format of its internal database > > from the traditional BerkeleyDB one to a new SQLite implementation. > > For compatibility purposes, including the ability to automatically > > migrate an old database to a new one during an upgrade, RPM needs to > > be able to read the old-format database. Some more information may > > be found in #1061258. > > > > Due to my omission when packaging the RPM update to 4.18.0, > > the corresponding configure-script option was not included when > > building the Debian RPM package. > > Please go ahead. Right, I should have mentioned that was a pre-approval request... Thanks! I just uploaded it. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1061775: shlibs is stricter than it needs to be
On Mon, Jan 29, 2024 at 04:58:47PM +0100, Steinar H. Gunderson wrote: > Package: libzstd-dev > Version: 1.5.5+dfsg2-2 > Severity: normal > > Hi, > > debian/rules contains > > dh_makeshlibs -plibzstd1 -V'libzstd1 (>= 1.5.5)' --add-udeb=libzstd1-udeb > > Would it be possible to change it to 1.5.4? I don't see anything between 1.5.4 > and 1.5.5 that would mean 1.5.5-built packages wouldn't work on 1.5.4, > and this would allow trixie-built .debs to be installable on bookworm. > (Of course, it would break if upstream truly introduces new APIs, but that's > fine.) Hmmm, my understanding might be wrong, but when using dh_makeshlibs directly without a symbols file, isn't it going to be a problem if a program is built against libzstd 1.5.5 and it uses the new ZSTD_CCtx_setFParams() function? > Ideally, of course, one would ship a .symbols file instead of .shlibs, > but that requires more careful tracking. Now that is interesting. I actually prefer using symbols files for shared libraries when possible for obvious reasons, but I was still under the impression that the libzstd upstream build system was not ready for that - see e.g. https://salsa.debian.org/pkg-rpm-team/libzstd/-/commit/7f600c89ec9dffefd0017190313dbc9a050b8798 and, hence, https://github.com/facebook/zstd/pull/2501 ...and I just realized that !2501 was merged back in version 1.5.1! Huh. That's actually pretty cool, so now I can start using a symbols file for libzstd, too! OK, so since I still believe that lowering the version given to dh_makeshlibs would break programs that use the two new functions in 1.5.5, what do you think about the idea to start using symbols files instead? With some careful backporting (for my build purposes only), I believe I could craft a symbols file that would go back all the way to version 1.5.1. That's earlier than the 1.5.4 version in bookworm, so I think it might still suit your goal? Thanks for bringing this up - I really hadn't noticed that the "really export symbols with care" merge request had been merged! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1061258: rpm: enable read-only BerkeleyDB backend for bookworm?
On Mon, Jan 22, 2024 at 07:21:22PM +, Holger Levsen wrote: > Hi Peter, > > On Mon, Jan 22, 2024 at 07:49:53PM +0200, Peter Pentchev wrote: > > Yes, I did fully intend to submit it for stable-updates after it had > > spent a couple of days in unstable and possibly migrated to > > testing. Thanks, though - for all you knew, I had not even > > considered it, so thanks for the reminder, > > awesome, thanks already! And please do reach out if you need any help > with that! FWIW, I just filed #1061487 with the proposed stable update. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1061487: bookworm-pu: package rpm/4.18.0+dfsg-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: r...@packages.debian.org, team+pkg-...@tracker.debian.org, r...@debian.org Control: affects -1 + src:rpm [ Reason ] Version 4.18 of RPM changed the format of its internal database from the traditional BerkeleyDB one to a new SQLite implementation. For compatibility purposes, including the ability to automatically migrate an old database to a new one during an upgrade, RPM needs to be able to read the old-format database. Some more information may be found in #1061258. Due to my omission when packaging the RPM update to 4.18.0, the corresponding configure-script option was not included when building the Debian RPM package. [ Impact ] Users who upgrade from RPM 4.16.0 or earlier to 4.18.0 cannot use their database of packages already installed via RPM. [ Tests ] None so far. [ Risks ] Although the `--enable-bdb-ro` option that allows RPM to read old-style BerkeleyDB files using its own parser is marked as experimental in the documentation, it is considered stable enough to use by other Linux distributions, both RPM-based and those that, like Debian, only provide RPM as a convenience to the users. IMHO any risk of data corruption or incorrect behavior is minimal. [ 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 ] Pass the `--enable-bdb-ro` option to the GNU configure script, thus building the internal BerkeleyDB parser that RPM will use to read the old-style database of installed packages. diff -Nru rpm-4.18.0+dfsg/debian/changelog rpm-4.18.0+dfsg/debian/changelog --- rpm-4.18.0+dfsg/debian/changelog2023-01-05 20:29:48.0 +0200 +++ rpm-4.18.0+dfsg/debian/changelog2024-01-25 14:18:24.0 +0200 @@ -1,3 +1,10 @@ +rpm (4.18.0+dfsg-1+deb12u1) bookworm; urgency=medium + + * Team upload. + * Enable the read-only BerkeleyDB backend. Closes: #1061258 + + -- Peter Pentchev Thu, 25 Jan 2024 14:18:24 +0200 + rpm (4.18.0+dfsg-1) unstable; urgency=medium * Team upload. diff -Nru rpm-4.18.0+dfsg/debian/rules rpm-4.18.0+dfsg/debian/rules --- rpm-4.18.0+dfsg/debian/rules2023-01-05 20:29:48.0 +0200 +++ rpm-4.18.0+dfsg/debian/rules2024-01-25 14:18:24.0 +0200 @@ -26,6 +26,7 @@ --with-vendor=debian \ --enable-shared \ --enable-python \ + --enable-bdb-ro \ CPPFLAGS="$(CPPFLAGS)" configure_paths += \ signature.asc Description: PGP signature
Bug#1061258: rpm: enable read-only BerkeleyDB backend for bookworm?
On Mon, Jan 22, 2024 at 02:36:24PM +, Holger Levsen wrote: > hi, > > from reading the d/changelog entry "Enable the read-only BerkeleyDB backend. > Closes: #1061258" it sounds like it should be possible to have this fix > in bookworm too, via the upcoming point release?! > > I think it would qualify, as it's breaking updating Qubes dom0 via > a debian based update-vm (see > https://github.com/QubesOS/qubes-issues/issues/8482) > which is a.) an important use-case and b.) a regression compared to bullseye. > > What do you think? Yes, I did fully intend to submit it for stable-updates after it had spent a couple of days in unstable and possibly migrated to testing. Thanks, though - for all you knew, I had not even considered it, so thanks for the reminder, and thanks for all your work on Debian. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Sat, Nov 04, 2023 at 06:05:41PM +0100, Andreas Henriksson wrote: > On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Tobias Heider > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: lzfse > > Version : 1.0 > > Upstream Authors: > > URL : https://github.com/lzfse/lzfse > > * License : BSD-3-Clause > > Description : LZFSE Compression library > > > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > > State Entropy coding. It targets similar compression rates at higher > > compression and decompression speed compared to deflate using zlib. > > > > I plan to maintain this as part of the bananas team. > > Calling all SO versioning experts! > > The upstream project does not have any shared object version set. > A downstream patch was introduced to set one: > https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch > > Upstream has seen no activity since 2017, so trying to interact is > assumed to not generate much. (sorry, I imagine you are already aware of what I am about to say, but still I think it's worth saying... Apologies if I'm lecturing, I think you may have been a DD longer than I have :)) This... may be a problem. This means that any fixes you have to make (security fixes, important bug fixes, or just improvements that really, really bug your sense of doing things right) will be specific to the Debian package, and unless the other packaging systems pick them up, with time things will diverge further and further. The best thing to do in this case is to - somehow - try to push things in a direction that ultimately leads to the library having active upstream developers. This may mean having you or somebody you know try to contact the current developers and ask to join them. In a close-to-the-extreme version of this, this may mean you (or somebody you know) taking over upstream development with the consent of the current developers. In a really, really extreme version, it may mean forking the project without the consent of the current developers and facing various kinds of weird things down the road, especially if they wake up one day and decide to carry on as usual, ignoring your fork. One thing to note that I have learned from bitter experience: you may feel that it would be fun and it would not be too difficult to take over upstream development, and doing this too many times may lead to a situation that you are the upstream developer for too many things and you cannot really give most of them enough attention. There is no single right answer here, but it would certainly be much, much, much better for everyone involved (including the end users of your Debian package, people who install something that uses this library) if there were an active upstream. > Also the ABI is unlikely to change (since > no changes are being made). Yeah... see above about the upstream developers waking up one day and deciding to carry on :) Also, it is possible that some packager from antoher packaging system decides to go ahead and fork the project... But still, those are all hypotheticals. > I've previously suggested that maybe it would be better to set a > debian-specific version (0d?), to avoid the theoretical situation > that upstream one day ships a different ABI under the 1 so version. > > I would welcome peoples input here on what you think is best from > the debian perspective. Obviously we're going to be incompatible with > everyone else[1], unless you install/runtime-depend-on the -dev package > for the unversioned so symlink. Please speak now before this is > submitted for NEW. When you say "incompatible with everyone else", how do other packaging systems handle this? Has this library been packaged somewhere else? It might be a good idea to do the same thing as some other packaging system... but it may also turn out that all of the current ones have chosen (possibly different) suboptimal ways to handle this, so being incompatible with them may turn out to be the best option for Debian itself. As above, there is no single right answer here. > FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS > containing embedded firmwares. See asahi-fwextract ITP: #1055206 > > Regards, > Andreas Henriksson > > > [1]: > https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1052135: ITP: check-build -- Check whether some example programs can be compiled and built
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team , r...@debian.org * Package name: check-build Version : 0.1.0 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/check-build * License : BSD-2-clause Programming Lang: Python Description : Check whether some example programs can be compiled and built The `check-build` tool can be used to build and test different programs in a temporary build directory. The programs are listed in a TOML configuration file, along with the commands to build and test them. A bundled copy of the check-build library is used in the libzstd autopkgtest to make sure that the C library's -dev package contains enough files so that a program that uses the library can be built. It will be removed in the next libzstd upload as soon as this package hits the archive. I will maintain this package as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1050005: ITP: pdftopng -- Convert PDF to PNG
On Tue, Aug 22, 2023 at 01:24:42PM +0200, Mathieu Malaterre wrote: > On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich wrote: > > > > * Elena Grandi [230818 05:27]: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Elena Grandi > > > > > > * Package name: pdftopng > > > Description : Convert PDF to PNG > > > > > > A command line tool and python library to convert PDFs to PNGs, based on > > > pdftoppm from poppler. > > uh ? > > % pdftoppm -h 2>&1| grep png > -png : generate a PNG file > > > > This is a dependency of camelot-py (#1049944) and I intend to maintain > > > it in the Python Team. > > > > Does pdftocairo from the poppler-utils package do what you need? If > > not, would it make sense to submit patches to add pdftopng to the > > poppler-utils package instead of creating a separate package for it? > > ...or at least document why pdftoppm is not suitable. I would imagine, since the original ITP also mentioned a Python project that requires this package, that the "Python library" part may be important: the upstream authors of the other project may have decided to use it, as a Python library, instead of fiddling with child process management by themselves. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1041439: zchunk: backport to bookworm
On Wed, Aug 09, 2023 at 09:36:11PM +0200, Bastian Germann wrote: > Hi Peter, > > On Tue, 18 Jul 2023 23:34:28 +0200 Bastian Germann wrote: > > Am 18.07.23 um 23:24 schrieb Peter Pentchev: > > > However, would you be terribly upset if I did the backport myself? > > > > I would actually prefer that. Thanks! > > Any chance of backporting soon? Sorry for the delay. I uploaded it last night, it's in the NEW queue now. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#826883: stunnel4: Please provide systemd unit file
On Mon, Jun 27, 2016 at 01:03:09PM +0300, Peter Pentchev wrote: > On Thu, Jun 09, 2016 at 02:30:50PM -0400, micah wrote: > > Package: stunnel4 > > Version: 3:5.32-1 > > Severity: wishlist > > Tags: patch > > > > Hi, > > > > It would be nice if stunnel4 had systemd integration... [snip example file for a single stunnel instance] > > Hi, > > Thanks for the suggestion, and thanks for the provided sample file! > Also, apologies for not replying sooner. > > Actually, I've been thinking about providing a native systemd unit / > service file for quite some time now... ...and I guess I should have marked this bug as fixed in version 3:5.56+dfsg-7 of the stunnel4 package; quoting from its NEWS.Debian file: For Debian installations running systemd, it is now possible to enable and start stunnel instances controlled by individual configuration files in the /etc/stunnel directory. The stunnel@ service template, when instantiated, will start an stunnel process and look for an /etc/stunnel/.conf file. User services are also available under systemd: if started via `systemctl --user start stunnel@instance.service`, stunnel will look for a ~/.config/stunnel/.conf file. Please note that in both cases, the service files use the "simple" systemd service type, so the configuration must include a "foreground = yes" setting. To prevent confusion with the `stunnel4` systemd service that is automatically generated for the /etc/init.d/stunnel4 file, the SystemV stunnel4 service is NO LONGER automatically enabled. This means that new installations on Debian systems that use the SysV init package will need to enable the stunnel4 service. -- Peter Pentchev Fri, 12 Feb 2021 00:28:35 +0200 This change is present in all of Debian unstable (sid), testing, stable (bookworm) and oldstable (bullseye). Does this meet your needs? Apologies for not mentioning it sooner... G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1037790: nix: ftbfs with GCC-13
control: tag -1 + pending
On Wed, Jun 14, 2023 at 09:29:02AM +, Matthias Klose wrote:
> Package: src:nix
> Version: 2.8.0-1.1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
>
> [This bug is targeted to the upcoming trixie release]
[snip]
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> severity of this report will be raised before the trixie release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2023/05/22/logs/nix_2.8.0-1.1_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
[snip]
> src/libutil/json.cc: In function ‘void nix::toJSON(std::ostream&, const
> char*, const char*)’:
> src/libutil/json.cc:33:22: error: ‘uint16_t’ was not declared in this scope
>33 | put(hex[(uint16_t(*i) >> 12) & 0xf]);
> | ^~~~
> src/libutil/json.cc:5:1: note: ‘uint16_t’ is defined in header ‘’;
> did you forget to ‘#include ’?
> 4 | #include
> +++ |+#include
> 5 |
> make[1]: *** [mk/patterns.mk:3: src/libutil/json.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j8 returned exit code 2
> make: *** [debian/rules:31: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
> 2
I am attaching the debdiff of the NMU that I uploaded to DELAYED/5 yesterday.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
diff -Nru nix-2.8.0/debian/changelog nix-2.8.0/debian/changelog
--- nix-2.8.0/debian/changelog 2022-10-15 13:28:28.0 +0300
+++ nix-2.8.0/debian/changelog 2023-07-22 19:16:28.0 +0300
@@ -1,3 +1,11 @@
+nix (2.8.0-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add the gcc13 patch to fix the build with GCC 13.
+Closes: #1037790
+
+ -- Peter Pentchev Sat, 22 Jul 2023 19:16:28 +0300
+
nix (2.8.0-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru nix-2.8.0/debian/patches/gcc13.patch
nix-2.8.0/debian/patches/gcc13.patch
--- nix-2.8.0/debian/patches/gcc13.patch1970-01-01 02:00:00.0
+0200
+++ nix-2.8.0/debian/patches/gcc13.patch2023-07-22 19:13:41.0
+0300
@@ -0,0 +1,17 @@
+Description: Fix the build with GCC 13
+ Include the header for the definition of the uint16_t type.
+Bug-Debian: https://bugs.debian.org/1037790
+Forwarded: no
+Author: Peter Pentchev
+Last-Update: 2023-07-22
+
+--- a/src/libutil/json.cc
b/src/libutil/json.cc
+@@ -1,6 +1,7 @@
+ #include "json.hh"
+
+ #include
++#include
+ #include
+
+ namespace nix {
diff -Nru nix-2.8.0/debian/patches/series nix-2.8.0/debian/patches/series
--- nix-2.8.0/debian/patches/series 2022-05-02 21:55:23.0 +0300
+++ nix-2.8.0/debian/patches/series 2023-07-22 19:16:28.0 +0300
@@ -4,3 +4,4 @@
fix_nix_DIR_in_doc_local_mk.patch
lowdown_does_not_declare_bsd_dep.patch
+gcc13.patch
signature.asc
Description: PGP signature
Bug#1041555: bookworm-pu: package stunnel4/3:5.68-2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: stunn...@packages.debian.org, r...@debian.org Control: affects -1 + src:stunnel4 Hi, This is a pre-approval request before I upload an update to the stunnel4 package targetting bookworm to fix a bug in the handling of improperly closed TLS connections; see #1041545. The patch was taken from stunnel4 version 5.70 that I just uploaded to unstable. [ Reason ] In versions before 5.70, stunnel4 fails to recognize a new OpenSSL 3.x error code that signals that the remote side closed the network connection without performing a proper TLS shutdown. Instead, stunnel treats this situation as an error. If there was any pending data that the stunnel service had enqueued for sending over the encrypted connection, it is discarded, so if the TLS session is later resumed, the encrypted data stream will be corrupted. [ Impact ] Quoting from the changelog entry for version 5.70: - Fixed TLS socket EOF handling with OpenSSL 3.x. This bug caused major interoperability issues between stunnel built with OpenSSL 3.x and Microsoft's Schannel Security Support Provider (SSP). The stunnel4 version in bookworm can fail to interoperate with some TLS applications, thus rendering the package unusable for people who want to set up such tunnels. [ Tests ] For the present there are no automated tests for this problem, but it can be reproduced manually using the following procedure: - set up a tunnel in non-client mode (stunnel4 accepts TLS connections and forwards to a plain-text service) listening on e.g. a loopback address and forwarding to e.g. another port on the loopback address - start (or restart) the stunnel4 service (a systemd user service will work just as well) so that it listens for incoming TLS connections - start a program that listens for plain-text connections, e.g. `nc -v -l 127.0.0.2 8086` - use `openssl s_client -connect ...` to connect to the stunnel instance - type a couple of words on both sides to make sure data is being forwarded correctly - kill the OpenSSL `s_client` process using e.g. an ABRT or FPE signal so that it does not get a chance to perform the proper TLS shutdown - look for an error message in the logs of the stunnel service; the error may look like: "LOG3[0]: SSL_read: ../ssl/record/rec_layer_s3.c:303: error:0A000126:SSL routines::unexpected eof while reading" The appearance of this error message means that stunnel has failed to recognize the OpenSSL error code that signifies an unexpectedly closed network connection, and treats it as an error instead of a closed connection. With the attached patch, stunnel will instead report "LOG6[1]: TLS socket closed (SSL_read)". [ Risks ] The code is easy to follow for people familiar with the C language; it is a no-op if the OpenSSL version used does not support that particular error code, and if it does, it is recognized and treated as a closed network connection event. In my opinion the risk is minimal, if any at all. [ 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 ] A new patch is added as the debian/patches/08-tls-eof.patch file; it adds several lines to the "handle an SSL error" case in the src/client.c file. diff -Nru stunnel4-5.68/debian/changelog stunnel4-5.68/debian/changelog --- stunnel4-5.68/debian/changelog 2023-02-12 13:40:09.0 +0200 +++ stunnel4-5.68/debian/changelog 2023-07-20 22:01:31.0 +0300 @@ -1,3 +1,11 @@ +stunnel4 (3:5.68-2+deb12u1) bookworm; urgency=medium + + * Add the 08-tls-eof patch to fix the handling of a peer closing +a TLS connection without proper TLS shutdown messaging. + Closes: #1041545 + + -- Peter Pentchev Thu, 20 Jul 2023 22:01:31 +0300 + stunnel4 (3:5.68-2) unstable; urgency=medium * Add the 07-tests-errmsg patch to fix the FTBFS on several architectures diff -Nru stunnel4-5.68/debian/patches/08-tls-eof.patch stunnel4-5.68/debian/patches/08-tls-eof.patch --- stunnel4-5.68/debian/patches/08-tls-eof.patch 1970-01-01 02:00:00.0 +0200 +++ stunnel4-5.68/debian/patches/08-tls-eof.patch 2023-07-20 22:00:46.0 +0300 @@ -0,0 +1,41 @@ +Description: Fix handling of socket closed without TLS shuttdown + In versions before 5.70, stunnel4 fails to recognize a new OpenSSL 3.x + error code that signals that the remote side closed the network + connection without performing a proper TLS shutdown. Instead, stunnel + treats this situation as an error. + . + If there was any pending data that the stunnel service had enqueued for + sending over the encrypted connection, it is discarded, so if the TLS + session is later resumed, the encrypted data stream will be corrupted. +Bug-Debian: h
Bug#1041545: [stunnel4] Fails to recognize EOF on a TLS socket without a proper TLS shutdown
Package: stunnel4 Version: 3:5.68-2 Severity: important Tags: patch upstream X-Debbugs-Cc: r...@debian.org In versions before 5.70, stunnel4 fails to recognize a new OpenSSL 3.x error code that signals that the remote side closed the network connection without performing a proper TLS shutdown. Instead, stunnel treats this situation as an error. If there was any pending data that the stunnel service had enqueued for sending over the encrypted connection, it is discarded, so if the TLS session is later resumed, the encrypted data stream will be corrupted. This is fixed in stunnel-5.70 by a block of code in the src/client.c file handling the SSL_R_UNEXPECTED_EOF_WHILE_READING error constant. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.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 stunnel4 depends on: ii adduser 3.134 ii init-system-helpers 1.65.2 ii libc6 2.37-5 ii libssl3 3.0.9-1 ii libsystemd0 253.5-1 ii libwrap07.6.q-32 ii netbase 6.4 ii openssl 3.0.9-1 ii perl5.36.0-7 ii systemd [systemd-sysusers] 253.5-1 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database -- no debconf information signature.asc Description: PGP signature
Bug#1041439: zchunk: backport to bookworm
On Tue, Jul 18, 2023 at 11:05:53PM +0200, Bastian Germann wrote: > Source: zchunk > Version: 1.3.1+ds1-1 > Severity: wishlist > X-Debbugs-Cc: r...@debian.org > > Hi, > > I would like to backport zchunk to bookworm. May I upload one? Wait, bookworm-backports is open now? Argh... so I just went back and reread the last couple of messages to d-b-changes and, wow, I did misread a couple of bookworm uploads as bullseye ones... Hm, thanks for reaching out and thanks a lot for volunteering. However, would you be terribly upset if I did the backport myself? Or I would at least like to keep it as part of pkg-rpm-team; if you do feel strongly about maintaining the backport (and I am not trying to gatekeep here, sorry if it sounds that way), would you consider joining the team? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1039051: RFA: gforth -- GNU Forth Language Environment
Package: wnpp Severity: normal X-Debbugs-Cc: gfo...@packages.debian.org, r...@debian.org Control: affects -1 + src:gforth I request an adopter for the gforth package. Turns out that in the past couple of years I have not given it enough care and attention. There is a Git repository containing all my Debian packaging work at https://gitlab.com/gforth/pkg-debian-full The package was in good shape at the time of its last update, but things have moved on since then. Notably, I tried to bring in some new upstream beta versions every now and then, but they failed their build-time tests, and it would appear overly optimistic to keep pretending that I will track those test failures down. The package description is: This is the GNU'ish implementation of a Forth programming environment. . Forth, as a language, is best known for being stack-based, and completely extensible. Each Forth environment provides one or more dictionaries of pre-defined words, and programming in Forth consists of defining and executing new words that are combinations of previously defined words. It has been said that learning Forth changes forever the way you think about writing programs. . For more information about Forth, visit the Forth Interest Group web site at http://www.forth.org/fig.html. Thanks in advance to whomever picks this package up! signature.asc Description: PGP signature
Bug#1038728: Coordinating libzstd 1.5.5 + python-zstandard 0.21.0 upload
On Wed, Jun 21, 2023 at 10:38:44AM +0300, Peter Pentchev wrote: > On Tue, Jun 20, 2023 at 11:34:18AM -0400, Boyuan Yang wrote: > > Source: libzstd > > Severity: normal > > Version: 1.5.4+dfsg2-5 > > Tags: sid > > Control: affects -1 src:python-zstandard > > X-Debbugs-CC: r...@debian.org > > > > Dear Debian libzstd maintainer, > > > > As we discussed months ago, we would like to coordinate on the package > > upload between src:libzstd and src:python-zstandard to use libzstd with > > matched versions. > > > > Please let me know when you plan to upgrade libzstd, and I shall coordinate > > the upgrade of src:python-zstandard to match libzstd release. Currently > > python-zstandard/0.21.0 needs libzstd/1.5.5. > > Yeah, thanks. I did in fact start working on the libzstd update to > version 1.5.5 (and other packaging refreshments) a couple of days ago; > I will let you know when I have something ready for testing your > updates against (before I upload it). > > Thanks for your work! Hi, I believe the Salsa Git repository for libzstd now contains a pretty much ready to upload version of libzstd/1.5.5+dfsg2-1. You can test your package update against it; I tested the build of zchunk and it worked fine. If you trust me, there are amd64 binary packages in my own Debian package repository: Types: deb deb-src URIs: https://debian.ringlet.net/debian-ringlet/ Suites: UNRELEASED Components: main Signed-By: /usr/share/keyrings/ringlet-keyring.gpg ...and the ringlet-keyring.gpg file (that contains my own OpenPGP key, the same one as in the Debian keyring) can be fetched from https://debian.ringlet.net/keys/ringlet-keyring.gpg Thanks again for your work and for coordinating these uploads! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1038728: Coordinating libzstd 1.5.5 + python-zstandard 0.21.0 upload
On Tue, Jun 20, 2023 at 11:34:18AM -0400, Boyuan Yang wrote: > Source: libzstd > Severity: normal > Version: 1.5.4+dfsg2-5 > Tags: sid > Control: affects -1 src:python-zstandard > X-Debbugs-CC: r...@debian.org > > Dear Debian libzstd maintainer, > > As we discussed months ago, we would like to coordinate on the package > upload between src:libzstd and src:python-zstandard to use libzstd with > matched versions. > > Please let me know when you plan to upgrade libzstd, and I shall coordinate > the upgrade of src:python-zstandard to match libzstd release. Currently > python-zstandard/0.21.0 needs libzstd/1.5.5. Yeah, thanks. I did in fact start working on the libzstd update to version 1.5.5 (and other packaging refreshments) a couple of days ago; I will let you know when I have something ready for testing your updates against (before I upload it). Thanks for your work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1037027: bsdtar tiny mistake
On Fri, Jun 02, 2023 at 12:55:59AM +, Budi wrote:
> Package: bsdtar
>
> its help message
>
> First option must be a mode specifier:
> -c Create -r Add/Replace -t List -u Update -x Extract
> Common Options:
> -b # Use # 512-byte records per I/O block
> -f Location of archive (default /dev/st0)
> -vVerbose
> -wInteractive
> Create: bsdtar -c [options] [ | | @ | -C ]
> , add these items to archive
> -z, -j, -J, --lzma Compress archive with gzip/bzip2/xz/lzma
> --format {ustar|pax|cpio|shar} Select archive format
> --exclude Skip files that match pattern
> -C Change to before processing remaining files
> @ Add entries from to output
> List: bsdtar -t [options] []
> If specified, list only entries that match
> Extract: bsdtar -x [options] []
> If specified, extract only entries that match
> -kKeep (don't overwrite) existing files
> -mDon't restore modification times
> -OWrite entries to stdout, don't restore to disk
> -pRestore permissions (including ACLs, owner, file flags)
>
> isn't supposed
>
> -C Change to before processing remaining files
>
>
> line in/under Extract: bsdtar -x .
>
> as tested works on: bsdtar -xf ..
> not work on bsdtar -cf ...
Thanks for your interest in bsdtar and libarchive!
I don't know, it works for me here, exactly as explained in
longer form in the manual page:
[roam@straylight ~/tmp/v/roam/tartest]$ mkdir sub
[roam@straylight ~/tmp/v/roam/tartest]$ echo 616 > sub/world.txt
[roam@straylight ~/tmp/v/roam/tartest]$ bsdtar -cf world-at-top-level.tar
-C sub world.txt
[roam@straylight ~/tmp/v/roam/tartest]$ bsdtar -tf world-at-top-level.tar
world.txt
[roam@straylight ~/tmp/v/roam/tartest]$ mkdir newsub
[roam@straylight ~/tmp/v/roam/tartest]$ bsdtar -xf world-at-top-level.tar
-C newsub
[roam@straylight ~/tmp/v/roam/tartest]$ cat newsub/world.txt
616
[roam@straylight ~/tmp/v/roam/tartest]$
What commands exactly did you try?
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: > On Sun, 14 May 2023 at 22:37, Josh Triplett wrote: > > > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > > > The loader is still available via the old path, so external/third > > > party/local/other software works unchanged. This should negatively > > > only affect our 1st party packages, when running on a non-merged > > > distro. > > > And are _all_ our packages really 100% compatible with other distros > > > at all? Are they even supposed to be? > > > > People build things on Debian that are not Debian packages. People > > compile binaries on Debian, and expect them to work on any system that > > has sufficiently new libraries. > > > > This is *not* about Debian packages failing to work on other > > distributions; this is about *software compiled on Debian* faliing to > > work in other environments. > > Why would "software compiled on Debian" fail to work in other > environments? Well, there are many reasons actually, people invented > containers/flatpaks/snaps exactly for that reason. But nothing do with > anything discussed here though, as far as I can tell? If an ELF executable, compiled on Debian, records its interpreter as /usr/lib/ld-linux.so.2, what happens when one tries to run it on a non-usr-merged system? Even one with a recent enough glibc version? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1036002: unblock: utf8-locale/1.0.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: utf8-loc...@packages.debian.org, r...@debian.org
Control: affects -1 + src:utf8-locale
Please unblock package utf8-locale
Version 1.0.0-2 fixes the #1035441 RC bug (serious, missing dependency
that breaks functionality). The package does have an autopkgtest suite,
and https://tracker.debian.org/pkg/utf8-locale seems to think that
everything is going to be just fine, but... I uploaded the package on
2023-05-04, which means that the 20-day wait before the testing
migration would place it *just* after the 2023-05-24 full freeze.
Any assistance would be appreciated :)
[ Reason ]
The C library's -dev package was missing a dependency on the C library
package itself, making the -dev package practically unusable.
[ Impact ]
Anyone who installs the -dev package and does not also explicitly
install the shared library package would not be able to link C programs
against the shared library.
[ Tests ]
The bug was caught by a piuparts run that flagged a dangling symlink.
I missed it because my autopkgtest suite installs all the packages
anyway, so there is no missing package :/
[ Risks ]
None at all, I believe.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock utf8-locale/1.0.0-2
diff -Nru utf8-locale-1.0.0/debian/changelog utf8-locale-1.0.0/debian/changelog
--- utf8-locale-1.0.0/debian/changelog 2022-10-23 00:55:41.0 +0300
+++ utf8-locale-1.0.0/debian/changelog 2023-05-04 21:30:41.0 +0300
@@ -1,3 +1,12 @@
+utf8-locale (1.0.0-2) unstable; urgency=medium
+
+ * Add the forgotten -dev package dependency on the library one.
+Closes: #1035441
+ * Add the year 2023 to my debian/* copyright notice
+ * Declare compliance with Policy 4.6.2 with no changes
+
+ -- Peter Pentchev Thu, 04 May 2023 21:30:41 +0300
+
utf8-locale (1.0.0-1) unstable; urgency=medium
* Declare compliance with Policy 4.6.1 with no changes.
diff -Nru utf8-locale-1.0.0/debian/control utf8-locale-1.0.0/debian/control
--- utf8-locale-1.0.0/debian/control2022-10-23 00:47:03.0 +0300
+++ utf8-locale-1.0.0/debian/control2023-05-04 21:26:59.0 +0300
@@ -9,7 +9,7 @@
pybuild-plugin-pyproject,
python3-all,
python3-setuptools,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Homepage: https://devel.ringlet.net/devel/utf8-locale/
Rules-Requires-Root: no
Vcs-Git: https://gitlab.com/ppentchev/utf8-locale.git -b debian/unstable
@@ -34,6 +34,7 @@
Section: libdevel
Architecture: any
Depends:
+ libutf8-locale0 (= ${binary:Version}),
${misc:Depends},
${shlibs:Depends},
Description: Detect a UTF-8-capable locale for running programs in -
development files
diff -Nru utf8-locale-1.0.0/debian/copyright utf8-locale-1.0.0/debian/copyright
--- utf8-locale-1.0.0/debian/copyright 2022-10-23 00:39:50.0 +0300
+++ utf8-locale-1.0.0/debian/copyright 2023-05-04 21:26:31.0 +0300
@@ -9,7 +9,7 @@
License: BSD-2-clause
Files: debian/*
-Copyright: Copyright (c) 2022 Peter Pentchev
+Copyright: Copyright (c) 2022, 2023 Peter Pentchev
License: BSD-2-clause
License: BSD-2-clause
signature.asc
Description: PGP signature
Bug#1036000: unblock: sniproxy/0.6.0-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: snipr...@packages.debian.org, snipr...@packages.debian.org,
r...@debian.org
Control: affects -1 + src:sniproxy
Please unblock package sniproxy
Version 0.6.0-2.1 fixes the #1033752 RC bug (grave, security)
about a buffer overflow that may lead to arbitrary code
execution. I am in the process of adopting the package
(see #1035759), and I'm in communication with Thorsten
Alteholz, who did the NMU to fix the bug.
[ Reason ]
Security issue, arbitrary code execution due to a buffer overflow.
See #1033752 for details.
[ Impact ]
Systems where sniproxy is used are currently vulnerable to
remote code execution.
[ Tests ]
The next upstream version of sniproxy, 0.6.1, that was
released with a single change - to fix this bug - and that
I will soon upload to experimental, contains a test case that
makes sure sniproxy does not die on such a malformed request:
https://github.com/dlundquist/sniproxy/commit/f8d9a433fe22ab2fa15c00179048ab02ae23d583#diff-e1a0a6ea76cf301ec1fc8564ca08c0a20ae7fdc14f27355ab77a217e09efd833
(the bad_dns_request_test change)
The patch includes this change, although the tests are not
run during the Debian package build or afterwards; however,
a manual `make check` in the package build directory will
show the test passing.
I intend to try to run those tests both during the build and
as autopkgtests.
[ Risks ]
The fix is straightforward (for someone familiar with network
programming in C) and targeted. IMHO the risks are minimal,
if any at all.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock sniproxy/0.6.0-2.1
diff -Nru sniproxy-0.6.0/debian/changelog sniproxy-0.6.0/debian/changelog
--- sniproxy-0.6.0/debian/changelog 2020-07-23 23:27:57.0 +0300
+++ sniproxy-0.6.0/debian/changelog 2023-04-29 20:03:02.0 +0300
@@ -1,3 +1,11 @@
+sniproxy (0.6.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * CVE-2023-25076 (Closes: #1033752)
+fix buffer overflow while handling wildcard backend hosts
+
+ -- Thorsten Alteholz Sat, 29 Apr 2023 19:03:02 +0200
+
sniproxy (0.6.0-2) unstable; urgency=medium
* Fix "ftbfs with GCC-10" by applying patch
diff -Nru sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch
sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch
--- sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch 1970-01-01
02:00:00.0 +0200
+++ sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch 2023-04-29
20:03:02.0 +0300
@@ -0,0 +1,71 @@
+commit f8d9a433fe22ab2fa15c00179048ab02ae23d583
+Author: Dustin Lundquist
+Date: Thu Mar 16 20:42:20 2023 -0700
+
+address: fix buffer overflow
+
+Update tests to work on Debian 11.
+
+Index: sniproxy-0.6.0/src/address.c
+===
+--- sniproxy-0.6.0.orig/src/address.c 2023-04-29 19:26:00.397699547 +0200
sniproxy-0.6.0/src/address.c 2023-04-29 19:26:00.397699547 +0200
+@@ -143,6 +143,8 @@
+ if (hostname_or_ip[0] == '[' &&
+ (port = strchr(hostname_or_ip, ']')) != NULL) {
+ len = (size_t)(port - hostname_or_ip - 1);
++if (len >= INET6_ADDRSTRLEN)
++return NULL;
+
+ /* inet_pton() will not parse the IP correctly unless it is in a
+ * separate string.
+Index: sniproxy-0.6.0/tests/Makefile.am
+===
+--- sniproxy-0.6.0.orig/tests/Makefile.am 2023-04-29 19:26:00.397699547
+0200
sniproxy-0.6.0/tests/Makefile.am 2023-04-29 19:26:25.017710380 +0200
+@@ -1,5 +1,7 @@
+ AM_CPPFLAGS = -I$(top_srcdir)/src -g $(LIBEV_CFLAGS) $(LIBPCRE_CFLAGS)
$(LIBUDNS_CFLAGS)
+
++.NOTPARALLEL:
++
+ TESTS = address_test \
+ buffer_test \
+ cfg_tokenizer_test \
+Index: sniproxy-0.6.0/tests/bad_dns_request_test
+===
+--- sniproxy-0.6.0.orig/tests/bad_dns_request_test 2023-04-29
19:26:00.397699547 +0200
sniproxy-0.6.0/tests/bad_dns_request_test 2023-04-29 19:26:00.397699547
+0200
+@@ -36,6 +36,11 @@
+ client => \_client,
+ },
+ {
++# Exceed hostname buffer size
++request => "GET / HTTP/1.1\r\nHost: [" . 'long.' x 60 .
"example.com]\r\n\r\n",
++client => \_client,
++},
++{
+ # Test client aborting connection before DNS response received
+ request => "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n",
+ client => \_client_abort,
+Index: sniproxy-0.6.0/tests/slow_client_test
+===
+--- sniproxy-0.6.0.orig/tests/slow_client_test 2023-04-29 19:26:00.397699547
+0200
sniproxy-0.6.0/tests/slow_client_test 2023-04-29 19:26:00.397699547
Bug#1035759: ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support
control: retitle -1 ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support control: owner -1 ! Thanks for your work on sniproxy over the years! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1035034: unblock: libmodulemd/2.14.0-3
Control: tags -1 -moreinfo
On Fri, Apr 28, 2023 at 08:55:51PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo confirmed
>
> On 2023-04-28 04:58:51 +0300, Peter Pentchev wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: libmodul...@packages.debian.org,
> > team+pkg-...@tracker.debian.org, r...@debian.org
> > Control: affects -1 + src:libmodulemd
> >
> > Please unblock package libmodulemd; this is a pre-approval request
> > before I upload version 2.14.0-3 to unstable.
>
> Please remove the moreinfo tag once the package is available in
> unstable.
libmodulemd-2.14.0-3 is in unstable now and it is already built for
all release architectures.
Thanks!
> > In version 2.13.0-1, I moved a file from the libmodulemd-dev package to
> > the gir1.2-modulemd-2.0 one, and I forgot to add the appropriate
> > Breaks+Replaces relationship. Helmut Grohne kindly reminded me in
> > the severity: serious bug #1034935 (thanks!).
> >
> > [ Reason ]
> > Declare the Breaks+Replaces relationship so that dpkg will not fail to
> > unpack the new version of the gir-* package over the old version of
> > the -dev one.
> >
> > [ Impact ]
> > An upgrade from bullseye to bookworm will break, see #1034935.
> >
> > [ Tests ]
> > piuparts, I guess... no idea why I did not notice that :(
> >
> > [ Risks ]
> > IMHO, no risk at all.
> >
> > [ Checklist ]
> > [x] all changes are documented in the d/changelog
> > [x] I reviewed all changes and I approve them
> > [x] attach debdiff against the package in testing
> >
> > unblock libmodulemd/2.14.0-3
>
> > diff -Nru libmodulemd-2.14.0/debian/changelog
> > libmodulemd-2.14.0/debian/changelog
> > --- libmodulemd-2.14.0/debian/changelog 2022-12-26 13:38:43.0
> > +0200
> > +++ libmodulemd-2.14.0/debian/changelog 2023-04-28 04:48:28.0
> > +0300
> > @@ -1,3 +1,10 @@
> > +libmodulemd (2.14.0-3) unstable; urgency=medium
> > +
> > + * Declare that the gir-* package Breaks+Replaces older versions of
> > +the -dev one. Closes: #1034935
> > +
> > + -- Peter Pentchev Fri, 28 Apr 2023 04:48:28 +0300
> > +
> > libmodulemd (2.14.0-2) unstable; urgency=medium
> >
> >* Use the GitHub API in the watch file.
> > diff -Nru libmodulemd-2.14.0/debian/control
> > libmodulemd-2.14.0/debian/control
> > --- libmodulemd-2.14.0/debian/control 2022-12-26 13:38:30.0
> > +0200
> > +++ libmodulemd-2.14.0/debian/control 2023-04-28 04:45:57.0
> > +0300
> > @@ -70,6 +70,8 @@
> > Section: introspection
> > Architecture: any
> > Multi-Arch: same
> > +Breaks: libmodulemd-dev (<< 2.13.0-1~)
> > +Replaces: libmodulemd-dev (<< 2.13.0-1~)
> > Depends:
> > ${gir:Depends},
> > ${misc:Depends},
>
>
>
>
> --
> Sebastian Ramacher
--
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#1035034: unblock: libmodulemd/2.14.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libmodul...@packages.debian.org, team+pkg-...@tracker.debian.org,
r...@debian.org
Control: affects -1 + src:libmodulemd
Please unblock package libmodulemd; this is a pre-approval request
before I upload version 2.14.0-3 to unstable.
In version 2.13.0-1, I moved a file from the libmodulemd-dev package to
the gir1.2-modulemd-2.0 one, and I forgot to add the appropriate
Breaks+Replaces relationship. Helmut Grohne kindly reminded me in
the severity: serious bug #1034935 (thanks!).
[ Reason ]
Declare the Breaks+Replaces relationship so that dpkg will not fail to
unpack the new version of the gir-* package over the old version of
the -dev one.
[ Impact ]
An upgrade from bullseye to bookworm will break, see #1034935.
[ Tests ]
piuparts, I guess... no idea why I did not notice that :(
[ Risks ]
IMHO, no risk at all.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock libmodulemd/2.14.0-3
diff -Nru libmodulemd-2.14.0/debian/changelog
libmodulemd-2.14.0/debian/changelog
--- libmodulemd-2.14.0/debian/changelog 2022-12-26 13:38:43.0 +0200
+++ libmodulemd-2.14.0/debian/changelog 2023-04-28 04:48:28.0 +0300
@@ -1,3 +1,10 @@
+libmodulemd (2.14.0-3) unstable; urgency=medium
+
+ * Declare that the gir-* package Breaks+Replaces older versions of
+the -dev one. Closes: #1034935
+
+ -- Peter Pentchev Fri, 28 Apr 2023 04:48:28 +0300
+
libmodulemd (2.14.0-2) unstable; urgency=medium
* Use the GitHub API in the watch file.
diff -Nru libmodulemd-2.14.0/debian/control libmodulemd-2.14.0/debian/control
--- libmodulemd-2.14.0/debian/control 2022-12-26 13:38:30.0 +0200
+++ libmodulemd-2.14.0/debian/control 2023-04-28 04:45:57.0 +0300
@@ -70,6 +70,8 @@
Section: introspection
Architecture: any
Multi-Arch: same
+Breaks: libmodulemd-dev (<< 2.13.0-1~)
+Replaces: libmodulemd-dev (<< 2.13.0-1~)
Depends:
${gir:Depends},
${misc:Depends},
signature.asc
Description: PGP signature
Bug#1034012: libzstd: Possible data corruption in zstd 1.5.x
control: notfound -1 1.5.4+dfsg2-4 On Thu, Apr 06, 2023 at 03:02:20PM +0300, Andrey Semashev wrote: > Package: libzstd1 > Version: 1.5.4+dfsg2-3 > Source: libzstd > > It was discovered that zstd versions from 1.5.0 to 1.5.4, inclusively, > may exhibit data corruption on high compression levels (>= 13). This is > fixed in zstd 1.5.5 and outlined in the release notes and the related > pull request: > > https://github.com/facebook/zstd/releases/tag/v1.5.5 > https://github.com/facebook/zstd/pull/3517 > > Please consider upgrading to zstd 1.5.5 or backporting the patch with > the fix. Hi, Thanks for filing this bug report. The patch is already included in libzstd 1.5.4+dfsg2-5 in unstable; I guess I will have to ask the release managers for a freeze exception so that this version migrates to testing. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1030630: Acknowledgement (mariadb: FTBFS on sparc64: /bin/sh: Bad address)
On Fri, Feb 10, 2023 at 09:12:01AM -0800, Otto Kekäläinen wrote: > For the record, latest upload 10.11.1-4 in > https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A10.11.1-4=1676000962=0 > no longer had the bad address issue, but instead if failed on two > tests: [snip] First of all, let me thank you for all your work on MariaDB, and let me thank the sparc64 porters for making it possible to build anything on Debian/sparc64 at all :) FWIW, I've been wondering whether something may be wrong with the sparc64 builder for a couple of weeks now: libzstd has been failing to build there since February: https://buildd.debian.org/status/logs.php?pkg=libzstd=sparc64 Now, I can explain the -1, -2, and -4 failures, they were due to problems in an upstream test that is run at build time, but the -3 and -5 ones should not really have happened: those uploads of libzstd built pretty much fine on all other Debian architectures (barring the ones where the build dependencies were unavailable). The cause for the failed builds seems to be a segfault that I cannot reproduce in a sbuild+schroot+qemu run on my x86_64 laptop. Of course, it may turn out that the problem is somehow related to the amount of memory, CPUs, or other differences in the build environment. Of course, it may be totally unrelated to the failed MariaDB builds, but I just thought I'd mention it in case it turns out to be. Once again, thanks everyone, and keep up the great work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1032592: libzstd: FTBFS on hppa and others - numeric value overflows 32-bit unsigned int
On Sat, Mar 18, 2023 at 11:25:52PM +0200, Peter Pentchev wrote: > On Thu, Mar 09, 2023 at 04:39:16PM +, John David Anglin wrote: > > Source: libzstd > > Version: 1.5.4+dfsg2-4 > > Severity: normal > > Tags: ftbfs [snip] > > 1.5.2+dfsg2-3 was okay. > > Well... it's not that it was okay, it's that some of the tests failed in -1, > so I disabled them in -2, then I applied an upstream fix and reenabled them in > -3, thinking that everything would be fine, but it was not :) ...and of course I messed up the revisions there, but you get the gist... > So yeah, thanks again for keeping track and filing this bug! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1032592: libzstd: FTBFS on hppa and others - numeric value overflows 32-bit unsigned int
On Thu, Mar 09, 2023 at 04:39:16PM +, John David Anglin wrote: > Source: libzstd > Version: 1.5.4+dfsg2-4 > Severity: normal > Tags: ftbfs > > Dear Maintainer, > > Build fails testing basic decompression: [snip] Actually this is a red herring, these error messages appear in the logs of the successful builds for the other architectures. The tests for zstd have some... questionable reporting. > Full log is here: > https://buildd.debian.org/status/fetch.php?pkg=libzstd=hppa=1.5.4%2Bdfsg2-4=1678356348=0 Yeah, I noticed that pretty much as soon as I uploaded -4, but it was some time before I could get into it, investigate it, and experiment properly. Thanks for filing the bug, though - it does help keep me honest :) > 1.5.2+dfsg2-3 was okay. Well... it's not that it was okay, it's that some of the tests failed in -1, so I disabled them in -2, then I applied an upstream fix and reenabled them in -3, thinking that everything would be fine, but it was not :) So yeah, thanks again for keeping track and filing this bug! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote: > On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote: > > Hi, > > > > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道： > > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum > > > wrote: > > > > Source: python-zstandard > > > > Version: 0.19.0-3 > > > > Severity: serious > > > > Justification: FTBFS > > > > Tags: bookworm sid ftbfs > > > > User: lu...@debian.org > > > > Usertags: ftbfs-20230216 ftbfs-bookworm > > > > > > > > Hi, > > > > > > > > During a rebuild of all packages in sid, your package failed to build > > > > on amd64. > > > > > > At the moment this is creating quite > > > the havoc with making a bunch of things FTBFS as well (see merhged bugs) > > > > > > This is likely due to py-zst trying to link with the zstandard in the > > > archive > > > which does not seem to go very well. > > > > > > Is someone working to fix this? > > > > Thanks for cc-ing. I did not monitor bugs for this package before. > > > > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out > > and have it packaged. > > > > On the long run, the mismatch of src:libzstd and src:python-zstandard will > > always occur intermittently due to its nature. I am not sure whether re- > > enabling bundled libzstd would be a good choice, but at least let's fix the > > combination for Debian 12 first. > > > > Any suggestions? > > Oof. Sorry about that. I guess I didn't consider the python-zstandard > package at all until now. > > As I am a member of both the pkg-rpm and pkg-python teams, I could try to > update the packages in sync from now on, possibly adding something like > Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to > libzstd itself if it breaks the then-current python-zstandard package. (of course, I meant Breaks: python3-zstandard (<< ...)) ...of course, another - or rather, an additional - option would be to relax (or remove) the check that python-zstandard makes regarding the libzstd version recorded at compile time. Since both libzstd upstream and the Debian package tries to hold true to the usual semver-like compatiblity scheme, python-zstandard ought to be able to believe that even a more recent version of libzstd would be ABI-compatible unless it has reason to think otherwise - and that case could be handled by Breaks: python3-zstandard (<< next-version) in libzstd as outlined above. So maybe (for future new upstream versions of libzstd): - relax (or remove) the python3-zstandard check for the libzstd version - each time a new libzstd upload is about to be done, check that python3-zstandard works, too - if it works, do nothing else, upload libzstd as usual - if python3-zstandard would for some reason break and needs updating, hold off with the libzstd upload until an updated version of python3-zstandard is released upstream, make sure it will work, and only then upload libzstd with a Breaks declaration - upload the updated version of python3-zstandard immediately (maybe even simultaneously) and declare a Depends relationship on the just-uploaded version of libzstd (as it does now) If this sounds good, I believe I can do it that way for future libzstd uploads. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z
On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote: > Hi, > > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道： > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum > > wrote: > > > Source: python-zstandard > > > Version: 0.19.0-3 > > > Severity: serious > > > Justification: FTBFS > > > Tags: bookworm sid ftbfs > > > User: lu...@debian.org > > > Usertags: ftbfs-20230216 ftbfs-bookworm > > > > > > Hi, > > > > > > During a rebuild of all packages in sid, your package failed to build > > > on amd64. > > > > At the moment this is creating quite > > the havoc with making a bunch of things FTBFS as well (see merhged bugs) > > > > This is likely due to py-zst trying to link with the zstandard in the > > archive > > which does not seem to go very well. > > > > Is someone working to fix this? > > Thanks for cc-ing. I did not monitor bugs for this package before. > > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out > and have it packaged. > > On the long run, the mismatch of src:libzstd and src:python-zstandard will > always occur intermittently due to its nature. I am not sure whether re- > enabling bundled libzstd would be a good choice, but at least let's fix the > combination for Debian 12 first. > > Any suggestions? Oof. Sorry about that. I guess I didn't consider the python-zstandard package at all until now. As I am a member of both the pkg-rpm and pkg-python teams, I could try to update the packages in sync from now on, possibly adding something like Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to libzstd itself if it breaks the then-current python-zstandard package. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1030757: ITP: python-parse-stages -- Parse a mini-language for selecting objects by tag or name
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-parse-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/parse-stages * License : BSD-2-clause Programming Lang: Python Description : Parse a mini-language for selecting objects by tag or name This library is mostly useful for command-line parsing by other tools like `tox-stages` and `nox-stages`. It may be used to parse e.g. a command-line specification like `@check and not pylint` or `@tests or ruff` and then match it against a list of objects that have names and lists of tags. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1030756: ITP: python-test-stages -- Run Tox, Nox, etc. tests in groups, stopping on errors
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-test-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/test-stages * License : BSD-2-clause Programming Lang: Python Description : Run Tox, Nox, etc. tests in groups, stopping on errors The `test-stages` library provides command-line tools that wrap Python test environment runners such as Tox or Nox, invoking them so as the various tests are run in parallel, in groups, as specified on the command line. This allows the fastest tests to be run first, and the slower ones to only be started if it makes sense (e.g. if tools like [ruff] or [flake8] did not uncover any trivial syntax errors). The `tox-stages` tool runs Tox with the specified groups of test environments, stopping if any of the tests in a group should fail. This allows quick static check tools like e.g. `ruff` to stop the testing process early, and also allows scenarios like running all the static check tools before the package's unit or functional tests to avoid unnecessary failures on simple errors. The syntax for grouping the test environments to be run is described in the `parse-stages` library's documentation. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1030546: qt6-base FTBFS on hppa
On Mon, Feb 06, 2023 at 03:22:21PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Control: tag -1 -patch > > El lunes, 6 de febrero de 2023 15:03:41 -03 Lisandro Damián Nicanor Pérez > Meyer escribió: > > clone 1030546 -1 > > reassign -1 src:libzstd 1.5.2+dfsg2-3 > > severity -1 important > > retitle -1 libzstd: breaks detection using cmake? > > block 1030546 by -1 > > thanks > > > > El sábado, 4 de febrero de 2023 18:23:34 -03 Helge Deller escribió: > > > Package: qt6-base > > > Tags: patch, ftbfs, hppa > > > Version: 6.4.2+dfsg > > > > > > The attached patch fixes this qt6-base "build-from-source" (FTBFS) failure > > > on hppa: /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o): > > > relocation R_PARISC_DPREL21L can not be used when making a shared object; > > > recompile with -fPIC > > > > > > The problem is, that qt6-base suddenly tries to link against the static > > > library of libzstd.a, while in the past it did linked against the shared > > > library: > > > > > > In current failing build (6.4.2+dfsg-1): > > > -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required > > > is "1.3") Full log is here: > > > https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4. > > > 2% 2Bdfsg-1=1675198832=0 > > > > > > while it worked in the past for qt6-base 6.4.2+dfsg~rc1-1 > > > -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable > > > version "1.5.2", minimum required is "1.3") Full log is here: > > > https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4. > > > 2% 2Bdfsg%7Erc1-1=1672201686=0 > > > > > > The attached patch changes WrapZSTD to prefer the dynamic library. > > > > the source code between those two versions (and in fact between > > 6.4.2+dfsg~rc1-1 and 6.4.2+dfsg~rc1-2) did not change, so there must be > > something else, external, triggering the change here. > > > > Look at this, on 6.4.2+dfsg~rc1-1 with libzstd 1.5.2+dfsg-1 > > > > -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable > > version "1.5.2", minimum required is "1.3") > > > > But on 6.4.2+dfsg~rc1-2, with 1.5.2+dfsg2-1: > > > > -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required > > is "1.3") > > > > > > libzstd maintainers: for some reason the libzstd detection changed between > > 1.5.2+dfsg-1 and 1.5.2+dfsg2-1. > > Well, the clone failed, but maybe this is not necessary. > > If I'm reading the code and the packaging changes correctly the change is > that > zstd changed from generating just pkgconfig files from also generating cmake > files. In this case the cmake files take precedence, but neither > zstd::libzstd_shared nor zstd::libzstd_static are being defined, and Helge's > patch reverses the order, thus changing the default. FWIW, I think that you're mostly on the right path, but with a small correction: both zstd::libzstd_shared and zstd::libzstd_static are defined by libzstd's newly-exposed CMake config. I added --trace-expand to qt6-base's dh_auto_configure arguments, and got (among much else) this output: ... /<>/cmake/FindWrapZSTD.cmake(21): find_package(zstd CONFIG QUIET ) /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdConfigVersion.cmake(12): set(PACKAGE_VERSION 1.5.2 ) ... /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake(69): add_library(zstd::libzstd_shared SHARED IMPORTED ) /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake(71): set_target_properties(zstd::libzstd_shared PROPERTIES INTERFACE_INCLUDE_DIRECTORIES /usr/include ) /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake(76): add_library(zstd::libzstd_static STATIC IMPORTED ) /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake(78): set_target_properties(zstd::libzstd_static PROPERTIES INTERFACE_INCLUDE_DIRECTORIES /usr/include ) ... /<>/cmake/FindWrapZSTD.cmake(25): if(TARGET zstd::libzstd_static OR TARGET zstd::libzstd_shared ) ... /<>/cmake/FindWrapZSTD.cmake(28): if(TARGET zstd::libzstd_static ) /<>/cmake/FindWrapZSTD.cmake(29): set(zstdtargetsuffix _static ) ... So qt6-base's cmake/FindWrapZSTD.cmake file asks CMake about the zstd configuration, then correctly determines that either the shared or the static libraries are defined as CMake targets (they both are), and then, at cmake/FindWrapZSTD.cmake line 28, prefers the static one to the shared one. That's what caused the change in behavior. > I'll open a bug upstream about this, in the meantime I'll create a derivative > patch that forces using the shared library, ie , being more aggressive so > it's > understood. Thanks for your analysis and your work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1027657: libmaa: FTBFS: dh_auto_build: error: exec (for cmd: mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDI
On Sun, Jan 01, 2023 at 03:34:44PM +0100, Lucas Nussbaum wrote: > Source: libmaa > Version: 1.4.7-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230101 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > debian/rules binary > > dh "binary" --buildsystem=mkcmake > >dh_update_autotools_config -O--buildsystem=mkcmake > >dh_autoreconf -O--buildsystem=mkcmake > >dh_auto_configure -O--buildsystem=mkcmake > >dh_auto_build -O--buildsystem=mkcmake > > mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info > > SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu > > LIBEXECDIR=/usr/lib/x86_64-linux-gnu > > Can't exec "mkcmake": No such file or directory at > > /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 518. > > dh_auto_build: error: exec (for cmd: mkcmake PREFIX=/usr > > MANDIR=/usr/share/man INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= > > LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDIR=/usr/lib/x86_64-linux-gnu) > > failed: No such file or directory > > dh_auto_build: error: mkcmake PREFIX=/usr MANDIR=/usr/share/man > > INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= > > LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDIR=/usr/lib/x86_64-linux-gnu > > returned exit code 25 > > make: *** [debian/rules:12: binary] Error 25 > > > The full build log is available from: > http://qa-logs.debian.net/2023/01/01/libmaa_1.4.7-1_unstable.log FTR, I think this was fixed by the upload of mk-configure/0.37.0-2, which actually installed the package files (including the mkcmake program). I believe this bug can be closed; a manual rebuild of libmaa in an unstable-amd64 chroot (with mk-configure-0.37.0-2) worked for me just now. Thanks for your periodic full archive rebuilds and for all your work on Debian! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#502468: keychain: always starts a new ssh-agent with --inherit any and SSH_AUTH_SOCK not set
On Thu, Oct 16, 2008 at 02:09:30PM -0400, Andrew Schulman wrote: > Package: keychain > Version: 2.6.8-2 > Severity: normal > > > When SSH_AUTH_SOCK is not set, keychain --inherit any never finds > an existing ssh-agent. It always starts a new one: > > $ echo $SSH_AUTH_SOCK > $ cat .keychain/helium-sh > SSH_AUTH_SOCK=/tmp/ssh-AeUWcuq462/agent.462; export SSH_AUTH_SOCK; > SSH_AGENT_PID=463; export SSH_AGENT_PID; > $ pgrep -U andrex ssh-agent > 463 > $ keychain --inherit any Hi, I'm sorry for not replying to this bug report earlier when I adopted the Debian package of keychain. Also, yeah, I realize that the bug report was filed a long time ago and you may have moved on. Still... are you sure that `--inherit any` is what you want to use in this case? Would `--inherit any-once` not be better? When I try running keychain after a ~/.keychain/-sh file has already been created, `--inherit any-once` looks at the file and uses the already running SSH agent. Again, sorry for not replying sooner! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#778792: ucspi-tcp-ipv6: tcprules doesn't support ipv6 addresses in rules file
control: owner -1 !
On Thu, Feb 19, 2015 at 11:33:25PM +0100, Michal Jirků wrote:
> Package: ucspi-tcp-ipv6
> Version: 1:0.88-3
> Severity: normal
> Tags: ipv6
>
> Dear Gerrit,
Hi,
I am currently in the process of adopting maintainership of
the ucspi-tcp package, so I came across this bug report that
was filed some years ago.
> I have found a problem with ucspi-tcp-ipv6 package; namely that
> tcprules dies when it encounters ipv6 address in rules file.
> E.g. adding ipv6 address to /etc/tcp.smtp fails:
>
> 2 root@palladium ~ # qmailctl cdb
> tcprules: fatal: unable to parse this line:
> 2001:4898:e0:66:82fa:5bff:fe0f:c0c9:allow,WHITELISTED="yes"
> Reloaded /etc/tcp.smtp.
Can you still reproduce this bug with a recent version of
the ucspi-tcp-ipv6 package?
If I run the attached shell program:
a) on my Debian testing laptop,
b) in a Debian unstable chroot environment, and
c) in a Debian Stretch chroot environment with ucspi-tcp-ipv6
version 1:0.88-3.1
...it always succeeds: the tcprules invocation succeeds, and all
the tcprulescheck invocations produce the expected result. Can you run
it on your system and see what happens? If something goes wrong with
attaching it (I have deliberately changed its extension to .txt so that
it should not give any mail filters a scare, but then who knows),
you can also find it at:
https://devel.ringlet.net/misc/test-tcprules/test-tcprules.txt
> I have discussed this issue with Felix von Leitner (the original
> author of the ipv6 patch for ucspi-tcp) and he's under the impression
> this is an issue related to this debian package.
>
> Because his patch does add the support for ipv6 addresses in tcprules.
> (works for him)
>
> We compared the tcprules.c file and the one shipping with ucspi-tcp-ipv6
> package seems to be unaffected by the changes providing the necessary
> support. E.g. tcprules.c:126 reads:
>
> colon = byte_chr(x,len,':');
[snip]
Yes, but the ucspi-tcp source package builds ucspi-tcp twice: once in
the actual source directory, and once in an ipv6/ subdirectory after
copying all the files there and applying Felix von Leitner's IPv6 patch.
So the fact that you cannot see the change in the tcprules.c file in
the source package still does not mean that the patch is not applied.
Sorry for bothering you if you have moved on to another way of doing
things in the years since you filed that bug report. Still, thank you
for trying to improve Debian by reporting a problem!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
#!/bin/sh
#
# Copyright (c) 2023 Peter Pentchev
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
set -e
set -x
check()
{
if [ "$#" -lt 2 ]; then
echo 'Internal error: check() invoked with too few arguments'
1>&2
exit 1
fi
local ipaddr="$1"
shift
env TCPREMOTEIP="$ipaddr" tcprulescheck rules.cdb > result.txt
cat result.txt
local arg=''
for arg; do
grep -Fe "$arg" result.txt
grep -Fqe "$arg" result.txt
done
}
# First, make sure the package is installed
dpkg-query -W -f '${Package}\t${Version}\n' ucspi-tcp-ipv6 | grep -Fe '1:0.88-'
# Create a temporary directory
tempd="$(mktemp -d -t test-tcprules.XX)"
trap "rm -rf -- '$tempd'" HUP INT QUIT TERM EXIT
cd -- "$tempd"
# Create the input file
cat <<'EOINPUT' > rules.txt
127.0.0.:
Bug#1027014: debhelper: pass --destdir to `meson install`
Package: debhelper
Version: 13.11.3
Severity: normal
Tags: patch
X-Debbugs-Cc: r...@debian.org
Hi,
First of all, thanks a lot for making Debian packaging a lot easier by
working on debhelper!
What do you think of the attached patch (also tracked in a Salsa merge request,
https://salsa.debian.org/debian/debhelper/-/merge_requests/101) that makes
the new `meson install` invocation pass the destdir as an argument to
`--destdir` instead of a positional parameter? I stumbled upon this when
I tried to use the new buildsystem functionality in the libmodulemd package:
putting 14 in debian/compat and changing the debhelper-compat B-D to
debhelper (>> 13.11~) made the build fail:
dh_auto_install
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson install
/<>/debian/tmp
usage: meson [-h]
{setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,help}
...
meson: error: unrecognized arguments: /<>/debian/tmp
dh_auto_install: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson
install /<>/debian/tmp returned exit code 2
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
Thanks again for all your work on Debian!
G'luck,
Peter
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.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 debhelper depends on:
ii autotools-dev20220109.1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.13.0-2
ii dpkg 1.21.13
ii dpkg-dev 1.21.13
ii dwz 0.14+20220924-2
ii file 1:5.41-4
ii libdebhelper-perl13.11.3
ii libdpkg-perl 1.21.13
ii man-db 2.11.1-1
ii perl 5.36.0-6
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make
-- no debconf information
From 70705d6429387f2142676b42d53dead01b547c09 Mon Sep 17 00:00:00 2001
From: Peter Pentchev
Date: Mon, 26 Dec 2022 11:57:01 +0200
Subject: [PATCH] Pass --destdir to `meson install`
The `meson install` subcommand does not like a directory passed directly as
a positional argument.
---
lib/Debian/Debhelper/Buildsystem/meson.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/Debian/Debhelper/Buildsystem/meson.pm
b/lib/Debian/Debhelper/Buildsystem/meson.pm
index 9d11b2c6..d82512f3 100644
--- a/lib/Debian/Debhelper/Buildsystem/meson.pm
+++ b/lib/Debian/Debhelper/Buildsystem/meson.pm
@@ -136,6 +136,7 @@ sub test {
sub install {
my $this = shift;
+ my ($destdir) = @_;
my $target = $this->get_targetbuildsystem;
if (compat(13) or $target->NAME ne 'ninja') {
@@ -148,7 +149,7 @@ sub install {
'LC_ALL' => 'C.UTF-8',
}
);
- $this->doit_in_builddir(\%options, 'meson', 'install', @_);
+ $this->doit_in_builddir(\%options, 'meson', 'install',
'--destdir', $destdir);
}
return 1;
}
--
2.35.1
signature.asc
Description: PGP signature
Bug#1026975: ITP: python-toml -- library for parsing and creating TOML
On Sun, Dec 25, 2022 at 09:11:29AM -0300, Josenilson Ferreira da Silva wrote: > Package: wnpp > Severity: wishlist > Owner: Josenilson Ferreira da Silva > X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com > > * Package name: python-toml > Version : 0.10.2 > Upstream Author : William Pearson > * URL : https://github.com/uiri/toml > * License : MIT/expat > Programming Lang: Python > Description : library for parsing and creating TOML > > this package is a dependency for "dom-toml" > Where "dom-toml" is a required dependency for the "whey" package: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204 Er, is this not https://tracker.debian.org/pkg/python-toml already? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1024974: [libc6] Schroedinger's fnmatch() in an UTF-8 locale
Package: libc6
Version: 2.36-5
Severity: normal
Tags: upstream
X-Debbugs-Cc: r...@debian.org
Hi,
Thanks for taking care of glibc in Debian!
While trying to write a test case for a text processing utility that is
sort of aware of locales and character encodings, I stumbled upon
the fact that, in an UTF-8-capable locale, fnmatch() seems to think
that the `ñ` ("enye", "LATIN SMALL LETTER N WITH TILDE", U+00F1)
character should match both the "?" and "??" patterns. See the attached
C program and the `run-test.sh` demonstration tool; `make test` in
a directory where all four files are installed should do it.
If anything goes wrong with the attached files, they are also available
in a GitLab repository at https://gitlab.com/ppentchev/fnmess
A bullseye chroot and Docker container do not show the problem
(the test passes).
FTR, I was able to reproduce the problem on an AlmaLinux 9 system with
glibc 2.34, so it might not be limited to 2.36.
Thanks in advance for your time, and keep up the great work!
G'luck,
Peter
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.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 libc6 depends on:
ii libgcc-s1 12.2.0-9
Versions of packages libc6 recommends:
ii libidn2-0 2.3.3-1+b1
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.79
pn glibc-doc
ii libc-l10n 2.36-5
pn libnss-nis
pn libnss-nisplus
ii locales2.36-5
-- debconf information:
* libraries/restart-without-asking: true
glibc/disable-screensaver:
glibc/kernel-not-supported:
glibc/kernel-too-old:
glibc/restart-failed:
glibc/restart-services:
glibc/upgrade: true
#!/usr/bin/make -f
#
# Copyright (c) 2022 Peter Pentchev
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
CPPFLAGS?= -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
CFLAGS_WARN?= -Wall -W -Wextra -Wno-trigraphs
CFLAGS_OPT?=-g -O -pipe
CFLAGS?=${CFLAGS_WARN} ${CFLAGS_OPT}
LDFLAGS?=
LIBS?=
all:fnmess
fnmess: fnmess.o
cc ${LDFLAGS} -o fnmess fnmess.o ${LIBS}
fnmess.o: fnmess.c
cc -c ${CPPFLAGS} ${CFLAGS} -o fnmess.o fnmess.c
clean:
rm -f fnmess fnmess.o
test: all
sh run-test.sh python3 fnmess.py
sh run-test.sh ./fnmess
.PHONY: clean all test
/**
* Copyright (c) 2022 Peter Pentchev
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR A
Bug#1024173: python-cfg-diag breaks remrun autopkgtest: 'Config' object has no attribute 'diag_'
On Tue, Nov 15, 2022 at 09:43:48PM +0100, Paul Gevers wrote: > Source: python-cfg-diag, remrun > Control: found -1 python-cfg-diag/0.4.0-1 > Control: found -1 remrun/0.2.2-1 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of python-cfg-diag the autopkgtest of remrun fails in > testing when that autopkgtest is run with the binary packages of > python-cfg-diag from unstable. It passes when run with only packages from > testing. In tabular form: > >passfail > python-cfg-diagfrom testing0.4.0-1 > remrun from testing0.2.2-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of python-cfg-diag to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and reassign > the bug to the right package? Hi, Thanks for filing this bug report, and thanks for working on all the infrastructure related to debci, autopkgtest, and ci.debian.org; it has made working on Debian easier and more pleasant! I am indeed aware that version 0.4.x of python-cfg-diag will break remrun-0.2.2; that's the reason I uploaded remrun-0.2.3 on the very next day - it includes a bumped dependency on python-cfg-diag >= 0.4 in both debian/control and debian/tests/control. I just realized that maybe I should have given a hint about that breakage in the python-cfg-diag package itself; would it be a good idea to upload a new Debian revision with `Breaks: remrun < 0.2.3`? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1021710: "r"eplacing high nibble doesn't take effect
control: tag -1 + confirmed upstream On Thu, Oct 13, 2022 at 01:41:36PM +0200, Philipp Marek wrote: > Package: hexer > Version: 1.0.6-1 > Severity: normal > X-Debbugs-Cc: phil...@marek.priv.at > > Replacing a nibble (only) has no effect; but the display indicates > otherwise. Thanks for your interest in hexer! This is related to another bug I noticed recently; I will try to fix it in the next couple of days. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1020721: ITA microsocks
package wnpp retitle 1020721 ITA: microsocks -- tiny, portable SOCKS5 server owner 1020721 ! thanks Hi, Thanks for your work on the microsocks package. I will adopt it and update it to the new upstream version. G'luck, Peter signature.asc Description: PGP signature
Bug#1016130: ITP: asdf -- multiple language runtime version manager
On Wed, Jul 27, 2022 at 02:24:36PM -0400, matt wrote: > Package: wnpp > Severity: wishlist > Owner: Matt Barry > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: asdf > Version : 0.10.2 > Upstream Author : Akash Manohar J > * URL : https://asdf-vm.org ITYM https://asdf-vm.com here. > * License : MIT > Programming Lang: Bash > Description : multiple language runtime version manager > > asdf is a CLI tool that can manage multiple language runtime > versions on a per-project basis. It is like gvm, nvm, rbenv > and pyenv (and more) all in one! Simply install your language's > plugin! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1014836: remrun: Source-only upload is needed
On Tue, Jul 12, 2022 at 04:50:57PM -0400, Boyuan Yang wrote: > Source: remrun > Version: 0.2.0-1 > Severity: important > X-Debbugs-CC: r...@debian.org > > Dear Debian remrun package maintainer, > > According to https://tracker.debian.org/pkg/remrun , your package needs > another source-only upload to be able to migrate to Debian Testing. Please > consider making another package upload to solve this problem. Thanks! Thanks for taking an interest in remrun, and thanks for the delayed NMU! The truth is I actually noticed this a couple of days ago (yeah, I know, I *really* should have noticed it three days after the original upload...) and I started working on minor upstream updates before uploading a new Debian version. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1013631: nmu: xnee_3.19-8
On Fri, Jun 24, 2022 at 03:09:43PM +0300, Peter Pentchev wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: r...@debian.org > > nmu xnee_3.19-8 . ANY . unstable . -m "Chase functions broken out into the > libXi.so.6 library. Closes: #1013581" Right, so I forgot to add a description, did I... Sorry about that! So recently, some X11 API functions were broken out into a separate library, libXi.so.6. The cnee executable links to some other libraries, but at the time it was built, there was no libXi.so.6 one, so now running it fails as shown in #1013581: [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?" cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: XIQueryVersion exit code 127 I believe a rebuild would fix that; it did on my local system. Thanks in advance, and sorry for filing this request without a description! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1013631: nmu: xnee_3.19-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: r...@debian.org nmu xnee_3.19-8 . ANY . unstable . -m "Chase functions broken out into the libXi.so.6 library. Closes: #1013581"
Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.
On Fri, Jun 24, 2022 at 01:28:57PM +0200, Vincent Bernat wrote: > On 6/24/22 13:05, Peter Pentchev wrote: > > Source: xnee > > Version: 3.19-8 > > Severity: serious > > X-Debbugs-Cc: r...@debian.org > > > > Hi, > > > > First of all, thanks for taking care of cnee/xnee in Debian! > > > > At some point recently, the XIQueryVersion() function from the X11 API > > moved to a separate library, libXi.so.6, found in the libxi6 Debian package. > > Since cnee 3.19-8 (in both unstable and testing) has not been linked > > against libXi.so.6 at build time, it does not try to load it, resulting in > > errors such as: > > > > [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?" > > cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: > > XIQueryVersion > > exit code 127 > > > > ...which breaks any program that tries to invoke cnee, leading to e.g. > > the wmanager tests breaking in #1013579. > > > > I think that a simple rebuild should be enough - I tested it on my local > > system and the cnee binary is now linked against libXi.so.6, too. > > If this is the case, could you just request a binNMU? Hm, that's actually an interesting idea... I'll look into it, and, in that case, sorry for bothering you! :) So yeah, I will look into it and probably close this bug accordingly. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.
Source: xnee Version: 3.19-8 Severity: serious X-Debbugs-Cc: r...@debian.org Hi, First of all, thanks for taking care of cnee/xnee in Debian! At some point recently, the XIQueryVersion() function from the X11 API moved to a separate library, libXi.so.6, found in the libxi6 Debian package. Since cnee 3.19-8 (in both unstable and testing) has not been linked against libXi.so.6 at build time, it does not try to load it, resulting in errors such as: [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?" cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: XIQueryVersion exit code 127 ...which breaks any program that tries to invoke cnee, leading to e.g. the wmanager tests breaking in #1013579. I think that a simple rebuild should be enough - I tested it on my local system and the cnee binary is now linked against libXi.so.6, too. Thanks again, and keep up the great work! G'luck, Peter -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.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 signature.asc Description: PGP signature
Bug#1008818: why is this rpm's fault?
On Mon, Apr 18, 2022 at 02:56:37PM +0200, la...@debian.org wrote: > > > On one side, “rpm -qa” will create the directory in my home directory as > > myself, but “sudo rpm -qa” will do the wrong thing. > > What do you mean by wrong? > > On my bullseye machine sudo rpm -qa creates the subdirectory in > /root/.rpmdb as root. So IMO this works correct. > > rpm -qa without sudo creates $HOME/rpmdb as my user. This is also > correct. > > I don't understand why this bug was assigned to rpm. If you run sudo without the "set_home" option, thus making it preserve the HOME environment variable, rpm run as root with HOME set to /home/something will indeed do the wrong thing. I will take a look into making the controversial Debian local patch to rpm for creating a per-user database perform some more checks. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1009427: zchunk: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 4
On Tue, Apr 12, 2022 at 09:18:34PM +0200, Bastian Germann wrote: > Am 12.04.22 um 21:04 schrieb Peter Pentchev: > > Thanks for filing this. I fixed it yesterday in the salsa Git repo for > > zchunk packaging: > > > > > > https://salsa.debian.org/pkg-rpm-team/zchunk/-/commit/79c480ffa9df4305c3fc5b0bfc4a553625e4c811 > > > > I intend to upload this in the next day or so; I was mainly waiting for > > the libzstd update to 1.5.x to hit the archive. > > The change is included in 1.2.*, so importing them would be preferrable. Almost. Yeah, sorry, in the hurry to reply I forgot to mention that I have a (not yet uploaded to salsa) update to 1.2.1 (and that's where I got most of that patch) and that that update is what I actually intend to upload in the next day or so, but zchunk 1.2.1 does not include the special case for a test that produces different checksums for 1.5.0 and 1.4.10 (most likely because 1.4.10 came out really recently). and there has been no real incentive for the zchunk developers to support it, since almost everyone has moved on to 1.5.x). So yeah, my update to zchunk-1.2.1 will still carry a version of that patch that only includes the 1.4.10 special case (and yes, I will submit it upstream, just in case). G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1009427: zchunk: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 4
Control: tag -1 + confirmed pending On Tue, Apr 12, 2022 at 08:40:39PM +0200, Lucas Nussbaum wrote: > Source: zchunk > Version: 1.1.16+ds1-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220412 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [snip] > > Summary of Failures: > > > > 23/30 compress auto-chunked file - no dictFAIL > > 0.11s exit status 1 > > 25/30 compress auto-chunked file - dict FAIL > > 0.10s exit status 1 > > 27/30 compress manual file - no dict FAIL > > 0.10s exit status 1 > > 29/30 compress manual file - dict FAIL > > 0.11s exit status 1 > > > > > > Ok: 25 > > Expected Fail: 1 > > Fail: 4 > > Unexpected Pass:0 > > Skipped:0 > > Timeout:0 > > dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 > > MESON_TESTTHREADS=8 meson test returned exit code 4 Thanks for filing this. I fixed it yesterday in the salsa Git repo for zchunk packaging: https://salsa.debian.org/pkg-rpm-team/zchunk/-/commit/79c480ffa9df4305c3fc5b0bfc4a553625e4c811 I intend to upload this in the next day or so; I was mainly waiting for the libzstd update to 1.5.x to hit the archive. Thanks for all your work on Debian! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1008078: zstd: Bump version to 1.4.10
On Wed, Mar 30, 2022 at 10:50:09AM +0200, Sedat Dilek wrote: > Hi, > > Friendly ping... > > BTW, where is the packaging happening today? > > dsc file says: > > Vcs-Browser: https://salsa.debian.org/med-team/libzstd > Vcs-Git: https://salsa.debian.org/med-team/libzstd.git [snip] > Can you please update The Vcs-* fields with the new version? Oooof, good catch! I forgot to update that, thanks a lot! > Just for the records: > > zstd v1.4.10 has many bug-fixes :-). Right... sorry, I am slowly getting 'round to that. Actually, I was about to ask you, since there are other people who would like to see libzstd 1.5 in Debian: does your use case require 1.4, or can it work with 1.5, too? If you do require 1.4, then there will probably have to be a separate package for that and it will have to go through the NEW queue, since I'd like to update libzstd itself to 1.5 some time soon. But anyway, the first step will certainly have to be to update the existing package to 1.4.10; I'll try to do that in the next couple of days, sorry for the delay. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1008207: ITP: remrun -- copy a file to a remote host and execute it there
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@ringlet.net * Package name: remrun Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/remrun/ * License : BSD-2-clause Programming Lang: POSIX shell Description : copy a file to a remote host and execute it there The remrun tool may be useful for one-off execution of a series of commands or a complicated command that does not easily lend itself to shell quoting and escaping via SSH. It copies the specified file to the remote host using SSH under a temporary filename, executes it on the remote side, then removes the temporary file. signature.asc Description: PGP signature
Bug#1007969: make: recognize more commands as shell built-ins
Package: make
Version: 4.2.1-1.2
Severity: normal
X-Debbugs-CC: r...@debian.org
Dear Maintainer,
First of all, thanks a lot for taking care of GNU make in Debian!
What do you think about the attached patches to the version of make in
Debian 10 (buster) that backport two commits from version 4.3 and
let make recognize more commands (both in recipes and in $(shell ...))
as shell built-ins that really need to be run via /bin/sh? I realize
that it may be a bit weird to file a report against oldstable, but
buster is still a supported release, and there is at least one shell
built-in, namely "command", that is in relatively wide use and hence
leads to problems.
I am also attaching a sample Makefile that demonstrates the way make(1)
fails to recognize "command" and "alias" as shell built-ins. I know that
"alias" is completely pointless in non-interactive shells, but it is on
the list of more recognized built-ins in the second patch/commit, so it
was easy to use for testing.
Thanks in advance for looking at this, and keep up the great work!
G'luck,
Peter
-- System Information:
Debian Release: 10.11
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages make depends on:
ii libc6 2.28-10
make recommends no packages.
Versions of packages make suggests:
pn make-doc
-- no debconf information
From 3f947d1a7dce1cffc4f20ffafab7e896f8919c7f Mon Sep 17 00:00:00 2001
From: Peter Pentchev
Date: Sat, 19 Mar 2022 20:05:01 +0200
Subject: [PATCH 1/3] Add "command" as a known shell built-in.
Obtained from:
https://git.savannah.gnu.org/cgit/make.git/commit/?id=1af314465e5dfe3e8baa839a32a72e83c04f26ef
---
job.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/job.c b/job.c
index 31799a5..857b8a1 100644
--- a/job.c
+++ b/job.c
@@ -2464,7 +2464,7 @@ construct_command_argv_internal (char *line, char
**restp, const char *shell,
{ "cd", "echo", "eval", "exec", "exit", "login", "logout", "set", "umask",
"wait", "while", "for", "case", "if", ":", ".", "break", "continue",
"export", "read", "readonly", "shift", "times", "trap", "switch",
- "unset", "ulimit", 0 };
+ "unset", "ulimit", "command", 0 };
const char *sh_chars;
const char **sh_cmds;
@@ -2491,7 +2491,7 @@ construct_command_argv_internal (char *line, char
**restp, const char *shell,
{ "echo", "cd", "eval", "exec", "exit", "login", "logout", "set", "umask",
"wait", "while", "for", "case", "if", ":", ".", "break", "continue",
"export", "read", "readonly", "shift", "times", "trap", "switch",
- "unset", 0 };
+ "unset", "command", 0 };
const char *sh_chars;
const char **sh_cmds;
@@ -2501,7 +2501,7 @@ construct_command_argv_internal (char *line, char
**restp, const char *shell,
static const char *sh_cmds[] =
{ "cd", "eval", "if", "delete", "echo", "copy", "rename", "set", "setenv",
"date", "makedir", "skip", "else", "endif", "path", "prompt", "unset",
- "unsetenv", "version", 0 };
+ "unsetenv", "version", "command", 0 };
#elif defined (WINDOWS32)
/* We used to have a double quote (") in sh_chars_dos[] below, but
@@ -2524,7 +2524,7 @@ construct_command_argv_internal (char *line, char
**restp, const char *shell,
static const char *sh_cmds_sh[] =
{ "cd", "eval", "exec", "exit", "login", "logout", "set", "umask", "wait",
"while", "for", "case", "if", ":", ".", "break", "continue", "export",
- "read", "readonly", "shift", "times", "trap", "switch", "test",
+ "read", "readonly", "shift", "times", &quo
Bug#1001542: perl: Hurd: sysread() fails with a "Bad file descriptor" error
On Tue, Mar 01, 2022 at 07:26:24PM +0200, Niko Tyni wrote:
> Hi, sorry for the delay.
>
> On Sun, Dec 12, 2021 at 12:15:50AM +0200, Peter Pentchev wrote:
> > Package: perl
> > Version: 5.32.1-6
> > Severity: normal
>
> > [roam@exodar ~]$ perl -e 'use v5.10; use strict; use warnings; sysopen my
> > $fh, "/bin/ls", 0 or die "sysopen: $!\n"; say "fd ".fileno $fh; my $data;
> > sysread $fh, $data, 32 or die "sysread: $!\n"; say length $data;'
> > fd 3
> > sysread: Bad file descriptor
>
> Quoting https://www.gnu.org/software/libc/manual/html_node/Access-Modes.html
>
> On GNU/Hurd systems (but not on other systems), O_RDONLY and O_WRONLY
> are independent bits that can be bitwise-ORed together, and it is
> valid for either bit to be set or clear. This means that O_RDWR is the
> same as O_RDONLY|O_WRONLY. A file access mode of zero is permissible;
> it allows no operations that do input or output to the file, but does
> allow other operations such as fchmod.
>
> Indeed, using Fcntl::O_RDONLY instead of 0 works fine for me on exodar.
>
> Python behaves the same btw:
>
> exodar% python3 -c 'import os; print(len(os.read(os.open("/bin/ls", 0),
> 32)))'
> Traceback (most recent call last):
> File "", line 1, in
> OSError: [Errno 1073741833] Bad file descriptor
>
> Closing, but let me know if there are still issues.
Oh wow. That was embarrassing. Thanks a *lot* for looking at this and
for pointing out the blindingly obvious.
I really have no idea how that happened... I mean, I *never* write
open(..., 0) in C; I have no idea why I wrote it there and why
I did not notice it afterwards.
Thanks again, sorry for wasting your time, and keep up the great work!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#1006606: ITP: python-cfg-diag -- common configuration-storage class with a .diag() method
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, r...@debian.org * Package name: python-cfg-diag Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://github.com/storpool/python-cfg_diag * License : BSD-2-clause Programming Lang: Python Description : common configuration-storage class with a .diag() method This module provides four classes that may be used as base classes for storing program runtime configuration with a `verbose` boolean field. The classes provide a `.diag(msg)` method that decides whether to output the provided message based on the value of the object's `verbose` field. I intend to maintain this package within the Python packaging team. signature.asc Description: PGP signature
Bug#1006522: bullseye-pu: package djbdns/1:1.05-13+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: r...@debian.org
This is a future unblock request before I upload
djbdns-1:1.05-13+deb11u1 to fix an RC bug in stable.
[ Reason ]
See #996807 for more information; in short, the tinydns server
program may stop responding to DNS queries because it has
reached the process data size limit. The reason is that recent
versions of glibc appear to need more memory, so the value of
the limit that has been enough for many years now is no longer
adequate. Note that this only happens on some Debian architectures.
[ Impact ]
The authoritative server (tinydns) from the djbdns package will
stop responding to queries, thus not fulfilling its basic purpose.
[ Tests ]
The attached debdiff also backports some improvements to
the autopkgtest suite, including a new test that sends a lot of
queries to the tinydns server to make sure it keeps responding.
[ Risks ]
The fix itself should not pose any risk at all, except maybe when
running the tinydns server in extremely resource-contstrained
environments when the additional 100K now available to the tinydns
process may eat into some other processes' memory. However, it is
my belief that people running tinydns in such environments will
use their own configuration files or at least be mindful of
changes in the Debian packages.
The changes to the autopkgtest suite should also not pose any
risk at all: they are mostly code clean-up and simplification.
If, however, it is your opinion that they are too extensive,
I can prepare another upload that drops them and only adds
the "raise the process data size limit" patch itself.
[ 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 ]
The data limit for the djbdns services is raised by an additional
100,000 bytes to reflect the programs' needs imposed by glibc.
The autopkgtest suite's Python code is cleaned up.
The autopkgtest suite performs an additional check: run a lot of
queries against a tinydns server to make sure it keeps responding.
Thanks in advance for looking at this, and keep up the great work!
G'luck,
Peter
diff -Nru djbdns-1.05/debian/changelog djbdns-1.05/debian/changelog
--- djbdns-1.05/debian/changelog2020-07-28 00:03:21.0 +0300
+++ djbdns-1.05/debian/changelog2022-02-26 19:29:35.0 +0200
@@ -1,3 +1,18 @@
+djbdns (1:1.05-13+deb11u1) bullseye; urgency=medium
+
+ * Add the 0011-datalimit patch to catch up with recent versions of
+glibc generating larger executable files. Closes: #996807
+ * Several improvements to the Python tinytest autopkgtest tool:
+- use "with subprocess.Popen()"
+- simplify the command-line parsing a bit
+- minor import statement fixes
+- add a tox.ini file to make it easier to run static code checkers
+- turn a class into a dataclass
+- send a lot of queries to tinydns to make sure that the fix for
+ #996807 actually works
+
+ -- Peter Pentchev Sat, 26 Feb 2022 19:29:35 +0200
+
djbdns (1:1.05-13) unstable; urgency=medium
* Do not even consider running tinydns during the package build.
diff -Nru djbdns-1.05/debian/patches/0011-datalimit.patch
djbdns-1.05/debian/patches/0011-datalimit.patch
--- djbdns-1.05/debian/patches/0011-datalimit.patch 1970-01-01
02:00:00.0 +0200
+++ djbdns-1.05/debian/patches/0011-datalimit.patch 2022-02-26
19:29:35.0 +0200
@@ -0,0 +1,38 @@
+Description: Raise the axfrdns, dnscache, and tinydns data limit.
+Bug-Debian: https://bugs.debian.org/996807
+Author: Peter Pentchev
+Last-Update: 2021-11-13
+
+--- a/axfrdns-conf.c
b/axfrdns-conf.c
+@@ -50,7 +50,7 @@
+
+ start("run");
+ outs("#!/bin/sh\nexec 2>&1\nexec envdir ./env sh -c '\n exec envuidgid ");
outs(user);
+- outs(" softlimit -d30 tcpserver -vDRHl0 -x tcp.cdb -- \"$IP\" 53 ");
++ outs(" softlimit -d40 tcpserver -vDRHl0 -x tcp.cdb -- \"$IP\" 53 ");
+ outs(auto_home); outs("/sbin/axfrdns\n'\n");
+ finish();
+ perm(0755);
+--- a/dnscache-conf.c
b/dnscache-conf.c
+@@ -118,7 +118,7 @@
+ seed_addtime(); perm(0644);
+ seed_addtime(); start("env/CACHESIZE"); outs("100\n"); finish();
+ seed_addtime(); perm(0644);
+- seed_addtime(); start("env/DATALIMIT"); outs("300\n"); finish();
++ seed_addtime(); start("env/DATALIMIT"); outs("400\n"); finish();
+ seed_addtime(); perm(0644);
+ seed_addtime(); start("run");
+ outs("#!/bin/sh\nexec 2>&1\nexec &1\nexec envuidgid "); outs(user);
+- outs(" envdir ./env softlimit -d30 ");
++ outs(" envdir ./env softlimit -d40
Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python
On Sat, Feb 26, 2022 at 08:12:27AM +, Edward Betts wrote: > Package: wnpp > Severity: wishlist > Owner: Edward Betts > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org > > * Package name: python3-mergedeep > Version : 1.3.4 > Upstream Author : Travis Clarke > * URL : https://github.com/clarketm/mergedeep > * License : MIT > Programming Lang: Python > Description : A deep merge function for Python I think you may have seen this already, but Carsten Schoenert filed #1006479 just today for the same library :) Thanks to both of you for your work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1006178: ITP: tox-delay -- run some Tox tests after others have completed
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org * Package name: tox-delay Version : 0.1.0 Upstream Author : Peter Pentchev * URL : https://devel.ringlet.net/devel/tox-delay/ * License : BSD-2-clause Programming Lang: POSIX shell Description : run some Tox tests after others have completed The tox-delay tool postpones the run of the specified Tox environments after the run of all the others has completed successfully. This may be useful if e.g. there are unit or functional test environments, which it would make no sense to run if the static checkers (pylint, mypy, etc) find problems. signature.asc Description: PGP signature
Bug#1005131: ITP: utf8-locale -- detect a UTF-8-capable locale for running child processes in
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org * Package name: utf8-locale Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/utf8-locale * License : BSD-2 Programming Lang: Python, Rust Description : detect a UTF-8-capable locale for running child processes in Sometimes it is useful for a program to be able to run a child process and more or less depend on its output being valid UTF-8. This can usually be accomplished by setting one or more environment variables, but there is the question of what to set them to - what UTF-8-capable locale is present on this particular system? This is where the utf8_locale module comes in.
Bug#1003281: ITP: bakunbak -- Easily .bak a file or folder, then restore it.
On Fri, Jan 07, 2022 at 09:32:18AM -0500, Michael Webster wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Webster > X-Debbugs-Cc: debian-de...@lists.debian.org, miketwebs...@gmail.com > > * Package name: bakunbak > Version : 1.0.0 > Upstream Author : Michael Webster > * URL : https://github.com/mtwebster/bakunbak > * License : GPL > Programming Lang: Python > Description : Easily .bak a file or folder, then restore it. > > This is a simple convenience tool for making temporary 'backup' > copies of files or folders, by adding and removing .bak to their > filenames. A limited number of options allow copying instead of > moving, and forcing overwrite of existing files. > > - why is this package useful/relevant? For people who do frequent >tests on packages that utilize configuration files or folders, >backing up and restoring previous configurations can become >tedious after a time. This reduces effort. > - is it a dependency for another package? It is standalone.. > - Do you use it? Yes frequently for testing browser package >updates. > - If there are other packages providing similar functionality, >how does it compare? I've found no other packages (though >it's possible something exists in utility/bin package >bundles that doesn't get mentioned in package descriptions. JFYI, are you aware of the "rename" package? I was going to ask whether you are aware of Perl's "prename" command-line utility, but it seems that it has been broken out some time ago... just goes to show my age, I guess :) Also, there are several packages (e.g. krename, gprename, mrename) that have a slightly different focus: rename a lot of files, usually as a one-time thing, with a graphical interface, but yeah, that's not exactly what your tool does. > - How do you plan to maintain it? It is a simple package, I >will maintain it myself. > - Are you looking for co-maintainers? No. > - Do you need a sponsor? I imagine so, as I've not previously >been involved in packaging for Debian. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1002703: bullseye-pu: package libarchive/3.4.3-2+deb11u1
On Thu, Dec 30, 2021 at 09:10:34PM +0100, Salvatore Bonaccorso wrote: > Hi Peter, > > On Mon, Dec 27, 2021 at 10:10:58PM +0200, Peter Pentchev wrote: > > Package: release.debian.org > > Severity: normal > > Tags: bullseye > > User: release.debian@packages.debian.org > > Usertags: pu > > X-Debbugs-Cc: r...@ringlet.net > > > > [ Reason ] > > This is a future unblock request before I upload > > libarchive-3.4.3-2+deb11u1 to fix a couple of bugs that were > > fixed in later upstream versions and in unstable. They are all > > related to setting permissions and ACLs when extracting > > archive members that represent symbolic and hard links. > > > > [ Impact ] > > Extracting some (rarely seen) archives may result in files > > having the wrong access permissions. > > > > [ Tests ] > > All the added patches are taken from upstream commits that > > include both the bugfixes and the testsuite additions to > > check for regressions. > > > > [ Risks ] > > The code is mostly easy to follow, the fixes are straightforward. > > > > [ Checklist ] > > [x] *all* changes are documented in the d/changelog > > [x] I reviewed all changes and I approve them > > [x] attach debdiff against the package in stable > > [x] the issue is verified as fixed in unstable > > > > [ Changes ] > > - correctly extract a hardlink to a symlink using the linkat(2) > > system call > > - do not change the ACLs on symlinks, since that would affect > > the symlink target instead > > - do not accidentally change the access mode of a symlink target > > when a change to the symlink's mode was intended > > > > [ Other info ] > > Thanks in advance for looking at this, and keep up the great work! > > > diff -Nru libarchive-3.4.3/debian/changelog > > libarchive-3.4.3/debian/changelog > > --- libarchive-3.4.3/debian/changelog 2020-08-01 21:46:12.0 > > +0300 > > +++ libarchive-3.4.3/debian/changelog 2021-12-27 18:45:51.0 > > +0200 > > @@ -1,3 +1,12 @@ > > +libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium > > + > > + * Add four upstream fixes for various problems: > > +- fix extracting hardlinks to symlinks > > +- fix handling of symlink ACLs; Closes: 1001986 > > +- never follow symlinks when setting file flags; Closes: 1001990 > > While at it, can you as well add the CVE references to the > debian/changelog? Right... I'm not very smart these days, am I? Thanks a lot for your patience with me these past few weeks! Attached is an updated debdiff, the only difference being the CVE references added to the changelog entry. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 diff -Nru libarchive-3.4.3/debian/changelog libarchive-3.4.3/debian/changelog --- libarchive-3.4.3/debian/changelog 2020-08-01 21:46:12.0 +0300 +++ libarchive-3.4.3/debian/changelog 2021-12-27 18:45:51.00000 +0200 @@ -1,3 +1,13 @@ +libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium + + * Add four upstream fixes for various problems: +- fix extracting hardlinks to symlinks +- CVE-2021-23177: fix handling of symlink ACLs; Closes: 1001986 +- CVE-2021-31566: never follow symlinks when setting file flags; + Closes: 1001990 + + -- Peter Pentchev Mon, 27 Dec 2021 18:45:51 +0200 + libarchive (3.4.3-2) unstable; urgency=medium * Add some more upstream patches: diff -Nru libarchive-3.4.3/debian/patches/series libarchive-3.4.3/debian/patches/series --- libarchive-3.4.3/debian/patches/series 2020-08-01 21:46:12.0 +0300 +++ libarchive-3.4.3/debian/patches/series 2021-12-27 18:45:51.0 +0200 @@ -8,3 +8,7 @@ upstream-rar-read-format.patch upstream-memory-stdlib.patch upstream-max-comp-level.patch +upstream-hardlinks-to-symlinks.patch +upstream-symlink-acls.patch +upstream-set-flags-nofollow.patch +upstream-fixup-nofollow.patch diff -Nru libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch --- libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch 1970-01-01 02:00:00.0 +0200 +++ libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch 2021-12-27 18:45:51.0 +0200 @@ -0,0 +1,168 @@ +Description: Do not follow symlinks when processing the fixup list + Published as CVE-2021-31566 +Origin: upstream, https://github.com/libarchive/libarchive/commit/b41daecb5ccb4c8e3b2c53fd6147109fc12c3043 +Bug-Debian: https://bugs.debian.org/1001990 +Author: Mart
Bug#1002703: bullseye-pu: package libarchive/3.4.3-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: r...@ringlet.net
[ Reason ]
This is a future unblock request before I upload
libarchive-3.4.3-2+deb11u1 to fix a couple of bugs that were
fixed in later upstream versions and in unstable. They are all
related to setting permissions and ACLs when extracting
archive members that represent symbolic and hard links.
[ Impact ]
Extracting some (rarely seen) archives may result in files
having the wrong access permissions.
[ Tests ]
All the added patches are taken from upstream commits that
include both the bugfixes and the testsuite additions to
check for regressions.
[ Risks ]
The code is mostly easy to follow, the fixes are straightforward.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
[ Changes ]
- correctly extract a hardlink to a symlink using the linkat(2)
system call
- do not change the ACLs on symlinks, since that would affect
the symlink target instead
- do not accidentally change the access mode of a symlink target
when a change to the symlink's mode was intended
[ Other info ]
Thanks in advance for looking at this, and keep up the great work!
diff -Nru libarchive-3.4.3/debian/changelog libarchive-3.4.3/debian/changelog
--- libarchive-3.4.3/debian/changelog 2020-08-01 21:46:12.0 +0300
+++ libarchive-3.4.3/debian/changelog 2021-12-27 18:45:51.0 +0200
@@ -1,3 +1,12 @@
+libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium
+
+ * Add four upstream fixes for various problems:
+- fix extracting hardlinks to symlinks
+- fix handling of symlink ACLs; Closes: 1001986
+- never follow symlinks when setting file flags; Closes: 1001990
+
+ -- Peter Pentchev Mon, 27 Dec 2021 18:45:51 +0200
+
libarchive (3.4.3-2) unstable; urgency=medium
* Add some more upstream patches:
diff -Nru libarchive-3.4.3/debian/patches/series
libarchive-3.4.3/debian/patches/series
--- libarchive-3.4.3/debian/patches/series 2020-08-01 21:46:12.0
+0300
+++ libarchive-3.4.3/debian/patches/series 2021-12-27 18:27:13.0
+0200
@@ -8,3 +8,7 @@
upstream-rar-read-format.patch
upstream-memory-stdlib.patch
upstream-max-comp-level.patch
+upstream-hardlinks-to-symlinks.patch
+upstream-symlink-acls.patch
+upstream-set-flags-nofollow.patch
+upstream-fixup-nofollow.patch
diff -Nru libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch
libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch
--- libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch
1970-01-01 02:00:00.0 +0200
+++ libarchive-3.4.3/debian/patches/upstream-fixup-nofollow.patch
2021-12-27 18:26:12.0 +0200
@@ -0,0 +1,168 @@
+Description: Do not follow symlinks when processing the fixup list
+ Published as CVE-2021-31566
+Origin: upstream,
https://github.com/libarchive/libarchive/commit/b41daecb5ccb4c8e3b2c53fd6147109fc12c3043
+Bug-Debian: https://bugs.debian.org/1001990
+Author: Martin Matuska
+Last-Update: 2021-12-20
+
+--- a/Makefile.am
b/Makefile.am
+@@ -556,6 +556,7 @@
+ libarchive/test/test_write_disk.c \
+ libarchive/test/test_write_disk_appledouble.c \
+ libarchive/test/test_write_disk_failures.c \
++ libarchive/test/test_write_disk_fixup.c \
+ libarchive/test/test_write_disk_hardlink.c \
+ libarchive/test/test_write_disk_hfs_compression.c \
+ libarchive/test/test_write_disk_lookup.c \
+--- a/libarchive/archive_write_disk_posix.c
b/libarchive/archive_write_disk_posix.c
+@@ -2461,6 +2461,7 @@
+ {
+ struct archive_write_disk *a = (struct archive_write_disk *)_a;
+ struct fixup_entry *next, *p;
++ struct stat st;
+ int fd, ret;
+
+ archive_check_magic(>archive, ARCHIVE_WRITE_DISK_MAGIC,
+@@ -2478,6 +2479,20 @@
+ (TODO_TIMES | TODO_MODE_BASE | TODO_ACLS | TODO_FFLAGS)) {
+ fd = open(p->name,
+ O_WRONLY | O_BINARY | O_NOFOLLOW | O_CLOEXEC);
++ if (fd == -1) {
++ /* If we cannot lstat, skip entry */
++ if (lstat(p->name, ) != 0)
++ goto skip_fixup_entry;
++ /*
++ * If we deal with a symbolic link, mark
++ * it in the fixup mode to ensure no
++ * modifications are made to its target.
++ */
++ if (S_ISLNK(st.st_mode)) {
++ p->mode &= ~S_IFMT;
++ p-
Bug#1002685: bullseye-pu: package prips/1.1.1-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: r...@ringlet.net Hi, First of all, thanks for all your work on Debian! [ Reason ] This is a future unblock request before I upload prips-1.1.1-3+deb11u1 to fix two upstream bugs that affect the base functionality of the program: an infinite loop if it is asked to print the addresses in a block that ends at the last IPv4 address (255.255.255.255), and incorrect output if asked to combine two very different IP addresses (e.g. 1.1.1.1 and 230.120.1.1) into a single CIDR block. [ Impact ] Incorrect operation of the prips tool with certain input data. [ Tests ] The fix for the 255.255.255.255 address handling includes a test added to the appropriate file in the test suite. The fix for the CIDR output mode includes a new file in the test suite that tests CIDR output; it was not possible to only include the single new test, since this file did not exist in the prips-1.1.1 test suite in bullseye. [ Risks ] The fixes are almost trivial, given familiarity with the C language. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] - add a test for a block that ends at 255.255.255.255 - fix the operation of prips for such a block - add a couple of tests for the CIDR mode output - fix the prips CIDR output for certain input data [ Other info ] Thanks in advance, and keep up the great work! diff -Nru prips-1.1.1/debian/changelog prips-1.1.1/debian/changelog --- prips-1.1.1/debian/changelog2020-05-10 18:58:46.0 +0300 +++ prips-1.1.1/debian/changelog2021-12-26 23:15:45.0 +0200 @@ -1,3 +1,13 @@ +prips (1.1.1-3+deb11u1) bullseye; urgency=medium + + * Add two patches from the 1.2.0 upstream version: +- stop-at-last-address: stop at 255.255.255.255 instead of wrapping + over to 0.0.0.0 and going on forever. Closes: #1001923 +- fix-different-cidr: fix the CIDR (-c) output when the addresses + differ in their very first bit. Closes: #1001924 + + -- Peter Pentchev Sun, 26 Dec 2021 23:15:45 +0200 + prips (1.1.1-3) unstable; urgency=medium * Declare compliance with Debian Policy 4.5.0 with no changes. diff -Nru prips-1.1.1/debian/patches/fix-different-cidr.patch prips-1.1.1/debian/patches/fix-different-cidr.patch --- prips-1.1.1/debian/patches/fix-different-cidr.patch 1970-01-01 02:00:00.0 +0200 +++ prips-1.1.1/debian/patches/fix-different-cidr.patch 2021-12-26 23:15:45.0 +0200 @@ -0,0 +1,106 @@ +Description: CIDR mode: handle "totally different" correctly. + If the addresses differ in their very first bit, report "0.0.0.0/0" + instead of the incorrect "x.y.z.t/32". +Bug-Debian: https://bugs.debian.org/1001924 +Origin: upstream, https://gitlab.com/prips/prips/-/commit/1afd3e6976f946317f3ac9980685549b5216a6f5 +Author: Peter Pentchev +Last-Updated: 2021-12-26 + +--- /dev/null b/t/06-cidrize.t +@@ -0,0 +1,74 @@ ++#!/bin/sh ++# ++# Copyright (c) 2021 Peter Pentchev ++# All rights reserved. ++# ++# Redistribution and use in source and binary forms, with or without ++# modification, are permitted provided that the following conditions ++# are met: ++# 1. Redistributions of source code must retain the above copyright ++#notice, this list of conditions and the following disclaimer. ++# 2. Redistributions in binary form must reproduce the above copyright ++#notice, this list of conditions and the following disclaimer in the ++#documentation and/or other materials provided with the distribution. ++# ++# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ++# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE ++# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ++# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE ++# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL ++# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS ++# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ++# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT ++# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY ++# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF ++# SUCH DAMAGE. ++ ++if [ -f 'tap-functions.sh' ]; then ++ . tap-functions.sh ++elif [ -f 't/tap-functions.sh' ]; then ++ . t/tap-functions.sh ++else ++ echo 'Bail out! Could not find tap-functions.sh' ++ exit 99 ++fi ++ ++[ -z "$PRIPS" ] && PRIPS='./prips' ++ ++plan_ 12 ++ ++v=`$PRIPS -c 127.0.0.0 127.0.0.7 2>/dev/null` ++res="$?" ++exp='127.0.0.0/29' ++if [ "$res" = 0 ]; then ok_; else not_
Bug#1001924: prips: wrong CIDR (-c) output when the first bit differs
Package: prips Version: 0.9.4-1 Severity: normal Tags: patch upstream X-Debbugs-Cc: r...@debian.org There is a bug in pretty much all versions of prips uploaded to Debian. The easiest way to reproduce it is: prips -c 127.0.0.1 128.0.0.1 It should output 0.0.0.0/0, since this is the only CIDR range that covers both addresses (their very first bits differ), but it outputs 127.0.0.1/32 instead. The bug has been fixed upstream: https://gitlab.com/prips/prips/-/commit/1afd3e6976f946317f3ac9980685549b5216a6f5 ...and it will be fixed in my next upload of prips to Debian. G'luck, Peter -- System Information: Distributor ID: Debian Description:Debian GNU/Linux bookworm/sid Release:testing Codename: bookworm Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prips depends on: ii libc6 2.33-1 prips recommends no packages. prips suggests no packages. signature.asc Description: PGP signature
Bug#1001923: prips: fails to stop at the last IPv4 address (255.255.255.255)
Package: prips Version: 0.9.4-1 Severity: normal Tags: patch upstream X-Debbugs-Cc: r...@debian.org There has been a bug in all versions of prips in Debian, both before after I took over upstream development and after. The easiest way to reproduce it is to run: prips 255.255.255.254/31 ...which should output two IP addresses and stop, but it overflows and goes on forever. The bug has been fixed upstream: https://gitlab.com/prips/prips/-/commit/172f71f6803ba5b1212e8ffecccb013ee4adf40b ...and it will be fixed in my next upload of prips to Debian. G'luck, Peter -- System Information: Distributor ID: Debian Description:Debian GNU/Linux bookworm/sid Release:testing Codename: bookworm Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prips depends on: ii libc6 2.33-1 prips recommends no packages. prips suggests no packages. signature.asc Description: PGP signature
Bug#1001612: ITP: deltarpm -- Tools to create and apply deltarpms
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-de...@lists.debian.org, r...@debian.org, team+pkg-...@tracker.debian.org * Package name: deltarpm Version : 3.6.3 Upstream Author : Michael Schroeder * URL : https://github.com/rpm-software-management/deltarpm * License : BSD-3-clause Programming Lang: C, Python Description : Tools to create and apply deltarpms This will bring the deltarpm package back into Debian. It was removed as part of the clean-up of the old Python-2-only createrepo-related tools; however, it is now possible to use deltarpm with the new set of createrepo-c/libmodulemd2/libdrpm0 packages, and it will help run the libdrpm upstream testsuite to its full extent. This is the long description of the package: A deltarpm contains the differences between an old and a new version of an RPM. This makes it possible to recreate the new RPM from the deltarpm and the old RPM. . On Debian and derived systems these tools may be useful for creating and maintaining repositories of RPM packages. I will maintain this package as part of the Debian RPM packaging team. signature.asc Description: PGP signature
Bug#1001542: perl: Hurd: sysread() fails with a "Bad file descriptor" error
Package: perl Version: 5.32.1-6 Severity: normal Hi, First of all, thanks for keeping Perl running on all the Debian architectures! I ran into a problem with a test tool for one of my Debian packages - it would refuse to read a bunch of random bytes from /dev/urandom when running on the Hurd. It turns out that the problem is not specific to /dev/urandom - at least on the exodar.debian.net porterbox right now, the following command fails for /etc/passwd, /tmp/roam.txt, /bin/ls, and /home/roam/foo.c, so it does not seem to depend on file ownership or directory hierarchy. Of course, not being very familiar with the Hurd, I may very well be missing something important here. [roam@exodar ~]$ perl -e 'use v5.10; use strict; use warnings; sysopen my $fh, "/bin/ls", 0 or die "sysopen: $!\n"; say "fd ".fileno $fh; my $data; sysread $fh, $data, 32 or die "sysread: $!\n"; say length $data;' fd 3 sysread: Bad file descriptor [roam@exodar ~]$ I tried comparing the rpctrace output for this command and for a similar Python program, but - again, not being very familiar with the Hurd - there is nothing that immediately caught my eye. Thanks again for all you people do for Perl and Debian in general, and keep up the great work! G'luck, Peter -- System Information: Debian Release: bookworm/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.8+git20210809-486/Hurd-0.9 Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages perl depends on: ii dpkg 1.21.1 ii libperl5.325.32.1-6 ii perl-base 5.32.1-6 ii perl-modules-5.32 5.32.1-6 Versions of packages perl recommends: ii netbase 6.3 Versions of packages perl suggests: pn libtap-harness-archive-perl pn libterm-readline-gnu-perl | libterm-readline-perl-perl ii make4.1-9.1 pn perl-doc -- no debconf information signature.asc Description: PGP signature
Bug#1000575: missing epoch from debugedit (build)dependency
control: tag -1 + confirmed pending On Thu, Nov 25, 2021 at 10:55:24AM +0100, Matthias Klose wrote: > Package: src:rpm > Version: 4.17.0+dfsg1-1 > Severity: important > > missing epoch from debugedit (build)dependency, please (build)depend on > debugedit (>= 1:5.0). Thanks, I don't know what I was thinking... G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1000030: confget: depends on obsolete pcre3 library
control: tag -1 + confirmed upstream pending On Thu, Nov 18, 2021 at 11:49:03AM +, Matthew Vernon wrote: > Source: confget > Severity: important > User: matthew-pcre...@debian.org > Usertags: obsolete-pcre3 > > Dear maintainer, > > Your package still depends on the old, obsolete PCRE3[0] libraries > (i.e. libpcre3-dev). This has been end of life for a while now, and > upstream do not intend to fix any further bugs in it. Accordingly, I > would like to remove the pcre3 libraries from Debian, preferably in > time for the release of Bookworm. Thanks for bringing my attention to this; I really have no idea how I missed that over the past six years :/ I have added pcre2 support to the upstream repository of confget: https://gitlab.com/confget/confget/-/commit/3be97f9b4095eeba8025a8d10908fcafedc1530b I guess I shall release a new upstream version and then update the Debian package in the next couple of days. Thanks again for this and everything else you're doing for Debian, and keep up the great work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#999904: Uncoordinated split of debugedit package out of src:rpm
Version: 4.17.0+dfsg1-1 On Thu, Nov 18, 2021 at 12:19:10PM +0200, Peter Pentchev wrote: > control: tag -1 + confirmed pending > > On Thu, Nov 18, 2021 at 09:45:06AM +0100, Laurent Bigonville wrote: > > Source: debugedit,rpm > > Severity: serious > > Tags: sid bookworm > > > > Hello, > > > > debugedit has been split out of the src:rpm package, but src:rpm is > > still building the package as well. > > > > In addition to that, rpm package has a strong versioned dependency > > against debugedit (debugedit (= 4.16.1.2+dfsg1-3)) which means that rpm > > cannot be installed anymore. > > > > We need to keep this package out of testing until this is resolved > > FTR, it has not been completely uncoordinated, there is an ongoing > discussion on the RPM packaging team's mailing list where Matthias > asked about our plans to upgrade rpm to 4.17 and I confirmed that > there is work in progress and it will most probably be done in > the next couple of days. > > Still, thanks for filing this bug for the purpose of keeping the new > version of debugedit out of testing for the present. Right, and of course I forgot to close this bug in the 4.17.0+dfsg1-1 changelog entry. Thanks again for filing it! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#999905: rpm: diff for NMU version 4.16.1.2+dfsg1-3.1
control: tag -1 + confirmed On Thu, Nov 18, 2021 at 09:56:50AM +0100, Laurent Bigonville wrote: > Package: rpm > Version: 4.16.1.2+dfsg1-3 > Severity: normal > Tags: patch pending > > > Dear maintainer, > > I've prepared an NMU for rpm (versioned as 4.16.1.2+dfsg1-3.1) and > uploaded it to DELAYED/3. Please feel free to tell me if I > should delay it longer. Hi, Yeah, I guess I really should have marked this bug as confirmed and pending yesterday when I started working on the RPM packaging... Thanks for doing this; it is indeed part of the commits that I just pushed - see https://salsa.debian.org/pkg-rpm-team/rpm/-/commits/master/ As mentioned in my comment in another bugreport, my next steps will be to update RPM to version 4.17 and drop the debugedit package. I hope that I will be able to do this within the next day or two. If you prefer, you can leave this upload in the delayed queue just in case I don't make it so that the FTBFS bug gets fixed. Thanks again for your work on this and Debian in general! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#999904: Uncoordinated split of debugedit package out of src:rpm
control: tag -1 + confirmed pending On Thu, Nov 18, 2021 at 09:45:06AM +0100, Laurent Bigonville wrote: > Source: debugedit,rpm > Severity: serious > Tags: sid bookworm > > Hello, > > debugedit has been split out of the src:rpm package, but src:rpm is > still building the package as well. > > In addition to that, rpm package has a strong versioned dependency > against debugedit (debugedit (= 4.16.1.2+dfsg1-3)) which means that rpm > cannot be installed anymore. > > We need to keep this package out of testing until this is resolved FTR, it has not been completely uncoordinated, there is an ongoing discussion on the RPM packaging team's mailing list where Matthias asked about our plans to upgrade rpm to 4.17 and I confirmed that there is work in progress and it will most probably be done in the next couple of days. Still, thanks for filing this bug for the purpose of keeping the new version of debugedit out of testing for the present. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#992465: [lintian] systemd-service-file-outside-lib should not flag /usr/lib/systemd/system/
On Thu, Aug 19, 2021 at 01:57:28AM +0300, Peter Pentchev wrote:
> Package: lintian
> Version: 2.104.0
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: r...@debian.org
>
> Hi,
>
> Thanks a lot for all your work on Lintian!
>
> The systemd-service-file-outside-lib checks have, since 2015, flagged
> unit files found in the /usr/lib/systemd/system/ directory. It seems
> that at some point since then (I'm not exactly sure when), maybe because
> of the merged-/usr layout, maybe for other reasons, systemd on Debian
> has started actually paying attention to unit files found there.
>
> I noticed this almost accidentally, when I rebuilt (still only locally,
> although I do intend to upload it soon) my stunnel4 package with
> debhelper 13.4 as found in unstable now: as part of fixing #987989,
> debhelper now installs unit files in /usr/lib/systemd/system/ instead of
> /lib/systemd/system/; see:
>
>
> https://salsa.debian.org/debian/debhelper/-/commit/d70caa69c64b124e3611c967cfab93aef48346d8
>
> So debhelper now produces packages that will place unit files into /usr,
> and I have just verified that the systemd in testing does, indeed,
> notice these files - I successfully enabled and started a stunnel@foo
> service through a stunnel@.service file in /usr/lib/systemd/system/.
>
> Maybe it's time to change the systemd-service-file-outside-lib check, at
> least partially? (the "do not place unit files in /etc" part is still
> very, very good advice for a package) What do you think about the
> attached patch? Tomorrow I will also send another one that adds
> (?:usr/)? to a couple of other regular expression checks (with some more
> work for at least one of them) so that these files are properly checked,
> too.
So, as promised, here's another patch that tries to extend some more
Lintian checks to files in /usr/lib/systemd/system. Note that it
currently fails the Perl::Critic test, most probably because of
the overly long line 605 in lib/Lintian/Check/InitD.pm, but I decided to
send it to you this way, since I am not exactly sure how you prefer to
resolve this type of problem (I personally would use the /x regex
modifier and split the regex into several lines).
Thanks again for your time and your work!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
From ad576808677d683860db06e17308895ed3449223 Mon Sep 17 00:00:00 2001
From: Peter Pentchev
Date: Fri, 20 Aug 2021 00:43:02 +0300
Subject: [PATCH 2/2] Check files in /usr/lib/systemd/system, too.
---
lib/Lintian/Check/InitD.pm | 10 +-
lib/Lintian/Check/Systemd.pm | 12 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/lib/Lintian/Check/InitD.pm b/lib/Lintian/Check/InitD.pm
index e19231dc3..da6817afd 100644
--- a/lib/Lintian/Check/InitD.pm
+++ b/lib/Lintian/Check/InitD.pm
@@ -601,19 +601,19 @@ sub visit_installed_files {
# check for missing init.d script when alternative init system is present
-if ( $item =~ m{etc/sv/([^/]+)/run$}
-|| $item =~ m{lib/systemd/system/([^/@]+)\.service}) {
+if ( $item =~ m{etc/sv/(?[^/]+)/run$}
+|| $item =~
m{(?usr/)?lib/systemd/system/(?[^/@]+)\.service}) {
-my $service = $1;
+my ($usr, $service) = ($+{usr} // $EMPTY, $+{svc});
$self->hint('package-supports-alternative-init-but-no-init.d-script',
$item)
unless $self->processable->installed->resolve_path(
"etc/init.d/${service}")
or $self->processable->installed->resolve_path(
-"lib/systemd/system/${service}.path")
+"${usr}lib/systemd/system/${service}.path")
or $self->processable->installed->resolve_path(
-"lib/systemd/system/${service}.timer");
+"${usr}lib/systemd/system/${service}.timer");
}
if ($item =~ m{etc/sv/([^/]+)/$}) {
diff --git a/lib/Lintian/Check/Systemd.pm b/lib/Lintian/Check/Systemd.pm
index 74a5c7eb6..06be256bf 100644
--- a/lib/Lintian/Check/Systemd.pm
+++ b/lib/Lintian/Check/Systemd.pm
@@ -116,7 +116,7 @@ sub setup_installed_files {
$self->services($self->get_systemd_service_names(\@service_files));
-my @timers = grep { m{^lib/systemd/system/[^\/]+\.timer$} }
+my @timers = grep { m{^(?:usr/)?lib/systemd/system/[^\/]+\.timer$} }
@{$self->processable->installed->sorted_list};
$self->timers(\@timers);
@@ -325,15 +325,15 @@ sub check_systemd_service_file {
# We are a "standalone" service file if we have no .path or .timer
# equivalent.
my $is_standalone = 1;
-if ($file =~ m{^lib/systemd/
Bug#932419: kakoune: Please package new release; v2019.07.01
Control: fixed -1 2020.01.16-1 On Thu, Jul 18, 2019 at 05:43:05PM -0700, John Eikenberry wrote: > Package: kakoune > Version: 2019.01.20-2 > Severity: wishlist > > Kakoune has released a new version. Please consider updating the packaged > version. Thanks. > > https://github.com/mawww/kakoune/releases/tag/v2019.07.01 Ah... I seem to have forgotten to close this bug, don't I... Anyway, 2020.01.16 is in the archive (and in bullseye), and I am now in the process of packaging 2020.09.01. Thanks for your interest in kakoune! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#992469: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Thu, Aug 19, 2021 at 12:18:51AM -0400, Theodore Ts'o wrote: > There appears to be a rather major regression in debhelper 1.13.4 and > 1.13.4nmu1, which is forcing unit files to go in > /usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd > will actually pay attention to them). > > On systems with ursmerge, things should still work, thanks to the > compatibility symlink, but this will cause packages with unit files > built since debhelper 1.13.4 was released to unstable, or uploaded as > source builds, to be incorrect, triggering a Lintian error and > breaking on systems that don't have usrmerge installed. > > For more details and analysis, please see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992469 > > I just wanted to post a warning that if you were planning on building > or uploading new source-only uploads to unstable now that Bullseye has > been released, and your package contains systemd unit files, you may > want to hold off until this bug gets fixed... Actually, I just reported #992465 against Lintian last night: the Lintian error is outdated. See the original message in #987989 that prompted the debhelper change: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987989#5 I got a scare yesterday, too, when I noticed a local rebuild moved a unit file to /usr/lib/systemd/system/, but then I read #987989 and then I actually tried it - and systemd happily found my service and started it. So, it's not as bad as it looks at first :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#992465: [lintian] systemd-service-file-outside-lib should not flag /usr/lib/systemd/system/
453752 Mon Sep 17 00:00:00 2001
From: Peter Pentchev
Date: Thu, 19 Aug 2021 00:41:23 +0300
Subject: [PATCH] Allow files in /usr/lib/systemd/system/.
---
lib/Lintian/Check/Systemd.pm | 3 ---
t/recipes/checks/systemd/systemd-general/eval/tags | 1 -
tags/s/systemd-service-file-outside-lib.tag| 5 ++---
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/lib/Lintian/Check/Systemd.pm b/lib/Lintian/Check/Systemd.pm
index 6f5ba7c3f..74a5c7eb6 100644
--- a/lib/Lintian/Check/Systemd.pm
+++ b/lib/Lintian/Check/Systemd.pm
@@ -291,9 +291,6 @@ sub check_systemd_service_file {
$self->hint('systemd-service-file-outside-lib', $file)
if $file =~ m{^etc/systemd/system/};
-$self->hint('systemd-service-file-outside-lib', $file)
- if $file =~ m{^usr/lib/systemd/system/};
-
unless ($file->is_open_ok
|| ($file->is_symlink && $file->link eq '/dev/null')) {
diff --git a/t/recipes/checks/systemd/systemd-general/eval/tags
b/t/recipes/checks/systemd/systemd-general/eval/tags
index b09465675..c5aaa1ae5 100644
--- a/t/recipes/checks/systemd/systemd-general/eval/tags
+++ b/t/recipes/checks/systemd/systemd-general/eval/tags
@@ -4,7 +4,6 @@ systemd-general (binary):
systemd-service-file-refers-to-obsolete-target usr/lib
systemd-general (binary): systemd-service-file-refers-to-obsolete-target
etc/systemd/system/systemd-general.test.service syslog.target
systemd-general (binary): systemd-service-file-refers-to-obsolete-bindto
usr/lib/systemd/system/systemd-general.test.service
systemd-general (binary): systemd-service-file-refers-to-obsolete-bindto
etc/systemd/system/systemd-general.test.service
-systemd-general (binary): systemd-service-file-outside-lib
usr/lib/systemd/system/systemd-general.test.service
systemd-general (binary): systemd-service-file-outside-lib
etc/systemd/system/systemd-general.test.service
systemd-general (binary): systemd-service-file-outside-lib
etc/systemd/system/fifo-pipe-as-init.service
systemd-general (binary): systemd-service-file-missing-hardening-features
usr/lib/systemd/system/systemd-general.test.service
diff --git a/tags/s/systemd-service-file-outside-lib.tag
b/tags/s/systemd-service-file-outside-lib.tag
index 222bbf319..cffa68293 100644
--- a/tags/s/systemd-service-file-outside-lib.tag
+++ b/tags/s/systemd-service-file-outside-lib.tag
@@ -4,9 +4,8 @@ Check: systemd
Explanation: The package ships a systemd service file outside
/lib/systemd/system/
.
- Systemd in Debian searches for unit files in /lib/systemd/system/
- and /etc/systemd/system. Notably, it does *not* look
- in /usr/lib/systemd/system/ for service files.
+ Systemd in Debian searches for unit files in
/lib/systemd/system/,
+ /usr/lib/systemd/system/, and /etc/systemd/system.
.
System administrators should have the possibility to overwrite a
service file (or parts of it, in newer systemd versions) by placing a
--
2.32.0
signature.asc
Description: PGP signature
Bug#991787: unblock: ucspi-unix/1.0-2
On Tue, Aug 03, 2021 at 09:19:27AM +0200, Sebastian Ramacher wrote: > On 2021-08-02 01:52:18 +0300, Peter Pentchev wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: r...@debian.org > > > > This is a pre-approval request before I upload ucspi-unix to > > unstable to fix a FTBFS on architectures where dietlibc is > > not built; see #991774. > > None of the release architectures are affected by this bug, so this > sounds like bookworm material to me. It's too late for this type of > changes, sorry. No worries, thanks for your time! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#991787: unblock: ucspi-unix/1.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: r...@debian.org
This is a pre-approval request before I upload ucspi-unix to
unstable to fix a FTBFS on architectures where dietlibc is
not built; see #991774.
[ Reason ]
See #991774 for more details: the way ucspi-unix runs the upstream build
twice is not fully conditional on the presence of the dietlibc build
helpers.
[ Impact ]
The ucspi-unix package is not built at all on architectures that
dietlibc does not support, thus Debian users are currently missing
the ucspi-unix functionality for these architectures.
[ Tests ]
None; it does not currently build at all.
[ Risks ]
Leaf package, not widely used. The risk that exposing Debian users to
the functionality of ucspi-unix would do them harm is, IMHO, negligible.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I based my fix on Dmitry Bogatov's already existing Salsa repository for
ucspi-unix. There was already a Salsa-specific commit there that is not
directly related to this bugfix, but does not affect the package at all.
Still, if you'd prefer me to prepare a new, bullseye-specific branch
that will only include this fix and not the Salsa CI definition, let me
know.
unblock ucspi-unix/1.0-2
diff -Nru ucspi-unix-1.0/debian/changelog ucspi-unix-1.0/debian/changelog
--- ucspi-unix-1.0/debian/changelog 2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/changelog 2021-08-02 01:36:27.0 +0300
@@ -1,3 +1,14 @@
+ucspi-unix (1.0-2) unstable; urgency=medium
+
+ [ Dmitry Bogatov ]
+ * Add a Gitlab CI config file.
+
+ [ Peter Pentchev ]
+ * New maintainer. Closes: #983804
+ * Only run the dietlibc build if possible. Closes: #991774
+
+ -- Peter Pentchev Mon, 02 Aug 2021 01:36:27 +0300
+
ucspi-unix (1.0-1) unstable; urgency=medium
* New maintainer (Closes: #907084)
diff -Nru ucspi-unix-1.0/debian/control ucspi-unix-1.0/debian/control
--- ucspi-unix-1.0/debian/control 2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/control 2021-08-02 00:59:30.0 +0300
@@ -1,7 +1,7 @@
Source: ucspi-unix
Section: net
Priority: optional
-Maintainer: Dmitry Bogatov
+Maintainer: Peter Pentchev
Build-Depends:
debhelper-compat (= 11),
dh-buildinfo (>= 0.11+nmu1),
diff -Nru ucspi-unix-1.0/debian/.gitlab-ci.yml
ucspi-unix-1.0/debian/.gitlab-ci.yml
--- ucspi-unix-1.0/debian/.gitlab-ci.yml1970-01-01 02:00:00.0
+0200
+++ ucspi-unix-1.0/debian/.gitlab-ci.yml2021-08-02 00:57:09.0
+0300
@@ -0,0 +1,5 @@
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ -
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+variables:
+ RELEASE: experimental
diff -Nru ucspi-unix-1.0/debian/rules ucspi-unix-1.0/debian/rules
--- ucspi-unix-1.0/debian/rules 2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/rules 2021-08-02 00:59:38.0 +0300
@@ -41,7 +41,9 @@
echo 'diet gcc $(LDFLAGS)' > diet/conf-ld
override_dh_auto_build:
+ifeq (${HAVE_DIETLIBC},yes)
$(MAKE) -C diet
+endif
$(MAKE) -C glibc
override_dh_auto_install:
signature.asc
Description: PGP signature
Bug#991774: ucspi-unix FTBFS on architectures without dietlibc
control: owner -1 !
control: tag -1 + confirmed patch pending
On Sun, Aug 01, 2021 at 05:47:49PM +0300, Adrian Bunk wrote:
> Source: ucspi-unix
> Version: 1.0-1
> Severity: important
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=ucspi-unix=sid
>
> ...
> chmod 755 compile
> ./compile unixclient.c
> ./compile: 4: exec: diet: not found
> make[2]: *** [Makefile:74: unixclient.o] Error 127
>
>
> This should either be fixed properly, or the build dependency
> on dietlibc-dev should become unconditional to avoid expected
> build failures.
Thanks for the report and for all your work on Debian. I think I have a
fix for this problem - see the attached patch, a.k.a.:
https://salsa.debian.org/debian/ucspi-unix/-/commit/6b39b6e8e4bbccecb140d5bd1519a1c57110a141
I will contact the release team to ask for a pre-approval, just in case
they decide that this is worth doing during the freeze.
Thanks again, and keep up the great work!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
commit 6b39b6e8e4bbccecb140d5bd1519a1c57110a141
Author: Peter Pentchev
Date: Mon Aug 2 00:51:53 2021 +0300
Only run the dietlibc build if possible.
Closes: #991774
Reported by: Adrian Bunk
diff --git a/debian/rules b/debian/rules
index 013eb22..747e13b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,9 @@ override_dh_auto_configure:
echo 'diet gcc $(LDFLAGS)' > diet/conf-ld
override_dh_auto_build:
+ifeq (${HAVE_DIETLIBC},yes)
$(MAKE) -C diet
+endif
$(MAKE) -C glibc
override_dh_auto_install:
signature.asc
Description: PGP signature
Bug#990880: unblock: nomad/0.12.10+dfsg1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: team+pkg...@tracker.debian.org
This is a pre-approval request before I upload nomad to unstable to
fix a security problem (CVE-2021-32575). Thanks in advance, and keep
up the great work!
[ Reason ]
See #990581 for more information: there is a CAP_NET_RAW capability
issue in Nomad that is fixed in a later upstream version.
[ Impact ]
Quoted from
https://discuss.hashicorp.com/t/hcsec-2021-14-nomad-bridge-networking-mode-allows-arp-spoofing-from-other-bridged-tasks-on-same-node/24296
It was discovered that processes launched by the docker, exec, and java
task drivers that make use of Nomad’s bridge networking mode can
perform ARP spoofing attacks against other tasks on the same node.
Specifically, tasks making use of bridge networking are susceptible to
other tasks on the same node performing DoS and MITM attacks due to the
default enablement of the CAP_NET_RAW 6 Linux capability by these task
drivers.
[ Tests ]
The upstream patch adds unit tests to the package's test suite.
[ Risks ]
The patch is not trivial, but its logic is not hard to follow.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock nomad/0.12.10+dfsg1-3
diff -Nru nomad-0.12.10+dfsg1/debian/changelog
nomad-0.12.10+dfsg1/debian/changelog
--- nomad-0.12.10+dfsg1/debian/changelog2021-05-09 10:14:36.0
+0300
+++ nomad-0.12.10+dfsg1/debian/changelog2021-07-10 02:29:09.0
+0300
@@ -1,3 +1,11 @@
+nomad (0.12.10+dfsg1-3) unstable; urgency=medium
+
+ * Team upload.
+ * Adapt the upstream patch for CVE-2021-32575 and add it as
+the disable-cap-net-raw patch. Closes: #990581
+
+ -- Peter Pentchev Sat, 10 Jul 2021 02:29:09 +0300
+
nomad (0.12.10+dfsg1-2) unstable; urgency=medium
* Disabled "TestConfig_outgoingWrapper_OK" (Closes: #987644).
diff -Nru nomad-0.12.10+dfsg1/debian/patches/disable-cap-net-raw.patch
nomad-0.12.10+dfsg1/debian/patches/disable-cap-net-raw.patch
--- nomad-0.12.10+dfsg1/debian/patches/disable-cap-net-raw.patch
1970-01-01 02:00:00.0 +0200
+++ nomad-0.12.10+dfsg1/debian/patches/disable-cap-net-raw.patch
2021-07-05 23:47:53.0 +0300
@@ -0,0 +1,592 @@
+Description: drivers/docker+exec+java: disable net_raw capability by default
+ The default Linux Capabilities set enabled by the docker, exec, and
+ java task drivers includes CAP_NET_RAW (for making ping just work),
+ which has the side affect of opening an ARP DoS/MiTM attack between
+ tasks using bridge networking on the same host network.
+ .
+
https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
+ .
+ This PR disables CAP_NET_RAW for the docker, exec, and java task
+ drivers. The previous behavior can be restored for docker using the
+ allow_caps docker plugin configuration option.
+ .
+ A future version of nomad will enable similar configurability for the
+ exec and java task drivers.
+ .
+ Note (Debian): The upstream patch was adapted because of code changes.
+Origin: upstream;
https://github.com/hashicorp/nomad/commit/003d68fe6df652b172bc68beabd11a25fd7e1b58
+Author: Seth Hoenig
+Bug-Debian: https://bugs.debian.org/990581
+Last-Update: 2021-07-05
+
+--- a/drivers/docker/config.go
b/drivers/docker/config.go
+@@ -35,17 +35,41 @@
+ // it is timed out.
+ dockerTimeout = 5 * time.Minute
+
+- // dockerBasicCaps is comma-separated list of Linux capabilities that
are
+- // allowed by docker by default, as documented in
+- //
https://docs.docker.com/engine/reference/run/#block-io-bandwidth-blkio-constraint
+- dockerBasicCaps =
"CHOWN,DAC_OVERRIDE,FSETID,FOWNER,MKNOD,NET_RAW,SETGID," +
+-
"SETUID,SETFCAP,SETPCAP,NET_BIND_SERVICE,SYS_CHROOT,KILL,AUDIT_WRITE"
+-
+ // dockerAuthHelperPrefix is the prefix to attach to the credential
helper
+ // and should be found in the $PATH. Example: ${prefix-}${helper-name}
+ dockerAuthHelperPrefix = "docker-credential-"
+ )
+
++// nomadDefaultCaps is the subset of dockerDefaultCaps that Nomad enables by
++// default and is used to compute the set of capabilities to add/drop given
++// docker driver configuration.
++func nomadDefaultCaps() []string {
++ return []string{
++ "AUDIT_WRITE",
++ "CHOWN",
++ "DAC_OVERRIDE",
++ "FOWNER",
++ "FSETID",
++ "KILL",
++ "MKNOD",
++ "NET_BIND_SERVICE",
++ "SETFCAP",
++ "SETGID",
++ "SETPCAP",
++ "SETUID",
++ "SYS_CHROOT",
++
Bug#990766: unblock: kakoune/2020.01.16-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package kakoune to fix a grave bug that makes it
unusable if it is started via "su" before being started from
a normal user account.
[ Reason ]
See #990635 for more information: if, after the system has been
restarted, kakoune is invoked via "su" before it has been invoked
from the session user's account, it will create its runtime
/run/user//kakoune directory owned by root. This will prevent
later instances of kakoune, started with normal user rights, from
running at all.
[ Impact ]
If the user runs `su -c 'kak ...'` before running `kak ...`, they
will be unable to run `kak ...` until they remove the runtime
directory or the system is restarted.
[ Tests ]
None.
[ Risks ]
Leaf package, not widely used. The upstream fix is pretty
straightforward - check user IDs, verify directory ownership,
use a different directory if necessary. Hopefully very low risk.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock kakoune/2020.01.16-3
diff -Nru kakoune-2020.01.16/debian/changelog
kakoune-2020.01.16/debian/changelog
--- kakoune-2020.01.16/debian/changelog 2020-07-26 01:56:44.0 +0300
+++ kakoune-2020.01.16/debian/changelog 2021-07-05 22:15:28.0 +0300
@@ -1,3 +1,12 @@
+kakoune (2020.01.16-3) unstable; urgency=medium
+
+ * Add the 13-upstream-check-dir-owner and 14-upstream-rework-dir-logic
+patches from the upstream Git repository to stop kakoune started as
+root from making its runtime directory inaccessible to the normal
+user account of the session user. Closes: #990635
+
+ -- Peter Pentchev Mon, 05 Jul 2021 22:15:28 +0300
+
kakoune (2020.01.16-2) unstable; urgency=medium
* Add some files to debian/clean to allow kakoune to be built twice in
diff -Nru kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch
kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch
--- kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch
1970-01-01 02:00:00.0 +0200
+++ kakoune-2020.01.16/debian/patches/13-upstream-check-dir-owner.patch
2021-07-05 22:05:35.0 +0300
@@ -0,0 +1,22 @@
+Description: Check XDG_RUNTIME_DIR owner before creating session directory
+ This avoids an issue when using `su` and running Kakoune which creates
+ a session directory owned by root and prevents the user from creating
+ more sessions.
+Origin: upstream;
https://github.com/mawww/kakoune/commit/7751c7e188bfc7b2f7e4a70e33032677d84597e5
+Author: Maxime Coste
+Bug-Debian: https://bugs.debian.org/990635
+Last-Update: 2021-07-05
+
+--- a/src/remote.cc
b/src/remote.cc
+@@ -554,6 +554,10 @@
+ // set sticky bit on the shared kakoune directory
+ make_directory(format("{}/kakoune", tmpdir()), 01777);
+ }
++else if (struct stat st;
++ stat(xdg_runtime_dir.zstr(), ) == 0 && st.st_uid != geteuid())
++throw runtime_error("XDG_RUNTIME_DIR is not owned by current user");
++
+ make_directory(session_directory(), 0711);
+ }
+
diff -Nru kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
--- kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
1970-01-01 02:00:00.0 +0200
+++ kakoune-2020.01.16/debian/patches/14-upstream-rework-dir-logic.patch
2021-07-05 22:15:28.0 +0300
@@ -0,0 +1,77 @@
+Description: Rework session directory logic
+ Do not use a shared kakoune/ directory for all users to avoid the
+ complexity of having to set the sticky bit on that dir, resolve the
+ session directory only once by using a static variable and an
+ immediately evaluated lambda.
+ .
+ This fixes an annoyance whenever using `su` and having Kakoune refuse
+ to start due to XDG_RUNTIME_DIR still being set.
+Origin: upstream;
https://github.com/mawww/kakoune/commit/db9ef82398a08bdf985ff26bfb230fb0cd1221a5
+Author: Maxime Coste
+Bug-Debian: https://bugs.debian.org/990635
+Last-Update: 2021-07-05
+
+--- a/src/remote.cc
b/src/remote.cc
+@@ -537,28 +537,20 @@
+ return getenv("USER");
+ }
+
+-String session_directory()
++const String& session_directory()
+ {
+-StringView xdg_runtime_dir = getenv("XDG_RUNTIME_DIR");
+-if (xdg_runtime_dir.empty())
+-return format("{}/kakoune/{}", tmpdir(), get_user_name());
+-else
+-return format("{}/kakoune", xdg_runtime_dir);
+-}
+-
+-void make_session_directory()
+-{
+-StringView xdg_runtime_dir = getenv("XDG_RUNTIME_DIR");
+-if (xdg_runtime_dir.empty())
+-{
+-// set sticky bit on the shared kakoune directory
+-make_directory(format("{}/kakoune", tmpdir())
Bug#990581: nomad: CVE-2021-32575
Hi, First of all, thanks for your work on nomad and Debian in general! Dmitry, what do you think about my attempt to backport the upstream patch for CVE-2021-32575 to the Debian package of nomad? The upstream patch is at: https://github.com/hashicorp/nomad/commit/003d68fe6df652b172bc68beabd11a25fd7e1b58 My proposed update to the Debian package is in my forked Salsa repo: https://salsa.debian.org/roam/nomad/-/commits/roam-CVE-2021-32575/ git clone -b roam-CVE-2021-32575 https://salsa.debian.org/roam/nomad.git If you have no objections, I could push these commits to the team repo, upload to unstable, and send an unblock request to the release team. Thanks again, and keep up the great work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#990635: kakoune: Fatal error: unable to bind listen socket Permission denied
On Sat, Jul 03, 2021 at 04:03:07PM +0300, Peter Pentchev wrote: > Control: tag -1 confirmed upstream patch pending > > On Sat, Jul 03, 2021 at 01:39:49PM +0200, xiscu wrote: > > Package: kakoune > > Version: 2020.01.16-2 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > i'm currently unable to use kakoune as it gives a Permission denied error > > on start > > (reinstalling the package hasn't solved the problem). The programm worked > > for me, > > but currently i get: > > > > Fatal error: unable to bind listen socket '/run/user/1000/kakoune/3781950': > > Permission denied > > Hi, > > Yes, you did stumble into an upstream kakoune bug that is fixed in > a later upstream release that is not in Debian yet. The problem is that > Kakoune determines the name of a "user-specific directory to put some > stuff in" using your desktop environment's idea of a "user-specific > directory to put some stuff in", i.e. the XDG_RUNTIME_DIR environment > variable that is set upon the start of your GUI session. However, if you > *first* run `sudo kak something` (and you have told sudo to preserve > the environment variables!) or `su kak something` (and su, by default, > does preserve the environment variables), as the first thing you do > after restarting your computer, before running Kakoune as yourself, > then Kakoune will create its own directory while running as root, and > the directory will not be writable by your actual user account. > So if later you run it from your user account, it will not be able to > put stuff into that directory. This has happened with other tools, too, > and this is actually part of the reason why sudo does NOT preserve all > the environment variables by default. (Note: I'm not saying "don't use > su, use sudo!"; I'm just saying "su does some weird things by default, > sudo tries to prevent some problems by doing *other* weird things by > default, and it is not always the better choice, but it does help > prevent *some* problems") > > I will test and adapt the patches for this problem... FTR, just to have it out there before I upload the bugfix version, the patches in question are: https://github.com/mawww/kakoune/commit/7751c7e188bfc7b2f7e4a70e33032677d84597e5 https://github.com/mawww/kakoune/commit/db9ef82398a08bdf985ff26bfb230fb0cd1221a5 > ...but in the meantime, > a short-term solution for your current situation is: > > 1. Make sure the problem is what I think it is: > >ls -ld /run/user/1000/kakoune > >...and check that it is owned by "root", not by your user account > > 2. Change its owner to your user account: > >sudo chown "$(id -un):$(id -gn)" /run/user/1000/kakoune > >or, if using su: > >su -c "chown '$(id -un)' /run/user/1000/kakoune" ...arrgh, *of course* this should have been: su -c "chown '$(id -un):$(id -gn)' /run/user/1000/kakoune" Sorry about that! Although it would work with just the username, too, since Kakoune would still be able to write into an owner-writable directory. >...of course, you can put your account's username and groupname >directly instead of the "$(id -un):$(id -gn)" construct :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#990635: kakoune: Fatal error: unable to bind listen socket Permission denied
Control: tag -1 confirmed upstream patch pending On Sat, Jul 03, 2021 at 01:39:49PM +0200, xiscu wrote: > Package: kakoune > Version: 2020.01.16-2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > i'm currently unable to use kakoune as it gives a Permission denied error on > start > (reinstalling the package hasn't solved the problem). The programm worked for > me, > but currently i get: > > Fatal error: unable to bind listen socket '/run/user/1000/kakoune/3781950': > Permission denied Hi, Yes, you did stumble into an upstream kakoune bug that is fixed in a later upstream release that is not in Debian yet. The problem is that Kakoune determines the name of a "user-specific directory to put some stuff in" using your desktop environment's idea of a "user-specific directory to put some stuff in", i.e. the XDG_RUNTIME_DIR environment variable that is set upon the start of your GUI session. However, if you *first* run `sudo kak something` (and you have told sudo to preserve the environment variables!) or `su kak something` (and su, by default, does preserve the environment variables), as the first thing you do after restarting your computer, before running Kakoune as yourself, then Kakoune will create its own directory while running as root, and the directory will not be writable by your actual user account. So if later you run it from your user account, it will not be able to put stuff into that directory. This has happened with other tools, too, and this is actually part of the reason why sudo does NOT preserve all the environment variables by default. (Note: I'm not saying "don't use su, use sudo!"; I'm just saying "su does some weird things by default, sudo tries to prevent some problems by doing *other* weird things by default, and it is not always the better choice, but it does help prevent *some* problems") I will test and adapt the patches for this problem, but in the meantime, a short-term solution for your current situation is: 1. Make sure the problem is what I think it is: ls -ld /run/user/1000/kakoune ...and check that it is owned by "root", not by your user account 2. Change its owner to your user account: sudo chown "$(id -un):$(id -gn)" /run/user/1000/kakoune or, if using su: su -c "chown '$(id -un)' /run/user/1000/kakoune" ...of course, you can put your account's username and groupname directly instead of the "$(id -un):$(id -gn)" construct :) That should fix it until the next time you restart your computer, since Kakoune will see that the directory already exists and will not attempt to recreate it. Even after you restart your computer, the problem will only show up if you run Kakoune through su *before* running it from your own user account. ...and I will indeed upload a bugfix version in the next couple of days. Thanks for using Kakoune, and thanks for making its Debian package better by reporting this problem! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#990455: unblock: rpm/4.16.1.2+dfsg1-2
Control: retitle -1 unblock: rpm/4.16.1.2+dfsg1-3
On Wed, Jun 30, 2021 at 02:15:43AM +0300, Peter Pentchev wrote:
> On Tue, Jun 29, 2021 at 09:02:43PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> >
> > On 2021-06-29 20:15:33 +0300, Peter Pentchev wrote:
[snip]
> > > ++struct taglate_s {
> > > ++rpmTagVal stag;
> > > ++rpmTagVal xtag;
> > > ++rpm_count_t count;
> > > ++int quirk;
> > > ++} const xlateTags[] = {
[snip]
> >
> > Is this constant really supposed to be part of the public ABI? This
> > looks like it could use a static modifier.
>
> Hm, you are right. At least for the moment, it does not seem that
> anything else is using it, so it does not need to be exposed in
> the public library.
>
> I'll adapt the patch, drop the symbol from the library's symbols
> file (yes, I know, it would have been so much better if it had
> never actually hit the archive... true), and upload a new version.
>
> Thanks for making me stop and think about this!
Hi,
This should be fixed in 4.16.1.2+dfsg1-3 that I just uploaded to
unstable. FWIW, the upstream developers already accepted the patch:
https://github.com/rpm-software-management/rpm/pull/1737
(and I just realized that in the hurry to forward it upstream I plain
forgot to credit you for noticing it; sorry about that!)
Thanks again for spotting this!
unblock rpm/4.16.1.2+dfsg1-3
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#990455: unblock: rpm/4.16.1.2+dfsg1-2
On Tue, Jun 29, 2021 at 09:02:43PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
>
> On 2021-06-29 20:15:33 +0300, Peter Pentchev wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: team+pkg-...@tracker.debian.org
> >
> > Please unblock package rpm to fix a couple of security problems in
> > handling untrusted RPM files.
> >
> > [ Reason ]
> > See #985308 for more information - there are three CVEs filed for
> > problems in rpm's parsing of various header fields, one of which
> > may even be used to lead to code execution.
[snip]
> > diff -Nru rpm-4.16.1.2+dfsg1/debian/librpm9.symbols
> > rpm-4.16.1.2+dfsg1/debian/librpm9.symbols
> > --- rpm-4.16.1.2+dfsg1/debian/librpm9.symbols 2021-01-02
> > 12:04:09.0 +0200
> > +++ rpm-4.16.1.2+dfsg1/debian/librpm9.symbols 2021-06-29
> > 12:23:21.0 +0300
> > @@ -473,3 +473,4 @@
> > rpmvsVerify@Base 4.16
> > showQueryPackage@Base 4.14.0+dfsg1
> > showVerifyPackage@Base 4.14.0+dfsg1
> > + xlateTags@Base 4.16.1.2+dfsg1
[snip]
> > diff -Nru
> > rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-3421-CVE-2021-20271.patch
> > rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-3421-CVE-2021-20271.patch
> > --- rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-3421-CVE-2021-20271.patch
> > 1970-01-01 02:00:00.0 +0200
> > +++ rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-3421-CVE-2021-20271.patch
> > 2021-06-29 17:06:43.0 +0300
> > @@ -0,0 +1,180 @@
> > +Description: Be much more careful about copying data from the signature
> > header
[snip]
> > +Origin: upstream;
> > https://github.com/rpm-software-management/rpm/commit/d6a86b5e69e46cc283b1e06c92343319beb42e21
> > +Author: Panu Matilainen
> > +Bug-Debian: https://bugs.debian.org/985308
> > +Last-Update: 2021-06-29
> > +
> > +--- a/lib/package.c
> > b/lib/package.c
> > +@@ -31,82 +31,78 @@
> > + rpmRC rc;
> > + };
> > +
> > ++struct taglate_s {
> > ++rpmTagVal stag;
> > ++rpmTagVal xtag;
> > ++rpm_count_t count;
> > ++int quirk;
> > ++} const xlateTags[] = {
> > ++{ RPMSIGTAG_SIZE, RPMTAG_SIGSIZE, 1, 0 },
> > ++{ RPMSIGTAG_PGP, RPMTAG_SIGPGP, 0, 0 },
> > ++{ RPMSIGTAG_MD5, RPMTAG_SIGMD5, 16, 0 },
> > ++{ RPMSIGTAG_GPG, RPMTAG_SIGGPG, 0, 0 },
> > ++/* { RPMSIGTAG_PGP5, RPMTAG_SIGPGP5, 0, 0 }, */ /* long obsolete,
> > dont use */
> > ++{ RPMSIGTAG_PAYLOADSIZE, RPMTAG_ARCHIVESIZE, 1, 1 },
> > ++{ RPMSIGTAG_FILESIGNATURES, RPMTAG_FILESIGNATURES, 0, 1 },
> > ++{ RPMSIGTAG_FILESIGNATURELENGTH, RPMTAG_FILESIGNATURELENGTH, 1, 1 },
> > ++{ RPMSIGTAG_SHA1, RPMTAG_SHA1HEADER, 1, 0 },
> > ++{ RPMSIGTAG_SHA256, RPMTAG_SHA256HEADER, 1, 0 },
> > ++{ RPMSIGTAG_DSA, RPMTAG_DSAHEADER, 0, 0 },
> > ++{ RPMSIGTAG_RSA, RPMTAG_RSAHEADER, 0, 0 },
> > ++{ RPMSIGTAG_LONGSIZE, RPMTAG_LONGSIGSIZE, 1, 0 },
> > ++{ RPMSIGTAG_LONGARCHIVESIZE, RPMTAG_LONGARCHIVESIZE, 1, 0 },
> > ++{ 0 }
> > ++};
>
> Is this constant really supposed to be part of the public ABI? This
> looks like it could use a static modifier.
Hm, you are right. At least for the moment, it does not seem that
anything else is using it, so it does not need to be exposed in
the public library.
I'll adapt the patch, drop the symbol from the library's symbols
file (yes, I know, it would have been so much better if it had
never actually hit the archive... true), and upload a new version.
Thanks for making me stop and think about this!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#990455: unblock: rpm/4.16.1.2+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: team+pkg-...@tracker.debian.org Please unblock package rpm to fix a couple of security problems in handling untrusted RPM files. [ Reason ] See #985308 for more information - there are three CVEs filed for problems in rpm's parsing of various header fields, one of which may even be used to lead to code execution. [ Impact ] If a maliciously-constructed RPM package is installed, the RPM database may be corrupted or unexpected code may be executed (other than the scriptlets within the RPM file). [ Tests ] None for the present. [ Risks ] The patches are mostly straightforward and extend already-existing checks. The only risk here would be rejecting a valid RPM file, but from what I understand of the source code, this should not happen any more, especially after catching one such case (one of the new patches to the Debian package combines three upstream commits, one of which relaxes some restrictions for this very reason). [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock rpm/4.16.1.2+dfsg1-2 diff -Nru rpm-4.16.1.2+dfsg1/debian/changelog rpm-4.16.1.2+dfsg1/debian/changelog --- rpm-4.16.1.2+dfsg1/debian/changelog 2021-01-28 12:22:55.0 +0200 +++ rpm-4.16.1.2+dfsg1/debian/changelog 2021-06-29 18:15:25.0 +0300 @@ -1,3 +1,35 @@ +rpm (4.16.1.2+dfsg1-2) unstable; urgency=medium + + * Team upload. + * Amend the CVE-2021-3421-CVE-2021-20271 patch, add two follow-up +upstream commits that relax the restrictions a little bit to +allow for some existing RPM packages. + + -- Peter Pentchev Tue, 29 Jun 2021 18:15:25 +0300 + +rpm (4.16.1.2+dfsg1-1) unstable; urgency=medium + + * Team upload. + * Acknowledge NMUs; thanks, Matthias and Boyuan! + * Add the CVE-2021-20266 and CVE-2021-3421-CVE-2021-20271 patches to +strengthen the verification of RPM signatures. Closes: #985308 + + -- Peter Pentchev Tue, 29 Jun 2021 14:11:21 +0300 + +rpm (4.16.1.2+dfsg1-0.6) unstable; urgency=medium + + * Non-maintainer upload. + * Only build-depend on gnupg2 on linux architectures. + + -- Matthias Klose Tue, 09 Mar 2021 23:39:07 +0100 + +rpm (4.16.1.2+dfsg1-0.5) unstable; urgency=medium + + * Non-maintainer upload. + * Only build-depend on libaudit-dev on linux architectures. + + -- Matthias Klose Tue, 09 Mar 2021 22:50:12 +0100 + rpm (4.16.1.2+dfsg1-0.4) unstable; urgency=medium * Non-maintainer upload. diff -Nru rpm-4.16.1.2+dfsg1/debian/control rpm-4.16.1.2+dfsg1/debian/control --- rpm-4.16.1.2+dfsg1/debian/control 2021-01-02 14:03:53.0 +0200 +++ rpm-4.16.1.2+dfsg1/debian/control 2021-06-27 01:21:05.0 +0300 @@ -33,8 +33,8 @@ liblua5.2-dev, libsemanage1-dev [linux-any], libgcrypt20-dev, - libaudit-dev, - gnupg2, + libaudit-dev [linux-any], + gnupg2 [linux-any], Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/pkg-rpm-team/rpm Vcs-Git: https://salsa.debian.org/pkg-rpm-team/rpm.git diff -Nru rpm-4.16.1.2+dfsg1/debian/debugedit.8 rpm-4.16.1.2+dfsg1/debian/debugedit.8 --- rpm-4.16.1.2+dfsg1/debian/debugedit.8 2021-01-28 12:22:55.0 +0200 +++ rpm-4.16.1.2+dfsg1/debian/debugedit.8 2021-06-27 01:21:05.0 +0300 @@ -1,5 +1,5 @@ -.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.16. -.TH DEBUGEDIT "8" "January 2021" "debugedit 4.16.1.2" "System Administration Utilities" +.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.48.2. +.TH DEBUGEDIT "8" "March 2021" "debugedit 4.16.1.2" "System Administration Utilities" .SH NAME debugedit \- Debuginfo editing helper .SH SYNOPSIS diff -Nru rpm-4.16.1.2+dfsg1/debian/librpm9.symbols rpm-4.16.1.2+dfsg1/debian/librpm9.symbols --- rpm-4.16.1.2+dfsg1/debian/librpm9.symbols 2021-01-02 12:04:09.0 +0200 +++ rpm-4.16.1.2+dfsg1/debian/librpm9.symbols 2021-06-29 12:23:21.0 +0300 @@ -473,3 +473,4 @@ rpmvsVerify@Base 4.16 showQueryPackage@Base 4.14.0+dfsg1 showVerifyPackage@Base 4.14.0+dfsg1 + xlateTags@Base 4.16.1.2+dfsg1 diff -Nru rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-20266.patch rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-20266.patch --- rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-20266.patch 1970-01-01 02:00:00.0 +0200 +++ rpm-4.16.1.2+dfsg1/debian/patches/CVE-2021-20266.patch 2021-06-29 12:23:21.0 +0300 @@ -0,0 +1,97 @@ +Description: hdrblobInit() needs bounds checks too + Users can pass untrusted data to hdrblobInit() and it must be robust + against this. +Origin: upstream; https://github.com/rpm-software-management/rpm/commit/8f4b3c3cab8922a2022b9e47c71f1ecf906077ef +Author
Bug#985308: Debian rpm package: import NMUs, fix three CVEs
On Mon, Jun 28, 2021 at 10:36:24AM +0200, Matthias Klose wrote: > On 6/27/21 7:04 PM, Michal Čihař wrote: > > Hi > > > > Peter Pentchev píše v Ne 27. 06. 2021 v 13:45 +0300: > >> So, Michal, do these changes look reasonable to you? If they do, > >> I can push them to the pkg-rpm/rpm repo itself, upload a new version > >> to > >> unstable, and send an unblock request to the release team. > > > > I won't have time to review the changes in near future, so I'd say you > > can go ahead. > > Michal, Peter, please also see the new source debugedit package in > experimental/NEW, splitted out from rpm. Unfortunately not yet accepted, but > if > you do an upload to experimental, please let rpm depend on it. Noted, thanks for your work on this! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
