Bug#1080122: marked as pending in powerline
Control: tag -1 pending Hello, Bug #1080122 in powerline reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/powerline/-/commit/81cf7f5d763ad465df55f186f95f1bb3c0713b79 d/rules: disable dh_auto_test again This never worked: the test suite never really ran, it just didn't error out: Ran 0 tests in 0.000s NO TESTS RAN Now with python3.12 it really fails and causes ftbfs. Unfortunately it's not an easy fix, the powerline test suite is highly complicated, relies on unpackaged dependencies and scripts. Even back when it didn't have external dependencies I could never get it to actually pass. Closes: #1080122 (this message was generated automatically) -- Greetings https://bugs.debian.org/1080122
Bug#1080122: Fallout from setuptools dropping the test command
On Sat, 31 Aug 2024 16:32:40 + Stefano Rivera wrote: FWIW: I think these bugs were all caused by setuptools v72 dropping support for the "test" command, so dh-python has fallen back to distutils / other test plugins. If you're trying to figure out how to fix the bug, look at the implementation of test_suite in setup.py to see what magic it does for test setup. In this particular case, dh_auto_test should simply not have been re-enabled in d/rules [0]. It never actually successfully ran the highly complex and custom shell-based test suite of this package, as an examination of the build logs demonstrate [1], but now it also errors-out. Unless someone else wanting to work this chimes in, I'll make an upload shortly that disables the tests again. -- Jérôme [0] https://salsa.debian.org/python-team/packages/powerline/-/commit/6f7ac0633507bbd6beae48cf5d79aadbe9b25043 [1] https://salsa.debian.org/python-team/packages/powerline/-/jobs/5959792#L2282
Bug#1078576: lektor: please update lektor so that python3-mistune0 can be removed
Control: tags -1 confirmed
Control: tags -1 upstream
Control: forwarded -1 https://github.com/lektor/lektor/issues/1156
Hello,
> Please switch to regular, alive, python3-mistune.
I looked into upgrading to the Lektor v3.4.x series today, which adds
support for mistune 2.
Unfortunately, python3-mistune already ships mistune 3, and Lektor
doesn't support it. It supports only mistune 0 or 2.
See https://github.com/lektor/lektor/issues/1156
In addition, Lektor doesn't build at all with mistune 3 because of
serious API changes between 2 and 3, for example:
ImportError while loading conftest
'/<>/.pybuild/cpython3_3.12_lektor/build/tests/conftest.py'.
tests/conftest.py:12: in
import lektor.project
lektor/project.py:12: in
from lektor.environment import Environment
lektor/environment/__init__.py:26: in
from lektor.markdown import Markdown
lektor/markdown/__init__.py:33: in
from lektor.markdown.mistune2 import MarkdownController2 as
controller_class
lektor/markdown/mistune2.py:74: in
class MarkdownController2(MarkdownController):
lektor/markdown/mistune2.py:93: in MarkdownController2
PLUGINS = {**mistune.PLUGINS}
E AttributeError: module 'mistune' has no attribute 'PLUGINS'
Until Lektor ships a markdown controller that supports mistune 3, or
Debian ships a mistune 2 package, I'm afraid it won't be possible to
keep Lektor in testing.
-- Jérôme
Bug#1080489: Reports causing unbounded filesystem usage growth
Package: puppet-agent Severity: serious Version: 8.4.0-1 Control: affects -1 puppetserver In bug #1078911 [0], a user reported that a cron job responbile for cleaning up old reports previously shipped in puppet-master was no longer shipped in puppetserver. The consequence was an accumulation of files under /var/lib/cache/reports until the filesystem filled up and the system broke. Further research has shown that the issue doesn't only affect environments where Puppet agents are attached to a Puppet Server, but also the "puppet apply" command which generates and stores reports locally upon every invocation, with no automatic cleanup out of the box. An upload of the puppetserver package adding a cleanup cron job led to a discussion thread [1] on the puppet-team mailing list. While the participants were unable to agree on the default retention this cron job should follow, there was agreement that ultimately, storing reports on the filesystem was a bad default and should simply be disabled in new installations. To do so requires a change in the libraries shipped by the puppet-agent package, where defaults used by both agent and server are defined. After consultation with the larger Puppet community on IRC, a pull request appeared to also disable reports by default in upstream Puppet [2]. Comments from a Puppet developper suggests this change will only be shipped in a future Puppet 9 release, however. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078911 [1] https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2024-August/013829.html [2] https://github.com/puppetlabs/puppet/pull/9461
Bug#1077976: marked as pending in puppetdb
Control: tag -1 pending Hello, Bug #1077976 in puppetdb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/puppet-team/puppetdb/-/commit/d7dda9f8a15139072576e753c5cf6bb55605954f d/tests: add allow-stderr to restrictions When the JVM version is unexpected, PuppetDB emits a warning on stderr causing the test to fail. Closes: #1077976 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077976
Bug#1078360: marked as pending in ruby-moneta
Control: tag -1 pending Hello, Bug #1078360 in ruby-moneta reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ruby-team/ruby-moneta/-/commit/2b1bc05ac08a178fc2c3cba5e4eacb0eda1c5d9c d/control: add missing ruby-sqlite3 build-dep Closes: #1078360 (this message was generated automatically) -- Greetings https://bugs.debian.org/1078360
Bug#1077976: puppetdb's autopkg tests fail with OpenJDK 21
Hello, Le 2024-08-05 à 07 h 48, Matthias Klose a écrit : Tests fail with: 201s autopkgtest [17:10:41]: summary 201s standalone FAIL stderr: warn: JDK 21.0.4 is neither tested nor supported. Please use JDK 17 I'm not sure about the value of such a test ... instead of testing that the software works. Obviously, the test is not only checking which JDK version is running. PuppetDB is simply emitting a warning about that on stderr, and the test is just missing "Restriction: allow-stderr". I'll fix that in the next upload. -- Jérôme
Bug#1070745: Bug#1070730 etc.: libglib2.0-0: ibus input regression
On Wed, 8 May 2024 13:03:51 +0100 Simon McVittie wrote: On Wed, 08 May 2024 at 03:48:21 +, unfathomabl...@protonmail.com wrote: > Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese > characters GTK programs (such as firefox, gedit etc). For users of testing/unstable, this will be fixed as soon as I can, probably by version 2.80.1-1. Each GLib build takes around an hour, plus the time required for testing, so it is not possible to fix this instantaneously. For users of Debian 12 'bookworm', a test-build of a fix for this regression is available here: https://people.debian.org/~smcv/bug1070730/ (amd64 + i386 + source) I can confirm these builds fix the input issues reported here on my system. Thank you for moving so fast on this, -- Jérôme
Bug#1069192: Autopkgtest failure: missing dependency on python3-pytz
Hi Nilesh, Le 2024-04-18 à 06 h 24, Nilesh Patra a écrit : I will NMU this in a week or so if I see no activity. This package has been going through in-attention for a while. Please, you may upload the fix whenever you wish, it's fine with me. -- Jérôme
Bug#1067209: marked as pending in jruby
Control: tag -1 pending Hello, Bug #1067209 in jruby reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/jruby/-/commit/1e0e33a4429ec76990cb8729df7e4b7bde33abb4 d/control: update libfixposix4 runtime depency libfixposix4 was renamed to libfixposix4t64 Closes: #1067209 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067209
Bug#1042314: closing 1042314
close 1042314 8.4.0-1 thanks I believe this bug is now fixed in the latest version of jruby and puppetserver uploaded to sid. Thanks, -- Jérôme
Bug#1064686: vagrant-librarian-puppet: FTBFS
Hello, I think this package should be removed from Debian. In addition to the FTBFS issues: - Project appears to be abandoned upstream, last commit was 6 years ago - The future of Vagrant in Debian is in serious doubt (see #104) - It's currently blocking the transition of the latest puppet-agent package in Debian I'm not a maintainer or uploader of this package, so if someone feels like they're wearing one of those hats, please file a removal request [0]. Thanks, -- Jérôme [0] https://wiki.debian.org/ftpmaster_Removals#How_to_request_removal
Bug#1025078: closing 1025078
close 1025078 5.0.3-1 thanks With now both ruby-faraday and ruby-puppet-forge up to date in sid, this issue is solved.
Bug#1064295: puppet-agent: ununsatisfiable dependencies: depends on ruby-concurrent (< 1.2.0)
Hello, On Mon, 19 Feb 2024 20:38:19 +0100 Aurelien Jarno wrote: puppet-agent in unstable is not installable anymore as it depends on ruby-concurrent (< 1.2.0), while the version in unstable is now 1.2.3-2. Yes, I'm aware. puppet-agent 8.4.0, which works with ruby-concurrent >= 1.2.0, is now available in experimental. It's working for me, but I'm waiting on some feedback before uploading it to unstable. Thanks, -- Jérôme
Bug#1033316: Autopkgtest is flaky
Control: tags -1 + confirmed Control: owner -1 ! Hello, I'm preparing an update for this package which should fix the issue. Thanks, -- Jérôme
Bug#1058702: pius fails completely on bookworm and up
On Thu, 14 Dec 2023 14:32:45 -0500 Antoine Beaupre wrote:> pius: error: GnuPG binary not found at /usr/bin/gpg2. gpg2 hasn't been around for a long time. but maybe we can work around this with: Yeah I would also like like to see this patched. pius: error: Keyring /home/anarcat/.gnupg/pubring.gpg doesn't exist Nope! That doesn't work either! I have not dared to use the --keyring argument to correct `.gnupg/pubring.kbx` keyring, for fear of corruption, but clearly something is wrong here. FWIW I've used --keyring and it didn't seem to corrupt the keyring or do anything bad, but you can also test it yourself on a copy of your keyring, the signatures thus produces will be just as valid. Another thing that would be nice to fix upstream, or in the package at least. -- Jérôme
Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)
Le 2023-12-09 à 17 h 29, tony mancill a écrit : On Sat, Dec 09, 2023 at 04:39:35PM -0500, Jérôme Charaoui wrote: On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann wrote: during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--unpack): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb Thanks for the heads up. I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed split away from "libtakari-polyglot-maven-java" and into "libtakari-polyglot-groovy-java", however the new version of "libtakari-polyglot-maven-java" does *not* depend on/recommend "libtakari-polyglot-groovy-java". So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the first place, during the piuparts upgrade. It's not present in testing, and it has currently zero reverse-dependencies. I did my own testing and on a bare system with "libtakari-polyglot-maven-java" installed, upgrading to sid does not include an installation of "libtakari-polyglot-groovy-java". Any idea what's going on? Hi Jérôme, I believe you're correct that in the normal upgrade case, this is unlikely to occur. Here's the test case I ran instead a clean trixie chroot: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. Update sources.list to unstable and then apt-get update 3. apt-get -y install libtakari-polyglot-groovy-java Step (3) will upgrade libtakari-polyglot-maven-java to 0.4.11-2 *before* installing libtakari-polyglot-groovy-java, so there's no problem. However, the issue can occur when using dpkg directly, or some other factor influences the ordering such that libtakari-polyglot-groovy-java is installed *before* libtakari-polyglot-maven-java is upgraded. For example: 1. Install libtakari-polyglot-maven-java (0.4.11-1) 2. wget http://ftp.us.debian.org/debian/pool/main/t/takari-polyglot-maven/libtakari-polyglot-groovy-java_0.4.11-2_all.deb 3. dpkg -i libtakari-polyglot-groovy-java_0.4.11-2_all.deb Preparing to unpack libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--install): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: libtakari-polyglot-groovy-java_0.4.11-2_all.deb This is the reason that the relationship needs to be explicit. I'm not 100% certain, but perhaps we can get away with only adding a versioned depends on libtakari-polyglot-maven-java (>= 0.4.11-2) to the libtakari-polyglot-groovy-java package. The problem as I see it is that the current unversioned Depends can be satisfied by any version of libtakari-polyglot-maven-java, including older versions with the file conflict. Requiring the newer libtakari-polyglot-maven-java would prevent this. Ok what I think I'll do is to add: "Breaks: libtakari-polyglot-maven-java (<< 0.4.11-2)" to libtakari-polyglot-groovy-java. I think that's more explicit than a versioned depends, and should prevent any instances of users accidentally having wrong versions of the two packages. -- Jérôme
Bug#1055049: libtakari-polyglot-groovy-java: missing Breaks+Replaces: libtakari-polyglot-maven-java (<< 0.4.11-2)
On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann wrote: during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ... Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ... dpkg: error processing archive /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb (--unpack): trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is also in package libtakari-polyglot-maven-java 0.4.11-1 Errors were encountered while processing: /var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb Thanks for the heads up. I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed split away from "libtakari-polyglot-maven-java" and into "libtakari-polyglot-groovy-java", however the new version of "libtakari-polyglot-maven-java" does *not* depend on/recommend "libtakari-polyglot-groovy-java". So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the first place, during the piuparts upgrade. It's not present in testing, and it has currently zero reverse-dependencies. I did my own testing and on a bare system with "libtakari-polyglot-maven-java" installed, upgrading to sid does not include an installation of "libtakari-polyglot-groovy-java". Any idea what's going on? Thanks, -- Jérôme
Bug#1052722: closing 1052722
close 1052722 2.6.0-1 thanks
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
Le 2023-11-25 à 06 h 30, Miguel Landaeta a écrit : On Sat, Nov 25, 2023 at 12:29 AM Jérôme Charaoui wrote: [...] I've been working on a 9.4 release, you can see the progress here: https://salsa.debian.org/lavamind/jruby I plan to upload this version to experimental within a few days, I still have some minor issues with the testsuite to iron out before. Excellent, that's good to hear. There is no point then just backporting the fix if you are close to finishing preparing an upload. Let me know if there is something else I can help with. I think I'll take a look at some jnr-* dependencies packages that could use a new upstream release and/or bugfixes. For the record, the upload is ready to go. I'm now only waiting for a new build-dependency to pass through NEW, jruby-mavengem.
Bug#1042129: jruby: FTBFS: [ERROR] /<>/core/src/main/java/org/jruby/ext/strscan/RubyStringScanner.java:[653,34] error: cannot find symbol
Hi Miguel, Le 2023-11-24 à 18 h 38, Miguel Landaeta a écrit : Thomas and Jérôme, Do you have any concerns with me uploading a fix for this issue? I'm working with some folks here in Cambridge MiniDebConf and I also have some cycles to spare to work on JRuby and maybe prepare a new upstream release for 9.3 and/or 9.4 series (experimental). I've been working on a 9.4 release, you can see the progress here: https://salsa.debian.org/lavamind/jruby I plan to upload this version to experimental within a few days, I still have some minor issues with the testsuite to iron out before. Thanks, -- Jérôme
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
On Wed, 7 Jun 2023 18:47:02 +0530 Utkarsh Gupta wrote:> I've prepared a fix for the regression and uploaded the binaries at: https://people.debian.org/~utkarsh/lts/ruby2.5/ Can you please give these a try and see if that fixes the regression you're seeing? These packages also fix the Puppet regression reported here, on our buster systems. Thanks, -- Jérôme
Bug#1034824: tomcat9 should not be released with Bookworm
Le 2023-05-25 à 17 h 41, Martin Hostettler a écrit : Quoting from J�r�me Charaoui in (#1036250): I did further tests with puppetserver, which is a downstream dependency of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web requests (access) logging remains broken. There are no warnings or error messages anywhere: as you can imagine, the logging events are simply lost in the ether. I'm not sure if the latest patches from 2023-05-22 do fix those, but there was no follow up on the bug with details. For the record, these patches only fix the build issue and work around the test failures by disabling the affected tests. The logging problem is still present in puppetserver (and almost certainly puppetdb) with the patched trapperkeeper-webserver-jetty9-clojure package. Thanks, -- Jérôme
Bug#1034855: trapperkeeper-webserver-jetty9-clojure: autopkgtest regression: Cannot invoke "Object.toString()" because "s" is null
This problem is caused by a recent patch shipped by the liblogback-java package, specifically this line, which causes log events to be silently ignored: https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91 See the discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036250 In my view this is a bug in src:logback. -- Jérôme
Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest
Hi Markus, Thank you, your patch does indeed fix the build problem for this package, however, the test failure is not insignificant. I did further tests with puppetserver, which is a downstream dependency of trapperkeeper-webserver-jetty9-clojure and unfortunately, the web requests (access) logging remains broken. There are no warnings or error messages anywhere: as you can imagine, the logging events are simply lost in the ether. I think these logs are a critical feature for debugging and security and it would be very unfortunate for bookworm to ship with logging crippled in this way for puppetserver. Although I did not test this specifically, I strongly suspect puppetdb is also affected in a similar way because they share many of the same components. Do you think it might be possible to backport the accessEvent variable fix from a later version of Logback? -- Jérôme Le 2023-05-19 à 09 h 53, Markus Koschany a écrit : Control: tags -1 patch Hi, I am attaching a patch for this issue. Somehow your package fell through the cracks because it has no dependency on logback. Logback is pulled in by Jetty though. While Logback and Jetty use the Jakarta servlet API now, your package still depends on libservlet-api-java. The fix for that was trivial. However the test failure is caused by my tomcat10-migration.patch https://salsa.debian.org/java-team/logback/-/blob/master/debian/patches/tomcat10-migration.patch#L91 Back then I thought it was acceptable to work around a build failure by setting the accessEvent variable to null since it seemed no package existed in Debian which would be affected by it. The Logback developers fixed that problem in newer versions, but a new upstream release of logback would have been too intrusive. Long story short: please double-check my patch and if we can ignore the logging problem Regards, Markus
Bug#1036250: trapperkeeper-webserver-jetty9-clojure: FTBFS in testing: MDCAccessLogConverter.java:54: error: cannot access HttpServletRequest
Control: tags -1 confirmed help Hello, This bug, as well as bug #1034855, have a common cause. The latest upload of src:logback, version 1:1.2.11-2, added a large patchset to migrate its dependencies from tomcat9 to tomcat10. When attempting to build this package with the previous version of liblogback-java, 1:1.2.11-1, everything works. Unfortunately I'm a little out of my depth here, because I'm not sure what's the best way to address this problem. At this point it seems inappropriate to introduce a large patchset in this package to migrate over to tomcat10 libraries, if that is even possible. Therefore, I would like to request assistance to find a solution. The removal of this package would inevitably lead to the removal of puppetserver from Debian, which would be highly unfortunate. Thanks, -- Jérôme
Bug#1033005: puppetdb: "fresh" installion results in "permission denied for table schema_migrations"
Control: tag -1 + moreinfo Control: severity -1 important Hello, The puppetdb package wasn't part of the last Debian release, bullseye. Are you upgrading from puppetdb 6.2.0-3 which was in Debian buster? I need to know precisely what were the steps you took here, so I can figure out how to reproduce the problem. But nonetheless, if you install puppetdb on a clean system (really fresh), you should not hit this bug, so I'm reducing the severity to non-release critical. If I can figure out how to reproduce and fix this I'll upload a fix, but since we're very close to the release I'm not sure if it'll get through. Thanks, -- Jérôme
Bug#1032734: OOM when unlocking encrypted root in initramfs
Tagging ‘moreinfo’ then. I can definitely see how one can reproduce this theoretically (and possibly in the future when the kernel's memory requirement increase high enough), and mentioned that in the upstream bug, but I'm unable to find a reproducer after dist-upgrading bullseye systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso, and “Encrypted LVM” partition scheme, on VMs with 1024M RAM). Jérôme, what memory cost is the keyslot using? (Paste the output of `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.) Would also be interested to see by how much the amount of memory available to cryptsetup has changed before and after the uprade. Please edit /usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at the begining of the setup_mapping() function (patch attached). My own findings are as follows (again on a minimal netinst system without changing any default). cryptsetup isn't even close to memory exhaustion. Memory cost: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 4 Memory: 787907 Threads:1 - >8 - Free memory: - 8< - Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... totalusedfree shared buff/cache available Mem: 993756 74720 725012 60 194024 660412 Swap: 0 0 0 - >8 - I've also tested on another of my virtual machines that has 1GiB of RAM and got another result, closer to what you got in your experimentation: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 6 Memory: 499912 Threads:1 - >8 - So, I think what's happening is that the first VM may have been created with a different (larger) memory configuration, and was reduced at a later point in time. I don't have absolute certainty of this, but it would very well explain the discrepancy in memory cost. Also, I think I agree with your assessment that in the memory usage increase of the kernel may be involved: between the two releases, according to your numbers it appears to have increased nearly 25% (!). So it could also explain why it (probably very nearly) worked under bullseye. I there any way we could make the cryptsetup-initramfs hook aware of this, and emit a warning if it finds that the encrypted root lacks a keyslot with appropriate (low-enough) memory cost? Thanks, -- Jérôme
Bug#1032734: OOM when unlocking encrypted root in initramfs
Package: cryptsetup Version: 2:2.6.1-1 Severity: critical Dear maintainer, Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of RAM to bookworm, and was very surprised to be confronted with an OOM immediately upon entering my LUKS password in the initramfs prompt: Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... Please unlock disk vda5_crypt: [7.982435] Out of memory: Killed process 243 (cryptsetup) total-vm:799000kB, anon-rss:678296kB, file-rss:6440kB, shmem-rss:0kB, UID:0 pgtables:1384kB oom_score_adj:0 Killed cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or options? This machine was booting just fine before upgrading, under bullseye. The problem appears to be perhaps related to #924560, but in this instance, the issue causing an unbootable system post-upgrade. Thanks, -- Jérôme
Bug#1030427: marked as pending in trapperkeeper-metrics-clojure
Control: tag -1 pending Hello, Bug #1030427 in trapperkeeper-metrics-clojure reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/clojure-team/trapperkeeper-metrics-clojure/-/commit/0a6c16e047b5bc56d7ab7114156a13ad9fbceedd drop jackson and snakeyaml version overrides Avoid leaking bogus dependency versions in maven-repo. Requires updated build-deps where the issue is fixed and makes the project.clj overrides obsolete. Closes: #1030427 (this message was generated automatically) -- Greetings https://bugs.debian.org/1030427
Bug#1030428: marked as pending in trapperkeeper-scheduler-clojure
Control: tag -1 pending Hello, Bug #1030428 in trapperkeeper-scheduler-clojure reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/clojure-team/trapperkeeper-scheduler-clojure/-/commit/34adc0f06153cae2ec61008d5fe397c80809f1c8 d/patches: remove gettext from :exclusions Closes: #1030428 (this message was generated automatically) -- Greetings https://bugs.debian.org/1030428
Bug#1030256: [Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
I think this is occurring because the test is being run as "root". I don't know how common that is in build environments, but it's not something that I have or think I should have in my build (sbuild) or test (autopkgtest) environments. Is there some flag we could use to tell reproducible-builds to build this package as a regular user instead of root? If not I might have to patch the test suite to work around some of the logic in there, which I'm not too excited about. Perhaps an alternative would be to add "puppet-agent" as a build dependency, because that package will create a "puppet" user in the environment. Thanks, -- Jérôme
Bug#1028333: puppetserver: find an upgrade path from puppet-master
The old "puppet-master" and "puppet-master-passenger" were basically just configuration files for the systemd/sysvinit and Apache2/Passenger, because the main (ruby) code was always in the "puppet" package. I think the way forward here is that first, we should make the 7.x transitional dummy package "puppet" "Breaks: puppet-master, puppet-master-passenger", to make clear that the old master packages cannot function with the libraries shipping in the latest puppet-agent package. And secondly, we should carefully consider whether a "seamless" transition is even possible at all. Puppetserver is completely different software which is configured differently than the old master, and as such I doubt that one can simple replace one package with the other and expect things to "just work". Even if it does, important bits of the configuration may likely be lost in translation (eg. auth.conf). So considering all this I'm currently leaning towards adding a transitional "puppet-master" and/or "puppet-master-passenger" package for the purpose of shipping a NEWS file recommending that users migrate to the puppetserver package manually. -- Jérôme
Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
Le 2023-01-03 à 11 h 45, Bastian Germann a écrit : X-Debbugs-Cc: jer...@riseup.net On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann wrote: This will be rectified with importing v3.3.0+. But there will be other problems with the current werkzeug version which are addressed with v3.4.0b1: https://github.com/lektor/lektor/pull/1051 I see the maintainer and Jérôme have worked on new versions but they were never released. Is there something missing? And of course I've just noticed that python3-mistune0 now exists in Debian, so maybe I can finally upload Lektor 3.3 ...
Bug#997323: lektor: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
Le 2023-01-03 à 11 h 45, Bastian Germann a écrit : X-Debbugs-Cc: jer...@riseup.net On Tue, 3 Jan 2023 17:35:24 +0100 Bastian Germann wrote: This will be rectified with importing v3.3.0+. But there will be other problems with the current werkzeug version which are addressed with v3.4.0b1: https://github.com/lektor/lektor/pull/1051 I see the maintainer and Jérôme have worked on new versions but they were never released. Is there something missing? Since python-mistune has moved to 2.x in Debian, the Lektor 3.2 and 3.3 branches are no longer functional. Upstream has integrated mistune 2.0 support in 3.4 but there have only been beta releases of it so far, and I'm not entirely sure if we should upload that and release it with bookworm? In short, I've been working on it but it has been quite a moving target so far. -- Jerome
Bug#1026329: bouncycastle breaks pgpainless autopkgtest: premature end of stream
Hello, According to the pgpainless upstream, this bug is fixed bouncycastle 1.72.1 and later versions. Unfortunately, upstream does not appear to have tagged any version beyond 1.72 in their git repository. Thanks, -- Jerome
Bug#1025442: marked as pending in jruby
Control: tag -1 pending Hello, Bug #1025442 in jruby reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/java-team/jruby/-/commit/456069f250320fc8b131d1446a73d2da8d2a87d9 d/control: add Breaks+Replaces on jruby-openssl (Closes: #1025442) A Provides is not necessary since no other packages depend on this jruby-specific library. (this message was generated automatically) -- Greetings https://bugs.debian.org/1025442
Bug#1013662: core-async-clojure: FTBFS randomly in bullseye
On Mon, 5 Dec 2022 22:04:06 +0100 Santiago Vila wrote: Hi. I attach an upload proposal for bullseye, in debdiff format against version 1.3.610-4 (stable version), so you can upload it "as is" if everything else is ok. There is a stable point release around the corner, it would be wonderful if this could be fixed by then. I'm not opposed to uploading it but I'm curious to know why this is needed now, because the next stable release is also "around the corner", in relative terms... Thanks, -- Jerome
Bug#1011967: trapperkeeper-clojure: autopkgtest regression: FileNotFoundException
Hello, This bug has been fixed by uploading core-async-clojure version 1.3.610-5 which includes this change: https://salsa.debian.org/clojure-team/core-async-clojure/-/commit/afae424e1de2e423e1842dec6d23085f31a5bc9c Thanks! -- Jerome
Bug#1013662: marked as pending in core-async-clojure
Control: tag -1 pending Hello, Bug #1013662 in core-async-clojure reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/clojure-team/core-async-clojure/-/commit/9cbf1ca97cf3ab072c70f5a5d8239b40fa3337ce Skip test assertions which hang in single-cpu env Replaces previous patch which didn't work on autobuilders, tests still failed systematically. Closes: #1013662 (this message was generated automatically) -- Greetings https://bugs.debian.org/1013662
Bug#1013662: core-async-clojure: FTBFS: make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1
Hello, I'm unable to reproduce this bug locally. When I diff, the build logs, the only relevant element I can find is that in my build environment, the "clojure_1.10.3-1" package is installed, whereas in the failing build log, it appears to be absent. I think it would be worth it to attempt to build it again. Thanks, -- Jerome
Bug#1011843: powerline-gitstatus: FTBFS: make[1]: *** [debian/rules:17: override_dh_auto_install] Error 1
Version: 1.3.1-4 The colorscheme patch was refreshed to fix the FTBFS bug. -- Jeroime
