Bug#1081696: puppet: Package 7.25.0 or newer

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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#1081214: Should ecere-sdk be removed from unstable?

[Jérôme St-Louis]

Control: tags -1 + wontfix

Dear all,

I really do hope to update the package to correct the FTBFS bugs, but 
have unfortunately been too busy lately.
Please keep the package in unstable, as I really do hope to provide an 
updated release that addresses these issues ASAP.


If anyone is available to help maintaining this package, I would much 
appreciate help and would be very keen to assist with that task.
Otherwise, I will certainly get around to it myself, hopefully within 
the next 6 months.
The bug fixes for these FTBFS issues should already be in our upstream 
master branch :


commit ca58cfa4e26e03271e32ee6aae3206956fdc26fd
Author: Jerome St-Louis 
Date:   Wed May 20 07:25:49 2020 -0400

    compiler/libec: Fixed multiple definitions issues breaking on GCC 
10 without -fcommon


commit c94efd6390599a4a291b7fe8b3d2d62699247380
Author: Jerome St-Louis 
Date:   Sun Sep 6 03:35:01 2020 -0400

    compiler/bootstrap: Updated for GCC 10 Common fixes

commit ca58cfa4e26e03271e32ee6aae3206956fdc26fd
Author: Jerome St-Louis 
Date:   Wed May 20 07:25:49 2020 -0400

    compiler/libec: Fixed multiple definitions issues breaking on GCC 
10 without -fcommon


and other fixes may also be available from our /latest/ branch 
.


Thank you, and apologies for the delays in fixing these issues.

Kind regards,

-Jerome

On 9/9/24 7:06 AM, Helmut Grohne wrote:

Source: ecere-sdk
Severity: important
User:helm...@debian.org
Usertags: sidremove

Dear maintainer,

I suggest removing ecere-sdk from Debian for the following reasons:
  * It accumulated 2 RC-bugs:
+ #898832: ecere-sdk: FTBFS on i386: 
/usr/lib/gcc/i686-linux-gnu/7/include/stddef.h:435:78: error: syntax error
  Last modified: 1 year, 2 months

+ #995050: ecere-sdk FTBFS with gcc 10
  Last modified: 1 year, 4 months

  * It is not part of bookworm or trixie and is not a key package.

This bug serves as a pre-removal warning. After one month, the bug will be
reassigned to ftp.debian.org to actually request removal of the package.

In case the package should be kept in unstable, please evaluate each of the
RC-bugs listed above.
  * If the bug is meant to permanently prevent the package from entering testing
or a stable release, but this package should stay part of unstable, please
add a usertag:

userhelm...@debian.org
usertags NNN + sidremove-ignore

  * If the bug no longer applies, please close it. If it is closed, check
whether the fixed version is correct and adjust if necessary.

  * Is the bug really release-critical? If not, please downgrade.

  * If the bug still applies, please send a status update at least once a year.

Once all of the mentioned RC bugs have been acted upon in one way or another,
please close this bug.

In case the package should be removed from unstable, you may reassign this
bug report:

 Control: severity -1 normal
 Control: retitle -1 RM: ecere-sdk -- RoM; rc-buggy
 Control: reassign -1 ftp.debian.org
 Control: affects -1 + src:ecere-sdk

Alternatively, you may wait a month and have it reassigned.

In case you disagree with the above, please add a wontfix tag to this bug.

 Control: tags -1 + wontfix

Doing so will also prevent automatic reassignment.

Kind regards

A tool for automatically removing packages from unstable

This bug report has been automatically filed with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne  for assistance.

Bug#1077614: RFP: puppetlabs-bolt -- infrastructure orchestration tool

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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  libtrapperkeep

Bug#1077976: puppetdb's autopkg tests fail with OpenJDK 21

[Jérôme Charaoui]

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#1061790: (no subject)

[Jérôme Pouiller]

I have same issue here.
-- 
Jérôme Pouiller

Bug#1058833: qlcplus: use udev.pc to place udev rules

[Jérôme]

Hi Chris,

Le 30/05/2024 à 19:53, Chris Hofstaedtler a écrit :

Hi Jérôme,

On Tue, Mar 26, 2024 at 03:18:06PM +0100, Jérôme wrote:

Hi Chris,

Thanks for your explained report and the patch! I finally took the time to
have a look and integrate it. I am waiting for the end of the
qtbase-opensource-src transition before uploading it - with the new upstream
release by the way.


Please make sure this lands in trixie before the transition freeze.
Now would be a great time.


Thank you for your attention and this reminder! It seems to be the right 
timing since I were waiting an upstream bugfix release - the last 4.13.0 
has some blocking bugs - which should come not later than this weekend.


Cheers,

Jérôme

Bug#1070745: Bug#1070730 etc.: libglib2.0-0: ibus input regression

[Jérôme Charaoui]

On Wed, 8 May 2024 13:03:51 +0100 Simon McVittie  wrote:

On Wed, 08 May 2024 at 03:48:21 +, unfathomabl...@protonmail.com wrote:
> Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese
> characters GTK programs (such as firefox, gedit etc).

For users of testing/unstable, this will be fixed as soon as I can,
probably by version 2.80.1-1. Each GLib build takes around an hour,
plus the time required for testing, so it is not possible to fix this
instantaneously.

For users of Debian 12 'bookworm', a test-build of a fix for this
regression is available here: https://people.debian.org/~smcv/bug1070730/
(amd64 + i386 + source)


I can confirm these builds fix the input issues reported here on my system.

Thank you for moving so fast on this,

-- Jérôme

Bug#963872: RFP: automx2 - Email client configuration made easy (replaces "automx")

[Jérôme]

Hi Jakob,

Le 21/04/2024 à 18:01, Jakob Haufe a écrit :

(cc'ing Jérôme as he expressed interest)
(cc'ing Juri as he started packaging at [1])

I recently learned about automx2 and would love to see it packaged in
Debian as well.

Does either of you still plan to maintain it? Is there anything I can
help with?


I finally don't used it as planned. I let you care about the Debian 
packaging so!


Cheers,

Jérôme



Cheers,
sur5r

[1] https://salsa.debian.org/python-team/packages/automx2

Bug#1021605: persepolis: Systemd dependencies

[BARDOT Jérôme]

So i will open a upstream request and see how that can be manage, thx 
for feedbacks.


Le 24/04/2024 à 16:59, Boyuan Yang a écrit :

X-Debbugs-CC: bardot.jer...@gmail.com

Hi,

On Tue, 11 Oct 2022 19:26:21 +0200 Bardot Jerome  
wrote:

Package: persepolis
Version: 3.0.1-1.1
Severity: important
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

It's look like the package need systemd … (throught recommends)
Can you please fix it ?

A default installation should not rely on a specific software that can break
all others software.

First of all, having a default status of needing systemd is not a big issue. It 
is not
hard dependency, so you always have the choice to uninstall any package 
recommendation
that needs systemd.

Secondly, I did not see that installing persepolis will introduce systemd 
itself. It
seems that only libsystemd library will be introduced due to dynamic library
dependency. Having libsystemd library installed is harmless because the library 
will
not do anything useful if systemd is not running. Please correct me if my 
observation
is wrong.

Finally, I have no idea on how to properly avoid systemd as you requested since 
all
packages listed in the Recommends field are legit, and removing or demoting any 
of them
are not reasonable. Do you have a good patch that can be used? I would be happy 
to take
patches if it could properly avoid introducing systemd by default without 
losing any of
persepolis' upstream-provided functionality.

Thanks,
Boyuan Yang

Bug#1063417: bookworm-pu: package libapache2-mod-qos/11.74-1+deb12u1

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

Le 2024-03-29 à 16 h 09, Jonathan Wiltshire a écrit :

Control: tag -1 moreinfo

Hi,

On Tue, Mar 12, 2024 at 10:24:16AM -0400, Jérôme Charaoui wrote:

Low, the patch is small (3 lines) and is
strictly designed to gracefully handle the
identified race condition.


The uploaded package also drops the .gitlab-ci.yml, is that intentional?


No, it isn't intentional, but it seems to me either that, or modifying 
debian/clean which specifically lists "debian/.gitlab-ci.yml". This was 
fixed in a later version of the source package.


-- Jérôme

Bug#1058833: qlcplus: use udev.pc to place udev rules

[Jérôme]

Hi Chris,

Thanks for your explained report and the patch! I finally took the time 
to have a look and integrate it. I am waiting for the end of the 
qtbase-opensource-src transition before uploading it - with the new 
upstream release by the way.


Best regards,

Jérôme

Bug#1066894: ITP: dh-puppet -- debhelper add-on to handle Puppet modules

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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)

[Jérôme Charaoui]

Package: src:ruby-concurrent
Version: 1.1.6+dfsg-5

Hello,

I'm currently working on upgrading the Puppet packages in Debian and one 
of the requirements is a newer version of ruby-concurrent, at least 1.2.2.


The reason is that memory leaks were identified in earlier versions.

Unless there's a reason to proceed in a more coordinated manner (if so, 
let me know), I'll upload an updated package myself some time soon.


Thanks,

-- Jérôme

Bug#1063268: tuxguitar: Tuxguitar was forked. New 1.6.x versions available.

[Jérôme Lafréchoux]

Package: tuxguitar
Version: 1.6.1-linux-swt
Severity: wishlist

Dear Maintainer,

I just found out that Tuxguitar was forked and new releases have already
been issued.

Here's the fork: https://github.com/helge17/tuxguitar/

I'm running the fork's 1.6.1 version (.deb provided in the repo
"Releases" section) and it works a treat.

Please consider using this as the new Tuxguitar source.

Thanks.

Jérôme


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tuxguitar depends on:
ii  default-jre   2:1.17-74
ii  libasound21.2.8-1+b1
ii  libfluidsynth32.3.1-2
ii  libjack-jackd2-0  1.9.21~dfsg-3
ii  liblilv-0-0   0.24.14-1
ii  libwebkit2gtk-4.0-37  2.42.4-1~deb12u1

Versions of packages tuxguitar recommends:
ii  fonts-wqy-zenhei  0.9.45-8
ii  guitarix-lv2  0.44.1+dfsg1-2librazik1

tuxguitar suggests no packages.

-- no debconf information

Bug#1059581: examples missing from documentation

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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)

[Jérôme Charaoui]

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)

[Jérôme Charaoui]

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

[Jérôme Charaoui]

Le 2023-11-25 à 06 h 30, Miguel Landaeta a écrit :

On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui  wrote:


[...]

I've been working on a 9.4 release, you can see the progress here:
https://salsa.debian.org/lavamind/jruby

I plan to upload this version to experimental within a few days, I still
have some minor issues with the testsuite to iron out before.


Excellent, that's good to hear.
There is no point then just backporting the fix if you are close to
finishing preparing an upload.

Let me know if there is something else I can help with.
I think I'll take a look at some jnr-* dependencies packages that
could use a new upstream release and/or bugfixes.


For the record, the upload is ready to go. I'm now only waiting for a 
new build-dependency to pass through NEW, jruby-mavengem.

Bug#1040144: Bisect ongoing

[Jérôme]

Issue still present in kernel 6.6 from experimental.

Is there anything I can do to help with this?

-- 
Jérôme

Bug#1056552: sop-java: 4.1.2 is available upstream

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

Package: maven-debian-helper
Version: 2.6.4
Severity: wishlist

Hello,

Lately, I've been working on updating the jruby-maven-plugins package. 
As part of this work I wanted to rename the binary package from 
"jruby-maven-plugins" which is not java-policy compliant, to 
"libjruby-maven-plugins-java".


However, this causes maven-debian-helper to install the jars into 
/usr/share/java because the package name isn't recognized as a maven 
plugin by the regex.


This might be easily fixed by passing -Dinstall.to.usj=false but 
unfortunately this can't be done because the maven command called by the 
maven debhelper module passes "-Dinstall.to.usj=true" to Maven directly.


I believe we can just drop this property from the debhelper Maven 
command-line: by default, the property is true anyway. This would allow 
packages to override the automatic decision to install to usj.


Alternatives are: package name status quo, using 
"libjruby-maven-plugin-java" (singular), or breaking out the various 
plugins into different packages (even though they all depend on each 
other), but it's all sub-optimal.


Thanks!

-- Jérôme

Bug#1053849: base-files: Allow .d for issue and issue.net

[BARDOT Jérôme]

Hi Santiago,

thx for feedback.


You re right about motd it will be do the work.

I guess somebody mess at the setup.

I fix it.


I m aware of the unattended-upgraded and related.


Thx for everything.

The issue can be close.


J.

Le 12/10/2023 à 19:30, Santiago Vila a écrit :

El 12/10/23 a las 14:41, Bardot Jerome escribió:

Is there is a way to use the conf.d mecanism for files in base-files.

In my case it's for issue and issue.net.

For explanation i will imagine the directory issue.d .

Maybe it's need an option to concatenate or erase default file.
And maybe the same way to load 10- 20- etc.


The files "issue" and "issue.net" have a single line of text.
I'd like to keep base-files simple. Creating a .d mechanism for
files with one line of text seems a little bit overkill to me.


Why asking ?

- to separate my own legal issue and the default one


Well. Good news: The file containing the legal issue is /etc/motd
and it's not contained in base-files.deb. This means that it's not
a conffile in the dpkg sense. There will be no questions about it
if you change it, because base-files creates it only once in
the very first install (from debootstrap) and then does not
touch it at all ever again.


- no more dpkg question on update/upgrade.


Well, you can avoid all questions by using the
"unattended-upgrades" package. This usually
works triggered by cron, but you can also
disable the cron part and run it whenever
you want to do the upgrade. It upgrades
everything but without any questions.

What would make /etc/issue so special that
we have to change the way we handle it when
people have a generic way to avoid all sort
of questions? (not just the ones in base-files).

Do you consider unattended-upgrades not enough
for your particular needs?

Thanks.

Bug#1054281: ITP: ruby-maven-tools

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 

   Package name : ruby-maven-tools
   Version  : 1.2.1
   Upstream author  : Christian Meier 
   URL  : https://github.com/jruby/maven-tools
   License  : Expat
   Programming Lang : Ruby
   Description  : helpers for maven related tasks

adds versions conversion from rubygems to maven and vice versa, ruby DSL 
for POM (Project Object Model from maven), pom generators, etc


This is part of an effort to improve the JRuby build chain in Debian.


Thanks,

-- Jerome

Bug#1053533: mbedtls: enable MBEDTLS_NIST_KW_C

[Jérôme Pouiller]

Source: mbedtls
Severity: wishlist
X-Debbugs-Cc: phco...@silabs.com, jerome.pouil...@gmail.com

Hello,

I have just noticed MBEDTLS_NIST_KW_C was not enabled (and obviously my
project[1] depends on it).

I usually use the default config provided by mbedtls (which I believe
enable all the possible options). Do you know if there is any reason to
strip down this configuration?


[1] https://github.com/SiliconLabs/wisun-br-linux

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1052519: New upstream version 7.2

[Jérôme]

Package: sweethome3d
Severity: wishlist

Dear maintainer(s),

Thanks for for maintaining sweethome3d in Debian! A new upstream version 
has just been released yesterday with nice features. It may be fast for 
this request - sorry about that - but could you consider to upload it?


Best regards,

Jérôme

Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

[Jérôme St-Louis]

The fixes for FTBFS have been in upstream for a long time, but I have 
not found time to do a proper release or update the Debian package for a 
while.


Those FTBFS were a result of GCC changes that we fixed in upstream.

The 'latest' branch on our Git repo ( 
https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes.


Could someone please help with the maintenance instead of removing it?

Thanks a lot.

Kind regards,

-Jerome


On 9/10/23 05:21, Sebastian Ramacher wrote:

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ecere-sdk

ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or
bookworm. Please remove this unmaintained package from the archive.

Cheers

Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

[Jérôme St-Louis]

Actually the 'master' branch ( 
https://github.com/ecere/ecere-sdk/commits/master ) also includes the 
FTBFS fixes and would be a more conservative update / fix with only 181 
commits instead of 1905.


Specifically some of the related fixing commits were:

https://github.com/ecere/ecere-sdk/commit/53ec01de1c42cf342a35dc125a4fef01ffb5fced
https://github.com/ecere/ecere-sdk/commit/e52df5589f3c674e8d3c23c8d7194496dc96d60c
https://github.com/ecere/ecere-sdk/commit/9085cb19656728b5ccdbbbe26377ad5112513d01

Thanks again.

Kind regards,

-Jerome

On 9/10/23 16:24, Jérôme St-Louis wrote:
The fixes for FTBFS have been in upstream for a long time, but I have 
not found time to do a proper release or update the Debian package for 
a while.


Those FTBFS were a result of GCC changes that we fixed in upstream.

The 'latest' branch on our Git repo ( 
https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes.


Could someone please help with the maintenance instead of removing it?

Thanks a lot.

Kind regards,

-Jerome


On 9/10/23 05:21, Sebastian Ramacher wrote:

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ecere-sdk

ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or
bookworm. Please remove this unmaintained package from the archive.

Cheers

Bug#1051172: Update to 0.5.1

[Jérôme Charaoui]

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

[Jérôme Charaoui]

According to https://github.com/pgpainless/pgpainless/tags version 1.6.1
was released 3 weeks ago.  It would be great to get this version into
debian.


This isn't possible at the moment because Debian still ships 
bouncycastle 1.72 which is too old for pgpainless 1.4 or later.


Once bouncycastle gets updated, hopefully to 1.76, I'll look into it.

-- Jérôme

Bug#1043253: tuxguitar: Missing java class ZipArchiveInputStream when opening .gp files

[Jérôme Lafréchoux]

Package: tuxguitar
Version: 1.5.6+dfsg1-6
Severity: normal

Dear Maintainer,

I get a missing java class error when opening .gp files.

I can open .gpx and .gp5 files but all .gp files fail with the following
error:

org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33)
... 4 more
Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28)
at 
org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28)
at 
org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49)
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40)
... 7 more
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39)
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23)
... 10 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream
... 12 more
Exception in thread "Thread-51" org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:35)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGOpenFileAction$1$1.run(TGOpenFileAction.java:40)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.herac.tuxguitar.action.TGActionException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:48)
at 
org.herac.tuxguitar.editor.action.TGActionBase.execute(TGActionBase.java:24)
at 
org.herac.tuxguitar.action.TGActionManager.execute(TGActionManager.java:67)
at 
org.herac.tuxguitar.app.action.impl.file.TGReadURLAction.processAction(TGReadURLAction.java:33)
... 4 more
Caused by: org.herac.tuxguitar.io.base.TGFileFormatException: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:28)
at 
org.herac.tuxguitar.io.base.TGSongReaderHelper.read(TGSongReaderHelper.java:28)
at 
org.herac.tuxguitar.io.base.TGFileFormatManager.read(TGFileFormatManager.java:49)
at 
org.herac.tuxguitar.editor.action.file.TGReadSongAction.processAction(TGReadSongAction.java:40)
... 7 more
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/compress/archivers/zip/ZipArchiveInputStream
at 
org.herac.tuxguitar.io.gpx.v7.GPXFileSystem.getFileContentsAsStream(GPXFileSystem.java:39)
at 
org.herac.tuxguitar.io.gpx.v7.GPXInputStream.read(GPXInputStream.java:23)
... 10 more
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream
... 12 more

From TuxGuitar, I can save as .gp3, .gp4 and .gp5 and then reopen, but I
can't open .gp files.

Here's a file that can be used to reproduce the error:
https://blog.guitar-pro.com/wp-content/uploads/2021/07/ACDC-The_Jack-2.gp

Thanks.

Jérôme



-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UN

Bug#644005: pcsxr: FFVIII can't detect memory card

[Jérôme]

FWIW, I had the same problem with Suikoden and changing the BIOS to 
SCPH7003.bin as instructed in aforementioned link did the trick.


I know, not the same game and 7 years later, but I figured it was worth 
mentioning, and worth copying the BIOS name in this thread rather than 
relying on an external forum.


(Note that apparently, after changing the BIOS, one can't reload 
emulator state, so better do it right away before going too far in a 
game.)


--
Jérôme

Bug#1009964: php-fpm.service should be hardened

[Jérôme Charaoui]

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

[Jérôme Charaoui]

Hello,

I also have this problem: after upgrading to bookworm, "lxc-copy 
--ephemeral" doesn't work anymore.


# lxc-copy -n autopkgtest-sid -e -l TRACE
Created autopkgtest-sid_4aGd6F as clone of autopkgtest-sid
lxc-copy: autopkgtest-sid: ../src/lxc/lxccontainer.c: 
wait_on_daemonized_start: 878 Received container state "ABORTING" 
instead of "RUNNING"
lxc-copy: autopkgtest-sid: ../src/lxc/af_unix.c: 
lxc_abstract_unix_recv_fds_iov: 218 Connection reset by peer - Failed to 
receive response
lxc-copy: autopkgtest-sid: ../src/lxc/commands.c: lxc_cmd_rsp_recv_fds: 
128 Failed to receive file descriptors for command "get_state"



Thanks.

-- Jérôme

Bug#1040144: Bisect ongoing

[Jérôme]

Narrowing down the issue... It seems the first 6.x version work fine.

KO
--

6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2~bpo11+1
(2023-04-23) x86_64 GNU/Linux


OK
--

6.0.0-trunk-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0-1~exp1
(2022-10-09) x86_64 GNU/Linux

-- 
Jérôme

Bug#1040144: Works with 5.10.0-22-amd64

[Jérôme]

On Tue, 4 Jul 2023 23:59:55 +0200 =?UTF-8?B?SsOpcsO0bWU=?=
 wrote:

> I just installed the kernel from Bullseye (oldstable), keeping
> firmwares from Bookwormn, and I confirm that there is no issue.

I should have specified the kernel version

5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux

-- 
Jérôme

Bug#1040144: Works with bouzin 5.10.0-22-amd64

[Jérôme]

I just installed the kernel from Bullseye (oldstable), keeping
firmwares from Bookwormn, and I confirm that there is no issue.

It may be obvious but I figured I'd mention it.

-- 
Jérôme

Bug#1009964: php-fpm.service should be hardened

[Jérôme Charaoui]

Hello,

I'm using this patch on two different servers, and have not encountered 
any issues.


I'm running with chroot'ed pools, and relatively complex/common 
applications like Drupal, Wordpress and Nextcloud.


Thanks,

-- Jérôme

Bug#1040144: same issue with latest kernel from experimental

[Jérôme]

Same issue with latest kernel from experimental.

6.4.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.1-1~exp1 (2023-07-01)
x86_64 GNU/Linux

-- 
Jérôme

Bug#1040144: linux-image-6.3.0-1-amd64: radeon driver fails to load: modprobe: ERROR: could not insert 'radeon': No such device

[Jérôme Lafréchoux]

Package: src:linux
Version: 6.3.7-1
Severity: normal

Dear Maintainer,

Since I upgraded to Debian Bookworm (Linux 6), radeon drivers won't
load.

I tried both Bookworm and Sid kernels. Reporting against Sid.



Graphic card


VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland 
PRO [Radeon R7 240/340 / Radeon 520] [1002:6613]

Graphics:
  Device-1: AMD Oland PRO [Radeon R7 240/340 / Radeon 520] driver: N/A
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: vesa
unloaded: fbdev,modesetting,radeon dri: swrast gpu: N/A
resolution: 1920x1080
  API: OpenGL v: 4.5 Mesa 22.3.6 renderer: llvmpipe (LLVM 15.0.6 128 bits)



Symptoms


modprobe: ERROR: could not insert 'radeon': No such device

Xorg log

[32.663] (EE) open /dev/dri/card0: No such file or directory
[32.663] (WW) Falling back to old probe method for modesetting
[32.663] (EE) open /dev/dri/card0: No such file or directory
[32.663] (II) Loading sub module "fbdevhw"
[32.663] (II) LoadModule: "fbdevhw"
[32.663] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[32.691] (II) Module fbdevhw: vendor="X.Org Foundation"
[32.691]compiled for 1.21.1.7, module version = 0.0.2
[32.691]ABI class: X.Org Video Driver, version 25.2
[32.691] (EE) Unable to find a valid framebuffer device
[32.691] (WW) Falling back to old probe method for fbdev
[32.691] (II) Loading sub module "fbdevhw"
[32.691] (II) LoadModule: "fbdevhw"
[32.691] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[32.691] (II) Module fbdevhw: vendor="X.Org Foundation"
[32.691]compiled for 1.21.1.7, module version = 0.0.2
[32.691]ABI class: X.Org Video Driver, version 25.2
[32.691] (EE) open /dev/fb0: No such file or directory
[32.691] (EE) Screen 0 deleted because of no matching config section.
[32.691] (II) UnloadModule: "radeon"
[32.691] (EE) Screen 0 deleted because of no matching config section.
[32.691] (II) UnloadModule: "modesetting"
[32.691] (EE) Screen 0 deleted because of no matching config section.
[32.691] (II) UnloadModule: "fbdev"
[32.691] (II) UnloadSubModule: "fbdevhw"
[32.691] (II) Loading sub module "vbe"
[32.691] (II) LoadModule: "vbe"
[32.691] (II) Loading /usr/lib/xorg/modules/libint10.so
[32.887] (II) Module int10: vendor="X.Org Foundation"
[32.887]compiled for 1.21.1.7, module version = 1.0.0
[32.887]ABI class: X.Org Video Driver, version 25.2
[32.887] (II) Loading sub module "int10"
[32.887] (II) LoadModule: "int10"
[32.887] (II) Loading /usr/lib/xorg/modules/libint10.so
[32.887] (II) Module int10: vendor="X.Org Foundation"
[32.887]compiled for 1.21.1.7, module version = 1.0.0
[32.887]ABI class: X.Org Video Driver, version 25.2
[32.887] (II) VESA(0): initializing int10
[32.891] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[32.891] (II) VESA(0): VESA BIOS detected
[32.891] (II) VESA(0): VESA VBE Version 3.0




-- Package-specific info:
** Version:
Linux version 6.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.3.0-1-amd64 
root=UUID=d719f337-d835-4688-baf2-3e29f147fe04 ro

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc
product_name: XPS 630i
product_version: Unknow
chassis_vendor: Dell Inc
chassis_version: Unknow
bios_vendor: Dell Inc.
bios_version: 1.0.12
board_vendor: Dell Inc
board_name: 0C113J
board_version: A00

** Loaded modules:
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq_midi
snd_seq_midi_event
snd_seq
qrtr
cmac
algif_hash
ecb
algif_skcipher
af_alg
bnep
cpufreq_powersave
cpufreq_userspace
cpufreq_conservative
cpufreq_ondemand
sunrpc
binfmt_misc
snd_usb_audio
btusb
snd_hda_codec_realtek
btrtl
btbcm
btintel
snd_hda_codec_generic
btmtk
ledtrig_audio
bluetooth
snd_usbmidi_lib
snd_hda_codec_hdmi
snd_hda_intel
snd_intel_dspcfg
snd_rawmidi
jitterentropy_rng
snd_intel_sdw_acpi
snd_seq_device
ctr
snd_hda_codec
drbg
mc
snd_hda_core
ansi_cprng
joydev
snd_hwdep
ecdh_generic
snd_pcm_oss
rfkill
snd_mixer_oss
ecc
snd_pcm
coretemp
snd_timer
snd
sha512_ssse3
dcdbas
soundcore
evdev
serio_raw
sha512_generic
pcspkr
sg
nv_tco
drivetemp
parport_pc
ppdev
lp
parport
dm_mod
fuse
loop
efi_pstore
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
uas
usb_storage
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid0
multipath
linear
hid_generic
usbhid
hid
raid1
md_mod
i2c_algo_bit
sd_mod
drm_display_helper

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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#1003862: Some news about a fix ?

[Jérôme Bardot]

thx …

Le ven. 5 mai 2023 à 16:16, Holger Levsen  a écrit :
>
> control: tags -1 + wontfix
> thanks
>
> On Fri, May 05, 2023 at 03:49:44PM +0200, Jérôme Bardot wrote:
> > That bug is currently blocking from using munin on not systemd systems.
>
> I'm not planning on supporting legacy initscripts myself. And despite tagging
> this bug 'wontfix' for the time being I will accept patches, so IOW I'm just
> tagging this 'wontfix' to set expectations right.
>
> In the long term I think munin's initscripts should be moved to
> src:orphan-sysvinit-scripts and be maintained there by those who care.
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
>  ⠈⠳⣄
>
> "A developed country is not a place where the poor have cars. It's where the
> rich use public transportation." (quote attributed to several people)

Bug#1003862: Some news about a fix ?

[Jérôme Bardot]

That bug is currently blocking from using munin on not systemd systems.

Bug#1032734: OOM when unlocking encrypted root in initramfs

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

Control: tag -1 moreinfo

Hello,

Unfortunately I'm unable to reproduce this issue. Is this a new 
puppetserver installation, or an upgrade from puppet-master 5.5?


In either case, please provide the full puppet and puppetserver 
configurations, as well as debug logs/output from the puppet agent and 
puppetserver daemon.


Thanks,

-- Jérôme

Bug#1003862:

[Jérôme Bardot]

Hello, some news about that bug ?
I currently get the same error. (also without systemd)

 Currently the post update conf fails on the post install script.

Bug#1031510: Please open a new debian-puppet list

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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

[Jérôme Charaoui]

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