Bug#1070745: Bug#1070730 etc.: libglib2.0-0: ibus input regression
On Wed, 8 May 2024 13:03:51 +0100 Simon McVittie wrote: On Wed, 08 May 2024 at 03:48:21 +, unfathomabl...@protonmail.com wrote: > Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese > characters GTK programs (such as firefox, gedit etc). For users of testing/unstable, this will be fixed as soon as I can, probably by version 2.80.1-1. Each GLib build takes around an hour, plus the time required for testing, so it is not possible to fix this instantaneously. For users of Debian 12 'bookworm', a test-build of a fix for this regression is available here: https://people.debian.org/~smcv/bug1070730/ (amd64 + i386 + source) I can confirm these builds fix the input issues reported here on my system. Thank you for moving so fast on this, -- Jérôme
Bug#963872: RFP: automx2 - Email client configuration made easy (replaces "automx")
Hi Jakob, Le 21/04/2024 à 18:01, Jakob Haufe a écrit : (cc'ing Jérôme as he expressed interest) (cc'ing Juri as he started packaging at [1]) I recently learned about automx2 and would love to see it packaged in Debian as well. Does either of you still plan to maintain it? Is there anything I can help with? I finally don't used it as planned. I let you care about the Debian packaging so! Cheers, Jérôme Cheers, sur5r [1] https://salsa.debian.org/python-team/packages/automx2
Bug#1021605: persepolis: Systemd dependencies
So i will open a upstream request and see how that can be manage, thx for feedbacks. Le 24/04/2024 à 16:59, Boyuan Yang a écrit : X-Debbugs-CC: bardot.jer...@gmail.com Hi, On Tue, 11 Oct 2022 19:26:21 +0200 Bardot Jerome wrote: Package: persepolis Version: 3.0.1-1.1 Severity: important X-Debbugs-Cc: bardot.jer...@gmail.com Dear Maintainer, It's look like the package need systemd … (throught recommends) Can you please fix it ? A default installation should not rely on a specific software that can break all others software. First of all, having a default status of needing systemd is not a big issue. It is not hard dependency, so you always have the choice to uninstall any package recommendation that needs systemd. Secondly, I did not see that installing persepolis will introduce systemd itself. It seems that only libsystemd library will be introduced due to dynamic library dependency. Having libsystemd library installed is harmless because the library will not do anything useful if systemd is not running. Please correct me if my observation is wrong. Finally, I have no idea on how to properly avoid systemd as you requested since all packages listed in the Recommends field are legit, and removing or demoting any of them are not reasonable. Do you have a good patch that can be used? I would be happy to take patches if it could properly avoid introducing systemd by default without losing any of persepolis' upstream-provided functionality. Thanks, Boyuan Yang
Bug#1063417: bookworm-pu: package libapache2-mod-qos/11.74-1+deb12u1
Le 2024-04-07 à 06 h 41, Jonathan Wiltshire a écrit : On Mon, Feb 26, 2024 at 10:50:39AM -0500, Jérôme Charaoui wrote: I had an exchange with a fellow DD about this update and uploading this to bookworm-backports was suggested as a possible alternative considering the large size of the .debdiff : olasd | lavamind: in terms of policy, a backport would be allowed (it's a new upstream release, it's in testing, and you seem to be using the package, so you might as well upload it to bpo); That still leaves a buggy package in bookworm, if the bookworm package has never worked, pulling in the newer upstream release into a stable update may be deemed acceptable by the SRMs; looking at the upstream changelog of libapache2-mod-qos, the changes for compatibility with pcre2 (which is what our apache2 now builds against, since 2.4.52-2) have been introduced in libapache2-mod-qos upstream 11.73. Backporting the pcre2 support to the libapache2-mod-qos version in bookworm isn't a very sensible option IMO, in terms of maintainability If SRMs agree with this assessement, I can close this bug and prepare and upload to bookworm-backports instead. It's one sensible path forward and it gives you more flexibility, but it leaves a gap for users upgrading from bullseye. Long term, is a new maintainer forthcoming? The orphan bug doesn't seem to have any interest since being opened in 2019 and there weren't any uploads at all until last year. Maybe its future should be considered first and then that will inform the decision about how to handle stable. I don't think I can personnally adopt this package considering my packaging Debian work-load at the moment. I also noticed a dozen or so other Apache modules are also orphaned at the moment and in need of a new maintainer, so it seems like the issue might be even a little wider than just this single package. I'll go ahead with uploading a backport, it will at least provide an upgrade path option for users, even if a manual one. Thanks, -- Jérôme
Bug#1069242: Please provide a bookworm backport
Package: libsequoia-octopus-librnp Severity: wishlist Dear maintainer, I'm very excited to see the octopus has entered unstable! This library is a daily driver for me on bookworm. It would be awesome if a backport could be made available for this release. Thanks! -- Jérôme
Bug#1069192: Autopkgtest failure: missing dependency on python3-pytz
Hi Nilesh, Le 2024-04-18 à 06 h 24, Nilesh Patra a écrit : I will NMU this in a week or so if I see no activity. This package has been going through in-attention for a while. Please, you may upload the fix whenever you wish, it's fine with me. -- Jérôme
Bug#1069162: Problem starting at boot, MAINPID to kill is a root-owned java process
Thanks for the bug report, that's a strange one indeed! One thing I'm wondering however, considering you're running unstable, is if the problem also occurs with the latest version of the puppetserver package, which is currently 8.4.0-3. -- Jérôme
Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1
Le 2024-03-29 à 16 h 09, Jonathan Wiltshire a écrit : Control: tag -1 moreinfo Hi, On Tue, Mar 12, 2024 at 10:24:16AM -0400, Jérôme Charaoui wrote: Low, the patch is small (3 lines) and is strictly designed to gracefully handle the identified race condition. The uploaded package also drops the .gitlab-ci.yml, is that intentional? No, it isn't intentional, but it seems to me either that, or modifying debian/clean which specifically lists "debian/.gitlab-ci.yml". This was fixed in a later version of the source package. -- Jérôme
Bug#1058833: qlcplus: use udev.pc to place udev rules
Hi Chris, Thanks for your explained report and the patch! I finally took the time to have a look and integrate it. I am waiting for the end of the qtbase-opensource-src transition before uploading it - with the new upstream release by the way. Best regards, Jérôme
Bug#1066894: ITP: dh-puppet -- debhelper add-on to handle Puppet modules
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org Package name : dh-puppet Version : 1.0 Upstream author : Jérôme Charaoui URL : https://salsa.debian.org/puppet-team/dh-puppet License : GPL-3.0 Programming Lang : Perl Description : debhelper add-on to handle Puppet modules dh-puppet provides a debhelper sequence named 'puppet-module' to simplify the packaging of Puppet modules: it helps install a module's files and documentation, provides common postinst and prerm maintainer scripts, and generates control substitution variables for dependencies
Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1
Just noting that I'm aware in the provided debdiff, the d/changelog entry is missing the Closes: tag. This is already fixed in the upload I'm preparing, but if requested I can upload a new .debdiff without issue. Also, as this is an NMU in its current form, I've also been in touch with the package maintainers in order to get additonal review and approval. Thanks.
Bug#1059496: podman: network ls: might fail to handle removed container
Just for the record, I've submitted a debdiff that includes the upstream patch for to fix this as a proposed-update for bookworm: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066096 -- Jérôme
Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:podman
X-Debbugs-Cc: pod...@packages.debian.org
[ Reason ]
podman in bookworm suffers from a race condition which causes the
"network ls" command to fail intermittently in certain scenarios
[ Impact ]
The issue is responsible for intermittent failures when using podman as
a GitLab CI runner executor and the 'FF_NETWORK_PER_BUILD' runner flag
is enabled. This bug has been reported on the BTS at #1059496.
[ Risk ]
Low, the patch is small (3 lines) and is strictly designed to gracefully
handle the identified race condition.
[ Tests ]
Autopkgtests are passing, and we've deployed this package on a small
fleet of GitLab CI runners for several weeks without issue of any kind,
and confirming the failures caused by the race condition do not occur
anymore.
[ 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 debdiff consists of the addition of a patch cherry-picked from
upstream to gracefully handle a race condition in the "network ls"
podman subcommand.
Thank you.
-- Jérôme
diff -Nru libpod-4.3.1+ds1/debian/changelog libpod-4.3.1+ds1/debian/changelog
--- libpod-4.3.1+ds1/debian/changelog 2023-04-30 08:19:54.0 -0400
+++ libpod-4.3.1+ds1/debian/changelog 2024-02-26 09:30:29.0 -0500
@@ -1,3 +1,10 @@
+libpod (4.3.1+ds1-8+deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * d/patches: backport fix for removed container handling
+
+ -- Jérôme Charaoui Mon, 26 Feb 2024 09:30:29 -0500
+
libpod (4.3.1+ds1-8) unstable; urgency=medium
* [upstream] unbreak using docker as client
diff -Nru libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
--- libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
1969-12-31 19:00:00.0 -0500
+++ libpod-4.3.1+ds1/debian/patches/fix-removed-container-handling.patch
2024-02-26 09:30:29.0 -0500
@@ -0,0 +1,28 @@
+From: Valentin Rothberg
+Date: Mon, 6 Feb 2023 13:52:40 +0100
+Subject: [PATCH] network ls: handle removed container
+
+Handle a race condition in the REST API when listing networks.
+In between listing all containers and inspecting them, they may have
+already been removed, so handle this case gracefully.
+
+[NO NEW TESTS NEEDED] as it's a race condition.
+
+Fixes: #17341
+
+Forwarded: not-needed
+Origin: upstream,
https://github.com/containers/podman/commit/ced934284058232c1c3d76956786106d64511f89
+diff --git a/pkg/api/handlers/compat/networks.go
b/pkg/api/handlers/compat/networks.go
+index 704af4b0e427..587da14361eb 100644
+--- a/pkg/api/handlers/compat/networks.go
b/pkg/api/handlers/compat/networks.go
+@@ -74,6 +74,9 @@ func convertLibpodNetworktoDockerNetwork(runtime
*libpod.Runtime, network *netty
+ for _, con := range cons {
+ data, err := con.Inspect(false)
+ if err != nil {
++ if errors.Is(err, define.ErrNoSuchCtr) ||
errors.Is(err, define.ErrCtrRemoved) {
++ continue
++ }
+ return nil, err
+ }
+ if netData, ok := data.NetworkSettings.Networks[network.Name];
ok {
diff -Nru libpod-4.3.1+ds1/debian/patches/series
libpod-4.3.1+ds1/debian/patches/series
--- libpod-4.3.1+ds1/debian/patches/series 2023-04-30 08:19:54.0
-0400
+++ libpod-4.3.1+ds1/debian/patches/series 2024-02-26 09:30:29.0
-0500
@@ -3,3 +3,4 @@
CVE-2023-0778.patch
fix-podman-client.patch
show-graphroot-before-removal.patch
+fix-removed-container-handling.patch
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1064686: vagrant-librarian-puppet: FTBFS
Hello, I think this package should be removed from Debian. In addition to the FTBFS issues: - Project appears to be abandoned upstream, last commit was 6 years ago - The future of Vagrant in Debian is in serious doubt (see #104) - It's currently blocking the transition of the latest puppet-agent package in Debian I'm not a maintainer or uploader of this package, so if someone feels like they're wearing one of those hats, please file a removal request [0]. Thanks, -- Jérôme [0] https://wiki.debian.org/ftpmaster_Removals#How_to_request_removal
Bug#1063417: bookworm-pu: package libapache2-mod-qos/11.74-1+deb12u1
Hello, I had an exchange with a fellow DD about this update and uploading this to bookworm-backports was suggested as a possible alternative considering the large size of the .debdiff : > olasd | lavamind: in terms of policy, a backport would be allowed (it's a new upstream release, it's in testing, and you seem to be using the package, so you might as well upload it to bpo); That still leaves a buggy package in bookworm, if the bookworm package has never worked, pulling in the newer upstream release into a stable update may be deemed acceptable by the SRMs; looking at the upstream changelog of libapache2-mod-qos, the changes for compatibility with pcre2 (which is what our apache2 now builds against, since 2.4.52-2) have been introduced in libapache2-mod-qos upstream 11.73. Backporting the pcre2 support to the libapache2-mod-qos version in bookworm isn't a very sensible option IMO, in terms of maintainability If SRMs agree with this assessement, I can close this bug and prepare and upload to bookworm-backports instead. Thanks! -- Jérôme
Bug#1064279: ITP: jnr-a64asm
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org Package name : jnr-a64asm Version : 1.0.0 Upstream author : Ossdev07 URL : https://github.com/jnr/jnr-a64asm License : Apache-2.0 Programming Lang : Java Description : Pure-java aarch64 assembler jnr-a64asm is a pure-java port of AsmJit, a lightweight library for machine code generation written in C++ language. This is a dependency of the jnr-ffi library (related parts are currently patched out). Thanks, -- Jerome
Bug#1064247: Update snakeyaml to v2.2 or later
Package: puppetserver Severity: normal Version: 8.4.0-1~exp1 Owner: po...@debian.org Hello, The "puppetserver" CLI subcommands have evolved a bit between Puppet Server releases 7 and 8, so the manpages should be updated to reflect those changes. Thanks! -- Jérôme
Bug#1033316: Autopkgtest is flaky
Control: tags -1 + confirmed Control: owner -1 ! Hello, I'm preparing an update for this package which should fix the issue. Thanks, -- Jérôme
Bug#1064146: Update snakeyaml to v2.2 or later
Package: snakeyaml Severity: wishlist Dear maintainer, Please upgrade snakeyaml to the latest version. To help prevent remote code execution vulnerabilities, snakeyaml 2.2 and later disallows global tags by default. This has prompted a number of projects to migrate to this new release, Puppet Server and PuppetDB, among others. Thank you! -- Jerome
Bug#1063802: Update to latest release (1.2.x)
Package: src:ruby-concurrent Version: 1.1.6+dfsg-5 Hello, I'm currently working on upgrading the Puppet packages in Debian and one of the requirements is a newer version of ruby-concurrent, at least 1.2.2. The reason is that memory leaks were identified in earlier versions. Unless there's a reason to proceed in a more coordinated manner (if so, let me know), I'll upload an updated package myself some time soon. Thanks, -- Jérôme
Bug#1063268: tuxguitar: Tuxguitar was forked. New 1.6.x versions available.
Package: tuxguitar Version: 1.6.1-linux-swt Severity: wishlist Dear Maintainer, I just found out that Tuxguitar was forked and new releases have already been issued. Here's the fork: https://github.com/helge17/tuxguitar/ I'm running the fork's 1.6.1 version (.deb provided in the repo "Releases" section) and it works a treat. Please consider using this as the new Tuxguitar source. Thanks. Jérôme -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tuxguitar depends on: ii default-jre 2:1.17-74 ii libasound21.2.8-1+b1 ii libfluidsynth32.3.1-2 ii libjack-jackd2-0 1.9.21~dfsg-3 ii liblilv-0-0 0.24.14-1 ii libwebkit2gtk-4.0-37 2.42.4-1~deb12u1 Versions of packages tuxguitar recommends: ii fonts-wqy-zenhei 0.9.45-8 ii guitarix-lv2 0.44.1+dfsg1-2librazik1 tuxguitar suggests no packages. -- no debconf information
Bug#1059581: examples missing from documentation
Package: xserver-xorg-video-nvidia Version: 525.147.05-4~deb12u1 Dear Maintainer, Since the package was updated on bookworm, the directory `/usr/share/doc/xserver-xorg-video-nvidia/examples` is no longer present, and I could not find an explanation for this, either in the Debian changelog nor in the package's Git repository. It contained the `nvidia-sleep.sh` script in addition to several systemd service units related to suspend/resume/hibernate, that are needed to enable Wayland under GNOME. I documented the steps to do so on the Debian wiki at https://wiki.debian.org/NvidiaGraphicsDrivers#Wayland Thanks, -- Jérôme
Bug#1058703: getsockopt test failures in JRuby on aarch64
Package: libjffi-jni
Version: 1.3.12+ds-1
Severity: normal
Hello,
I'm encountering unexpected failures when running the JRuby testsuite on
aarch64 with libjffi-jni_1.3.12+ds-1:
===
Failure: test_tcp_info(SocketTest)
/tmp/autopkgtest.LCcGF4/autopkgtest_tmp/test/jruby/test_socket.rb:60:in
`block in test_tcp_info'
57: t.join
58: tcp_info = client.getsockopt(Socket::IPPROTO_TCP,
Socket::TCP_INFO)
59: state = tcp_info.unpack("C")[0]
=> 60: assert_equal(8, state) # CLOSE_WAIT
61: ensure
62: server.close if server && !server.closed?
63: end
/tmp/autopkgtest.LCcGF4/autopkgtest_tmp/test/jruby/test_socket.rb:49:in
`test_tcp_info'
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
<8> expected but was
===
..E
===
Error: test_tcp_socket_get_keep_cnt(SocketTest): TypeError: size differ.
expected as sizeof(int)=4 but 0
org/jruby/ext/socket/Option.java:201:in `int'
/tmp/autopkgtest.LCcGF4/autopkgtest_tmp/test/jruby/test_socket.rb:197:in
`test_tcp_socket_get_keep_cnt'
194:
195: def test_tcp_socket_get_keep_cnt
196: socket = Socket.new(Socket::AF_INET,
Socket::SOCK_STREAM, 0)
=> 197: assert_instance_of(Integer,
socket.getsockopt(Socket::SOL_TCP, Socket::TCP_KEEPCNT).int)
198: ensure
199: socket.close
200: end
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
===
E
===
Error: test_tcp_socket_get_keep_idle(SocketTest): TypeError: size
differ. expected as sizeof(int)=4 but 0
org/jruby/ext/socket/Option.java:201:in `int'
/tmp/autopkgtest.LCcGF4/autopkgtest_tmp/test/jruby/test_socket.rb:183:in
`test_tcp_socket_get_keep_idle'
180: if RbConfig::CONFIG['target_os'] == 'linux'
181: def test_tcp_socket_get_keep_idle
182: socket = Socket.new(Socket::AF_INET,
Socket::SOCK_STREAM, 0)
=> 183: assert_instance_of(Integer,
socket.getsockopt(Socket::SOL_TCP, Socket::TCP_KEEPIDLE).int)
184: ensure
185: socket.close
186: end
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
org/jruby/RubyKernel.java:1308:in `catch'
org/jruby/RubyKernel.java:1303:in `catch'
===
E
===
Error: test_tcp_socket_get_keep_intvl(SocketTest): TypeError: size
differ. expected as sizeof(int)=4 but 0
org/jruby/ext/socket/Option.java:201:in `int'
/tmp/autopkgtest.LCcGF4/autopkgtest_tmp/test/jruby/test_socket.rb:190:in
`test_tcp_socket_get_keep_intvl'
187:
188: def test_tcp_socket_get_keep_intvl
189: socket = Socket.new(Socket::AF_INET,
Socket::SOCK_STREAM, 0)
=> 190: assert_instance_of(Integer,
socket.getsockopt(Socket::SOL_TCP, Socket::TCP_KEEPINTVL).int)
191: ensure
192: socket.close
193: end
===
These failures are *not* present when running the testsuite with
libjffi-jni_1.3.9+ds-6 shipped in bookworm, nor with the upstream-built
1.3.12 binary version of this library.
I'm not sure but I suspect maybe some element deeper in the build chain
changed between bookworm and sid, causing these new issues.
These tests pass fine on amd64.
Thanks,
-- Jérôme
Bug#1058702: pius fails completely on bookworm and up
On Thu, 14 Dec 2023 14:32:45 -0500 Antoine Beaupre wrote:> pius: error: GnuPG binary not found at /usr/bin/gpg2. gpg2 hasn't been around for a long time. but maybe we can work around this with: Yeah I would also like like to see this patched. pius: error: Keyring /home/anarcat/.gnupg/pubring.gpg doesn't exist Nope! That doesn't work either! I have not dared to use the --keyring argument to correct `.gnupg/pubring.kbx` keyring, for fear of corruption, but clearly something is wrong here. FWIW I've used --keyring and it didn't seem to corrupt the keyring or do anything bad, but you can also test it yourself on a copy of your keyring, the signatures thus produces will be just as valid. Another thing that would be nice to fix upstream, or in the package at least. -- Jérôme
Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)
Le 2023-12-09 à 17 h 29, tony mancill a écrit : On Sat, Dec 09, 2023 at 04:39:35PM -0500, Jérôme Charaoui wrote: On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann wrote: during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--unpack): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb Thanks for the heads up. I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed split away from "libtakari-polyglot-maven-java" and into "libtakari-polyglot-groovy-java", however the new version of "libtakari-polyglot-maven-java" does *not* depend on/recommend "libtakari-polyglot-groovy-java". So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the first place, during the piuparts upgrade. It's not present in testing, and it has currently zero reverse-dependencies. I did my own testing and on a bare system with "libtakari-polyglot-maven-java" installed, upgrading to sid does not include an installation of "libtakari-polyglot-groovy-java". Any idea what's going on? Hi Jérôme, I believe you're correct that in the normal upgrade case, this is unlikely to occur. Here's the test case I ran instead a clean trixie chroot: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. Update sources.list to unstable and then apt-get update 3. apt-get -y install libtakari-polyglot-groovy-java Step (3) will upgrade libtakari-polyglot-maven-java to 0.4.11-2 *before* installing libtakari-polyglot-groovy-java, so there's no problem. However, the issue can occur when using dpkg directly, or some other factor influences the ordering such that libtakari-polyglot-groovy-java is installed *before* libtakari-polyglot-maven-java is upgraded. For example: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. wget http://ftp.us.debian.org/debian/pool/main/t/takari-polyglot-maven/libtakari-polyglot-groovy-java_0.4.11-2_all.deb 3. dpkg -i libtakari-polyglot-groovy-java_0.4.11-2_all.deb Preparing to unpack libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--install): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: libtakari-polyglot-groovy-java_0.4.11-2_all.deb This is the reason that the relationship needs to be explicit. I'm not 100% certain, but perhaps we can get away with only adding a versioned depends on libtakari-polyglot-maven-java (>= 0.4.11-2) to the libtakari-polyglot-groovy-java package. The problem as I see it is that the current unversioned Depends can be satisfied by any version of libtakari-polyglot-maven-java, including older versions with the file conflict. Requiring the newer libtakari-polyglot-maven-java would prevent this. Ok what I think I'll do is to add: "Breaks: libtakari-polyglot-maven-java (<< 0.4.11-2)" to libtakari-polyglot-groovy-java. I think that's more explicit than a versioned depends, and should prevent any instances of users accidentally having wrong versions of the two packages. -- Jérôme
Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)
On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann wrote: during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--unpack): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb Thanks for the heads up. I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed split away from "libtakari-polyglot-maven-java" and into "libtakari-polyglot-groovy-java", however the new version of "libtakari-polyglot-maven-java" does *not* depend on/recommend "libtakari-polyglot-groovy-java". So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the first place, during the piuparts upgrade. It's not present in testing, and it has currently zero reverse-dependencies. I did my own testing and on a bare system with "libtakari-polyglot-maven-java" installed, upgrading to sid does not include an installation of "libtakari-polyglot-groovy-java". Any idea what's going on? Thanks, -- Jérôme
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
Le 2023-11-25 à 06 h 30, Miguel Landaeta a écrit : On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui wrote: [...] I've been working on a 9.4 release, you can see the progress here: https://salsa.debian.org/lavamind/jruby I plan to upload this version to experimental within a few days, I still have some minor issues with the testsuite to iron out before. Excellent, that's good to hear. There is no point then just backporting the fix if you are close to finishing preparing an upload. Let me know if there is something else I can help with. I think I'll take a look at some jnr-* dependencies packages that could use a new upstream release and/or bugfixes. For the record, the upload is ready to go. I'm now only waiting for a new build-dependency to pass through NEW, jruby-mavengem.
Bug#1040144: Bisect ongoing
Issue still present in kernel 6.6 from experimental. Is there anything I can do to help with this? -- Jérôme
Bug#1056552: sop-java: 4.1.2 is available upstream
Le 2023-12-02 à 14 h 24, Jérôme Charaoui a écrit : However, sop-java upstream have ported their code to Kotlin, and I'm not sure whether its feasible to keep it in Debian anymore since Kotlin, although in Debian currently, is quite new and has two unfixed CVEs against it. Never mind, the Kotlin port only landed in the 8.x branch of sop-java. We should be able to package 7.x with minimal issues. -- Jérôme
Bug#1056552: sop-java: 4.1.2 is available upstream
On Wed, 22 Nov 2023 17:24:06 -0500 Daniel Kahn Gillmor wrote: Package: src:sop-java Version: 4.1.0 Control: affects -1 + pgpainless-cli Hi folks-- sop-java 4.1.2 is available upstream, and should be a relatively straightforward update in Debian. As are several substantially newer versions, but the newer ones look like they might be semver incompatible, so for the purposes of keeping the 1.3.* series of pgpainless-cli in debian they are probably not advisable to upgrade until the newer version of bouncycastle lands in unstable, see #1049356. The 1.3.* series of pgpainless doesn't build with bouncycastle-1.77, which has been uploaded in Debian recently, so I think we don't have much choice but to bring both sop-java and pgpainless to the latest versions. However, sop-java upstream have ported their code to Kotlin, and I'm not sure whether its feasible to keep it in Debian anymore since Kotlin, although in Debian currently, is quite new and has two unfixed CVEs against it. I also couldn't find any other Kotlin projects in Debian which build-depend on Kotlin (aside from Kotlin itself and some related plugins). What do you think? -- Jérôme
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
Hi Miguel, Le 2023-11-24 à 18 h 38, Miguel Landaeta a écrit : Thomas and Jérôme, Do you have any concerns with me uploading a fix for this issue? I'm working with some folks here in Cambridge MiniDebConf and I also have some cycles to spare to work on JRuby and maybe prepare a new upstream release for 9.3 and/or 9.4 series (experimental). I've been working on a 9.4 release, you can see the progress here: https://salsa.debian.org/lavamind/jruby I plan to upload this version to experimental within a few days, I still have some minor issues with the testsuite to iron out before. Thanks, -- Jérôme
Bug#1054592: ITP: snakeyaml-engine
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org Package name : snakeyaml-engine Version : 2.7 Upstream author : Andrey Somov URL : https://bitbucket.org/snakeyaml/snakeyaml-engine License : Apache-2.0 Programming Lang : Java Description : Core YAML 1.2 parser and emitter for Java YAML is a data serialization format designed for human readability and interaction with scripting languages. SnakeYAML Engine is a YAML 1.2 processor for the Java Virtual Machine version 8 and higher. This a new dependency introduced in version 5.1 of the Ruby psych java extension. Thanks, -- Jerome
Bug#1054361: ITP: jruby-jzlib
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org Package name : jruby-jzlib Version : 1.1.5 Upstream author : y...@jcraft.com, JCraft,Inc. Upstream contact : Charles Oliver Nutter URL : https://github.com/jruby/jzlib License : BSD-3-clause Programming Lang : Java Description : JRuby's fork of the jzlib pure-Java zlib library JZlib is a re-implementation of zlib in pure Java. This version is a fork of com.jcraft:jzlib with additional improvements for the JRuby environment. This is part of an effort to improve the JRuby build chain in Debian. Thanks, -- Jerome
Bug#1054360: ITP: copy-rename-maven-plugin
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org Package name : copy-rename-maven-plugin Version : 2.0.0 Upstream author : Aneesh Joseph URL : https://github.com/kohlschutter/copy-rename-maven-plugin License : Expat Programming Lang : Java Description : m2e compatible maven plugin for renaming/copying This plugin helps in copying files or renaming files or directories during the Maven build lifecycle. This is part of an effort to improve the JRuby build chain in Debian. Thanks, -- Jerome
Bug#1054332: ITP: jruby-mavengem
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : jruby-mavengem Version : 2.0.1 Upstream author : Christian Meier URL : https://github.com/jruby/mavengem License : EPL-1.0 Programming Lang : Java Description : Mavengem Protocol and Mavengem Wagon mavengem protocol converts a rubygems repository on the fly to a maven repository and the mavengem wagon uses it to provide gem artifacts to maven POMs This is part of an effort to improve the JRuby build chain in Debian. Although it's most often used to retrieve gems from an online repository, it can also be used offline for building other packages in Debian thanks to its ability to pick up Ruby gems present in a local Maven repository (eg. debian/maven-repo). Thanks, -- Jerome
Bug#1054324: Inability to override install.to.usj property
Le 2023-10-21 à 17 h 28, Emmanuel Bourg a écrit : Le 21/10/2023 à 22:54, Jérôme Charaoui a écrit : Alternatives are: package name status quo, using "libjruby-maven-plugin-java" (singular), or breaking out the various plugins into different packages (even though they all depend on each other), but it's all sub-optimal. +1 for libjruby-maven-plugin-java, I'd rather not touch the settings of maven-debian-helper without extensive testing. Fair enough, I'll do that in the short term. Maybe the bug can remain open so that the issue may be looked at at some point in the future. Thanks, -- Jérôme
Bug#1054324: Inability to override install.to.usj property
Package: maven-debian-helper Version: 2.6.4 Severity: wishlist Hello, Lately, I've been working on updating the jruby-maven-plugins package. As part of this work I wanted to rename the binary package from "jruby-maven-plugins" which is not java-policy compliant, to "libjruby-maven-plugins-java". However, this causes maven-debian-helper to install the jars into /usr/share/java because the package name isn't recognized as a maven plugin by the regex. This might be easily fixed by passing -Dinstall.to.usj=false but unfortunately this can't be done because the maven command called by the maven debhelper module passes "-Dinstall.to.usj=true" to Maven directly. I believe we can just drop this property from the debhelper Maven command-line: by default, the property is true anyway. This would allow packages to override the automatic decision to install to usj. Alternatives are: package name status quo, using "libjruby-maven-plugin-java" (singular), or breaking out the various plugins into different packages (even though they all depend on each other), but it's all sub-optimal. Thanks! -- Jérôme
Bug#1053849: base-files: Allow .d for issue and issue.net
Hi Santiago, thx for feedback. You re right about motd it will be do the work. I guess somebody mess at the setup. I fix it. I m aware of the unattended-upgraded and related. Thx for everything. The issue can be close. J. Le 12/10/2023 à 19:30, Santiago Vila a écrit : El 12/10/23 a las 14:41, Bardot Jerome escribió: Is there is a way to use the conf.d mecanism for files in base-files. In my case it's for issue and issue.net. For explanation i will imagine the directory issue.d . Maybe it's need an option to concatenate or erase default file. And maybe the same way to load 10- 20- etc. The files "issue" and "issue.net" have a single line of text. I'd like to keep base-files simple. Creating a .d mechanism for files with one line of text seems a little bit overkill to me. Why asking ? - to separate my own legal issue and the default one Well. Good news: The file containing the legal issue is /etc/motd and it's not contained in base-files.deb. This means that it's not a conffile in the dpkg sense. There will be no questions about it if you change it, because base-files creates it only once in the very first install (from debootstrap) and then does not touch it at all ever again. - no more dpkg question on update/upgrade. Well, you can avoid all questions by using the "unattended-upgrades" package. This usually works triggered by cron, but you can also disable the cron part and run it whenever you want to do the upgrade. It upgrades everything but without any questions. What would make /etc/issue so special that we have to change the way we handle it when people have a generic way to avoid all sort of questions? (not just the ones in base-files). Do you consider unattended-upgrades not enough for your particular needs? Thanks.
Bug#1054281: ITP: ruby-maven-tools
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : ruby-maven-tools Version : 1.2.1 Upstream author : Christian Meier URL : https://github.com/jruby/maven-tools License : Expat Programming Lang : Ruby Description : helpers for maven related tasks adds versions conversion from rubygems to maven and vice versa, ruby DSL for POM (Project Object Model from maven), pom generators, etc This is part of an effort to improve the JRuby build chain in Debian. Thanks, -- Jerome
Bug#1053533: mbedtls: enable MBEDTLS_NIST_KW_C
Source: mbedtls Severity: wishlist X-Debbugs-Cc: phco...@silabs.com, jerome.pouil...@gmail.com Hello, I have just noticed MBEDTLS_NIST_KW_C was not enabled (and obviously my project[1] depends on it). I usually use the default config provided by mbedtls (which I believe enable all the possible options). Do you know if there is any reason to strip down this configuration? [1] https://github.com/SiliconLabs/wisun-br-linux -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1052519: New upstream version 7.2
Package: sweethome3d Severity: wishlist Dear maintainer(s), Thanks for for maintaining sweethome3d in Debian! A new upstream version has just been released yesterday with nice features. It may be fast for this request - sorry about that - but could you consider to upload it? Best regards, Jérôme
Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS
The fixes for FTBFS have been in upstream for a long time, but I have not found time to do a proper release or update the Debian package for a while. Those FTBFS were a result of GCC changes that we fixed in upstream. The 'latest' branch on our Git repo ( https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes. Could someone please help with the maintenance instead of removing it? Thanks a lot. Kind regards, -Jerome On 9/10/23 05:21, Sebastian Ramacher wrote: Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org Control: affects -1 + src:ecere-sdk ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or bookworm. Please remove this unmaintained package from the archive. Cheers
Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS
Actually the 'master' branch ( https://github.com/ecere/ecere-sdk/commits/master ) also includes the FTBFS fixes and would be a more conservative update / fix with only 181 commits instead of 1905. Specifically some of the related fixing commits were: https://github.com/ecere/ecere-sdk/commit/53ec01de1c42cf342a35dc125a4fef01ffb5fced https://github.com/ecere/ecere-sdk/commit/e52df5589f3c674e8d3c23c8d7194496dc96d60c https://github.com/ecere/ecere-sdk/commit/9085cb19656728b5ccdbbbe26377ad5112513d01 Thanks again. Kind regards, -Jerome On 9/10/23 16:24, Jérôme St-Louis wrote: The fixes for FTBFS have been in upstream for a long time, but I have not found time to do a proper release or update the Debian package for a while. Those FTBFS were a result of GCC changes that we fixed in upstream. The 'latest' branch on our Git repo ( https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes. Could someone please help with the maintenance instead of removing it? Thanks a lot. Kind regards, -Jerome On 9/10/23 05:21, Sebastian Ramacher wrote: Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org Control: affects -1 + src:ecere-sdk ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or bookworm. Please remove this unmaintained package from the archive. Cheers
Bug#1051172: Update to 0.5.1
Package: libfixposix Severity: wishlist Hello, Please update libfixposix to 0.5.1, as it is needed to update JRuby in Debian (via its new Ruby SubSpawn dependency). Thanks! -- Jérôme
Bug#1043471: please update pgpainless
According to https://github.com/pgpainless/pgpainless/tags version 1.6.1 was released 3 weeks ago. It would be great to get this version into debian. This isn't possible at the moment because Debian still ships bouncycastle 1.72 which is too old for pgpainless 1.4 or later. Once bouncycastle gets updated, hopefully to 1.76, I'll look into it. -- Jérôme
Bug#1043253: tuxguitar: Missing java class ZipArchiveInputStream when opening .gp files
Package: tuxguitar Version: 1.5.6+dfsg1-6 Severity: normal Dear Maintainer, I get a missing java class error when opening .gp files. I can open .gpx and .gp5 files but all .gp files fail with the following error: org.herac.tuxguitar.action.TGActionException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35) at org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24) at org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67) at org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: org.herac.tuxguitar.action.TGActionException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48) at org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24) at org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67) at org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33) ... 4 more Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28) at org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28) at org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49) at org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40) ... 7 more Caused by: java.lang.NoClassDefFoundError: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39) at org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23) ... 10 more Caused by: java.lang.ClassNotFoundException: org.apache.commons.compress.archivers.zip.ZipArchiveInputStream ... 12 more Exception in thread "Thread-51" org.herac.tuxguitar.action.TGActionException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35) at org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24) at org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67) at org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: org.herac.tuxguitar.action.TGActionException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48) at org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24) at org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67) at org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33) ... 4 more Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28) at org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28) at org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49) at org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40) ... 7 more Caused by: java.lang.NoClassDefFoundError: org/apache/commons/compress/archivers/zip/ZipArchiveInputStream at org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39) at org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23) ... 10 more Caused by: java.lang.ClassNotFoundException: org.apache.commons.compress.archivers.zip.ZipArchiveInputStream ... 12 more From TuxGuitar, I can save as .gp3, .gp4 and .gp5 and then reopen, but I can't open .gp files. Here's a file that can be used to reproduce the error: https://blog.guitar-pro.com/wp-content/uploads/2021/07/ACDC-The_Jack-2.gp Thanks. Jérôme -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=f
Bug#644005: pcsxr: FFVIII can't detect memory card
FWIW, I had the same problem with Suikoden and changing the BIOS to SCPH7003.bin as instructed in aforementioned link did the trick. I know, not the same game and 7 years later, but I figured it was worth mentioning, and worth copying the BIOS name in this thread rather than relying on an external forum. (Note that apparently, after changing the BIOS, one can't reload emulator state, so better do it right away before going too far in a game.) -- Jérôme
Bug#1009964: php-fpm.service should be hardened
On Mon, 3 Jul 2023 10:17:06 -0400 =?UTF-8?B?SsOpcsO0bWUgQ2hhcmFvdWk=?= wrote: Hello, I'm using this patch on two different servers, and have not encountered any issues. I'm running with chroot'ed pools, and relatively complex/common applications like Drupal, Wordpress and Nextcloud. So it seems I wasn't doing my tests correctly and the patch does indeed need adjustment to work with chroot'ed pools: Add the CAP_SYS_CHROOT capability and "chroot" to the system call filter. -- Jérôme
Bug#1039737: reportbug: lxc-copy --ephemeral always fails
Hello, I also have this problem: after upgrading to bookworm, "lxc-copy --ephemeral" doesn't work anymore. # lxc-copy -n autopkgtest-sid -e -l TRACE Created autopkgtest-sid_4aGd6F as clone of autopkgtest-sid lxc-copy: autopkgtest-sid: ../src/lxc/lxccontainer.c: wait_on_daemonized_start: 878 Received container state "ABORTING" instead of "RUNNING" lxc-copy: autopkgtest-sid: ../src/lxc/af_unix.c: lxc_abstract_unix_recv_fds_iov: 218 Connection reset by peer - Failed to receive response lxc-copy: autopkgtest-sid: ../src/lxc/commands.c: lxc_cmd_rsp_recv_fds: 128 Failed to receive file descriptors for command "get_state" Thanks. -- Jérôme
Bug#1040144: Bisect ongoing
Narrowing down the issue... It seems the first 6.x version work fine. KO -- 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux OK -- 6.0.0-trunk-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0-1~exp1 (2022-10-09) x86_64 GNU/Linux -- Jérôme
Bug#1040144: Works with 5.10.0-22-amd64
On Tue, 4 Jul 2023 23:59:55 +0200 =?UTF-8?B?SsOpcsO0bWU=?= wrote: > I just installed the kernel from Bullseye (oldstable), keeping > firmwares from Bookwormn, and I confirm that there is no issue. I should have specified the kernel version 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux -- Jérôme
Bug#1040144: Works with bouzin 5.10.0-22-amd64
I just installed the kernel from Bullseye (oldstable), keeping firmwares from Bookwormn, and I confirm that there is no issue. It may be obvious but I figured I'd mention it. -- Jérôme
Bug#1009964: php-fpm.service should be hardened
Hello, I'm using this patch on two different servers, and have not encountered any issues. I'm running with chroot'ed pools, and relatively complex/common applications like Drupal, Wordpress and Nextcloud. Thanks, -- Jérôme
Bug#1040144: same issue with latest kernel from experimental
Same issue with latest kernel from experimental. 6.4.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.1-1~exp1 (2023-07-01) x86_64 GNU/Linux -- Jérôme
Bug#1040144: linux-image-6.3.0-1-amd64: radeon driver fails to load: modprobe: ERROR: could not insert 'radeon': No such device
Package: src:linux Version: 6.3.7-1 Severity: normal Dear Maintainer, Since I upgraded to Debian Bookworm (Linux 6), radeon drivers won't load. I tried both Bookworm and Sid kernels. Reporting against Sid. Graphic card VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340 / Radeon 520] [1002:6613] Graphics: Device-1: AMD Oland PRO [Radeon R7 240/340 / Radeon 520] driver: N/A Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: vesa unloaded: fbdev,modesetting,radeon dri: swrast gpu: N/A resolution: 1920x1080 API: OpenGL v: 4.5 Mesa 22.3.6 renderer: llvmpipe (LLVM 15.0.6 128 bits) Symptoms modprobe: ERROR: could not insert 'radeon': No such device Xorg log [32.663] (EE) open /dev/dri/card0: No such file or directory [32.663] (WW) Falling back to old probe method for modesetting [32.663] (EE) open /dev/dri/card0: No such file or directory [32.663] (II) Loading sub module "fbdevhw" [32.663] (II) LoadModule: "fbdevhw" [32.663] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [32.691] (II) Module fbdevhw: vendor="X.Org Foundation" [32.691]compiled for 1.21.1.7, module version = 0.0.2 [32.691]ABI class: X.Org Video Driver, version 25.2 [32.691] (EE) Unable to find a valid framebuffer device [32.691] (WW) Falling back to old probe method for fbdev [32.691] (II) Loading sub module "fbdevhw" [32.691] (II) LoadModule: "fbdevhw" [32.691] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [32.691] (II) Module fbdevhw: vendor="X.Org Foundation" [32.691]compiled for 1.21.1.7, module version = 0.0.2 [32.691]ABI class: X.Org Video Driver, version 25.2 [32.691] (EE) open /dev/fb0: No such file or directory [32.691] (EE) Screen 0 deleted because of no matching config section. [32.691] (II) UnloadModule: "radeon" [32.691] (EE) Screen 0 deleted because of no matching config section. [32.691] (II) UnloadModule: "modesetting" [32.691] (EE) Screen 0 deleted because of no matching config section. [32.691] (II) UnloadModule: "fbdev" [32.691] (II) UnloadSubModule: "fbdevhw" [32.691] (II) Loading sub module "vbe" [32.691] (II) LoadModule: "vbe" [32.691] (II) Loading /usr/lib/xorg/modules/libint10.so [32.887] (II) Module int10: vendor="X.Org Foundation" [32.887]compiled for 1.21.1.7, module version = 1.0.0 [32.887]ABI class: X.Org Video Driver, version 25.2 [32.887] (II) Loading sub module "int10" [32.887] (II) LoadModule: "int10" [32.887] (II) Loading /usr/lib/xorg/modules/libint10.so [32.887] (II) Module int10: vendor="X.Org Foundation" [32.887]compiled for 1.21.1.7, module version = 1.0.0 [32.887]ABI class: X.Org Video Driver, version 25.2 [32.887] (II) VESA(0): initializing int10 [32.891] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [32.891] (II) VESA(0): VESA BIOS detected [32.891] (II) VESA(0): VESA VBE Version 3.0 -- Package-specific info: ** Version: Linux version 6.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.3.0-1-amd64 root=UUID=d719f337-d835-4688-baf2-3e29f147fe04 ro ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc product_name: XPS 630i product_version: Unknow chassis_vendor: Dell Inc chassis_version: Unknow bios_vendor: Dell Inc. bios_version: 1.0.12 board_vendor: Dell Inc board_name: 0C113J board_version: A00 ** Loaded modules: rfcomm snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_seq qrtr cmac algif_hash ecb algif_skcipher af_alg bnep cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_ondemand sunrpc binfmt_misc snd_usb_audio btusb snd_hda_codec_realtek btrtl btbcm btintel snd_hda_codec_generic btmtk ledtrig_audio bluetooth snd_usbmidi_lib snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_rawmidi jitterentropy_rng snd_intel_sdw_acpi snd_seq_device ctr snd_hda_codec drbg mc snd_hda_core ansi_cprng joydev snd_hwdep ecdh_generic snd_pcm_oss rfkill snd_mixer_oss ecc snd_pcm coretemp snd_timer snd sha512_ssse3 dcdbas soundcore evdev serio_raw sha512_generic pcspkr sg nv_tco drivetemp parport_pc ppdev lp parport dm_mod fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 uas usb_storage efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid0 multipath linear hid_generic usbhid hid raid1 md_mod i2c_algo_bit sd_mod drm_display_helper
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
On Wed, 7 Jun 2023 18:47:02 +0530 Utkarsh Gupta wrote:> I've prepared a fix for the regression and uploaded the binaries at: https://people.debian.org/~utkarsh/lts/ruby2.5/ Can you please give these a try and see if that fixes the regression you're seeing? These packages also fix the Puppet regression reported here, on our buster systems. Thanks, -- Jérôme
Bug#1026026: /usr/sbin/needrestart: typo prevents vm detection and leads to error in microcode check
Control: severity -1 important Hello, This is crippling the usefulness of needrestart in virtual machines, because it is systematically reporting a failure every time it runs, with the output including: Failed to check for processor microcode upgrades. Furthermore, it is causing needrestart's "nagios check" mode to report a false "UNKNWOWN" status where it should be reporting "OK". Would it be possible to please backport this trivial patch? Thank you, -- Jérôme
Bug#1034824: tomcat9 should not be released with Bookworm
Le 2023-05-25 à 17 h 41, Martin Hostettler a écrit : Quoting from J�r�me Charaoui in (#1036250): I did further tests with puppetserver, which is a downstream dependency of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web requests (access) logging remains broken. There are no warnings or error messages anywhere: as you can imagine, the logging events are simply lost in the ether. I'm not sure if the latest patches from 2023-05-22 do fix those, but there was no follow up on the bug with details. For the record, these patches only fix the build issue and work around the test failures by disabling the affected tests. The logging problem is still present in puppetserver (and almost certainly puppetdb) with the patched trapperkeeper-webserver-jetty9-clojure package. Thanks, -- Jérôme
Bug#1036401: tools-dep-clojure/0.16.1264-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: team+cloj...@tracker.debian.org Control: affects -1 + src:tools-dep-clojure I would like to request an unblock to upload tools-dep-clojure/0.16.1264-3 which fixes a FTBFS bug. - #1036386 - tools-deps-clojure: FTBFS without network access [ Reason ] The package currently FTBFS because the testsuite which runs during build requires network access. [ Impact ] Accepting this release should not have any impact beyond tools-dep-clojure itself. libtools-dep-clojure has no rdeps in bookworm. [ Tests ] Test-related FTBFS issue was reproduced and fixed locally. Autopkgtest are passing. [ Risks ] None that I can imagine considering the very small delta. [ 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 Thanks! -- Jérômediff -Nru tools-deps-clojure-0.16.1264/debian/changelog tools-deps-clojure-0.16.1264/debian/changelog --- tools-deps-clojure-0.16.1264/debian/changelog 2023-01-22 22:02:21.0 -0500 +++ tools-deps-clojure-0.16.1264/debian/changelog 2023-05-20 08:54:30.0 -0400 @@ -1,3 +1,9 @@ +tools-deps-clojure (0.16.1264-3) unstable; urgency=medium + + * d/run-build-tests: skip test that requires internet (Closes: #1036386) + + -- Jérôme Charaoui Sat, 20 May 2023 08:54:30 -0400 + tools-deps-clojure (0.16.1264-2) unstable; urgency=medium * Team upload. diff -Nru tools-deps-clojure-0.16.1264/debian/run-build-tests tools-deps-clojure-0.16.1264/debian/run-build-tests --- tools-deps-clojure-0.16.1264/debian/run-build-tests 2023-01-22 22:02:21.0 -0500 +++ tools-deps-clojure-0.16.1264/debian/run-build-tests 2023-05-20 08:54:30.0 -0400 @@ -12,6 +12,5 @@ -e "(require '[clojure.tools.deps.util.dir-test])" \ -e "(System/exit (if (clojure.test/successful? (clojure.test/run-tests 'clojure.tools.deps.extensions.faken -'clojure.tools.deps.extensions.test-git 'clojure.tools.deps.gen.test-pom 'clojure.tools.deps.util.dir-test)) 0 1))"
Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest
Hi Markus, Thank you, your patch does indeed fix the build problem for this package, however, the test failure is not insignificant. I did further tests with puppetserver, which is a downstream dependency of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web requests (access) logging remains broken. There are no warnings or error messages anywhere: as you can imagine, the logging events are simply lost in the ether. I think these logs are a critical feature for debugging and security and it would be very unfortunate for bookworm to ship with logging crippled in this way for puppetserver. Although I did not test this specifically, I strongly suspect puppetdb is also affected in a similar way because they share many of the same components. Do you think it might be possible to backport the accessEvent variable fix from a later version of Logback? -- Jérôme Le 2023-05-19 à 09 h 53, Markus Koschany a écrit : Control: tags -1 patch Hi, I am attaching a patch for this issue. Somehow your package fell through the cracks because it has no dependency on logback. Logback is pulled in by Jetty though. While Logback and Jetty use the Jakarta servlet API now, your package still depends on libservlet-api-java. The fix for that was trivial. However the test failure is caused by my tomcat10-migration.patch https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91 Back then I thought it was acceptable to work around a build failure by setting the accessEvent variable to null since it seemed no package existed in Debian which would be affected by it. The Logback developers fixed that problem in newer versions, but a new upstream release of logback would have been too intrusive. Long story short: please double-check my patch and if we can ignore the logging problem Regards, Markus
Bug#1035674: pre-approval: unblock: puppetserver/7.9.5-2
Le 2023-05-14 à 15 h 19, Paul Gevers a écrit : Hi, On 11-05-2023 17:36, Jérôme Charaoui wrote: Uploaded to unstable. Thanks! and unblocked and aged. Thanks! Paul PS: while not a regression, the autopkgtest fails on armel. Have you checked why that is? Yes, I've looked and its failing to automatically generate its PKI at startup for some reason. I suspect the bug is somewhere deep down in JRuby but I haven't had the cycles to track it down. It's probably related to some of the 32-bit stuff that was failing in JRuby's autopkgtests, some of which was fixed in 9.4. So my plan currently is to fix it in sid at some point by upgrading to JRuby 9.4 and puppetserver 8. -- Jérôme
Bug#1032407: Cannot start mariadb-server unless manually mkdir -p /var/lib/mysql
Control: forwarded -1 https://github.com/puppetlabs/puppetlabs-mysql/issues/1566 After hitting this bug when upgrading a MariaDB server to bookworm, I submitted a bug report upstream: https://github.com/puppetlabs/puppetlabs-mysql/issues/1566 -- Jérôme
Bug#1035674: pre-approval: unblock: puppetserver/7.9.5-2
Le 2023-05-11 à 04 h 23, Paul Gevers a écrit : Control: tags -1 confirmed moreinfo Hi Jérôme, On 07-05-2023 17:47, Jérôme Charaoui wrote: I would like to request an unblock to upload puppetserver/7.9.5-2 which fixes two bugs using targeted fixes. - #1032241 puppetserver - service unit fails to realize the main process died - #1035541 puppetserver: CVE-2023-1894 Please go ahead. Uploaded to unstable. Thanks! -- Jérôme
Bug#1035674: pre-approval: unblock: puppetserver/7.9.5-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-puppet-de...@alioth-lists.debian.net
Control: affects -1 + src:puppetserver
I would like to request an unblock to upload puppetserver/7.9.5-2 which
fixes two bugs using targeted fixes.
- #1032241 puppetserver - service unit fails to realize the main
process died
- #1035541 puppetserver: CVE-2023-1894
[ Reason ]
The main reason is to fix the denial-of-service security issue prior to
the release. The second fix has been in the source repository's main
branch for some time, awaiting release.
[ Impact ]
Accepting this release should not have any impact beyond puppetserver
itself.
[ Tests ]
Build and autopkgtest are passing. The service unit fix has been applied
locally on my production system for several weeks.
[ Risks ]
There is a (low) risk that the patches introduce new bugs.
[ 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
Thanks!
-- Jérômediff -Nru puppetserver-7.9.5/debian/changelog
puppetserver-7.9.5/debian/changelog
--- puppetserver-7.9.5/debian/changelog 2023-02-09 21:11:26.0 -0500
+++ puppetserver-7.9.5/debian/changelog 2023-05-07 11:09:17.0 -0400
@@ -1,3 +1,10 @@
+puppetserver (7.9.5-2) unstable; urgency=medium
+
+ * abort service start/reload if mainpid dies (Closes: #1032241)
+ * add patch fixing CVE-2023-1894 (Closes: #1035541)
+
+ -- Jérôme Charaoui Sun, 07 May 2023 11:09:17 -0400
+
puppetserver (7.9.5-1) unstable; urgency=medium
* New upstream version 7.9.5
diff -Nru
puppetserver-7.9.5/debian/patches/0010-Backport-fix-for-CVE-2023-1894.patch
puppetserver-7.9.5/debian/patches/0010-Backport-fix-for-CVE-2023-1894.patch
--- puppetserver-7.9.5/debian/patches/0010-Backport-fix-for-CVE-2023-1894.patch
1969-12-31 19:00:00.0 -0500
+++ puppetserver-7.9.5/debian/patches/0010-Backport-fix-for-CVE-2023-1894.patch
2023-05-07 11:09:17.0 -0400
@@ -0,0 +1,127 @@
+From: =?utf-8?b?SsOpcsO0bWUgQ2hhcmFvdWk=?=
+Date: Sun, 7 May 2023 11:00:09 -0400
+Subject: Backport fix for CVE-2023-1894
+
+Forwarded: not-needed
+Bug: https://tickets.puppetlabs.com/browse/PE-35786
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035541
+Origin:
+ commit,
https://github.com/puppetlabs/puppetserver/commit/9e0239c19bc852b98c1a63fb33998de7eae388dc
+ backport,
https://github.com/puppetlabs/puppetserver/commit/545998b71baf70e35dc60c287f2cb2fc11ef9be2
+---
+ .../puppetserver/certificate_authority.clj | 33 +---
+ .../puppetserver/certificate_authority_test.clj| 36 ++
+ 2 files changed, 52 insertions(+), 17 deletions(-)
+
+diff --git a/src/clj/puppetlabs/puppetserver/certificate_authority.clj
b/src/clj/puppetlabs/puppetserver/certificate_authority.clj
+index 46429f4..16ab834 100644
+--- a/src/clj/puppetlabs/puppetserver/certificate_authority.clj
b/src/clj/puppetlabs/puppetserver/certificate_authority.clj
+@@ -787,6 +787,11 @@
+ (utils/subject-alt-names {:dns-name (conj default-alt-names host-name)}
false)
+ (utils/subject-alt-names (update alt-names-list :dns-name conj
host-name) false
+
++
++(def pattern-match-dot #"\.")
++(def pattern-starts-with-alphanumeric-or-underscore #"^[\p{Alnum}_].*")
++(def pattern-matches-alphanumeric-with-symbols-string
#"^[\p{Alnum}\-_]*[\p{Alnum}_]$")
++
+ (schema/defn validate-subject!
+ "Validate the CSR or certificate's subject name. The subject name must:
+ * match the hostname specified in the HTTP request (the `subject`
parameter)
+@@ -795,12 +800,16 @@
+ * not contain the wildcard character (*)"
+ [hostname :- schema/Str
+subject :- schema/Str]
++ (log/debug (i18n/trs "Checking \"{0}\" for validity" subject))
++
+ (when-not (= hostname subject)
++(log/infof "Rejecting subject \"%s\" because it doesn't match hostname
\"%s\"" subject hostname)
+ (sling/throw+
+ {:kind :hostname-mismatch
+- :msg (i18n/tru "Instance name \"{0}\" does not match requested key
\"{1}\"" subject hostname)}))
++ :msg (format "Instance name \"%s\" does not match requested key
\"%s\"" subject hostname)}))
+
+ (when (contains-uppercase? hostname)
++(log/info (i18n/tru "Rejecting subject \"{0}\" because all characters
must be lowercase" subject))
+ (sling/throw+
+ {:kind :invalid-subject-name
+:msg (i18n/tru "Certificate names must be lower case.")}))
+@@ -809,11 +818,25 @@
+ (sling/throw+
+ {:kind :invalid-subject-name
+:msg (i18n/tru "Subject contains a wildcard, which is not allowed:
{0}" subject)}))
+-
+- (when-not (re-matches
#"
Bug#1003862: Some news about a fix ?
thx … Le ven. 5 mai 2023 à 16:16, Holger Levsen a écrit : > > control: tags -1 + wontfix > thanks > > On Fri, May 05, 2023 at 03:49:44PM +0200, Jérôme Bardot wrote: > > That bug is currently blocking from using munin on not systemd systems. > > I'm not planning on supporting legacy initscripts myself. And despite tagging > this bug 'wontfix' for the time being I will accept patches, so IOW I'm just > tagging this 'wontfix' to set expectations right. > > In the long term I think munin's initscripts should be moved to > src:orphan-sysvinit-scripts and be maintained there by those who care. > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C > ⠈⠳⣄ > > "A developed country is not a place where the poor have cars. It's where the > rich use public transportation." (quote attributed to several people)
Bug#1003862: Some news about a fix ?
That bug is currently blocking from using munin on not systemd systems.
Bug#1032734: OOM when unlocking encrypted root in initramfs
Tagging ‘moreinfo’ then. I can definitely see how one can reproduce this theoretically (and possibly in the future when the kernel's memory requirement increase high enough), and mentioned that in the upstream bug, but I'm unable to find a reproducer after dist-upgrading bullseye systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso, and “Encrypted LVM” partition scheme, on VMs with 1024M RAM). Jérôme, what memory cost is the keyslot using? (Paste the output of `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.) Would also be interested to see by how much the amount of memory available to cryptsetup has changed before and after the uprade. Please edit /usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at the begining of the setup_mapping() function (patch attached). My own findings are as follows (again on a minimal netinst system without changing any default). cryptsetup isn't even close to memory exhaustion. Memory cost: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 4 Memory: 787907 Threads:1 - >8 - Free memory: - 8< - Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... totalusedfree shared buff/cache available Mem: 993756 74720 725012 60 194024 660412 Swap: 0 0 0 - >8 - I've also tested on another of my virtual machines that has 1GiB of RAM and got another result, closer to what you got in your experimentation: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 6 Memory: 499912 Threads:1 - >8 - So, I think what's happening is that the first VM may have been created with a different (larger) memory configuration, and was reduced at a later point in time. I don't have absolute certainty of this, but it would very well explain the discrepancy in memory cost. Also, I think I agree with your assessment that in the memory usage increase of the kernel may be involved: between the two releases, according to your numbers it appears to have increased nearly 25% (!). So it could also explain why it (probably very nearly) worked under bullseye. I there any way we could make the cryptsetup-initramfs hook aware of this, and emit a warning if it finds that the encrypted root lacks a keyslot with appropriate (low-enough) memory cost? Thanks, -- Jérôme
Bug#1032734: OOM when unlocking encrypted root in initramfs
Package: cryptsetup Version: 2:2.6.1-1 Severity: critical Dear maintainer, Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of RAM to bookworm, and was very surprised to be confronted with an OOM immediately upon entering my LUKS password in the initramfs prompt: Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... Please unlock disk vda5_crypt: [7.982435] Out of memory: Killed process 243 (cryptsetup) total-vm:799000kB, anon-rss:678296kB, file-rss:6440kB, shmem-rss:0kB, UID:0 pgtables:1384kB oom_score_adj:0 Killed cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or options? This machine was booting just fine before upgrading, under bullseye. The problem appears to be perhaps related to #924560, but in this instance, the issue causing an unbootable system post-upgrade. Thanks, -- Jérôme
Bug#1032061: puppetserver setup ca results in incomplete cert chain
Le 2023-03-04 à 03 h 09, Bastian Blank a écrit : On Fri, Mar 03, 2023 at 04:04:55PM -0500, Jérôme Charaoui wrote: I'm not able to reproduce this issue. Okay, then _what_ do you see? I'm seeing puppetserver generate its CA without errors, it's able to sign agent signing requests and agents are able to retrieve their catalogs from the server (including the server node itself) without any kind of PKI errors or issues. Easy check: | # grep BEGIN /etc/puppet/puppetserver/ca/ca_crt.pem /etc/puppet/puppetserver/ca/signed/* | /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE- | /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE- | /etc/puppet/puppetserver/ca/signed/debian-sid.home.arpa.pem:-BEGIN CERTIFICATE- > The CA file must only include one certificate, the trust root. The entity file needs to contain two: the intermediate CA and the entity cert. In a Debian container with the upstream Puppetlabs agent/server packages, running "puppetserver ca setup" results in a similiar (and working) certificate setup as seen with the Debian packages. The upstream documentation is light on details (it doesn't mention the intermediate cert anywhere...) but it doesn't otherwise appear to suggest that what we're seeing is wrong: https://www.puppet.com/docs/puppet/7/dirs_ssldir.html And using openssl: | # openssl s_client -connect localhost:8140 -CAfile /var/lib/puppet/ssl/certs/ca.pem -cert /var/lib/puppet/ssl/certs/debian-sid.home.arpa.pem -key /var/lib/puppet/ssl/private_keys/debian-sid.home.arpa.pem | CONNECTED(0003) | Can't use SSL_get_servername | depth=2 CN = Puppet Root CA: 74ab090112e6f0 | verify return:1 | depth=1 CN = Puppet CA: debian-sid.home.arpa | verify return:1 | depth=0 CN = debian-sid.home.arpa | verify return:1 | --- | Certificate chain | 0 s:CN = debian-sid.home.arpa |i:CN = Puppet CA: debian-sid.home.arpa |a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 |v:NotBefore: Mar 3 08:01:08 2023 GMT; NotAfter: Feb 28 08:01:12 2038 GMT | --- The certificate chain needs to contain two certificates, the entity one and the intermediate CA, otherwise it's incomplete. If the cert chain is indeed incomplete, we would see verification errors, no? Is this what you're encountering? Are you facing any failures in agent/server communications because of this? Any logs or errors messages you could share? Thanks. -- Jérôme
Bug#1032061: puppetserver setup ca results in incomplete cert chain
Hello, I'm not able to reproduce this issue. This seems likely to be related to bug #1032060 where the certificate name of "debian-sid." (with a trailing dot) was found to be the cause of PKI issues in puppetserver. Do you think we can close this as a duplicate of that bug? Thanks, -- Jérôme
Bug#1032241: puppetserver - service unit fails to realize the main process died
Control: severity -1 minor This is by design. The ExecStartPost command mirrors the upstream behavior of the startup shell script, only with much less bash: https://github.com/puppetlabs/ezbake/blob/main/resources/puppetlabs/lein-ezbake/template/global/ext/cli/start.erb The purpose is to ensure that systemd is aware of the puppetserver's internal state of readiness, because once java is spawned it can take up to minutes for the service to be ready to accept connections. Without ExecStartPost, systemd will consider the service started too early, and this could cause failures in the unit's dependents. The bug you describe is an unfortunate, yet minor side-effect, because the service manager does eventually realize the unit is failed (after 300 seconds, by default). If needed, this delay may be shortened by overriding the TimeoutStartSec unit parameter. I'm keeping this bug opened because the right solution is to implement support for sd_notify() signals in puppetserver, instead of the current clunky text-file method. This needs to actually be be implemented in trapperkeeper-clojure itself, and a new-feature ticket has already been filed upstream to track this: https://tickets.puppetlabs.com/projects/TK/issues/TK-499 Once this lands in Debian we'll be able to switch to Type=notify and get rid of the ExecStartPost commands altogether. -- Jérôme
Bug#1032060: puppetserver setup ca does not finish setup
Control: severity -1 normal Le 2023-02-27 à 11 h 29, Bastian Blank a écrit : On Mon, Feb 27, 2023 at 10:14:33AM -0500, Jérôme Charaoui wrote: Unfortunately I'm unable to reproduce this issue. Is this a new puppetserver installation, or an upgrade from puppet-master 5.5? This is a new installation. However I found the reason. The hostname setup is incomplete. The server considers the name for the certificate to be "debian-sid." and uses files "debian-sid..crt" (aka it adds a trailing dot). The agent seems to be not that kind and tries to get a new certificate, which fails as the CN is already in use. I'm curious to learn how one may reproduce this issue. Here in my test containers none of the machines' hostnames have a FQDN: only the host part exists, and neither do puppet agent nor puppetserver add a trailing dot to the client certificate. Le 2023-02-27 à 11 h 46, Antoine Beaupré a écrit : > Is not having a FQDN even supported in Puppet? If a certificate can be generated for it, it works, so yes one can use puppet on machines without FQDNs. > Maybe this could warrant a severity downgrade too... Seems like an edge case... Downgraded to normal. -- Jérôme
Bug#1032060: puppetserver setup ca does not finish setup
Control: tag -1 moreinfo Hello, Unfortunately I'm unable to reproduce this issue. Is this a new puppetserver installation, or an upgrade from puppet-master 5.5? In either case, please provide the full puppet and puppetserver configurations, as well as debug logs/output from the puppet agent and puppetserver daemon. Thanks, -- Jérôme
Bug#1003862:
Hello, some news about that bug ? I currently get the same error. (also without systemd) Currently the post update conf fails on the post install script.
Bug#1031510: Please open a new debian-puppet list
Hello, I'm a member of the Debian Puppet team, and I approve this message. Thanks, -- Jérôme
Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent
Le 2023-02-02 à 16 h 20, Antoine Beaupre a écrit : Package: puppet-agent Version: 7.22.0-3 Severity: normal [...] It should also be noted (perhaps in the NEWS.Debian?) that the previous START=no variable will probably not work to disable the agent daemon... Considering `exit 0` in there, not sure. Considering that 1) by default sysvinit systems have been migrated to systemd three releases ago, 2) the systemd unit file takes precendence over the initscript, and 3) that this systemd unit file is installed disabled-by-default, I don't think any further work or even a NEWS item is warranted here. -- Jérôme
Bug#1030323: /etc/default/puppet refers to non-existent /etc/init.d/puppet-agent
Le 2023-02-02 à 16 h 20, Antoine Beaupre a écrit : Package: puppet-agent Version: 7.22.0-3 Severity: normal Today's upgrade suggested this patch to the configuration file: Configuration file '/etc/default/puppet' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** puppet (Y/I/N/O/D/Z) [default=N] ? d --- /etc/default/puppet 2022-09-29 12:50:59.011237328 -0400 +++ /etc/default/puppet.dpkg-new2023-01-29 10:45:20.0 -0500 @@ -1 +1,4 @@ -START=no +# Defaults for puppet - sourced by /etc/init.d/puppet + +# Startup options +DAEMON_OPTS="" Yet that file doesn't exist: cat: /etc/init.d/puppet: No such file or directory The init file is actually /etc/init.d/puppet-agent now, so the default file needs to be corrected. Actually, this is most likely a manifestation of #1030212: the confffile /etc/init.d/puppet-agent should have been renamed to /etc/init.d/puppet but it didn't happen because I messed up as described in the bug report. The service name (both sysv and systemd) is indeed supposed to be "puppet" rather than "puppet-agent". The change was implemented in the interest of cross-platform compatibility. -- Jérôme
Bug#1030212: puppet-agent: conffiles not removed: /etc/init.d/puppet-agent /etc/default/puppet-agent
Le 2023-02-01 à 23 h 14, Paul Wise a écrit : On Wed, 2023-02-01 at 08:22 -0500, Jérôme Charaoui wrote: Specifically, I added to d/puppet-agent.maintscript: mv_conffile /etc/default/puppet-agent /etc/default/puppet 7.21.0-2~ mv_conffile /etc/init.d/puppet-agent /etc/init.d/puppet 7.21.0-2~ Do you know why this isn't working as intended? According to the dpkg-maintscript-helper manual page: If the conffile has not been shipped for several versions, and you are now modifying the maintainer scripts to clean up the obsolete file, prior-version should be based on the version of the package that you are now preparing, not the first version of the package that lacked the conffile. For example, for a conffile removed in version 2.0-1 of a package, prior-version should be set to 2.0-1~. This will cause the conffile to be removed even if the user rebuilt the previous version 1.0-1 as 1.0-1local1. Or a package switching a path from a symlink (shipped in version 1.0-1) to a directory (shipped in version 2.0-1), but only performing the actual switch in the maintainer scripts in version 3.0-1, should set prior-version to 3.0-1~. So 7.22.0-3~ should have been used for the version number, but for the next upload it should be 7.22.0-4~ or similar instead. Thanks for the clarification. I think you meant that I should have used prior-version "7.21.0-3~" instead of "7.21.0.2~", because the first version of the package with the service renamed was "7.21.0-3", and that is also the version where I added those lines in d/puppet-agent.maintscript. I'll adjust the prior-version to "7.22.0-4~" in my next upload, hopefully that fixes things. -- Jérôme
Bug#1030256: [Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
I think this is occurring because the test is being run as "root". I don't know how common that is in build environments, but it's not something that I have or think I should have in my build (sbuild) or test (autopkgtest) environments. Is there some flag we could use to tell reproducible-builds to build this package as a regular user instead of root? If not I might have to patch the test suite to work around some of the logic in there, which I'm not too excited about. Perhaps an alternative would be to add "puppet-agent" as a build dependency, because that package will create a "puppet" user in the environment. Thanks, -- Jérôme
Bug#1030212: puppet-agent: conffiles not removed: /etc/init.d/puppet-agent /etc/default/puppet-agent
Le 2023-02-01 à 03 h 14, Paul Wise a écrit :
Package: puppet-agent
Version: 7.22.0-3
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb
$ p=puppet-agent ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p |
grep obsolete
puppet-agent: obsolete-conffile /etc/init.d/puppet-agent
puppet-agent: obsolete-conffile /etc/default/puppet-agent
/etc/init.d/puppet-agent e57bcd8733d0b1f87def2289c80e1598 obsolete
/etc/default/puppet-agent b1a39e98f886262927fe4ab56a5c5991 obsolete
I thought that would be dealt with in this commit:
https://salsa.debian.org/puppet-team/puppet-agent/-/commit/20b3ba73d86ed69a3ec31c11277198dd8a906b2e
Specifically, I added to d/puppet-agent.maintscript:
mv_conffile /etc/default/puppet-agent /etc/default/puppet 7.21.0-2~
mv_conffile /etc/init.d/puppet-agent /etc/init.d/puppet 7.21.0-2~
Do you know why this isn't working as intended?
Thanks,
-- Jérôme
Bug#1029927: Unable run removal scripts
I've submitted a merge request on salsa to fix this issue: https://salsa.debian.org/debian/dbconfig-common/-/merge_requests/9 Thanks!
Bug#1029927: Unable run removal scripts
Package: dbconfig-common Version: 2.0.22 Hello, I would like to provide a dbconfig-common removal script, to remove an extra read-only database user account, by installing an executable at: /usr/share/dbconfig-common/scripts/puppetdb/remove/pgsql However, there is an error when the maintainer script is invoked via dbconfig-common: running maintainer removal script hook... remove": 1: Syntax error: Unterminated quoted string error encountered running maintainer removal hook: /usr/share/dbconfig-common/scripts/puppetdb/remove/pgsql existed with non-zero status When I invoke the script manually, it works fine, so it seems to be a problem with dbconfig-common itself. Thanks, -- Jérôme
Bug#1028333: puppetserver: find an upgrade path from puppet-master
The old "puppet-master" and "puppet-master-passenger" were basically just configuration files for the systemd/sysvinit and Apache2/Passenger, because the main (ruby) code was always in the "puppet" package. I think the way forward here is that first, we should make the 7.x transitional dummy package "puppet" "Breaks: puppet-master, puppet-master-passenger", to make clear that the old master packages cannot function with the libraries shipping in the latest puppet-agent package. And secondly, we should carefully consider whether a "seamless" transition is even possible at all. Puppetserver is completely different software which is configured differently than the old master, and as such I doubt that one can simple replace one package with the other and expect things to "just work". Even if it does, important bits of the configuration may likely be lost in translation (eg. auth.conf). So considering all this I'm currently leaning towards adding a transitional "puppet-master" and/or "puppet-master-passenger" package for the purpose of shipping a NEWS file recommending that users migrate to the puppetserver package manually. -- Jérôme
Bug#819332: closed by Debian FTP Masters (reply to Helmar Gerloni ) (Bug#819332: fixed in tuxguitar 1.5.6+dfsg1-1)
Thank you so much, Helmar and Tony for taking care of this! -- Jérôme
Bug#1029139: Please include Java/JRuby native extension
I've submitted a MR on Salsa implementing this change: https://salsa.debian.org/ruby-team/ruby-concurrent/-/merge_requests/1 Please review and merge at your earliest convenience. If you prefer, as a member of the Ruby team, I can also take care of performing the merge and uploading a new package revision. Thanks! -- Jérôme
Bug#1029139: Please include Java/JRuby native extension
Package: src:ruby-concurrent Version: 1.1.6+dfsg-5 Please include the Java/JRuby native extension (concurrent_ruby.jar) in the binary package. It should be possible to compile it now that jruby is once again in the archive. This is a dependency for the introduction of puppetserver into Debian bookworm. Thanks! -- Jerome
Bug#1029051: ITP: ruby-puppetserver-ca-cli
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : ruby-puppetserver-ca-cli Version : 2.3.6 Upstream author : Puppet, Inc. URL : https://github.com/puppetlabs/puppetserver-ca-cli License : Apache-2.0 Programming Lang : Ruby Description : configuration management system, ca cli library Puppet is a configuration management system that allows you to define the state of your IT infrastructure, then automatically enforces the correct state. This gem provides the functionality behind the Puppet Server CA interactions Thanks, -- Jerome
Bug#1029023: puppet agent fails as regular user in default configuration
Package: puppet-agent Version: 7.21.0-2 When executing "puppet agent --test" as a regular user, in a default configuration, the command will fail with: Warning: /File[/var/lib/puppet/ssl]: Could not stat; permission denied Error: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Error: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Wrapped exception: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl Error: /File[/var/lib/puppet/ssl]/ensure: change from 'absent' to 'directory' failed: Could not set 'directory' on ensure: Permission denied @ dir_s_mkdir - /var/lib/puppet/ssl This happens because in Debian the default setting for "ssldir" in Puppet is "/var/lib/puppet/ssl", whereas upstream uses "$confdir/ssl". A workaround is to run "puppet config set ssldir '$confdir/ssl'" to set "ssldir = $confdir/ssl" in "puppet.conf".
Bug#1028542: ITP: ruby-puppet-resource-api
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : ruby-puppet-resource-api Version : 1.8.16 Upstream author : David Schmitt URL : https://github.com/puppetlabs/puppet-resource_api License : Apache-2.0 Programming Lang : Ruby Description : Implementation of the Puppet Resource API specification A resource is the basic unit that is managed by Puppet. Each resource has a set of attributes describing its current state. Some attributes can be changed throughout the lifetime of the resource, whereas others are only reported back but cannot be changed. This library provides a simple way to write new native resources for Puppet. This Ruby gem is a required dependency for Puppetserver. Thanks, -- Jerome
Bug#935378: lektor: Package the admin UI
Version: 3.3.7-1 As documented in the package description and NEWS, we're currently unable to ship the Lektor frontend interface due to missing javascript build dependencies to compile the frontend. The upcoming Lektor 3.4 branch appears to be simplifying the build process for the frontend, so I'm keeping this bug open so we revisit this next upstream release. Thanks, -- Jérôme
Bug#1028024: libcommons-parent-java: regression between 43-1 and 55-1: Failed to read artifact descriptor for org.apache.commons:commons-compress:jar:debian
On Thu, 5 Jan 2023 19:43:38 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote:> For example, when trying to build `trapperkeeper-metrics-clojure`, the `lein jar` step fails with: Failed to read artifact descriptor for org.apache.commons:commons-compress:jar:debian Failed to read artifact descriptor for commons-codec:commons-codec:jar:debian Failed to read artifact descriptor for commons-io:commons-io:jar:debian Failed to read artifact descriptor for commons-logging:commons-logging:jar:debian I've hit this problem on my latest attempt to build puppetdb. Looking at the pom.xml diff, it seems that version 55-1 introduced a dependency on org.junit/junit-bom, which is not packaged in Debian. Add it to debian/maven.ignoreRules fixes the issue. Please find a debdiff attached for your convenience. Thanks!diff -Nru commons-parent-55/debian/changelog commons-parent-55/debian/changelog --- commons-parent-55/debian/changelog 2023-01-02 08:29:01.0 -0500 +++ commons-parent-55/debian/changelog 2023-01-06 10:09:56.0 -0500 @@ -1,3 +1,10 @@ +commons-parent (55-2) unstable; urgency=medium + + * Team upload. + * add org.junit/junit-bom to ignoreRules + + -- Jérôme Charaoui Fri, 06 Jan 2023 10:09:56 -0500 + commons-parent (55-1) unstable; urgency=medium * New upstream release diff -Nru commons-parent-55/debian/maven.ignoreRules commons-parent-55/debian/maven.ignoreRules --- commons-parent-55/debian/maven.ignoreRules 2023-01-02 08:29:01.0 -0500 +++ commons-parent-55/debian/maven.ignoreRules 2023-01-06 10:08:40.0 -0500 @@ -42,3 +42,4 @@ org.jacoco jacoco-maven-plugin org.spdx spdx-maven-plugin org.apache.maven.wagon wagon-ssh +org.junit junit-bom
Bug#1027861: linux: consider enabling CONFIG_IPV6_RPL_LWTUNNEL
Source: linux Severity: wishlist Tags: ipv6 X-Debbugs-Cc: jerome.pouil...@gmail.com Hi folks, "RPL Source Routing Header" (CONFIG_IPV6_RPL_LWTUNNEL) is currently disabled. It seems it is only an oversight since this option is not explicitly mentioned in debian kernel config file (and features like "Segment Routing Header encapsulation" are enabled while they are very close of "RPL Source Routing Header"). We consider to use RPL Source Routing Header in our implementation of border router for Low-Power and Lossy Networks[1]. So, I would be very glad to see this option enabled on Debian. FYI, I have build a custom kernel with this option enabled without any pain. I could send a patch if you need. Thank you, [1]: https://github.com/SiliconLabs/wisun-br-linux -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.10-custom (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
Le 2023-01-03 à 11 h 45, Bastian Germann a écrit : X-Debbugs-Cc: jer...@riseup.net On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann wrote: This will be rectified with importing v3.3.0+. But there will be other problems with the current werkzeug version which are addressed with v3.4.0b1: https://github.com/lektor/lektor/pull/1051 I see the maintainer and Jérôme have worked on new versions but they were never released. Is there something missing? Since python-mistune has moved to 2.x in Debian, the Lektor 3.2 and 3.3 branches are no longer functional. Upstream has integrated mistune 2.0 support in 3.4 but there have only been beta releases of it so far, and I'm not entirely sure if we should upload that and release it with bookworm? In short, I've been working on it but it has been quite a moving target so far. -- Jerome
Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
Le 2023-01-03 à 11 h 45, Bastian Germann a écrit : X-Debbugs-Cc: jer...@riseup.net On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann wrote: This will be rectified with importing v3.3.0+. But there will be other problems with the current werkzeug version which are addressed with v3.4.0b1: https://github.com/lektor/lektor/pull/1051 I see the maintainer and Jérôme have worked on new versions but they were never released. Is there something missing? And of course I've just noticed that python3-mistune0 now exists in Debian, so maybe I can finally upload Lektor 3.3 ...
Bug#1026925: ITP: tools-deps-clojure
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : tools-deps-clojure Version : 0.16.1264 Upstream author : 2017-2022, Rich Hickey, Alex Miller, and contributors URL : https://github.com/clojure/tools.deps License : EPL-1.0 Programming Lang : Clojure Description : API for transitive dependency graph expansion, classpath creation tools.deps makes it simple and easy to interactively consume JVM libraries, without dragging in unrelated concerns of building programs or project management. tools.deps will support package installers for Clojure (e.g. brew, apt-get, etc) to provide a path for Clojure installation and ongoing Clojure development. This package supersedes tools-deps-alpha-clojure, which has been deprecated. Thanks, -- Jerome
Bug#1026917: RM: jruby-openssl -- ROM; now bundled in jruby
Package: ftp.debian.org Severity: normal Please remove the jruby-openssl package. It is now bundled in the jruby package, and is not depended on by any other package in the archive. The reason for bundling is explained here: https://salsa.debian.org/java-team/jruby/-/blob/master/debian/README.source#L21-33 Thank you. -- Jerome
Bug#1026329: bouncycastle breaks pgpainless autopkgtest: premature end of stream
Hello, According to the pgpainless upstream, this bug is fixed bouncycastle 1.72.1 and later versions. Unfortunately, upstream does not appear to have tagged any version beyond 1.72 in their git repository. Thanks, -- Jerome
Bug#1025553: bullseye-pu: package core-async-clojure/1.3.610-5+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] core-async-clojure in stable suffers from frequent ftbfs issues described in bug #1013662 [ Impact ] Not accepting this change means this package will continue to ftbfs in the stable release [ Risk ] Low risk, only the package's testsuite is affected [ Tests ] The patch is been confirmed to fix the ftbfs problem [ 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 debdiff consists of the addition of a patch to the package's testsuite that fixes a serious ftbfs issue Thank you. -- Jeromediff -Nru core-async-clojure-1.3.610/debian/changelog core-async-clojure-1.3.610/debian/changelog --- core-async-clojure-1.3.610/debian/changelog 2022-05-13 11:12:48.0 -0400 +++ core-async-clojure-1.3.610/debian/changelog 2022-12-06 07:51:55.0 -0500 @@ -1,3 +1,10 @@ +core-async-clojure (1.3.610-5+deb11u1) bullseye; urgency=medium + + * Team upload. + * Skip test assertions which hang in single-cpu env (Closes: #1013662). + + -- Jérôme Charaoui Tue, 06 Dec 2022 07:51:55 -0500 + core-async-clojure (1.3.610-5) unstable; urgency=medium * Team upload. diff -Nru core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch --- core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch 1969-12-31 19:00:00.0 -0500 +++ core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch 2022-12-06 07:51:55.0 -0500 @@ -0,0 +1,39 @@ +From: =?utf-8?b?SsOpcsO0bWUgQ2hhcmFvdWk=?= +Date: Tue, 5 Jul 2022 17:56:14 -0400 +Subject: Skip test assertions which hang in single-cpu env + +This part hangs indefinitely (possible deadlock) when running on a +single-cpu system, or as a part of a single-cpu bound cgroup. + +Forwarded: no +--- + src/test/clojure/clojure/core/async_test.clj | 18 +- + 1 file changed, 1 insertion(+), 17 deletions(-) + +--- a/src/test/clojure/clojure/core/async_test.clj b/src/test/clojure/clojure/core/async_test.clj +@@ -288,23 +288,7 @@ + (is (= [0 1 2 3] + (
Bug#1013662: core-async-clojure: FTBFS randomly in bullseye
On Mon, 5 Dec 2022 22:04:06 +0100 Santiago Vila wrote: Hi. I attach an upload proposal for bullseye, in debdiff format against version 1.3.610-4 (stable version), so you can upload it "as is" if everything else is ok. There is a stable point release around the corner, it would be wonderful if this could be fixed by then. I'm not opposed to uploading it but I'm curious to know why this is needed now, because the next stable release is also "around the corner", in relative terms... Thanks, -- Jerome
Bug#1022860: bullseye-pu: package powerline-gitstatus/1.3.2-1+deb11u1
Le 2022-10-27 à 00 h 25, Salvatore Bonaccorso a écrit : On Wed, Oct 26, 2022 at 11:05:05PM -0400, Jérôme Charaoui wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] I would like to upload powerline-gitstatus to stable to fix CVE-2022-42906. I have consulted with the security team and they suggested we make the fix available via the next point release. [ Impact ] powerline-gitstatus/1.3.1 and earlier versions are susceptible to code execution via malicious repository. Note that the malicious repository must be obtained other than by "git clone". [ Tests ] The package has no autopkgtests. It has been tested manually. [ Risks ] The changeset between 1.3.1 and 1.3.2 is small. The risk is low that a new bug or security issue is introduced. [ 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 fix for CVE-2022-42906 is straightforward: it simply appends the argument "-C core.fsmonitor=" to the git command. Aside from that, a simple program option was added (untracked_not_dirty) and the README is updated. [Other info] As I expect a positive response, I will be uploading the package shortly. -- Jerome diff -Nru powerline-gitstatus-1.3.1/debian/changelog powerline-gitstatus-1.3.2/debian/changelog --- powerline-gitstatus-1.3.1/debian/changelog 2020-07-08 16:17:05.0 -0400 +++ powerline-gitstatus-1.3.2/debian/changelog 2022-10-26 22:54:03.0 -0400 @@ -1,3 +1,10 @@ +powerline-gitstatus (1.3.2-1+deb11u1) bullseye; urgency=medium + + * New upstream version 1.3.2 +- Fix command injection via malicious repository config (CVE-2022-42906) + + -- Jérôme Charaoui Wed, 26 Oct 2022 22:54:03 -0400 + powerline-gitstatus (1.3.1-2) unstable; urgency=medium The former proposed update was to just cherry-pick the needed change, so the version number 1.3.1-2+deb11u1. But if you propose to import 1.3.2 instread, then you need to pick 1.3.2-1~deb11u1 or 1.3.2-0+deb11u1 here, to have it sorting before the version which hit the archive as 1.3.2-1. In fact, if you just import a new upstream version on top of the current packaging then I would go for 1.3.2-0+deb11u1. If it is OTOH merely a rebuild of the upper-suite version then 1.3.2-1~deb11u1. In your case I think both of the ones is perfectly reasonable. Thanks for the review. I've opted to import the new upstream version on top of the bullseye packaging, so I have uploaded version 1.3.2-0+deb11u1. -- Jerome
