Bug#1081696: puppet: Package 7.25.0 or newer
Le 2024-09-13 à 16 h 59, Jesse Hathaway a écrit : Package: puppet Version: 7.23.0-1 Severity: wishlist It would be great if puppet 7.25.0 or newer could be packaged for bookworm. 7.25.0 adds an option, allow_pson_serialization, which may be used to disable pson serialization. Puppet 8 removes pson serialization, so it would be nice to be able to prepare for that change while still on puppet 7. I think a backport would be feasible: I doubt the dependencies are very different between the two versions. But several concerns that come to mind: - The backport policy [0] states that "To guarantee an upgrade path from stable+backports to the next stable, the package needs to be in testing.". Does it only mean that the package "puppet-agent" must be in testing, or that it must be in testing *and* the same version? In other words, would we be allowed to upload a newer puppet 7 even though testing has puppet 8? This should be clarified with the backports team. - The updated puppet-agent package should avoid breaking the version of puppetserver currently in bookworm - If puppet-agent enters backports, someone will need to be responsible for maintaining it in that suite and respond to security issues if they arise. Thanks, -- Jérôme [0] https://backports.debian.org/Contribute/#index5h3
Bug#1080968: bookworm-pu: package puppetserver_7.9.5-2+deb12u1
Le 2024-09-10 à 17 h 21, Jonathan Wiltshire a écrit :
Control: tag -1 confirmed
On Tue, Sep 10, 2024 at 05:11:40PM -0400, Jérôme Charaoui wrote:
Le 2024-09-10 à 15 h 48, Jonathan Wiltshire a écrit :
Control: tag -1 moreinfo
Hi,
On Thu, Sep 05, 2024 at 10:18:15PM -0400, Jérôme Charaoui wrote:
This is causing some installations that were upgraded from bullseye to
bookworm to break after some time because of the large amounts of reports
generated and stored on the Puppet server. An example of this is
https://bugs.debian.org/1078911
How does this interact with the puppetdb setting report-ttl?
(https://www.puppet.com/docs/puppetdb/7/maintain_and_tune.html#clean-up-old-reports)
There is no interaction: when reports are sent to PuppetDB ("reports =
puppetdb" in /etc/puppet/puppet.conf), they're stored in database backend,
typically PostgreSQL. The "report-ttl" setting is independent and affects
only those reports which are stored in the database.
In that case please added Closes for any applicable bugs and go ahead with
the upload.
Thank you.
Should Closes still be added for a bug that was closed by an upload to
unstable that addressed the bug in another manner? I'm referring here to
https://bugs.debian.org/1080489
-- Jérôme
Bug#1080968: bookworm-pu: package puppetserver_7.9.5-2+deb12u1
Le 2024-09-10 à 15 h 48, Jonathan Wiltshire a écrit :
Control: tag -1 moreinfo
Hi,
On Thu, Sep 05, 2024 at 10:18:15PM -0400, Jérôme Charaoui wrote:
This is causing some installations that were upgraded from bullseye to
bookworm to break after some time because of the large amounts of reports
generated and stored on the Puppet server. An example of this is
https://bugs.debian.org/1078911
How does this interact with the puppetdb setting report-ttl?
(https://www.puppet.com/docs/puppetdb/7/maintain_and_tune.html#clean-up-old-reports)
There is no interaction: when reports are sent to PuppetDB ("reports =
puppetdb" in /etc/puppet/puppet.conf), they're stored in database
backend, typically PostgreSQL. The "report-ttl" setting is independent
and affects only those reports which are stored in the database.
-- Jérôme
Bug#1081290: ITP: ruby-puppetfile-resolver
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-puppet-de...@alioth-lists.debian.net Control: block 1077614 by -1 Package name : ruby-puppetfile-resolver Version : 0.6.3 Upstream author : Puppet URL : https://github.com/puppetlabs/puppetfile-resolver License : Apache-2.0 Programming Lang : Ruby Description : Dependency resolver for Puppetfiles Resolves the Puppet Modules in a Puppetfile with a full dependency graph, including Puppet version checks. This is a dependency for packaging Puppet Bolt in Debian, see https://bugs.debian.org/1077614 Thanks, -- Jerome
Bug#1077614: RFP: puppetlabs-bolt -- infrastructure orchestration tool
Control: retitle -1 ITP: puppetlabs-bolt -- infrastructure orchestration tool Control: owner -1 ! On Tue, 30 Jul 2024 16:17:41 +0200 Laurent Bigonville wrote: Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-puppet-de...@lists.alioth.debian.org * Package name: puppetlabs-bolt Version : 3.29.0 Upstream Contact: pup...@puppet.com * URL : https://www.puppet.com/docs/bolt/ * License : Apache License 2.0 Programming Lang: Ruby Description : infrastructure orchestration tool [...] I'll be happy to have a stab at packaging this, I've been curious about Bolt for a while. None of the Windows stuff (winrm, ruby_smb) is in Debian however, so I'm not sure this part will be functional unless somone looks into that if they need it. -- Jérôme
Bug#1080122: Fallout from setuptools dropping the test command
On Sat, 31 Aug 2024 16:32:40 + Stefano Rivera wrote: FWIW: I think these bugs were all caused by setuptools v72 dropping support for the "test" command, so dh-python has fallen back to distutils / other test plugins. If you're trying to figure out how to fix the bug, look at the implementation of test_suite in setup.py to see what magic it does for test setup. In this particular case, dh_auto_test should simply not have been re-enabled in d/rules [0]. It never actually successfully ran the highly complex and custom shell-based test suite of this package, as an examination of the build logs demonstrate [1], but now it also errors-out. Unless someone else wanting to work this chimes in, I'll make an upload shortly that disables the tests again. -- Jérôme [0] https://salsa.debian.org/python-team/packages/powerline/-/commit/6f7ac0633507bbd6beae48cf5d79aadbe9b25043 [1] https://salsa.debian.org/python-team/packages/powerline/-/jobs/5959792#L2282
Bug#1080968: bookworm-pu: package puppetserver_7.9.5-2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu Control: affects -1 + src:puppetserver X-Debbugs-Cc: pkg-puppet-de...@alioth-lists.debian.net [ Reason ] The cronjob responsible for cleaning up the directory where reports are stored in the puppet-master package was omitted from its successor, puppetserver. [ Impact ] This is causing some installations that were upgraded from bullseye to bookworm to break after some time because of the large amounts of reports generated and stored on the Puppet server. An example of this is https://bugs.debian.org/1078911 Generating and storing these reports is enabled by default. [ Risk ] Users relying on the current behavior for long-term storage of the reports may suffer from data-loss, but is considered an acceptable trade-off as it will prevent outages from saturated root filesystems. [ Tests ] This has been tested in my home-lab Puppet server to work as expected. [ 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 attached debdiff consists of the addition of a daily cronjob which retrieves the current Puppet setting for "reportdir", and if the directory exists, deletes all contained files older than 30 days. It also removes any empty directory it finds. A systemd timer unit is not included because Puppet servers are typically not installed on desktop or laptop machines. In unstable, puppet-agent was simply modifed not to enable reports by default, see https://bugs.debian.org/1080489 Thank you. -- Jérômediff -Nru puppetserver-7.9.5/debian/changelog puppetserver-7.9.5/debian/changelog --- puppetserver-7.9.5/debian/changelog 2023-05-07 11:09:17.0 -0400 +++ puppetserver-7.9.5/debian/changelog 2024-09-05 21:30:33.0 -0400 @@ -1,3 +1,9 @@ +puppetserver (7.9.5-2+deb12u1) bookworm; urgency=medium + + * ship cronjob to clean up reportdir automatically + + -- Jérôme Charaoui Thu, 05 Sep 2024 21:30:33 -0400 + puppetserver (7.9.5-2) unstable; urgency=medium * abort service start/reload if mainpid dies (Closes: #1032241) diff -Nru puppetserver-7.9.5/debian/puppetserver.cron.daily puppetserver-7.9.5/debian/puppetserver.cron.daily --- puppetserver-7.9.5/debian/puppetserver.cron.daily 1969-12-31 19:00:00.0 -0500 +++ puppetserver-7.9.5/debian/puppetserver.cron.daily 2024-09-05 21:30:33.0 -0400 @@ -0,0 +1,10 @@ +#!/bin/sh + +reportdir="$(puppet config print reportdir)" + +if [ -e "$reportdir" ] ; then +find "$reportdir" -type f -ctime +30 -delete +find "$reportdir" -mindepth 1 -type d -empty -delete +fi + +exit 0
Bug#1078576: lektor: please update lektor so that python3-mistune0 can be removed
Control: tags -1 confirmed
Control: tags -1 upstream
Control: forwarded -1 https://github.com/lektor/lektor/issues/1156
Hello,
> Please switch to regular, alive, python3-mistune.
I looked into upgrading to the Lektor v3.4.x series today, which adds
support for mistune 2.
Unfortunately, python3-mistune already ships mistune 3, and Lektor
doesn't support it. It supports only mistune 0 or 2.
See https://github.com/lektor/lektor/issues/1156
In addition, Lektor doesn't build at all with mistune 3 because of
serious API changes between 2 and 3, for example:
ImportError while loading conftest
'/<>/.pybuild/cpython3_3.12_lektor/build/tests/conftest.py'.
tests/conftest.py:12: in
import lektor.project
lektor/project.py:12: in
from lektor.environment import Environment
lektor/environment/__init__.py:26: in
from lektor.markdown import Markdown
lektor/markdown/__init__.py:33: in
from lektor.markdown.mistune2 import MarkdownController2 as
controller_class
lektor/markdown/mistune2.py:74: in
class MarkdownController2(MarkdownController):
lektor/markdown/mistune2.py:93: in MarkdownController2
PLUGINS = {**mistune.PLUGINS}
E AttributeError: module 'mistune' has no attribute 'PLUGINS'
Until Lektor ships a markdown controller that supports mistune 3, or
Debian ships a mistune 2 package, I'm afraid it won't be possible to
keep Lektor in testing.
-- Jérôme
Bug#1080489: Reports causing unbounded filesystem usage growth
Package: puppet-agent Severity: serious Version: 8.4.0-1 Control: affects -1 puppetserver In bug #1078911 [0], a user reported that a cron job responbile for cleaning up old reports previously shipped in puppet-master was no longer shipped in puppetserver. The consequence was an accumulation of files under /var/lib/cache/reports until the filesystem filled up and the system broke. Further research has shown that the issue doesn't only affect environments where Puppet agents are attached to a Puppet Server, but also the "puppet apply" command which generates and stores reports locally upon every invocation, with no automatic cleanup out of the box. An upload of the puppetserver package adding a cleanup cron job led to a discussion thread [1] on the puppet-team mailing list. While the participants were unable to agree on the default retention this cron job should follow, there was agreement that ultimately, storing reports on the filesystem was a bad default and should simply be disabled in new installations. To do so requires a change in the libraries shipped by the puppet-agent package, where defaults used by both agent and server are defined. After consultation with the larger Puppet community on IRC, a pull request appeared to also disable reports by default in upstream Puppet [2]. Comments from a Puppet developper suggests this change will only be shipped in a future Puppet 9 release, however. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078911 [1] https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2024-August/013829.html [2] https://github.com/puppetlabs/puppet/pull/9461
Bug#1070744: [Pkg-puppet-devel] Bug#1070744: /usr/bin/puppet: puts non-regeneratable data in /var/cache
Le 2024-09-04 à 10 h 45, Antoine Beaupré a écrit : On 2024-09-04 10:35:57, Jérôme Charaoui wrote: I agree perhaps the default of "/var/cache/puppet/reports" isn't ideal. But instead of changing only "reportdir", we might want to instead change "vardir" from "/var/cache/puppet" to something like "/var/puppet". I'm not sure that anything puppet puts inside "vardir" can really be qualified as "cache"? That would break the FHS too, no? perhaps /var/spool/puppet or /var/lib/puppet instead? The $libdir variable in puppet.conf is already set to /var/lib/puppet, I'm not sure if it would be wise to use the same path for both settings... The upstream docs describe both parameters as such: vardir: Where Puppet stores dynamic and growing data. libdir: An extra search path for Puppet. This is only useful for those files that Puppet will load on demand, and is only guaranteed to work for those cases. In fact, the autoload mechanism is responsible for making sure this directory is in Ruby's search path So maybe vardir could be /var/lib/puppet and libdir: $vardir/ruby ? -- Jérôme
Bug#1070744: /usr/bin/puppet: puts non-regeneratable data in /var/cache
Hello, On Wed, 8 May 2024 11:20:47 +0200 Hendrik Jaeger wrote: Package: puppet-agent Version: 7.23.0-1 Severity: minor File: /usr/bin/puppet X-Debbugs-Cc: debian-b...@henk.geekmail.org Dear Maintainer, * What led up to the situation? I was trying to build an exclude list for my backups and went through the content of my filesystems. * What was the outcome of this action? I noticed that there are reports of puppet runs in /var/cache/puppet/reports. * What outcome did you expect instead? I did expect all data in /var/cache and its subdirectories to be regeneratable and not contain any information one might want to backup. According to the FHS in https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05. > /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. This is not the case for reports: Puppet can not regenerate the report for a specific run. Also "cache" usually refers to data that will be reused which is not the case for these reports. /var/log seems a better fit for those. In my concrete case, it seems suboptimal that these reports are in a directory that I would like to exclude from backups because it should not contain anything worth backing up anyway as all data in there is supposed to be regeneratable and these reports clearly are not. Under the "Rationale" this use case is even mentioned explicitly: > The existence of a separate directory for cached data allows system administrators to set different disk and backup policies from other directories in /var. The argument has been made on IRC that usually reports are not stored locally anyway, but it seemed implied that the server would also store the reports in a directory named "cache", but outside the FHS in /opt/puppetlabs/puppet/cache/reports in the case of a non-debian installation. I have no puppetserver installation with debian on hand, so I don’t know how the debian package would behave. Another argument has been made that the reports are stored in puppetdb and the reports are thus only stored temporarily as files on a disk. IMHO that still wouldn’t make them "cache" data. "temporary" data maybe, so in that case they should probably go to /var/tmp or /tmp. Or, as https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s14.html mentions: > /var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed. Both of these arguments are kind of OK for a certain set of circumstances but not everybody is running a puppetdb or even a puppetserver. I am running puppet standalone, i.e. with `puppet apply`, so the reports will not be transferred to the server and will not be consumed into/by puppetdb. In any case, treating reports as "cached" data seems quite clearly wrong. In the case of standalone puppet (i.e. `puppet apply`) IMHO they are "logs" and should go to /var/log. In the case of a puppet-agent (i.e. a puppet client/agent connecting to a puppet server _without_ a puppetdb), they should probably not be saved on the client at all but if so, they are also "logs" IMHO and should be treated like mentioned above. On the server, they should also be treated like "logs" but not necessarily go to /var/log like machine-local log data. I don’t think I have a concrete sensible suggestion for this case. Maybe /var/lib. In the case of a puppetserver with a puppetdb, they should probably not be saved as files at all on the server. Unless they are sent directly to the puppetdb from the puppedserver, but consumed later, they are probably "spool" data. I agree perhaps the default of "/var/cache/puppet/reports" isn't ideal. But instead of changing only "reportdir", we might want to instead change "vardir" from "/var/cache/puppet" to something like "/var/puppet". I'm not sure that anything puppet puts inside "vardir" can really be qualified as "cache"? I think perhaps the only reason it's that way is because of the naming choices made by upstream a long time ago. -- Jérôme
Bug#1040767: facter: inconsistent detection of Xen dom0
Control: reassign -1 virt-what 1.25 Le 2024-09-02 à 05 h 34, sergio.gel...@astro.su.se a écrit : On Sat, Aug 31, 2024 at 01:36:52AM +0200, Jérôme Charaoui wrote: If you look at the virt-what resolver [0], it's just matching for strings in the output. If the output of virt-what contains both 'xen-hvm' and 'xen-dom0' then 'xenhvm' is going to be used because 'xen-hvm' will match first. It's possible we might want to actually match for 'xen-dom0' *first*, but this all depends on virt-what's full output. Would it be possible to share here what virt-what is outputting both on dom0 and domU? Here is a fresh transcript from a bookworm dom0: According to this output, it definitely looks like virt-what is at fault here. Reassigning. I also think it's wrong for the fact value to depend on whether virt-what is installed. (In a guest, I get "xenu" if virt-what is absent, "xen" if it is present. This adds unnecessary complexity to Puppet manifests.) As far as I'm concerned facter should not use virt-what. I achieve this on my systems by removing virt-what (I had to re-add it manually in order to produce the test output above). At best, facter and virt-what should agree on about the virtualisation environment, otherwise virt-what should more precise than facter by itself. -- Jérôme
Bug#1040767: facter: inconsistent detection of Xen dom0
On Wed, 19 Jul 2023 09:48:21 + Sergio Gelato wrote: systemd has a similar issue, tracked in #1038901. (Maybe one should ask the virt-what maintainers whether they agree with https://github.com/systemd/systemd/issues/28113#issuecomment-1621986461, in which case this bug can be reassigned to virt-what.) Actually the origin of the bug could indeed be facter. If you look at the virt-what resolver [0], it's just matching for strings in the output. If the output of virt-what contains both 'xen-hvm' and 'xen-dom0' then 'xenhvm' is going to be used because 'xen-hvm' will match first. It's possible we might want to actually match for 'xen-dom0' *first*, but this all depends on virt-what's full output. Would it be possible to share here what virt-what is outputting both on dom0 and domU? Thanks, -- Jérôme [0] https://github.com/puppetlabs/facter/blob/main/lib/facter/resolvers/virt_what.rb#L25-L35
Bug#1079793: puppetserver 7 upgrade doesn't clean up old puppetmaster 5 files
Hello, Just a note of caution: the upgrade from puppet-master to puppetserver uses the same "puppet.conf" configuration, which sometimes has the "vardir" setting defined to "/var/lib/puppet". If that's the case, then this directory will not only contain the "old puppetmaster" files, but also the new ones. As for the ssl files, puppetserver has some heuristics to move the files itself on upgrade, see the "puppetserver migrate" command. Since the puppetserver CA files are quite sensitive and losing them can cause a serious outage, my preference would be to *not* touch these at all with the package maintscripts. In general, I'm weary of dealing with this issue because the medicine might end up being worse than the disease (a few stray files). Maintainer's time is also scarce, and I'm also tempted to mention that the 5.5 -> 7 upgrade ship in Debian has sailed... Thanks, -- Jérôme Le 2024-08-27 à 09 h 50, Antoine Beaupre a écrit : Package: puppetserver Version: 7.9.5-2 Severity: minor This is a followup for #1078911 which was interpreted as only an emergency fix to cleanup large report directories. But it seems to me there's more work to be done here: in that bug report, I described a situation where I had lots of old reports lying around from the old puppetmaster in /var/lib/puppet. I have also just realized I have "facts" from the previous puppetmaster here: anarcat@marcos:~$ sudo ls -al /var/lib/puppet/yaml/facts total 164 drwxr-xr-x 2 puppet puppet 4096 4 avr 2023 . drwxr-x--- 3 puppet puppet 4096 22 jun 2020 .. -rw-rw 1 puppet puppet 19614 25 jan 2023 angela.anarc.at.yaml -rw-rw 1 puppet puppet 15192 25 jan 2023 curie.anarc.at.yaml -rw-rw 1 puppet puppet 13463 21 aoû 2020 emma.anarc.at.yaml -rw-rw 1 puppet puppet 14625 25 jan 2023 louise.anarc.at.yaml -rw-rw 1 puppet puppet 54690 25 jan 2023 marcos.anarc.at.yaml -rw-rw 1 puppet puppet 24955 25 jan 2023 tubman.anarc.at.yaml I'm not sure how to tell the "client" from the "server" stuff apart, so this is a bit tricky. But I even found an old CA in there... Perhaps we could move over or delete the files owned by "puppet" in there? anarcat@marcos:~$ sudo find /var/lib/puppet -user puppet -type d /var/lib/puppet /var/lib/puppet/bucket /var/lib/puppet/ssl /var/lib/puppet/ssl/private_keys /var/lib/puppet/ssl/certificate_requests /var/lib/puppet/ssl/public_keys /var/lib/puppet/ssl/private /var/lib/puppet/ssl/certs /var/lib/puppet/ssh_keys /var/lib/puppet/ssh_keys/curie.anarc.at /var/lib/puppet/ssh_keys/emma.anarc.at /var/lib/puppet/ssh_keys/angela.anarc.at /var/lib/puppet/preview /var/lib/puppet/yaml /var/lib/puppet/yaml/facts /var/lib/puppet/server_data Not sure how to untangle this, but we should at least have an upgrade procedure for this. -- System Information: Debian Release: 12.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 puppetserver depends on: ii default-jre-headless 2:1.17-74 ii facter 4.3.0-2 ii hiera3.10.0-1 ii jruby9.3.9.0+ds-8 ii libclj-time-clojure 0.15.2-2 ii libclj-yaml-clojure 0.7.2-1 ii libclojure-java 1.11.1-2 ii libcomidi-clojure0.3.2-2 ii libcommons-exec-java 1.3-2 ii libcommons-io-java 2.11.0-2 ii libcommons-lang-java 2.6-10 ii libdropwizard-metrics-java 3.2.6-1 ii libdujour-version-check-clojure 0.2.3-1 ii libjruby-utils-clojure 4.0.3-4 ii libkitchensink-clojure 3.2.1-1 ii libliberator-clojure 0.15.3-1 ii libprismatic-schema-clojure 1.2.0-4 ii libpuppetlabs-http-client-clojure2.1.1-1 ii libpuppetlabs-i18n-clojure 0.9.2-2 ii libpuppetlabs-ring-middleware-clojure1.3.1-3 ii libraynes-fs-clojure 1.5.2-1 ii libsemver-clojure0.3.0-2 ii libshell-utils-clojure 1.0.2-3 ii libslingshot-clojure 0.12.2-3 ii libssl-utils-clojure 3.5.0-2 ii libtrapperkeeper-authorization-clojure 1.0.0-4 ii libtrapperkeeper-clojure 3.2.0-4 ii libtrapperkeeper-comidi-metrics-clojure 0.1.2-2 ii libtrapperkeeper-filesystem-watcher-clojure 1.2.2-3 ii libtrapperkeeper-metrics
Bug#1077976: puppetdb's autopkg tests fail with OpenJDK 21
Hello, Le 2024-08-05 à 07 h 48, Matthias Klose a écrit : Tests fail with: 201s autopkgtest [17:10:41]: summary 201s standalone FAIL stderr: warn: JDK 21.0.4 is neither tested nor supported. Please use JDK 17 I'm not sure about the value of such a test ... instead of testing that the software works. Obviously, the test is not only checking which JDK version is running. PuppetDB is simply emitting a warning about that on stderr, and the test is just missing "Restriction: allow-stderr". I'll fix that in the next upload. -- Jérôme
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#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#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#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#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#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#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#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#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#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-m
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#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#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#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
Bug#1022860: bullseye-pu: package powerline-gitstatus/1.3.2-1+deb11u1
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
[ Jann Haber ]
diff -Nru powerline-gitstatus-1.3.1/powerline_gitstatus/segments.py
powerline-gitstatus-1.3.2/powerline_gitstatus/segments.py
--- powerline-gitstatus-1.3.1/powerline_gitstatus/segments.py 2019-01-11
08:50:57.0 -0500
+++ powerline-gitstatus-1.3.2/powerline_gitstatus/segments.py 2022-10-09
08:58:20.0 -0400
@@ -11,9 +11,9 @@
def execute(self, pl, command):
pl.debug('Executing command: %s' % ' '.join(command))
-
+
git_env = os.environ.copy()
-git_env['LC_ALL'] = 'C'
+git_env['LC_ALL'] = 'C'
proc = Popen(command, stdout=PIPE, stderr=PIPE, env=git_env)
out, err = [item.decode('utf-8') for item in proc.communicate()]
@@ -27,13 +27,13 @@
def get_base_command(self, cwd, use_dash_c):
if use_dash_c:
-return ['git', '-C', cwd]
+return ['git', '-c', 'core.fsmonitor=', '-C', cwd]
while cwd and cwd != os.sep:
gitdir = os.path.join(cwd, '.git')
if os.path.isdir(gitdir):
-return ['git', '--git-dir=%s' % gitdir, '--work-tree=%s' % cwd]
+return ['git', '-c', 'core.fsmonitor=', '--git-dir=%s' %
gitdir, '--work-tree=%s' % cwd]
cwd = os.path.dirname(cwd)
@@ -80,10 +80,10 @@
return (staged, unmerged, changed, untracked)
-def build_segments(self, formats, branch, detached, tag, behind, ahead,
staged, unmerged, changed, untracked, stashed):
+def build_segments(self, formats, branch, detached, tag, behind, ahead,
staged, unmerged, changed, untracked, stashed, untracked_not_dirty):
if detached:
branch_group = 'gitstatus_branch_detached'
-elif staged or unmerged or changed or untracked:
+elif staged or unmerged or changed or (untracked and not
untracked_not_dirty):
branch_group = 'gitstatus_branch_dirty'
else:
branch_group = 'gitstatus_branch_clean'
@@ -111,7 +111,7 @@
return segments
-def __call__(self, pl, segment_info, use_dash_c=True, show_tag=False,
formats={}, detached_head_style='revision'):
+def __call__(self, pl, segment_info, use_dash_c=True, show_tag=False,
formats={}, detached_head_style='revision', untracked_not_dirty=False):
pl.debug('Running gitstatus %s -C' % ('with' if use_dash_c else
'without'))
cwd = segment_info['getcwd']()
@@ -160,7 +160,7 @@
else:
tag = tag[0]
-return self.build_segments(formats, branch, detached, tag, behind,
ahead, staged, unmerged, changed, untracked, stashed)
+return self.build_segments(formats, branch, detached, tag, behind,
ahead, staged, unmerged, changed, untracked, stashed, untracked_not_dirty)
gitstatus = with_docstring(G
Bug#978663: facter: please package facter 4.x
On Tue, 29 Dec 2020 15:41:08 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote: Package: src:facter Severity: wishlist Dear maintainer, While puppet 6 still supports facter 3.x, I think it wouldn't be a bad idea to package facter 4.x in the archive. It seems the current version of puppet in Debian (puppet 5) requires the 3.x version though [1], so we can't just push 4.x to sid. Considering facter 4.x is a re-write in ruby, I think the best option would be to create a "facter4" package and keep facter in Debian as "facter3". Now that puppet-agent 7.x is in unstable, I don't think keeping facter 3.x is relevant at all. In fact, that version is now deprecated and unmaintained. So I think it's best to keep the package named "facter" in version 4 and beyond. -- Jerome
Bug#1009329: New upstream version 2.7.1 - Please package
Control: tags -1 +patch Dear maintainer, Just a quick note that a merge request has been submitted on Salsa to build a new version of this package. https://salsa.debian.org/debian/keepassxc/-/merge_requests/9 Please review it at your convenience. Thank you! -- Jerome
Bug#987255: puppet: needs an extra systemd config line to use the right SE Linux context
Control: notfound 987255 7.16.0-2 Control: reassign 987255 src:puppet Hello, With Puppet 7.x and later, the server and agent binaries are not the same anymore. Thus, this problem only affects the 5.x series when using the deprecated puppet-master, and this patch is obsolete. -- Jerome
Bug#989031: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989031
Hello, I found that the same bug can also be triggered by using the '--debug' switch. It seems this problem was fixed by upstream, here: https://github.com/jaymzh/pius/commit/6a92664fe0cfacffb03e6f3312c1c5fb4d785297 Thanks, -- Jerome
Bug#1015957: ITP: junit5-system-exit
Package: wnpp Severity: wishlist Owner: Jérôme Charaoui Package name : junit5-system-exit Version : 1.1.2 Upstream author : Todd Ginsberg URL : https://github.com/tginsberg/junit5-system-exit License : Expat Programming Lang : Java Description : JUnit5 Extension to help write tests that call System.exit() This JUnit 5 Extension helps you write tests for code that calls System.exit(). Starting with JUnit 5, @Rules, @ClassRules, and Runners were replaced by the Extension concept. This package is a dependency for PGPainless (ITP #1005300). Thanks, -- Jerome
Bug#998708: Please upgrade to 6.9.1
Hello, I would like to add that the current version of Gradle in Debian is unable to execute the test suites of many Gradle-built packages, since support for JUnit5 tests was only added in the 4.6 release: https://docs.gradle.org/4.6/release-notes.html#junit-5-support Thanks, -- Jerome
