Bug#1066662: hping3: FTBFS: script.c:1351:29: error: implicit declaration of function ‘asprintf’; did you mean ‘vsprintf’? [-Werror=implicit-function-declaration]
* Lucas Nussbaum [Wed Mar 13, 2024 at 12:51:29PM +0100]: [...] > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > gcc -c -g -O2 -Werror=implicit-function-declaration > > -ffile-prefix-map=/<>=. -fstack-protector-strong > > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > > -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -Wall -I/usr/include/pcap > > -I/usr/include/tcl8.6 -DUSE_TCL -g ars.c > > script.c: In function ‘HpingTcl_AppInit’: > > script.c:1351:29: error: implicit declaration of function ‘asprintf’; did > > you mean ‘vsprintf’? [-Werror=implicit-function-declaration] > > 1351 | if (asprintf(, "%s/.hpingrc", home) > > < 0) > > | ^~~~ > > | vsprintf [...] Pending patch / MR available at https://salsa.debian.org/debian/hping3/-/merge_requests/4 regards -mika- signature.asc Description: PGP signature
Bug#1066662: hping3: FTBFS: script.c:1351:29: error: implicit declaration of function ‘asprintf’; did you mean ‘vsprintf’? [-Werror=implicit-function-declaration]
* Lucas Nussbaum [Wed Mar 13, 2024 at 12:51:29PM +0100]: [...] > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > gcc -c -g -O2 -Werror=implicit-function-declaration > > -ffile-prefix-map=/<>=. -fstack-protector-strong > > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > > -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -Wall -I/usr/include/pcap > > -I/usr/include/tcl8.6 -DUSE_TCL -g ars.c > > script.c: In function ‘HpingTcl_AppInit’: > > script.c:1351:29: error: implicit declaration of function ‘asprintf’; did > > you mean ‘vsprintf’? [-Werror=implicit-function-declaration] > > 1351 | if (asprintf(, "%s/.hpingrc", home) > > < 0) > > | ^~~~ > > | vsprintf [...] Pending patch / MR available at https://salsa.debian.org/debian/hping3/-/merge_requests/4 regards -mika- signature.asc Description: PGP signature
Bug#1070113: kylin-nm: predictable filenames under /tmp with system()
Package: kylin-nm
Version: 3.0.3.1-1
Severity: grave
Tags: security
Justification: user security hole
Hi,
the kylin_network_get_activecon_info() function in
src/kylin-network-interface.c uses predictable filenames under /tmp
and invokes system() on it:
| activecon *kylin_network_get_activecon_info()
| {
| struct passwd *pwd;
| pwd = getpwuid(getuid());
| char *name = pwd->pw_name;
| char *tmpPrefix = "/tmp/kylin-nm-activecon-";
| char *chr = "nmcli connection show -active > ";
|
| char *cmd;
| asprintf(, "%s%s%s", chr, tmpPrefix, name);
| char *path;
| asprintf(, "%s%s", tmpPrefix, name);
| int status = system(cmd);
| if (status != 0)
| syslog(LOG_ERR, "execute 'nmcli connection show -active' in function
'kylin_network_get_activecon_info' failed");
| free(cmd);
Predictable filenames under /tmp and executing system() on it is
highly problematic and a potential security issue. It should instead
use e.g. mkstemp() and the execl-family of functions or similar.
FTR: the same code is present also in ukui-screensaver, which seems
to have a copy of the KylinNM source code included.
regards
-mika-
signature.asc
Description: PGP signature
Bug#1070113: kylin-nm: predictable filenames under /tmp with system()
Package: kylin-nm
Version: 3.0.3.1-1
Severity: grave
Tags: security
Justification: user security hole
Hi,
the kylin_network_get_activecon_info() function in
src/kylin-network-interface.c uses predictable filenames under /tmp
and invokes system() on it:
| activecon *kylin_network_get_activecon_info()
| {
| struct passwd *pwd;
| pwd = getpwuid(getuid());
| char *name = pwd->pw_name;
| char *tmpPrefix = "/tmp/kylin-nm-activecon-";
| char *chr = "nmcli connection show -active > ";
|
| char *cmd;
| asprintf(, "%s%s%s", chr, tmpPrefix, name);
| char *path;
| asprintf(, "%s%s", tmpPrefix, name);
| int status = system(cmd);
| if (status != 0)
| syslog(LOG_ERR, "execute 'nmcli connection show -active' in function
'kylin_network_get_activecon_info' failed");
| free(cmd);
Predictable filenames under /tmp and executing system() on it is
highly problematic and a potential security issue. It should instead
use e.g. mkstemp() and the execl-family of functions or similar.
FTR: the same code is present also in ukui-screensaver, which seems
to have a copy of the KylinNM source code included.
regards
-mika-
signature.asc
Description: PGP signature
Re: Pondering sunsetting the Jenkins CI and repo for dpkg
Hi! * Guillem Jover [Fri Apr 26, 2024 at 09:57:09AM +0200]: > On Thu, 2024-03-14 at 00:19:09 +0100, Alexandre Detiste wrote: > > Le sam. 9 mars 2024 à 18:29, Guillem Jover a écrit : > > > The grml.org project has been hosting Jenkins jobs for dpkg for a long > > > time now, as the very initial CI we had. The jobs also generate a repo > > > so that people can run the latest code from git main, with the > > > following apt config: > > > > > > deb https://jenkins.grml.org/debian dpkg main > > > > > > Due to security issues in Jenkins or continuous attacks (AFAIR/AFAIUI) > > > its web interface at https://jenkins.grml.org/ has been firewalled, so > > > it now becomes a bit cumbersome to diagnose issues that happen there > > > w/o having to bother someone. > > > > > > I've talked about this briefly with Mika, and I while I hugely appreciate > > > the service that has been provided over the years (thanks Mika!), I'm > > > thinking it's probably time to permanently disable it (I did this the > > > other day as a temporary measure to stop spamming the list) given the [...] > > I could have used "deb https://jenkins.grml.org/debian dpkg main" > > but it seems a lot of work to maintain compared to my little use. > > So, Mika, I guess it's time to disable and remove the jobs from Jenkins? Perfectly fine for me :) > Unless perhaps there are stats showing lots of usage for that repo (which > I'd doubt)? Although I don't think this is urgent at all. Nowadays there's only very little usage of it AFAICS, so I think it makes sense to retire the service. Thanks for reaching out, I'll take care of disabling and removing it. regards -mika- signature.asc Description: PGP signature
Re: Offer help on initramfs-tools
Hi! * Benjamin Drung [Wed Mar 06, 2024 at 11:45:38AM +0100]: > initramfs-tools hasn't seen an upload since 2022-07-12 and has several > open merge requests without response. Since I am maintaining initramfs- > tools in Ubuntu, I offer my help on initramfs-tools in Debian. In case I > became uploader, I would merge the fixes and uncontroversial changes and > cut a release. For various reasons I am personally no longer really active in initramfs-tools (i-t) development, but since nobody else responded to you yet: thanks for your work and efforts and reaching out, *I* think any contributions and work around i-t are more than welcome. > One change that we did in Ubuntu recently is using dracut-install which > speeds up the initramfs generation a lot: > https://launchpad.net/bugs/2031185 > Do you want to have that in Debian as well? Sounds great to me! :) regards -mika- signature.asc Description: PGP signature
[Grml] Grml - new stable release 2024.02 available
Hi, we said we'll release by the end of February, and here we are! The stable release of Grml version 2024.02 with codename 'Glumpad' is available. More information about this release is available in the release notes of Grml 2024.02: https://grml.org/changelogs/README-grml-2024.02/ Grab the latest Grml ISO(s) and spread the word: https://grml.org/download/ If you should notice any bugs please let us know: https://grml.org/bugs/ We welcome constructive feedback, suggestions for improvement and your contributions, please just reach out to us: https://grml.org/contact/ Thanks to everyone contributing to Grml and this release! Take care and happy Grml-ing! -mika- - for the Grml project signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
[Grml-devel] Grml - new stable release 2024.02 available
Hi, we said we'll release by the end of February, and here we are! The stable release of Grml version 2024.02 with codename 'Glumpad' is available. More information about this release is available in the release notes of Grml 2024.02: https://grml.org/changelogs/README-grml-2024.02/ Grab the latest Grml ISO(s) and spread the word: https://grml.org/download/ If you should notice any bugs please let us know: https://grml.org/bugs/ We welcome constructive feedback, suggestions for improvement and your contributions, please just reach out to us: https://grml.org/contact/ Thanks to everyone contributing to Grml and this release! Take care and happy Grml-ing! -mika- - for the Grml project signature.asc Description: PGP signature ___ Grml-devel mailing list Grml-devel@ml.grml.org http://ml.grml.org/mailman/listinfo/grml-devel
Bug#1064463: reptyr: New upstream version 0.10.0 available
Package: reptyr Version: 0.9.0-1+b1 Severity: wishlist Hi, since 2023-06-04 version 0.10.0 is available, see https://github.com/nelhage/reptyr/tags According to the changelog, it's only about "Add arm7 and aarch64 support for FreeBSD", not sure it's relevant for Debian context though? :) Thanks for packaging + maintaining reptyr in Debian! :) regards -mika-
[Grml] First Release Candidate of Grml version 2024.02 available
Hi, our first release candidate of the upcoming Grml version 2024.02, code-named 'Glumpad' is available. This Grml release provides fresh software packages from Debian trixie. As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release. For detailed information about the changes between 2022.11 and 2024.02-rc1 have a look at the official release announcement: https://grml.org/changelogs/README-grml-2024.02-rc1/ You can download Grml 2024.02-rc1 from: https://grml.org/download/prerelease/ Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of Februar (2024! :)). Thanks to all our contributors! regards, -mika- - for the Grml.org project signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
[Grml-devel] First Release Candidate of Grml version 2024.02 available
Hi, our first release candidate of the upcoming Grml version 2024.02, code-named 'Glumpad' is available. This Grml release provides fresh software packages from Debian trixie. As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release. For detailed information about the changes between 2022.11 and 2024.02-rc1 have a look at the official release announcement: https://grml.org/changelogs/README-grml-2024.02-rc1/ You can download Grml 2024.02-rc1 from: https://grml.org/download/prerelease/ Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of Februar (2024! :)). Thanks to all our contributors! regards, -mika- - for the Grml.org project signature.asc Description: PGP signature ___ Grml-devel mailing list Grml-devel@ml.grml.org http://ml.grml.org/mailman/listinfo/grml-devel
Bug#1057610: marked as pending in zsh
Control: tag -1 pending Hello, Bug #1057610 in zsh 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/debian/zsh/-/commit/c366ecc5d0b6f14f9e0112cf26b0b7ee9519b3bd Cherry pick upstream commit ecd3f9c9 to fix FTBFS issue with newer texinfo Fixes: | texi2any -c TEXI2HTML=1 --output . --ifinfo --split=chapter --node-files \ | --init-file texi2html.conf ../../Doc/zsh.texi | texi2any: error parsing ./texi2html.conf: Undefined subroutine ::Config::set_from_init_file called at ./texi2html.conf line 1. Cherry picked (excluding Changelog change) from upstream commit https://github.com/zsh-users/zsh/commit/ecd3f9c9506c7720dc6c0833dc5d5eb00e4459c4 Also see https://www.zsh.org/mla/workers/2023/msg00591.html Closes: #1057610 fixup of debian/patches/cherry-pick-ecd3f9c9-1057610-support-texinfo-7.0.patch fixup (this message was generated automatically) -- Greetings https://bugs.debian.org/1057610
Bug#1059232: imvirt: version 0.9.6-12 failed to build in unstable - uninstallable
Package: imvirt Version: 0.9.6-12 Severity: important Hi, imvirt is uninstallable in Debian/unstable since 2023-12-12 due to the upload of a broken v0.9.6-12 which wasn't built on Debian's build infrastructure: | root@7b9ce5803a7d:/# apt update | Get:1 http://deb.debian.org/debian unstable InRelease [198 kB] | Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9605 kB] | Fetched 9803 kB in 3s (3616 kB/s) | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | 2 packages can be upgraded. Run 'apt list --upgradable' to see them. | root@7b9ce5803a7d:/# apt install imvirt | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Package imvirt is not available, but is referred to by another package. | This may mean that the package is missing, has been obsoleted, or | is only available from another source | However the following packages replace it: | imvirt-helper | | E: Package 'imvirt' has no installation candidate FTR: | % rmadison imvirt imvirt-helper -s unstable | imvirt| 0.9.6-11 | unstable | source, all | imvirt| 0.9.6-12 | unstable | source | imvirt-helper | 0.9.6-12 | unstable | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x Quoting from https://buildd.debian.org/status/fetch.php?pkg=imvirt=all=0.9.6-12=1702397779=0 -> | dh_missing: warning: usr/libexec/imvirt/xen exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/lib/imvirt/xen") | dh_missing: error: missing files, aborting | | While detecting missing files, dh_missing noted some files with a similar name to those | that were missing. This error /might/ be resolved by replacing references to the | missing files with the similarly named ones that dh_missing found - assuming the content | is identical. | | As an example, you might want to replace: |* debian/tmp/usr/lib/imvirt/hvm | with: |* usr/libexec/imvirt/hvm | in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. | (Note it is possible the paths are not used verbatim but instead directories | containing or globs matching them are used instead) | | Alternatively, add the missing file to debian/not-installed if it cannot and should not | be used. | | The following debhelper tools have reported what they installed (with files per package) |* dh_install: imvirt (1), imvirt-helper (1), libimvirt-perl (2) |* dh_installdocs: imvirt (2), imvirt-helper (0), libimvirt-perl (0) |* dh_installman: imvirt (1), imvirt-helper (1), libimvirt-perl (1) | If the missing files are installed by another tool, please file a bug against it. | When filing the report, if the tool is not part of debhelper itself, please reference the | "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). | (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz) | Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built | If the omission is intentional or no other helper can take care of this consider adding the | paths to debian/not-installed. | make: *** [debian/rules:6: binary-indep] Error 25 | dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit status 2 regards -mika-
Re: [Grml] W-Lan Treiber rtl8188fufw
Hallo, (Cc-ing H-P. Teufel explicitly, since he's not subscribed to the mailing list when sending the mail to the mailing list, which I just let the moderation queue bypass) * h-p.teu...@web.de [Mon Dec 18, 2023 at 12:21:12PM +0100]: > wie möchten und das 14 tägliche herunterladen der testing-Versin ersparen, > und sie bitten und mitzuteilen, sobald der W-Lan Treiber > rtl8188fufw.bin > in die lib/firmware/rtlwifi/ eingefügt wurde. > > Mit freundlichen Grüßen aus Eisenach > > H-P. Teufel > > Mit "neudeutsch" kann ich ihnen nicht dienen. Auch des Angebot von "Deepl" > wurde von 5000 Zeichen auf 1500 Zeichen gekürzt. > > > Hello gentlemen, > > We would like to save you the trouble of downloading the testing version 14 > times a day and ask you to let us know as soon as the W-Lan driver has been > added. Grml is based on Debian, so *usually* only once the rtl8188fufw.bin firmware file makes it to an according firmware package of Debian, Grml will pick it up. :) According to https://forums.debian.net/viewtopic.php?p=788378=64e91139e2212e972b4c7693233ec9ec#p788378 there are chances this might happen soonish, given that https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-main.tar.gz seems to already include the file? Reaching out to the Debian kernel folks might be worth it, if it's important for you. Once https://packages.debian.org/search?searchon=contents=rtl8188fufw.bin=path=testing=any reports the file to be included in a Debian package, chances are that Grml might also provide it then. :) regards -mika- signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
Bug#1054571: devscripts: debootsnap: Missing Recommends on python3-pycurl
* David (Plasma) Paul [Wed Nov 29, 2023 at 03:47:50PM -0600]: > On Tue, 28 Nov 2023 12:48:31 +0100 Michael Prokop wrote: > > * David (Plasma) Paul [Wed Oct 25, 2023 at 11:36:48PM -0500]: [...] > > And the package description for says: > > > > | - debootsnap: Combines debootstrap and snapshot.debian.org to create a > > chroot > > | containing exactly the requested selection of packages. This can be used > > | to re-create a chroot from the past, for example to reproduce a bug. The > > | tool is also used by debrebuild to build a package in a chroot with > > build > > | dependencies in the same version as recorded in the buildinfo file. > > | [apt-utils, dpkg-dev, equivs, mmdebstrap, python3-pycurl] > > > > I can confirm that apt-utils, equivs, mmdebstrap and python3-pycurl, > > but also python3-debian and python3-requests seem to be required. > > > > Given that e.g. `equivs` is listed in both Recommends, but also in > > the `[...]` section of the debootsnap's description, maybe the list > > should be updated to: > > > > [apt-utils equivs mmdebstrap python3-debian python3-pycurl > > python3-requests] > > > > ? > > I concur. Given that dpkg-dev is already listed as a hard Dependency of > devscripts and given that debootsnap indeed requires python3-debian and > python3-requests, the list of packages following 'debootsnap' in the > Description stanza of devscripts' metadata should read: > > [apt-utils, equivs, mmdebstrap, python3-debian, python3-pycurl, > python3-requests] *nod* I implemented this at https://salsa.debian.org/debian/devscripts/-/merge_requests/374 regards -mika- signature.asc Description: PGP signature
Bug#1054571: devscripts: debootsnap: Missing Recommends on python3-pycurl
Hi, * David (Plasma) Paul [Wed Oct 25, 2023 at 11:36:48PM -0500]: > Package: devscripts > Version: 2.21.6 > Severity: normal > > Dear Maintainer, > > The devscripts binary package is missing a Recommends on python3-pycurl > which is a dependency of the debootsnap script. So in devscripts v2.23.6 we have: | Depends: dpkg-dev (>= 1.18.19), fakeroot, file, gnupg | gnupg2, gpgv | gpgv2, libfile-dirlist-perl, libfile-homedir-perl, libfile-touch-perl, libfile-which-perl, libipc-run-perl, libmoo-perl, libwww-perl, patchutils, sensible-utils, wdiff, perl:any, python3:any | Recommends: apt (>= 1.3~pre3), dctrl-tools, dput | dupload, libdistro-info-perl, libdpkg-perl, libencode-locale-perl, libgit-wrapper-perl, libgitlab-api-v4-perl, libjson-perl, liblist-compare-perl, libstring-shellquote-perl, libtry-tiny-perl, liburi-perl, licensecheck, lintian, man-db, patch, python3-apt, python3-debian (>= 0.1.15), python3-magic, python3-requests, python3-unidiff, python3-xdg, strace, unzip, wget | curl, xz-utils, debian-keyring, equivs, liblwp-protocol-https-perl, libsoap-lite-perl, pristine-tar | Suggests: adequate, at, autopkgtest, bls-standalone, bsd-mailx | mailx, build-essential, check-all-the-things, cvs-buildpackage, debhelper, diffoscope, disorderfs, dose-extra (>= 4.0), duck, elpa-devscripts, faketime, gnuplot, how-can-i-help, libauthen-sasl-perl, libdbd-pg-perl, libfile-desktopentry-perl, libterm-size-perl, libtimedate-perl, libyaml-syck-perl, mmdebstrap, mozilla-devscripts, mutt, piuparts, postgresql-client, pristine-lfs, quilt, ratt, reprotest, ssh-client, svn-buildpackage, w3m And the package description for says: | - debootsnap: Combines debootstrap and snapshot.debian.org to create a chroot | containing exactly the requested selection of packages. This can be used | to re-create a chroot from the past, for example to reproduce a bug. The | tool is also used by debrebuild to build a package in a chroot with build | dependencies in the same version as recorded in the buildinfo file. | [apt-utils, dpkg-dev, equivs, mmdebstrap, python3-pycurl] I can confirm that apt-utils, equivs, mmdebstrap and python3-pycurl, but also python3-debian and python3-requests seem to be required. Given that e.g. `equivs` is listed in both Recommends, but also in the `[...]` section of the debootsnap's description, maybe the list should be updated to: [apt-utils equivs mmdebstrap python3-debian python3-pycurl python3-requests] ? regards -mika- signature.asc Description: PGP signature
Bug#1056151: fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions
* Chris Hofstaedtler [Fri Nov 17, 2023 at 08:54:29PM +0100]: > > you will have noticed that systemd 255 moves its files from / to /usr. > This includes /sbin/init. > > Now a problem arises, when: > - I use a basefile tar.gz, made with an old systemd (say, it uses > testing as of today) > - During baseupdate, systemd gets updated and moves its file (say, I'm > actually installing unstable) > > What happens is this: > - base image gets unpacked, /sbin is a symlink to /usr/sbin, > /sbin/init is actually /usr/sbin/init > - baseupdate diverts /sbin/init to /sbin/init.distrib (and using > symlinks, /usr/sbin/init became /usr/sbin/init.distrib) > - baseupdate updates systemd, dpkg 'moves' /sbin/init to /usr/sbin/init, > but the divert stays in place for /sbin/init. > At this time, dpkg will have overwritten /usr/sbin/init with the new > file(!) > - fai-divert -R runs, removes /sbin/init, and removes the divert of > /sbin/init. > But: at this point /sbin/init was already the new /usr/sbin/init, > which is now lost. > > As a result /usr/sbin/init is missing, and the system does not boot. > > I would suggest dropping all the fai-divert calls in baseupdate. Thanks for the great analysis, Chris. It seems that https://github.com/faiproject/fai/commit/7294b415ab2982f84b293900a9610eab49184201 works around the issue, at least for my use case (though the commit message sadly isn't really verbose and doesn't say what the underlying reason for the change was). The change didn't make it into any fai release yet, though. regards -mika- signature.asc Description: PGP signature
Bug#1041999: tgt: Drop glusterfs support for 32-bit architectures
Hi, * Michael Prokop [Fri Sep 22, 2023 at 05:36:31PM +0200]: > * Patrick Matthäi [Tue Jul 25, 2023 at 04:00:46PM +0200]: > > > > because of the bug #1039604 [0] I will drop glusterfs completly from > > non x64 architectures. You package has a reverse dependency on. > > > > So you should change your (build)-dependeny e.g. on libglusterfs-dev to: > > libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 > > sparc64] > > > > In experimental with glusterfs 11.0-1 the !x64 support has been already > > dropped. > > I plan to upload it to unstable after the reverse dependencies are fixed. > > > > If you need help, please let me know :) > > > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039604 > > This is available as MR now: > https://salsa.debian.org/debian/tgt/-/merge_requests/2 > > Apollon, could you please merge and upload this, so we get tgt back > to Debian/testing? Friendly maintainer ping? :) regards -mika- signature.asc Description: PGP signature
Bug#1041999: tgt: Drop glusterfs support for 32-bit architectures
Hi, * Michael Prokop [Fri Sep 22, 2023 at 05:36:31PM +0200]: > * Patrick Matthäi [Tue Jul 25, 2023 at 04:00:46PM +0200]: > > > > because of the bug #1039604 [0] I will drop glusterfs completly from > > non x64 architectures. You package has a reverse dependency on. > > > > So you should change your (build)-dependeny e.g. on libglusterfs-dev to: > > libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 > > sparc64] > > > > In experimental with glusterfs 11.0-1 the !x64 support has been already > > dropped. > > I plan to upload it to unstable after the reverse dependencies are fixed. > > > > If you need help, please let me know :) > > > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039604 > > This is available as MR now: > https://salsa.debian.org/debian/tgt/-/merge_requests/2 > > Apollon, could you please merge and upload this, so we get tgt back > to Debian/testing? Friendly maintainer ping? :) regards -mika- signature.asc Description: PGP signature
Re: [RFC] locking down rsyslog.service
* Michael Biebl [Wed Oct 11, 2023 at 12:14:47PM +0200]: > Am 11.10.23 um 08:03 schrieb Simon Richter: > > On 10/11/23 03:22, Michael Biebl wrote: > > > > > I intend to lock down rsyslog.service in Debian in one of the next > > > uploads using the following systemd directives > > > > > CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE > > > CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE > > > CAP_SYSLOG > > > > Does it actually need CAP_NET_ADMIN and CAP_SYS_ADMIN? > > > > Everything else looks good to me. > > The list is based on > https://github.com/rsyslog/rsyslog/pull/4999#issuecomment-1313362425 > > - CAP_NET_ADMIN: use of setsockopt() > - CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on the > number of open files, in system calls that open files (e.g. accept execve), > use of setns(),... > > I trimmed stuff like CAP_SETGID and CAP_SETUID, which the Debian package > doesn't need. Just in case you haven't seen it yet, be aware of the CAP_DAC_OVERRIDE change for omprog module usage at https://github.com/rsyslog/rsyslog/pull/5223 regards -mika- signature.asc Description: PGP signature
Re: [RFC] locking down rsyslog.service
* Michael Biebl [Tue Oct 10, 2023 at 08:22:26PM +0200]: > I intend to lock down rsyslog.service in Debian in one of the next > uploads using the following systemd directives That's great to hear, thanks for working on this. > PrivateTmp=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp= > > PrivateDevices=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateDevices= > > ProtectHome=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome= > > ProtectSystem=full > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem= > > ProtectKernelTunables=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables= > > ProtectKernelModules=yes > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelModules= All those work fine for rsyslog within a platform of a customer of mine, for whom I implemented the systemd hardening back in 2020. Same also for: | NoNewPrivileges=yes | ProtectControlGroups=yes which are mentioned elsewhere in this thread. You might also consider enabling the following options: # Service cannot create writable executable memory mappings that are writable and executable at the same time MemoryDenyWriteExecute=yes # Service may execute system calls only with native ABI SystemCallArchitectures=native # Service cannot change ABI personality LockPersonality=true # Restrict access to the various process namespace types the Linux kernel provides RestrictNamespaces=true regards -mika- signature.asc Description: PGP signature
Re: [Grml] memtest86+ in grml 2022.11
Hi, * Sebastian Bachmann [Sat Oct 14, 2023 at 06:26:11PM +0200]: > I just had the issue that the memtest86+ on my grml usb stick always froze > during testing. I had this issue now several times with newer hardware and > it is certainly a problem with old memtest86+. > My stick had 2021.07 on it and I replaced it by 2022.11 now. The release > notes say that apparently memtest86+ v6 should be integrated, but it still > boots v5.01? > To check the memory now, I grabbed another stick and dd'ed the memtest image > for v6.2 - which works perfectly and the memtest is currently running. Good to know :) > I just wondered if grml 2022.11 should ship memtest86+ v6 but still ships > 5.01 by mistake or if this is a mistake in the documentation (or perhaps > means something different)? The grml64-full 2022.11-ISO indeed ships memtest86+ in version 6.00-1 and this is the one that also starts when booting in *EFI* mode, but in *BIOS* mode it indeed ends up as memtest86+ v5.01. This is caused by a combination of different facts, but long story short, the memtest binary for BIOS boot ends up being the one from the building host (and not the ones from the live system, as already being done for EFI situation). This is known as https://github.com/grml/grml/issues/178 and https://github.com/grml/grml-live/issues/128. Now that we have Debian bookworm with memtest86+ v6.10-4 available as base, things should hopefully be easier to sort out. :) Thanks for reporting, Sebastian! regards -mika- signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
Bug#1030312: Bug#503215: apt-get: provide a way to ignore nonexistent packages
Hi!
* David Madore [Thu Oct 23, 2008 at 07:11:46PM +0200]:
> It would be nice to have an option --ignore-nonexistent to instruct
> apt-get to emit a non-fatal warning if any nonexistent packages are
> requested (on install, remove, etc.) rather than terminating with an
> error. E.g., "apt-get install --ignore-nonexistent dpkg blurb" would
> just turn "Couldn't find package blurb" into a warning rather than an
> error.
>
> The reason this would be useful is that sometimes one wishes to
> install huge lists of packages (e.g., copied from another machine's
> output of dpkg -l) from which various packages may have been removed.
> When installing a list of over 2000 packages from which perhaps 100
> are nonexistent, it is a pain to have to restart 100 times apt-get,
> each time removing *one* offending package.
>
> So a --ignore-nonexistent option would be hugely useful.
>
> This is, of course, totally unrelated to --ignore-missing.
I'd like to refresh this request :)
* Eugene V. Lyubimkin [Thu Oct 23, 2008 at 08:24:21PM +0300]:
> JFYI: you can use 'aptitude install' as a workaround.
Yes, this is what is (somewhat) available with aptitude, though it
would be nice, if also apt/apt-get would support this.
For example FAI supports an option to use aptitude instead of
apt-get by using its "PACKAGES aptitude" syntax (though this is
currently broken for aptitude in FAI, see #1030312).
Demonstration with Debian/triexi, where the package tgt currently
isn't available:
| root@bc3b54bda765:~# apt install tgt zsh tgt-
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| E: Unable to locate package tgt
| E: Unable to locate package tgt
Also aptitude fails in that situation:
| root@bc3b54bda765:~# aptitude install tgt zsh tgt-
| Couldn't find any package whose name is "tgt", but there are 8 packages which
contain "tgt" in their name:
| liblibreofficekitgtk istgt libgnunetgtk3 libgnunetgtk-dev
libwebkitgtk-6.0-dev gir1.2-spiceclientgtk-3.0 libwebkitgtk-6.0-4
gir1.2-inftextgtk-0.7
| Unable to apply some actions, aborting
| root@bc3b54bda765:~# echo $?
| 255
Whereas in Debian/unstable (where package tgt *is* available),
aptitude behaves as follows (excluding the tgt package from the
list):
| root@42073ece6102:~# aptitude install tgt zsh tgt-
| Package tgt is not installed, so it will not be removed
| Package tgt is not installed, so it will not be removed
| The following NEW packages will be installed:
| adduser{a} zsh zsh-common{a}
| 0 packages upgraded, 3 newly installed, 0 to remove and 20 not upgraded.
| Need to get 5196 kB of archives. After unpacking 19.9 MB will be used.
| Do you want to continue? [Y/n/?]
| [...]
While apt behaves as follows:
| root@42073ece6102:~# apt install tgt zsh tgt-
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| Package 'tgt' is not installed, so not removed
| The following additional packages will be installed:
| adduser ibverbs-providers libaio1 libconfig-general-perl libibverbs1
libnl-3-200 libnl-route-3-200 librdmacm1 libsgutils2-1.46-2 sg3-utils zsh-common
| Suggested packages:
| cron quota tgt-glusterfs tgt-rbd zsh-doc
| The following NEW packages will be installed:
| adduser ibverbs-providers libaio1 libconfig-general-perl libibverbs1
libnl-3-200 libnl-route-3-200 librdmacm1 libsgutils2-1.46-2 sg3-utils tgt zsh
zsh-common
| The following held packages will be changed:
| tgt
| 0 upgraded, 13 newly installed, 0 to remove and 20 not upgraded.
| Need to get 7173 kB of archives.
| After this operation, 26.5 MB of additional disk space will be used.
| Do you want to continue? [Y/n]
| [...]
FTR, all command lines above executed with latest apt/aptitude versions:
| # aptitude --version | head -1
| aptitude 0.8.13
| # apt-get --version | head -1
| apt 2.7.6 (amd64)
It would be nice, if apt and aptitude could both behave similar.
Though it would be *great* if one could build command lines like:
| # apt install foo bar baz foo-
... to install the "bar baz" packages only, and ignore the foo
package. If one is wondering why this might be useful:
1) When building live systems with big(ger) amount of packages,
sometimes packages might not be available/installable at all times
(esp. true for Debian/testing). Then it's great if one can keep the
original package list as-is, but only extend a list of packages that
should be ignored. This is kind of available with aptitude and FAI
with its class approach, where one can use something like this:
| # head /etc/grml/fai/config/package_config/BASE
| PACKAGES aptitude
|
| foo
| bar
| baz
| # cat /etc/grml/fai/config/package_config/IGNORE
|
| PACKAGES aptitude
| foo-
Then the package "foo" gets ignored, though the original software
selection in the "BASE" file doesn't need to be modified.
2) Trying to install a list of packages on the command line often
ends up in bisecting the package that's actually causing the
Bug#1031874: upx-ucl: CVE-2023-23457
* Moritz Mühlenhoff [Fri Feb 24, 2023 at 05:04:53PM +0100]: > The following vulnerability was published for upx-ucl. > > CVE-2023-23457[0]: > | A Segmentation fault was found in UPX in > | PackLinuxElf64::invert_pt_dynamic() in p_lx_elf.cpp. An attacker with > | a crafted input file allows invalid memory address access that could > | lead to a denial of service. > > https://github.com/upx/upx/issues/631 > https://github.com/upx/upx/commit/779b648c5f6aa9b33f4728f79dd4d0efec0bf860 [...] There are patches available for this and also for #1033258 since several months, also upstream released multiple versions since 3.96 (latest being v4.1.0 as of 2023-08-08). Is there any reason why this wasn't yet taken care of? Is the package maintainer still around? regards -mika- signature.asc Description: PGP signature
Bug#1031874: upx-ucl: CVE-2023-23457
* Moritz Mühlenhoff [Fri Feb 24, 2023 at 05:04:53PM +0100]: > The following vulnerability was published for upx-ucl. > > CVE-2023-23457[0]: > | A Segmentation fault was found in UPX in > | PackLinuxElf64::invert_pt_dynamic() in p_lx_elf.cpp. An attacker with > | a crafted input file allows invalid memory address access that could > | lead to a denial of service. > > https://github.com/upx/upx/issues/631 > https://github.com/upx/upx/commit/779b648c5f6aa9b33f4728f79dd4d0efec0bf860 [...] There are patches available for this and also for #1033258 since several months, also upstream released multiple versions since 3.96 (latest being v4.1.0 as of 2023-08-08). Is there any reason why this wasn't yet taken care of? Is the package maintainer still around? regards -mika- signature.asc Description: PGP signature
Bug#980041: paps: please update to 0.7.1
* Stephen Kitt [Wed Jan 13, 2021 at 11:50:23AM +0100]: > paps is now maintained on https://github.com/dov/paps, and there have > been releases since 0.6.8. In particular, current versions produce PS > files with the original text content, instead of only rendered > glyphs. Friendly maintainer ping, paps feels like being unmaintained within Debian? | % rmadison paps | paps | 0.6.8-7.1 | oldoldstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | paps | 0.6.8-7.1 | oldstable | source | paps | 0.6.8-7.1 | stable | source | paps | 0.6.8-7.1 | testing| source | paps | 0.6.8-7.1 | unstable | source, riscv64 | paps | 0.6.8-7.1 | unstable-debug | source | paps | 0.6.8-7.1+b1 | oldstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x | paps | 0.6.8-7.1+b1 | stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x | paps | 0.6.8-7.1+b1 | testing| amd64, arm64, armel, armhf, i386, mips64el, ppc64el, s390x | paps | 0.6.8-7.1+b1 | unstable | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, s390x regards -mika- signature.asc Description: PGP signature
Bug#1041999: tgt: Drop glusterfs support for 32-bit architectures
* Patrick Matthäi [Tue Jul 25, 2023 at 04:00:46PM +0200]: > > because of the bug #1039604 [0] I will drop glusterfs completly from > non x64 architectures. You package has a reverse dependency on. > > So you should change your (build)-dependeny e.g. on libglusterfs-dev to: > libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 > sparc64] > > In experimental with glusterfs 11.0-1 the !x64 support has been already > dropped. > I plan to upload it to unstable after the reverse dependencies are fixed. > > If you need help, please let me know :) > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039604 This is available as MR now: https://salsa.debian.org/debian/tgt/-/merge_requests/2 Apollon, could you please merge and upload this, so we get tgt back to Debian/testing? regards -mika- signature.asc Description: PGP signature
Bug#1041999: tgt: Drop glusterfs support for 32-bit architectures
* Patrick Matthäi [Tue Jul 25, 2023 at 04:00:46PM +0200]: > > because of the bug #1039604 [0] I will drop glusterfs completly from > non x64 architectures. You package has a reverse dependency on. > > So you should change your (build)-dependeny e.g. on libglusterfs-dev to: > libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 mips64el s390x ia64 > sparc64] > > In experimental with glusterfs 11.0-1 the !x64 support has been already > dropped. > I plan to upload it to unstable after the reverse dependencies are fixed. > > If you need help, please let me know :) > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039604 This is available as MR now: https://salsa.debian.org/debian/tgt/-/merge_requests/2 Apollon, could you please merge and upload this, so we get tgt back to Debian/testing? regards -mika- signature.asc Description: PGP signature
Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0
* Adrian Bunk [Fri Jul 14, 2023 at 09:19:31PM +0300]: > Source: thin-provisioning-tools > Version: 0.9.0-2 > Severity: serious > Tags: ftbfs trixie sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/thin-provisioning-tools.html > > ... > In file included from > /usr/src/googletest/googletest/include/gtest/gtest-message.h:57, > from > /usr/src/googletest/googletest/include/gtest/gtest-assertion-result.h:46, > from /usr/src/googletest/googletest/include/gtest/gtest.h:64, > from /usr/src/googletest/googletest/src/gtest-all.cc:38: > /usr/src/googletest/googletest/include/gtest/internal/gtest-port.h:270:2: > error: #error C++ versions less than C++14 are not supported. > 270 | #error C++ versions less than C++14 are not supported. > | ^ > ... > > > > This can be fixed by changing the two -std=c++11 to -std=c++14 > in unit-tests/Makefile.in Thanks, Adrian. Available as MR now: https://salsa.debian.org/lvm-team/thin-provisioning-tools/-/merge_requests/3 Bastian, could you please merge and upload it, so we get thin-provisioning-tools back in Debian/testing? regards -mika- signature.asc Description: PGP signature
Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0
* Adrian Bunk [Fri Jul 14, 2023 at 09:19:31PM +0300]: > Source: thin-provisioning-tools > Version: 0.9.0-2 > Severity: serious > Tags: ftbfs trixie sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/thin-provisioning-tools.html > > ... > In file included from > /usr/src/googletest/googletest/include/gtest/gtest-message.h:57, > from > /usr/src/googletest/googletest/include/gtest/gtest-assertion-result.h:46, > from /usr/src/googletest/googletest/include/gtest/gtest.h:64, > from /usr/src/googletest/googletest/src/gtest-all.cc:38: > /usr/src/googletest/googletest/include/gtest/internal/gtest-port.h:270:2: > error: #error C++ versions less than C++14 are not supported. > 270 | #error C++ versions less than C++14 are not supported. > | ^ > ... > > > > This can be fixed by changing the two -std=c++11 to -std=c++14 > in unit-tests/Makefile.in Thanks, Adrian. Available as MR now: https://salsa.debian.org/lvm-team/thin-provisioning-tools/-/merge_requests/3 Bastian, could you please merge and upload it, so we get thin-provisioning-tools back in Debian/testing? regards -mika- signature.asc Description: PGP signature
Bug#1052465: thin-provisioning-tools: New upstream version v1.0.6 available
Package: thin-provisioning-tools Version: 0.9.0-2 Severity: wishlist Hi, version 1.0.6 is available since 2023-08-09: https://github.com/jthornber/thin-provisioning-tools/tags FTR: upstream seemed to have rewritten it in Rust (see https://github.com/jthornber/thin-provisioning-tools/blob/main/CHANGES ) regards -mika-
Re: [Grml] fstab-entry change
Hi Hans, * Hans Schneidhofer [Fri Aug 11, 2023 at 06:08:17PM +]: > on a PC with Debian 11 installed, an SSD can neither be read nor > written. > > I have now restarted the PC with a grml. > How can I change the entry in /etc/fstab on this PC with the help of > grml so that this defective SSD is not taken into account when > restarting? > > Unfortunately, I can't quite get along with the new grml. I used to be > able to log in with a password and mount the file system of the PC > system with root rights, e.g. on /mnt /computername/ and then edit > /etc/fstab. > > How can I do this with the new version grml-64-full 2022 ? Can you actually access the SSD at all, as in: is it still alive? Check output of `lsblk` and look for failures in `dmesg` and `journalctl -p 4`. If the disk is present, check its SMART data with `smartctl -a /dev/sdX`, and if it's "alive" and you can acces it, mounting it should be possible as usual™. (Depending on the actual setup you of course might have to also do LVM, mdadm, cryptsetup,... magic, but then we'd need more details about your setup.) HTH! regards -mika- signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
Bug#1051464: hwinfo: New upstream version 23.2 available
Package: hwinfo Version: 21.82-1 Severity: wishlist Hi, plenty of hwinfo versions got released since version 21.82-1, as of 2023-07-20 version 23.2 is the latest upstream version, see https://github.com/openSUSE/hwinfo/tags Would be nice to have an updated hwinfo package in Debian. :) regards -mika-
Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client
Hi, * Michael Prokop [Thu Sep 07, 2023 at 05:36:06PM +0200]: > as of v21.4-2, Debian's cloud-init has a hard dependency on > isc-dhcp-client, while the isc-dhcp suite has been deprecated by the > ISC (also see e.g. > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components). > > This makes integration/usage of cloud-init with e.g. dhcpcd > impossible: > > | # apt install cloud-init dhcpcd > | Reading package lists... Done > | Building dependency tree... Done > | Some packages could not be installed. This may mean that you have > | requested an impossible situation or if you are using the unstable > | distribution that some required packages have not yet been created > | or been moved out of Incoming. > | The following information may help to resolve the situation: > | > | The following packages have unmet dependencies: > | dhcpcd-base : Conflicts: dhcp-client > | E: Unable to correct problems, you have held broken packages. Sorry, forgot to clarify: the `apt install cloud-init dhcpcd` from above doesn't work on Debian <=bookworm, while on >= trixie it works, because dhcpcd-base no longer conflicts with dhcp-client, as it used to do up and until bookworm: | root@f50263b65142:/# apt-get install dhcpcd isc-dhcp-client 2>&1 | tail -3 | The following packages have unmet dependencies: | dhcpcd-base : Conflicts: dhcp-client | E: Unable to correct problems, you have held broken packages. | root@f50263b65142:/# apt-cache show dhcpcd-base | grep Conflicts | Conflicts: dhcp-client > Quoting from > https://github.com/canonical/cloud-init/releases/tag/23.3, > cloud-init doesn't seem to strictly depend on isc-dhcp-client any > longer though: > > | network: support busybox micro DHCP client (udhcpc) alternative to > | deprecated isc-dhcp-client. > > So while one can install udhcpc next to isc-dhcp-client in > Debian (because they don't conflict with each other), it's > not yet possible to use Debian with cloud-init, without having > also isc-dhcp-client on the system. > > Please consider adapting the Depends for the new cloud-init version > in Debian accordingly, so one can use e.g. cloud-init with udhcpc > (which also allows co-installation next to dhcpcd), but without > having to also have isc-dhcp-client present. While this request still stands of course, to actually get rid of isc-dhcp-client (at least with >=trixie). :) regards -mika- signature.asc Description: PGP signature
Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client
Hi, * Michael Prokop [Thu Sep 07, 2023 at 05:36:06PM +0200]: > as of v21.4-2, Debian's cloud-init has a hard dependency on > isc-dhcp-client, while the isc-dhcp suite has been deprecated by the > ISC (also see e.g. > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components). > > This makes integration/usage of cloud-init with e.g. dhcpcd > impossible: > > | # apt install cloud-init dhcpcd > | Reading package lists... Done > | Building dependency tree... Done > | Some packages could not be installed. This may mean that you have > | requested an impossible situation or if you are using the unstable > | distribution that some required packages have not yet been created > | or been moved out of Incoming. > | The following information may help to resolve the situation: > | > | The following packages have unmet dependencies: > | dhcpcd-base : Conflicts: dhcp-client > | E: Unable to correct problems, you have held broken packages. Sorry, forgot to clarify: the `apt install cloud-init dhcpcd` from above doesn't work on Debian <=bookworm, while on >= trixie it works, because dhcpcd-base no longer conflicts with dhcp-client, as it used to do up and until bookworm: | root@f50263b65142:/# apt-get install dhcpcd isc-dhcp-client 2>&1 | tail -3 | The following packages have unmet dependencies: | dhcpcd-base : Conflicts: dhcp-client | E: Unable to correct problems, you have held broken packages. | root@f50263b65142:/# apt-cache show dhcpcd-base | grep Conflicts | Conflicts: dhcp-client > Quoting from > https://github.com/canonical/cloud-init/releases/tag/23.3, > cloud-init doesn't seem to strictly depend on isc-dhcp-client any > longer though: > > | network: support busybox micro DHCP client (udhcpc) alternative to > | deprecated isc-dhcp-client. > > So while one can install udhcpc next to isc-dhcp-client in > Debian (because they don't conflict with each other), it's > not yet possible to use Debian with cloud-init, without having > also isc-dhcp-client on the system. > > Please consider adapting the Depends for the new cloud-init version > in Debian accordingly, so one can use e.g. cloud-init with udhcpc > (which also allows co-installation next to dhcpcd), but without > having to also have isc-dhcp-client present. While this request still stands of course, to actually get rid of isc-dhcp-client (at least with >=trixie). :) regards -mika- signature.asc Description: PGP signature
Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client
Package: cloud-init Version: 23.2.1-1 Severity: normal Hi, as of v21.4-2, Debian's cloud-init has a hard dependency on isc-dhcp-client, while the isc-dhcp suite has been deprecated by the ISC (also see e.g. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components). This makes integration/usage of cloud-init with e.g. dhcpcd impossible: | # apt install cloud-init dhcpcd | Reading package lists... Done | Building dependency tree... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | dhcpcd-base : Conflicts: dhcp-client | E: Unable to correct problems, you have held broken packages. Quoting from https://github.com/canonical/cloud-init/releases/tag/23.3, cloud-init doesn't seem to strictly depend on isc-dhcp-client any longer though: | network: support busybox micro DHCP client (udhcpc) alternative to | deprecated isc-dhcp-client. So while one can install udhcpc next to isc-dhcp-client in Debian (because they don't conflict with each other), it's not yet possible to use Debian with cloud-init, without having also isc-dhcp-client on the system. Please consider adapting the Depends for the new cloud-init version in Debian accordingly, so one can use e.g. cloud-init with udhcpc (which also allows co-installation next to dhcpcd), but without having to also have isc-dhcp-client present. -mika-
Bug#1050874: rsyslog: logging with short hostname instead of FQDN until first HUP
Package: rsyslog
Version: 8.2302.0-1
Severity: important
Hi,
it looks like the rsyslog version in bookworm is affected by
something related to https://github.com/rsyslog/rsyslog/issues/4975,
quoting from there:
| After rsyslog start, local hostname is short name only. It changes to FQDN
after the first HUP.
I observed this and can reproduce it on several bookworm systems:
| synpromika@example01 ~ % hostname
| example01
| synpromika@example01 ~ % hostname --fqdn
| example01.in.example.com
| synpromika@example01 ~ % logger mika-was-here
| synpromika@example01 ~ % sudo tail /var/log/syslog
| [...]
| 2023-08-30T16:54:12.429181+02:00 example01 synpromika: mika-was-here
Only when sending HUP to rsyslog it behaves as expected:
| synpromika@example01 ~ % sudo pkill -HUP rsyslogd
| synpromika@example01 ~ % logger mika-was-here2
| synpromika@example01 ~ % sudo tail /var/log/syslog
| []
| 2023-08-30T16:54:12.429181+02:00 example01 synpromika: mika-was-here
| 2023-08-30T16:54:20.194863+02:00 example01.in.example.com rsyslogd: [origin
software="rsyslogd" swVersion="8.2302.0" x-pid="5181"
x-info="https://www.rsyslog.com;] rsyslogd was HUPed
| 2023-08-30T16:54:23.708793+02:00 example01.in.example.com synpromika:
mika-was-here2
FTR, the systems have the default /etc/rsyslog.conf:
| synpromika@example01 ~ % grep -v '^#' /etc/rsyslog.conf | sed '/^$/d'
| module(load="imuxsock") # provides support for local system logging
| module(load="imklog") # provides kernel logging support
| $FileOwner root
| $FileGroup adm
| $FileCreateMode 0640
| $DirCreateMode 0755
| $Umask 0022
| $WorkDirectory /var/spool/rsyslog
| $IncludeConfig /etc/rsyslog.d/*.conf
| *.*;auth,authpriv.none -/var/log/syslog
| auth,authpriv.* /var/log/auth.log
| cron.* -/var/log/cron.log
| kern.* -/var/log/kern.log
| mail.* -/var/log/mail.log
| user.* -/var/log/user.log
| *.emerg :omusrmsg:*
And /etc/rsyslog.d/postfix.conf as shipped by the postfix package,
plus a custom /etc/rsyslog.d/graylog.conf for central logging are
also in place:
| synpromika@example01 ~ % grep -v '^#' /etc/rsyslog.d/*.conf | sed '/^$/d'
| /etc/rsyslog.d/graylog.conf:$PreserveFQDN on
| /etc/rsyslog.d/graylog.conf:*.*
@logging01.in.example.com:5140;RSYSLOG_SyslogProtocol23Format
| /etc/rsyslog.d/postfix.conf:$AddUnixListenSocket /var/spool/postfix/dev/log
This is especially tricky, as rsyslog's logrotate configuration also
sends the HUP:
| synpromika@example01 ~ % cat /etc/logrotate.d/rsyslog
| /var/log/syslog
| /var/log/mail.log
| /var/log/kern.log
| /var/log/auth.log
| /var/log/user.log
| /var/log/cron.log
| {
| rotate 4
| weekly
| missingok
| notifempty
| compress
| delaycompress
| sharedscripts
| postrotate
| /usr/lib/rsyslog/rsyslog-rotate
| endscript
| }
| synpromika@example01 ~ % cat /usr/lib/rsyslog/rsyslog-rotate
| #!/bin/sh
|
| if [ -d /run/systemd/system ]; then
| systemctl kill -s HUP rsyslog.service
| fi
So this causes systems to log with short hostname after fresh system
start (and also after every single rsyslog service restart), but
once logrotate kicks in it switches to logging with FQDN / full
hostname instead:
| 2023-08-18T00:00:08.311354+02:00 testsuitecrm01 systemd[1]: Reloaded
apache2.service - The Apache HTTP Server.
| 2023-08-18T00:00:08.331611+02:00 testsuitecrm01.in.example.com systemd[1]:
rsyslog.service: Sent signal SIGHUP to main process 550 (rsyslogd) on client
request.
| 2023-08-18T00:00:08.332430+02:00 testsuitecrm01.in.example.com rsyslogd:
[origin software="rsyslogd" swVersion="8.2302.0" x-pid="550"
x-info="https://www.rsyslog.com;] rsyslogd was HUPed
| 2023-08-18T00:00:08.553169+02:00 testsuitecrm01.in.example.com systemd[1]:
logrotate.service: Deactivated successfully.
| 2023-08-18T00:00:08.553771+02:00 testsuitecrm01.in.example.com systemd[1]:
Finished logrotate.service - Rotate log files.
Especially for folks with log monitoring/alerting based on FQDNs
(e.g. with central loggging or logwatch) this might result in
*quite* some unexpected behavior.
The issue feels similar to what was reported and supposedly fixed
with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022128 and
https://github.com/rsyslog/rsyslog/pull/5004, though it looks like
to be incomplete yet?
regards
-mika-
Bug#1050137: gparted: New upstream version v1.5.0 available
Package: gparted Version: 1.3.1-1 Severity: wishlist Hi, https://gparted.org/news.php reports v1.5.0-1 as latest stable release, available since 2023-02-22 (and the v1.4.0 releases is available since 2022-03-28). regards -mika-
Bug#1043457: ftp.debian.org: buster-backports repository signed with bullseye + bookworm keys
Package: ftp.debian.org
Severity: important
Hi,
the buster-backports repository seems to be signed only with
the bullseye + bookworm keys now:
| % wget --quiet
http://deb.debian.org/debian/dists/buster-backports/Release{,.gpg}
| % gpg --verify Release.gpg Release 2>&1 | grep 'using RSA'
| gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
| gpg:using RSA key 4CB50190207B4758A3F73A796ED0E7B82643E131
STR:
| podman run --pull=always --rm -i -t debian:buster bash
| mv /etc/apt/trusted.gpg.d/debian-archive-bookworm-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bookworm-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bookworm-stable.gpg .
| mv /etc/apt/trusted.gpg.d/debian-archive-bullseye-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-security-automatic.gpg
/etc/apt/trusted.gpg.d/debian-archive-bullseye-stable.gpg .
| echo "deb http://deb.debian.org/debian buster-backports main" >
/etc/apt/sources.list.d/backports.list
| apt update
This then reports:
| [...]
| Hit:1 http://deb.debian.org/debian buster InRelease
| Hit:2 http://deb.debian.org/debian-security buster/updates InRelease
| Hit:3 http://deb.debian.org/debian buster-updates InRelease
| Hit:4 http://deb.debian.org/debian buster-backports InRelease
| Err:4 http://deb.debian.org/debian buster-backports InRelease
| The following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| All packages are up to date.
| W: An error occurred during the signature verification. The repository is not
updated and the previous index files will be used. GPG error:
http://deb.debian.org/debian buster-backports InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| W: Failed to fetch
http://deb.debian.org/debian/dists/buster-backports/InRelease The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
| W: Some index files failed to download. They have been ignored, or old ones
used instead.
regards
-mika-
Bug#1041091: python3-virtualenv: re-execution of virtualenv command removes python-debian's debian directory
* Stefano Rivera [Sat Jul 15, 2023 at 10:22:37PM +]: > This is a subtle bug. I can reproduce it from upstream sources, from > https://github.com/pypa/virtualenv/commit/b4564569171628ee839e14853a00f296686cae6a > to > https://github.com/pypa/virtualenv/commit/94f3cf581bc00eae81eca8bfd545fc3bec6d4bb6 > > The issue is with re-installing setuptools. It seems that: > setuptools-*.dist-info/top_level.txt contains "debian". > > That started to happen around setuptools 51.3.0, with this commit: > https://github.com/pypa/setuptools/commit/0df40810ec54590c888ae0e4073d73f731c91f4a > And the solution is to exclude "debian*" from options.packages.find > > Trivial workaround: build the virtualenv with --no-setuptools. That's > the future, anyway. ACK. I can confirm, that virtualenv's --no-setuptools works around this behavior. Thanks for your fast reply and looking into this, Stefano, appreciated. regards -mika- signature.asc Description: PGP signature
Bug#1041091: python3-virtualenv: re-execution of virtualenv command removes python-debian's debian directory
Package: python3-virtualenv Version: 20.17.1+ds-1 Severity: important Hi, as funny as the subject might sound, this took a while to track down. :) Reporting this, since this might bite other folks as well, and I also have STR. The behavior that was present until and incl. bullseye was as follows (newlines between command lines added by myself to make it easier to read/parse/follow): | % podman run --pull=always --rm -i -t debian:bullseye bash | root@9b5d718485de:/# cd | root@9b5d718485de:~# apt update ; apt -y install python3-virtualenv | [...] | root@9b5d718485de:~# virtualenv --python=python3 virtualenv | created virtual environment CPython3.9.2.final.0-64 in 162ms | creator CPython3Posix(dest=/root/virtualenv, clear=False, no_vcs_ignore=False, global=False) | seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv) | added seed packages: pip==20.3.4, pkg_resources==0.0.0, setuptools==44.1.1, wheel==0.34.2 | activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator | | root@9b5d718485de:~# . virtualenv/bin/activate | | (virtualenv) root@9b5d718485de:~# pip install python-debian | Collecting python-debian | Downloading python_debian-0.1.49-py3-none-any.whl (132 kB) | || 132 kB 5.9 MB/s | Collecting chardet | Downloading chardet-5.1.0-py3-none-any.whl (199 kB) | || 199 kB 18.4 MB/s | Installing collected packages: chardet, python-debian | Successfully installed chardet-5.1.0 python-debian-0.1.49 | | (virtualenv) root@9b5d718485de:~# python3 -c "from debian import deb822" | | (virtualenv) root@9b5d718485de:~# virtualenv --python=python3 virtualenv | created virtual environment CPython3.9.2.final.0-64 in 142ms | creator CPython3Posix(dest=/root/virtualenv, clear=False, no_vcs_ignore=False, global=False) | seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv) | added seed packages: chardet==5.1.0, pip==20.3.4, pkg_resources==0.0.0, python_debian==0.1.49, setuptools==44.1.1, wheel==0.34.2 | activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator | | (virtualenv) root@9b5d718485de:~# python3 -c "from debian import deb822" So everything fine, no problems. But on bookworm, this doesn't behave as such any longer: | % podman run --pull=always --rm -i -t debian:bookworm bash | root@491ed520fc26:/# cd | root@491ed520fc26:~# apt update ; apt -y install python3-virtualenv | [...] | root@491ed520fc26:~# virtualenv --python=python3 virtualenv | created virtual environment CPython3.11.2.final.0-64 in 439ms | creator CPython3Posix(dest=/root/virtualenv, clear=False, no_vcs_ignore=False, global=False) | seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv) | added seed packages: pip==23.0.1, setuptools==66.1.1, wheel==0.38.4 | activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator | | root@491ed520fc26:~# . virtualenv/bin/activate | | (virtualenv) root@491ed520fc26:~# pip install python-debian | Collecting python-debian | Downloading python_debian-0.1.49-py3-none-any.whl (132 kB) | 132.5/132.5 kB 3.7 MB/s eta 0:00:00 | Collecting chardet | Downloading chardet-5.1.0-py3-none-any.whl (199 kB) | 199.1/199.1 kB 6.5 MB/s eta 0:00:00 | Installing collected packages: chardet, python-debian | Successfully installed chardet-5.1.0 python-debian-0.1.49 | | (virtualenv) root@491ed520fc26:~# python3 -c "from debian import deb822" | | (virtualenv) root@491ed520fc26:~# virtualenv --python=python3 virtualenv | created virtual environment CPython3.11.2.final.0-64 in 341ms | creator CPython3Posix(dest=/root/virtualenv, clear=False, no_vcs_ignore=False, global=False) | seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv) | added seed packages: chardet==5.1.0, pip==23.0.1, python_debian==0.1.49, setuptools==66.1.1, wheel==0.38.4 | activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator | | (virtualenv) root@491ed520fc26:~# python3 -c "from debian import deb822" | Traceback (most recent call last): | File "", line 1, in | ModuleNotFoundError: No module named 'debian' So the re-execution of `virtualenv` for some reason removes the debian directory of python-debian on the filesystem. :-/ To highlight this from another run: | (virtualenv) root@b5d06fb7:~# ls virtualenv/lib/python3.11/site-packages/debian | __init__.py __pycache__ _arch_table.py _deb822_repro _util.py _version.py
Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind
Hi, * Ondřej Surý [Fri Jun 16, 2023 at 05:04:41PM +0200]: > > On 16. 6. 2023, at 13:19, Michael Prokop wrote: > > And I purged all of the php7.4 one > You did not. The rc at the beginning of the line means exactly that. > ondrej@calcifer:~$ dpkg -l php7.4-memcached > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/tri> > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version > > +++--> > rc php7.4-memcached 3.1.5+2.2.0-9+0~20210228.30+debian11~1.g> > > ondrej@calcifer:~$ sudo dpkg --purge php7.4-memcached > (Reading database ... 309586 files and directories currently installed.) > Purging configuration files for php7.4-memcached > (3.1.5+2.2.0-9+0~20210228.30+debian11~1.gbp2db493) ... > > ondrej@calcifer:~$ dpkg -l php7.4-memcached > dpkg-query: no packages found matching php7.4-memcached > ondrej@calcifer:~$ Yeah? I've no idea why you're bringing up php7.4-memcached now, I never mentioned this nor had it installed, I also did remove and purge *all* the php7.4 packages as you can see from my output provided in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038166#15 Let me try again, see my STR (repeating from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038166#15, I once again verified it): % podman run --pull=always --rm -i -t debian:bullseye bash # apt update ; apt-get -y install php-imagick [...] # cat > /etc/apt/sources.list << EOF deb http://deb.debian.org/debian bookworm main non-free-firmware deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb http://deb.debian.org/debian bookworm-updates main non-free-firmware EOF # apt update ; apt-get -y install php-common [...] # dpkg --purge php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-phpdbg php7.4-readline # dpkg -S /etc/php/7.4/mods-available/imagick.ini php-imagick: /etc/php/7.4/mods-available/imagick.ini And to highlight its result: root@8c0e4100a294:/# dpkg -l | grep php ii php-common 2:93 all Common files for PHP packages ii php-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library ii php8.2-cli 8.2.7-1~deb12u1 amd64 command-line interpreter for the PHP scripting language ii php8.2-common 8.2.7-1~deb12u1 amd64 documentation, examples and common module for PHP ii php8.2-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library ii php8.2-opcache 8.2.7-1~deb12u1 amd64 Zend OpCache module for PHP ii php8.2-phpdbg 8.2.7-1~deb12u1 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) ii php8.2-readline 8.2.7-1~deb12u1 amd64 readline module for PHP root@8c0e4100a294:/# dpkg -l | grep -v '^ii' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=== root@8c0e4100a294:/# dpkg -S /etc/php/7.4/mods-available/imagick.ini php-imagick: /etc/php/7.4/mods-available/imagick.ini I really don't see what I should have done wrong, sorry. regards -mika- signature.asc Description: PGP signature
Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind
Hi, * Ondřej Surý [Fri Jun 16, 2023 at 12:26:39PM +0200]: > You have just removed but not purged the php7.4 packages, so that’s expected. As stated, those are all php* packages that exist(ed) on the system: > > | # dpkg -l | grep php > > | ii php-common 2:93 all > > Common files for PHP packages > > | ii php-imagick 3.7.0-4 amd64 > > Provides a wrapper to the ImageMagick library > > | rc php7.4-cli 7.4.33-1+deb11u4 amd64 > > command-line interpreter for the PHP scripting language > > | rc php7.4-common 7.4.33-1+deb11u4 amd64 > > documentation, examples and common module for PHP > > | rc php7.4-json 7.4.33-1+deb11u4 amd64 > > JSON module for PHP > > | rc php7.4-opcache 7.4.33-1+deb11u4 amd64 > > Zend OpCache module for PHP > > | rc php7.4-phpdbg 7.4.33-1+deb11u4 amd64 > > server-side, HTML-embedded scripting language (PHPDBG binary) > > | rc php7.4-readline 7.4.33-1+deb11u4 amd64 > > readline module for PHP > > | ii php8.2-cli 8.2.7-1~deb12u1 amd64 > > command-line interpreter for the PHP scripting language > > | ii php8.2-common 8.2.7-1~deb12u1 amd64 > > documentation, examples and common module for PHP > > | ii php8.2-imagick 3.7.0-4 amd64 > > Provides a wrapper to the ImageMagick library > > | ii php8.2-opcache 8.2.7-1~deb12u1 amd64 > > Zend OpCache module for PHP > > | ii php8.2-phpdbg 8.2.7-1~deb12u1 amd64 > > server-side, HTML-embedded scripting language (PHPDBG binary) > > | ii php8.2-readline 8.2.7-1~deb12u1 amd64 > > readline module for PHP And I purged all of the php7.4 ones (as stated): | root@d17a279d1015:/# dpkg -l | grep php | ii php-common 2:93 all Common files for PHP packages | ii php-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library | rc php7.4-cli 7.4.33-1+deb11u4 amd64 command-line interpreter for the PHP scripting language | rc php7.4-common 7.4.33-1+deb11u4 amd64 documentation, examples and common module for PHP | rc php7.4-json 7.4.33-1+deb11u4 amd64 JSON module for PHP | rc php7.4-opcache 7.4.33-1+deb11u4 amd64 Zend OpCache module for PHP | rc php7.4-phpdbg 7.4.33-1+deb11u4 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) | rc php7.4-readline 7.4.33-1+deb11u4 amd64 readline module for PHP | ii php8.2-cli 8.2.7-1~deb12u1 amd64 command-line interpreter for the PHP scripting language | ii php8.2-common 8.2.7-1~deb12u1 amd64 documentation, examples and common module for PHP | ii php8.2-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library | ii php8.2-opcache 8.2.7-1~deb12u1 amd64 Zend OpCache module for PHP | ii php8.2-phpdbg 8.2.7-1~deb12u1 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) | ii php8.2-readline 8.2.7-1~deb12u1 amd64 readline module for PHP | root@d17a279d1015:/# dpkg --purge php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-phpdbg php7.4-readline | (Reading database ... 11733 files and directories currently installed.) | Purging configuration files for php7.4-cli (7.4.33-1+deb11u4) ... | Purging configuration files for php7.4-common (7.4.33-1+deb11u4) ... | Purging configuration files for php7.4-json (7.4.33-1+deb11u4) ... | dpkg: warning: while removing php7.4-json, directory '/etc/php/7.4/mods-available' not empty so not removed | Purging configuration files for php7.4-opcache (7.4.33-1+deb11u4) ... | Purging configuration files for php7.4-phpdbg (7.4.33-1+deb11u4) ... | dpkg: warning: while removing php7.4-phpdbg, directory '/etc/php/7.4' not empty so not removed | Purging configuration files for php7.4-readline (7.4.33-1+deb11u4) ... | root@d17a279d1015:/# dpkg -l | grep php | ii php-common 2:93 all Common files for PHP packages | ii php-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library | ii php8.2-cli 8.2.7-1~deb12u1 amd64 command-line interpreter for the PHP scripting language | ii
Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind
Package: php-imagick Version: 3.7.0-4 Severity: important Hi, this might be related to #951847, I stumbled upon this behavior during an upgrade of a Debian system from bullseye to bookworm, where only file /etc/php/7.4/mods-available/imagick.ini is left behind. System based on bullseye looking as follows: | # ls -la /etc/php/7.4/mods-available/ | total 92 | drwxr-xr-x 2 root root 4096 Jun 16 09:15 . | drwxr-xr-x 5 root root 4096 Jun 16 09:15 .. | -rw-r--r-- 1 root root 74 Jun 9 16:51 calendar.ini | -rw-r--r-- 1 root root 71 Jun 9 16:51 ctype.ini | -rw-r--r-- 1 root root 70 Jun 9 16:51 exif.ini | -rw-r--r-- 1 root root 69 Jun 9 16:51 ffi.ini | -rw-r--r-- 1 root root 74 Jun 9 16:51 fileinfo.ini | -rw-r--r-- 1 root root 69 Jun 9 16:51 ftp.ini | -rw-r--r-- 1 root root 73 Jun 9 16:51 gettext.ini | -rw-r--r-- 1 root root 71 Jun 9 16:51 iconv.ini | -rw-r--r-- 1 root root 60 Mar 5 2021 imagick.ini | -rw-r--r-- 1 root root 68 Jun 9 16:51 json.ini | -rw-r--r-- 1 root root 79 Jun 9 16:51 opcache.ini | -rw-r--r-- 1 root root 69 Jun 9 16:51 pdo.ini | -rw-r--r-- 1 root root 70 Jun 9 16:51 phar.ini | -rw-r--r-- 1 root root 71 Jun 9 16:51 posix.ini | -rw-r--r-- 1 root root 76 Jun 9 16:51 readline.ini | -rw-r--r-- 1 root root 71 Jun 9 16:51 shmop.ini | -rw-r--r-- 1 root root 73 Jun 9 16:51 sockets.ini | -rw-r--r-- 1 root root 73 Jun 9 16:51 sysvmsg.ini | -rw-r--r-- 1 root root 73 Jun 9 16:51 sysvsem.ini | -rw-r--r-- 1 root root 73 Jun 9 16:51 sysvshm.ini | -rw-r--r-- 1 root root 75 Jun 9 16:51 tokenizer.ini | # cat /etc/php/7.4/mods-available/imagick.ini | ; configuration for php imagick module | extension=imagick.so Then after upgrading the system to bookworm and applying configuration file cleanup: | # dpkg -l | grep php | ii php-common 2:93 all Common files for PHP packages | ii php-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library | rc php7.4-cli 7.4.33-1+deb11u4 amd64 command-line interpreter for the PHP scripting language | rc php7.4-common 7.4.33-1+deb11u4 amd64 documentation, examples and common module for PHP | rc php7.4-json 7.4.33-1+deb11u4 amd64 JSON module for PHP | rc php7.4-opcache 7.4.33-1+deb11u4 amd64 Zend OpCache module for PHP | rc php7.4-phpdbg 7.4.33-1+deb11u4 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) | rc php7.4-readline 7.4.33-1+deb11u4 amd64 readline module for PHP | ii php8.2-cli 8.2.7-1~deb12u1 amd64 command-line interpreter for the PHP scripting language | ii php8.2-common 8.2.7-1~deb12u1 amd64 documentation, examples and common module for PHP | ii php8.2-imagick 3.7.0-4 amd64 Provides a wrapper to the ImageMagick library | ii php8.2-opcache 8.2.7-1~deb12u1 amd64 Zend OpCache module for PHP | ii php8.2-phpdbg 8.2.7-1~deb12u1 amd64 server-side, HTML-embedded scripting language (PHPDBG binary) | ii php8.2-readline 8.2.7-1~deb12u1 amd64 readline module for PHP | # dpkg --purge php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-phpdbg php7.4-readline | [...] Then only `/etc/php/7.4/mods-available/imagick.ini` is left behind: | # ls -la /etc/php/7.4/mods-available/ | total 12 | drwxr-xr-x 2 root root 4096 Jun 16 09:25 . | drwxr-xr-x 3 root root 4096 Jun 16 09:25 .. | -rw-r--r-- 1 root root 60 Mar 5 2021 imagick.ini | | # ls -la /etc/php/7.4/mods-available/imagick.ini | -rw-r--r-- 1 root root 60 Mar 5 2021 | /etc/php/7.4/mods-available/imagick.ini | # dpkg -S /etc/php/7.4/mods-available/imagick.ini | php-imagick: /etc/php/7.4/mods-available/imagick.ini Something feels wrong here? FTR: | # apt-cache policy php-imagick php8.2-imagick | php-imagick: | Installed: 3.7.0-4 | Candidate: 3.7.0-4 | Version table: | *** 3.7.0-4 500 | 500 http://deb.debian.org/debian bookworm/main amd64 Packages | 100 /var/lib/dpkg/status | php8.2-imagick: | Installed: 3.7.0-4 | Candidate: 3.7.0-4 | Version table: | *** 3.7.0-4 500 | 500 http://deb.debian.org/debian bookworm/main amd64 Packages | 100 /var/lib/dpkg/status | | # dpkg -L php-imagick | /. | /usr | /usr/share | /usr/share/doc | /usr/share/doc/php-imagick | /usr/share/doc/php-imagick/changelog.Debian.gz | /usr/share/doc/php-imagick/copyright | /etc/php/7.4/mods-available/imagick.ini | | # cat /var/lib/dpkg/info/php-imagick.list | /. | /usr | /usr/share | /usr/share/doc | /usr/share/doc/php-imagick | /usr/share/doc/php-imagick/changelog.Debian.gz |
Bug#1037946: mmdebstrap: Create /var/lib/dpkg/available for Debian releases <=buster
Hi,
* Johannes Schauer Marin Rodrigues [Wed Jun 14, 2023 at 07:09:35PM +0200]:
> Quoting Michael Prokop (2023-06-14 17:19:37)
> > since version 1.20.0, dpkg no longer creates /var/lib/dpkg/available (see
> > #647911).
>
> I see that the bug talks about 1.20.0 but I've had code creating
> /var/lib/dpkg/available in mmdebstrap for a while and determined that it
> wasn't
> necessary anymore since dpkg 1.17.11. Did you do practical tests or are you
> only basing your analysis on that bug?
This showed up in an actual environment, where we automatically
deploy systems on a daily base. The deployment of a buster based
system failed as soon as we upgraded the host system (a Grml based
live system) to bookworm, which provides dpkg v1.21.22 and
mmdebstrap v1.3.5-7. (Deploying bullseye where dpkg v1.20.12 exists
works fine, FTR)
> I'm quite certain about the version requirement because I did tests using
> debbisect and using the suggestion below I'm able to create chroots for all of
> unstable since 2006-08-10.
mmdebstrap itself does *not* fail, but the installation of e.g. the
`nullmailer` package inside the target buster environment then fails:
| Error: Execution of '/usr/bin/apt-get -q -y -o
DPkg::Options::=--force-confold install nullmailer' returned 100: Reading
package lists...
| Building dependency tree...
| Reading state information...
| The following packages were automatically installed and are no longer
required:
| libevent-2.1-6 libgnutls-dane0 libunbound8
| Use 'apt autoremove' to remove them.
| The following packages will be REMOVED:
| exim4-base exim4-config exim4-daemon-light
| The following NEW packages will be installed:
| nullmailer
| 0 upgraded, 1 newly installed, 3 to remove and 0 not upgraded.
| Need to get 109 kB of archives.
| After this operation, 3560 kB disk space will be freed.
| [...]
| [master dbda30d] saving uncommitted changes in /etc prior to apt run
| 6 files changed, 115 insertions(+), 575 deletions(-)
| rewrite locale.gen (99%)
| create mode 100644 needrestart/conf.d/ignore.conf
| debconf: delaying package configuration, since apt-utils is not installed
| dpkg: error: failed to open package info file '/var/lib/dpkg/available' for
reading: No such file or directory
| Fetched 109 kB in 0s (542 kB/s)
| E: Sub-process dpkg --set-selections returned an error code (2)
| E: Couldn't record the approved state changes as dpkg selection states[0m
(FTR, this is part of an automated puppet run)
I can manually reproduce the problem with:
| # mmdebstrap buster /tmp/buster
| [...]
| # chroot /tmp/buster apt update
| [...]
| # chroot /tmp/buster apt install nullmailer
| [...]
| # chroot /tmp/buster apt purge nullmailer
| [...]
| perl: warning: Falling back to the standard locale ("C").
| locale: Cannot set LC_CTYPE to default locale: No such file or directory
| locale: Cannot set LC_MESSAGES to default locale: No such file or directory
| locale: Cannot set LC_ALL to default locale: No such file or directory
| dpkg: error: failed to open package info file '/var/lib/dpkg/available' for
reading: No such file or directory
| E: Sub-process dpkg --set-selections returned an error code (2)
| E: Couldn't record the approved state changes as dpkg selection states
> > But on Debian releases until and including buster, dpkg fails to operate
> > with
> > e.g. `dpkg --set-selections`, if /var/lib/dpkg/available doesn't exist:
> >
> > | The following NEW packages will be installed:
> > | [...]
> > | debconf: delaying package configuration, since apt-utils is not installed
> > | dpkg: error: failed to open package info file '/var/lib/dpkg/available'
> > for reading: No such file or directory
> >
> > My workaround to work around this is to run:
> >
> > chroot "${TARGET}" /usr/lib/dpkg/methods/apt/update /var/lib/dpkg
> >
> > As mmdebstrap seems to rely on dpkg of the host system, it would be
> > nice if mmdebstrap could ensure to create an environment where apt/dpkg of
> > the installed system doesn't stumble upon. :)
>
> this already exists as a hook. :)
>
> Try running mmdebstrap with
>
> --hook-dir=/usr/share/mmdebstrap/hooks/jessie-or-older
>
> which will unconditionally do certain things only necessary for old releases.
This indeed solves the problem, /var/lib/dpkg/available exists in
the target system then (as empty file, FTR).
> If you instead use
>
> --hook-dir=/usr/share/mmdebstrap/hooks/maybe-jessie-or-older
>
> some detection code will only run the hook if necessary (in case you do not
> know upfront which release you are creating a chroot for).
This does *not* help/work, though, FYI.
(FTR, we already have a local workaround, I just thought that it
would make sense to have a decent and nice out-of-the-box experience
also for other users. :))
Thanks! :)
regards
-mika-
signature.asc
Description: PGP signature
Bug#1037946: mmdebstrap: Create /var/lib/dpkg/available for Debian releases <=buster
Package: mmdebstrap
Version: 1.3.5-7
Severity: normal
Hi,
since version 1.20.0, dpkg no longer creates /var/lib/dpkg/available
(see #647911).
But on Debian releases until and including buster, dpkg fails to
operate with e.g. `dpkg --set-selections`, if
/var/lib/dpkg/available doesn't exist:
| The following NEW packages will be installed:
| [...]
| debconf: delaying package configuration, since apt-utils is not installed
| dpkg: error: failed to open package info file '/var/lib/dpkg/available' for
reading: No such file or directory
My workaround to work around this is to run:
chroot "${TARGET}" /usr/lib/dpkg/methods/apt/update /var/lib/dpkg
As mmdebstrap seems to rely on dpkg of the host system, it would be
nice if mmdebstrap could ensure to create an environment where
apt/dpkg of the installed system doesn't stumble upon. :)
Thanks for mmdebstrap!
regards
-mika-
Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)
* Otto Kekäläinen [Wed Jun 07, 2023 at 07:07:50PM -0700]: > Note that upstream released 10.11.4 today. Import preparation in > progress at > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50. > I plan to upload this to experimental tomorrow and eventually into > bookworm-pu if the release team approves. I want to add my +1 as a user of mariadb, the current mariadb version in bookworm has a serios regression which turned out to be https://jira.mariadb.org/browse/MDEV-31403 and is fixed by 1:10.11.4-1 (as present in current Debian/unstable), so a fixed package of mariadb would be highly appreciated. Thanks, Otto and release team :) regards -mika- signature.asc Description: PGP signature
Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)
* Otto Kekäläinen [Wed Jun 07, 2023 at 07:07:50PM -0700]: > Note that upstream released 10.11.4 today. Import preparation in > progress at > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50. > I plan to upload this to experimental tomorrow and eventually into > bookworm-pu if the release team approves. I want to add my +1 as a user of mariadb, the current mariadb version in bookworm has a serios regression which turned out to be https://jira.mariadb.org/browse/MDEV-31403 and is fixed by 1:10.11.4-1 (as present in current Debian/unstable), so a fixed package of mariadb would be highly appreciated. Thanks, Otto and release team :) regards -mika- signature.asc Description: PGP signature
Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)
* Otto Kekäläinen [Wed Jun 07, 2023 at 07:07:50PM -0700]: > Note that upstream released 10.11.4 today. Import preparation in > progress at > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50. > I plan to upload this to experimental tomorrow and eventually into > bookworm-pu if the release team approves. I want to add my +1 as a user of mariadb, the current mariadb version in bookworm has a serios regression which turned out to be https://jira.mariadb.org/browse/MDEV-31403 and is fixed by 1:10.11.4-1 (as present in current Debian/unstable), so a fixed package of mariadb would be highly appreciated. Thanks, Otto and release team :) regards -mika- signature.asc Description: PGP signature
Bug#1034609: Fails to start under Python 3.11
* Arto Jantunen [Wed Apr 19, 2023 at 07:49:33PM +0300]: > The package fails to import under Python 3.11 with the following traceback: > Traceback (most recent call last): [...] > File "/usr/lib/python3/dist-packages/sqlacodegen/main.py", line 10, in > > from sqlacodegen.codegen import CodeGenerator > File "/usr/lib/python3/dist-packages/sqlacodegen/codegen.py", line 4, in > > from inspect import ArgSpec > ImportError: cannot import name 'ArgSpec' from 'inspect' > (/usr/lib/python3.11/inspect.py) > > The issue seems to have been fixed in the latest release candidate, but that > isn't really suitable for bookworm during the freeze, so the intent of this > bug is to cause the package to be dropped from the release. If you don't want to maintain this package or its 1.1.6 version within bookworm then nevermind my comment :) - but looking at https://github.com/agronholm/sqlacodegen/issues/239#issuecomment-1457728533 the fix for this *might* be as simple as replacing: from inspect import ArgSpec with: from inspect import FullArgSpec Also see https://docs.python.org/3/whatsnew/changelog.html + https://docs.python.org/3/library/inspect.html#inspect.getfullargspec But given that v1.1.6 was released on 2015-05-15 and not updated within Debian since then, while upstream relased multiple stable versions like e.g. v2.3.0 on 2020-07-13, I'd understand your reasoning to drop this package at least for bookworm. :) HTH && regards -mika- signature.asc Description: PGP signature
Bug#1034609: Fails to start under Python 3.11
* Arto Jantunen [Wed Apr 19, 2023 at 07:49:33PM +0300]: > The package fails to import under Python 3.11 with the following traceback: > Traceback (most recent call last): [...] > File "/usr/lib/python3/dist-packages/sqlacodegen/main.py", line 10, in > > from sqlacodegen.codegen import CodeGenerator > File "/usr/lib/python3/dist-packages/sqlacodegen/codegen.py", line 4, in > > from inspect import ArgSpec > ImportError: cannot import name 'ArgSpec' from 'inspect' > (/usr/lib/python3.11/inspect.py) > > The issue seems to have been fixed in the latest release candidate, but that > isn't really suitable for bookworm during the freeze, so the intent of this > bug is to cause the package to be dropped from the release. If you don't want to maintain this package or its 1.1.6 version within bookworm then nevermind my comment :) - but looking at https://github.com/agronholm/sqlacodegen/issues/239#issuecomment-1457728533 the fix for this *might* be as simple as replacing: from inspect import ArgSpec with: from inspect import FullArgSpec Also see https://docs.python.org/3/whatsnew/changelog.html + https://docs.python.org/3/library/inspect.html#inspect.getfullargspec But given that v1.1.6 was released on 2015-05-15 and not updated within Debian since then, while upstream relased multiple stable versions like e.g. v2.3.0 on 2020-07-13, I'd understand your reasoning to drop this package at least for bookworm. :) HTH && regards -mika- signature.asc Description: PGP signature
Bug#1034398: ccze: Project homepage on github no longer exists / abandoned upstream?
Package: ccze Version: 0.2.1-7 Severity: normal Hi, https://github.com/madhouse/ccze throws a 404, maybe https://git.madhouse-project.org/archive/ccze is the proper place to refer to nowadays, but it looks like the project was abandoned / is unmaintained from upstream? regards -mika-
Bug#1034280: False positive "down" reports from IPv6addr "monitor" action
Package: resource-agents
Version: 1:4.12.0-1
Severity: important
Hi,
forwarding this from
https://github.com/ClusterLabs/resource-agents/issues/1855:
The "monitor" action of IPv6addr is sending an ICMPv6 echo request
to the given local address:
| resource-agents/heartbeat/IPv6addr.c
| Line 630 in d6b9548
| ret = sendto(icmp_sock, (char *)outpack, sizeof(outpack), 0,
and is then expecting to receive the respective echo response
immediately, without delay, using MSG_DONTWAIT:
| resource-agents/heartbeat/IPv6addr.c
| Line 647 in d6b9548
| ret = recvmsg(icmp_sock, , MSG_DONTWAIT);
This works fine most of the time, but occasionally under heavy
network load, the echo response is not immediately available, and
the recvmsg fails with EAGAIN, leading to a false positive down
event ("not running") on the resource:
| Mar 28 18:53:59 sp1 pacemaker-schedulerd[41843]: warning: Unexpected result
(not running) was recorded for monitor of p_vip_neth0_v6_1 on sp1 at Mar 28
00:02:38 2023
That problem is fixed by
https://github.com/ClusterLabs/resource-agents/pull/1858 which in
the meantime was accepted and merged by upstream already, though not
yet part of any new release.
Would it be possible to get this fix into the resource-agents
version in bullseye and/or bookworm (both are affected)?
I could provide the necessary changes as MR at salsa, if that would
help.
regards
-mika-
Bug#1034141: bpftrace: tcpconnect.bt, tcpdrop.bt,... depend on libc6-dev
Package: bpftrace Version: 0.17.0-1 Severity: normal Hi, for example tcpconnect.bt depends on libc6-dev: | # tcpconnect.bt | definitions.h:6:10: fatal error: 'sys/socket.h' file not found | | # apt install libc6-dev | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | The following additional packages will be installed: | libc-bin libc-dev-bin libc-l10n libc6 locales | Suggested packages: | glibc-doc libnss-nis libnss-nisplus manpages-dev | Recommended packages: | manpages manpages-dev libc-devtools | The following NEW packages will be installed: | libc6-dev | The following packages will be upgraded: | libc-bin libc-dev-bin libc-l10n libc6 locales | 5 upgraded, 1 newly installed, 0 to remove and 646 not upgraded. | Need to get 9,866 kB of archives. | After this operation, 12.2 MB of additional disk space will be used. | [...] | | # tcpconnect.bt | Attaching 2 probes... | Tracing tcp connections. Hit Ctrl-C to end. | [...] Same for tcpaccept.bt, tcpdrop.bt, tcplife.bt + tcpretrans.bt. So it might be worth adding libc6-dev to Suggests/Recommends? regards -mika-
Bug#1034139: bpftrace: Manual pages shipped as $tool.bt.bt.8.gz
Package: bpftrace Version: 0.17.0-1 Severity: normal Hi, all manual pages (except for the main bpftrace manual page itself) recently are shipped as /usr/share/man/man8/$TOOL.bt.bt.8.gz instead of /usr/share/man/man8/$tool.bt.8.gz: | % dpkg -L bpftrace | grep 'man.*bt.bt' | /usr/share/man/man8/bashreadline.bt.bt.8.gz | /usr/share/man/man8/biolatency.bt.bt.8.gz | /usr/share/man/man8/biosnoop.bt.bt.8.gz | /usr/share/man/man8/biostacks.bt.bt.8.gz | /usr/share/man/man8/bitesize.bt.bt.8.gz | /usr/share/man/man8/capable.bt.bt.8.gz | /usr/share/man/man8/cpuwalk.bt.bt.8.gz | /usr/share/man/man8/dcsnoop.bt.bt.8.gz | /usr/share/man/man8/execsnoop.bt.bt.8.gz | /usr/share/man/man8/gethostlatency.bt.bt.8.gz | /usr/share/man/man8/killsnoop.bt.bt.8.gz | /usr/share/man/man8/loads.bt.bt.8.gz | /usr/share/man/man8/mdflush.bt.bt.8.gz | /usr/share/man/man8/naptime.bt.bt.8.gz | /usr/share/man/man8/oomkill.bt.bt.8.gz | /usr/share/man/man8/opensnoop.bt.bt.8.gz | /usr/share/man/man8/pidpersec.bt.bt.8.gz | /usr/share/man/man8/runqlat.bt.bt.8.gz | /usr/share/man/man8/runqlen.bt.bt.8.gz | /usr/share/man/man8/setuids.bt.bt.8.gz | /usr/share/man/man8/ssllatency.bt.bt.8.gz | /usr/share/man/man8/sslsnoop.bt.bt.8.gz | /usr/share/man/man8/statsnoop.bt.bt.8.gz | /usr/share/man/man8/swapin.bt.bt.8.gz | /usr/share/man/man8/syncsnoop.bt.bt.8.gz | /usr/share/man/man8/syscount.bt.bt.8.gz | /usr/share/man/man8/tcpaccept.bt.bt.8.gz | /usr/share/man/man8/tcpconnect.bt.bt.8.gz | /usr/share/man/man8/tcpdrop.bt.bt.8.gz | /usr/share/man/man8/tcplife.bt.bt.8.gz | /usr/share/man/man8/tcpretrans.bt.bt.8.gz | /usr/share/man/man8/tcpsynbl.bt.bt.8.gz | /usr/share/man/man8/threadsnoop.bt.bt.8.gz | /usr/share/man/man8/undump.bt.bt.8.gz | /usr/share/man/man8/vfscount.bt.bt.8.gz | /usr/share/man/man8/vfsstat.bt.bt.8.gz | /usr/share/man/man8/writeback.bt.bt.8.gz | /usr/share/man/man8/xfsdist.bt.bt.8.gz Thanks for maintaining bpftrace! :) regards -mika-
Bug#1032029: mosquitto ignores ip address for websocket listeners
severity 1032029 normal
thanks
Hi,
I looked into this as it's the underlying reason for why a bunch of
packages are "flagged for removal" because of "buggy deps
mosquitto".
* Helmut Grohne [Sun Feb 26, 2023 at 08:37:13PM +0100]:
> If you configure a websocket listener for mosquitto with an IP address
> to bind to, mosquitto will instead bind the wildcard address. This
> renders a secure configuration insecure.
>
> A simple configuration producing this behaviour is a default
> installation together with one config update:
>
> $ cat /etc/mosquitto/conf.d/listen.conf
> bind_address localhost
> listener 9001 127.0.0.1
> protocol websockets
> $
>
> If you (re)start mosquitto, you can see the insecure bind:
>
> $ ss -tlp
> ...
> LISTEN0 4096 *:9001 *:*
>users:(("mosquitto",pid=269,fd=7))
> ...
> $
>
> The mosquitto.conf manual page in section 5 says that for websockets,
> you can only give an IP address as bind address, which kinda implies
> that you can given an IP address there. I think it is a reasonable
> expectation that binding to 127.0.0.1 should be secure.
With your configuration applied I see the following line in the logs:
| mosquitto[1750]: 1678096815: The 'bind_address' option is now deprecated and
will be removed in a future version. The behaviour will default to true.
Quoting from mosquitto.conf(5) (also see
https://mosquitto.org/man/mosquitto-conf-5.html):
|bind_address address
|
|This option is deprecated and will be removed in a future
|version. Use the listener instead.
|
|Listen for incoming network connections on the specified IP
|address/hostname only. This is useful to restrict access to
|certain network interfaces. To restrict access to mosquitto
|to the local host only, use "bind_address localhost". This
|only applies to the default listener. Use the listener option
|to control other listeners.
|
|It is recommended to use an explicit listener rather than
|rely on the implicit default listener options like this.
And indeed, with a configuration like follows:
| # cat /etc/mosquitto/conf.d/listen.conf
| listener 1883 127.0.0.1
| socket_domain ipv4
| protocol mqtt
|
| listener 9001 127.0.0.1
| socket_domain ipv4
| protocol websockets
... it behaves as documented/expected:
| # ss -tlpn | grep mosquitto
| LISTEN 0 4096 127.0.0.1:9001 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=8))
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=5))
Using *only* `bind_address localhost` inside
/etc/mosquitto/conf.d/listen.conf also makes the default listener to
be active on localhost only, as expected and documented:
| # ss -tlpn | grep mosquitto
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=2027,fd=5))
> I am filing this as severity serious, because normally a security
> vulnerability would be grave, but this vulnerability only surfaces in a
> (possibly common) non-default configuration. Hence lowering to serious.
IMO this isn't even a bug, so for now I downgraded the severity,
though if you agree I'd tend to close this bug report. (But I'm
neither the bug reporter nor the package maintainer, so leaving that
to either one of you :))
regards
-mika-
signature.asc
Description: PGP signature
Bug#1032029: mosquitto ignores ip address for websocket listeners
severity 1032029 normal
thanks
Hi,
I looked into this as it's the underlying reason for why a bunch of
packages are "flagged for removal" because of "buggy deps
mosquitto".
* Helmut Grohne [Sun Feb 26, 2023 at 08:37:13PM +0100]:
> If you configure a websocket listener for mosquitto with an IP address
> to bind to, mosquitto will instead bind the wildcard address. This
> renders a secure configuration insecure.
>
> A simple configuration producing this behaviour is a default
> installation together with one config update:
>
> $ cat /etc/mosquitto/conf.d/listen.conf
> bind_address localhost
> listener 9001 127.0.0.1
> protocol websockets
> $
>
> If you (re)start mosquitto, you can see the insecure bind:
>
> $ ss -tlp
> ...
> LISTEN0 4096 *:9001 *:*
>users:(("mosquitto",pid=269,fd=7))
> ...
> $
>
> The mosquitto.conf manual page in section 5 says that for websockets,
> you can only give an IP address as bind address, which kinda implies
> that you can given an IP address there. I think it is a reasonable
> expectation that binding to 127.0.0.1 should be secure.
With your configuration applied I see the following line in the logs:
| mosquitto[1750]: 1678096815: The 'bind_address' option is now deprecated and
will be removed in a future version. The behaviour will default to true.
Quoting from mosquitto.conf(5) (also see
https://mosquitto.org/man/mosquitto-conf-5.html):
|bind_address address
|
|This option is deprecated and will be removed in a future
|version. Use the listener instead.
|
|Listen for incoming network connections on the specified IP
|address/hostname only. This is useful to restrict access to
|certain network interfaces. To restrict access to mosquitto
|to the local host only, use "bind_address localhost". This
|only applies to the default listener. Use the listener option
|to control other listeners.
|
|It is recommended to use an explicit listener rather than
|rely on the implicit default listener options like this.
And indeed, with a configuration like follows:
| # cat /etc/mosquitto/conf.d/listen.conf
| listener 1883 127.0.0.1
| socket_domain ipv4
| protocol mqtt
|
| listener 9001 127.0.0.1
| socket_domain ipv4
| protocol websockets
... it behaves as documented/expected:
| # ss -tlpn | grep mosquitto
| LISTEN 0 4096 127.0.0.1:9001 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=8))
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=1994,fd=5))
Using *only* `bind_address localhost` inside
/etc/mosquitto/conf.d/listen.conf also makes the default listener to
be active on localhost only, as expected and documented:
| # ss -tlpn | grep mosquitto
| LISTEN 0 100127.0.0.1:1883 0.0.0.0:*
users:(("mosquitto",pid=2027,fd=5))
> I am filing this as severity serious, because normally a security
> vulnerability would be grave, but this vulnerability only surfaces in a
> (possibly common) non-default configuration. Hence lowering to serious.
IMO this isn't even a bug, so for now I downgraded the severity,
though if you agree I'd tend to close this bug report. (But I'm
neither the bug reporter nor the package maintainer, so leaving that
to either one of you :))
regards
-mika-
signature.asc
Description: PGP signature
Bug#1016288: pulseaudio-dlna: crashes on start
* Frank Loeffler [Mon Sep 05, 2022 at 04:01:55PM +0200]: > Package: pulseaudio-dlna > Version: 0.5.3+git20200329-0.1 > Followup-For: Bug #1016288 > > Dear Maintainer, > > A similar situation occurs on stable: [...] > Versions > 0.5.2 are available from here: > https://github.com/Cygn/pulseaudio-dlna . > > I am reporting this here even though the previous report was for > unstable because quite likely versions of dependencies are the problem > in both cases and similar fixes/updates could be made in both cases. > > Without any change, this package is quite unuseable also on Debian > stable, so 'grave' seems to be the correct severity. Due to this bug pulseaudio-dlna didn't migrate to Debian/testing and therefore won't be shipped with the upcoming Debian/stable release AKA bookworm. In the meanwhile version 0.6.6-1 got released by upstream, see https://github.com/Cygn/pulseaudio-dlna/releases/tag/pulseaudio-dlna-0.6.6-1 It looks like this issue might be related to https://github.com/home-assistant-libs/pychromecast/pull/556 so if this issue should still be present then the version of python3-pychromecast might not fit. Briefly looking at https://github.com/Cygn/pulseaudio-dlna/commits/master it looks like it nowadays depends on pychromecast v10 which is available as python3-pychromecast in Debian/experimental. Might make sense to clarify the situation and ensure that it's at least working Debian/unstable again (and could possibly be backported in the future to bookworm then)? Muammar, are you still maintaining this package? regards -mika- signature.asc Description: PGP signature
Bug#1016288: pulseaudio-dlna: crashes on start
* Frank Loeffler [Mon Sep 05, 2022 at 04:01:55PM +0200]: > Package: pulseaudio-dlna > Version: 0.5.3+git20200329-0.1 > Followup-For: Bug #1016288 > > Dear Maintainer, > > A similar situation occurs on stable: [...] > Versions > 0.5.2 are available from here: > https://github.com/Cygn/pulseaudio-dlna . > > I am reporting this here even though the previous report was for > unstable because quite likely versions of dependencies are the problem > in both cases and similar fixes/updates could be made in both cases. > > Without any change, this package is quite unuseable also on Debian > stable, so 'grave' seems to be the correct severity. Due to this bug pulseaudio-dlna didn't migrate to Debian/testing and therefore won't be shipped with the upcoming Debian/stable release AKA bookworm. In the meanwhile version 0.6.6-1 got released by upstream, see https://github.com/Cygn/pulseaudio-dlna/releases/tag/pulseaudio-dlna-0.6.6-1 It looks like this issue might be related to https://github.com/home-assistant-libs/pychromecast/pull/556 so if this issue should still be present then the version of python3-pychromecast might not fit. Briefly looking at https://github.com/Cygn/pulseaudio-dlna/commits/master it looks like it nowadays depends on pychromecast v10 which is available as python3-pychromecast in Debian/experimental. Might make sense to clarify the situation and ensure that it's at least working Debian/unstable again (and could possibly be backported in the future to bookworm then)? Muammar, are you still maintaining this package? regards -mika- signature.asc Description: PGP signature
Re: MariaDB 10.11 in Bookworm - call for contributions
* Thomas Goirand [Fri Feb 24, 2023 at 04:00:43PM +0100]: > On 2/23/23 17:22, Otto Kekäläinen wrote: > > I am currently preparing the upload of MariaDB 10.11.2-2 to Debian > > unstable and aim for the highest possible quality. I am currently > > doing the bulk of the testing and packaging alone and to make sure > > that the quality is top notch, I would be glad to see more people > > contribute. [...] > Another issue, > My package depends on default-mysql-server, which doesn't pull > mariadb-server 10.11, but 10.6. As a result, I can't install both... :/ > Can this be fixed? This is #1029092 and Otto just marked the blocking bug as resolved (thanks Otto!), so this should hopefully be fixed soon: | % grep-excuses mysql-defaults | mysql-defaults (1.0.8 to 1.1.0) | Maintainer: Debian MySQL Maintainers | Migration status for mysql-defaults (1.0.8 to 1.1.0): BLOCKED: Rejected/violates migration policy/introduces a regression | Issues preventing migration: | ∙ ∙ Updating mysql-defaults would introduce bugs in testing: #1029092 | Additional info: | ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/m/mysql-defaults.html | ∙ ∙ 38 days old (needed 10 days) regards -mika- signature.asc Description: PGP signature
Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early
Hi! * Otto Kekäläinen [Thu Feb 23, 2023 at 08:24:47AM -0800]: > > Paul Gevers [Thu, 23 Feb 2023 17:13:25 +0100]: > > > This severity 'serious' bug should prevent the migration > > > automatically. Close this bug when migration is free to proceed. > > I believe this has happened now. Do you think it should solve that issue > > I was seeing? > Potentially, but I need more info. > > This mysql-defaults definitely needs to migrate for the full > repository view to be correct/complete. I was planning to do it 1-2 > days after mariadb has migrated. Is anything missing yet, or is there anything we could help with? Because currently bookworm is broken due #1029092 blocking migration of the mysql-defaults packages to bookworm (while mariadb-client/mariadb-server packages are fine AFAICT), FTR: | # apt install mariadb-server mariadb-client default-mysql-client default-mysql-server | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | default-mysql-client : Depends: mariadb-client-10.6 but it is not installable | default-mysql-server : Depends: mariadb-server-10.6 but it is not installable | E: Unable to correct problems, you have held broken packages. | | # apt install mariadb-server mariadb-client default-mysql-client default-mysql-server mariadb-client-10.6 mariadb-server-10.6 | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | mariadb-client : Conflicts: virtual-mysql-client | Breaks: mariadb-client-10.6 but 1:10.6.11-2 is to be installed | Breaks: mariadb-server-10.6 but 1:10.6.11-2 is to be installed | mariadb-client-10.6 : Depends: mariadb-client-core-10.6 (>= 1:10.6.11-2) but it is not installable |Conflicts: virtual-mysql-client | mariadb-server : Conflicts: virtual-mysql-server | Breaks: mariadb-server-10.6 but 1:10.6.11-2 is to be installed | mariadb-server-10.6 : Depends: mariadb-server-core-10.6 (>= 1:10.6.11-2) but it is not installable |Conflicts: virtual-mysql-server | E: Unable to correct problems, you have held broken packages. regards -mika- signature.asc Description: PGP signature
Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early
Hi! * Otto Kekäläinen [Thu Feb 23, 2023 at 08:24:47AM -0800]: > > Paul Gevers [Thu, 23 Feb 2023 17:13:25 +0100]: > > > This severity 'serious' bug should prevent the migration > > > automatically. Close this bug when migration is free to proceed. > > I believe this has happened now. Do you think it should solve that issue > > I was seeing? > Potentially, but I need more info. > > This mysql-defaults definitely needs to migrate for the full > repository view to be correct/complete. I was planning to do it 1-2 > days after mariadb has migrated. Is anything missing yet, or is there anything we could help with? Because currently bookworm is broken due #1029092 blocking migration of the mysql-defaults packages to bookworm (while mariadb-client/mariadb-server packages are fine AFAICT), FTR: | # apt install mariadb-server mariadb-client default-mysql-client default-mysql-server | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | default-mysql-client : Depends: mariadb-client-10.6 but it is not installable | default-mysql-server : Depends: mariadb-server-10.6 but it is not installable | E: Unable to correct problems, you have held broken packages. | | # apt install mariadb-server mariadb-client default-mysql-client default-mysql-server mariadb-client-10.6 mariadb-server-10.6 | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | mariadb-client : Conflicts: virtual-mysql-client | Breaks: mariadb-client-10.6 but 1:10.6.11-2 is to be installed | Breaks: mariadb-server-10.6 but 1:10.6.11-2 is to be installed | mariadb-client-10.6 : Depends: mariadb-client-core-10.6 (>= 1:10.6.11-2) but it is not installable |Conflicts: virtual-mysql-client | mariadb-server : Conflicts: virtual-mysql-server | Breaks: mariadb-server-10.6 but 1:10.6.11-2 is to be installed | mariadb-server-10.6 : Depends: mariadb-server-core-10.6 (>= 1:10.6.11-2) but it is not installable |Conflicts: virtual-mysql-server | E: Unable to correct problems, you have held broken packages. regards -mika- signature.asc Description: PGP signature
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
* Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]: > On 2023-02-15 13:17:38 -0700, Sam Hartman wrote: > > But for example you're not leaving a lot of time for asking programs > > like vmdb2 or fai-diskimage to adjust how they call fsck. > > If you made this change a few months ago, it would be reasonable to file > > bugs against those packages and ask them to adjust how they call > > mkfs.ext4. > To better understand the impact of this change, I was wondering which > tools / image builders in the archive would be affected by this change. > I've cloned the bug to vmdb2, but what about others? I didn't verify it yet, but AFAICT grml-debootstrap is affected as well, since it supports installing older Debian releases from within more recent Debian/Grml environments and uses mkfs.ext4 as default. BTW, we had a similar situation already in the past when mkfs.ext4 of e2fsprogs >=1.43~WIP.2015.05.18-1 enabled the "metadata_csum" feature, while this was unsupported on jessie and older releases. (grml-debootstrap provides a workaround for this.) regards -mika- signature.asc Description: PGP signature
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
* Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]: > On 2023-02-15 13:17:38 -0700, Sam Hartman wrote: > > But for example you're not leaving a lot of time for asking programs > > like vmdb2 or fai-diskimage to adjust how they call fsck. > > If you made this change a few months ago, it would be reasonable to file > > bugs against those packages and ask them to adjust how they call > > mkfs.ext4. > To better understand the impact of this change, I was wondering which > tools / image builders in the archive would be affected by this change. > I've cloned the bug to vmdb2, but what about others? I didn't verify it yet, but AFAICT grml-debootstrap is affected as well, since it supports installing older Debian releases from within more recent Debian/Grml environments and uses mkfs.ext4 as default. BTW, we had a similar situation already in the past when mkfs.ext4 of e2fsprogs >=1.43~WIP.2015.05.18-1 enabled the "metadata_csum" feature, while this was unsupported on jessie and older releases. (grml-debootstrap provides a workaround for this.) regards -mika- signature.asc Description: PGP signature
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
* Sebastian Ramacher [Thu Feb 16, 2023 at 09:09:08AM +0100]: > On 2023-02-15 13:17:38 -0700, Sam Hartman wrote: > > But for example you're not leaving a lot of time for asking programs > > like vmdb2 or fai-diskimage to adjust how they call fsck. > > If you made this change a few months ago, it would be reasonable to file > > bugs against those packages and ask them to adjust how they call > > mkfs.ext4. > To better understand the impact of this change, I was wondering which > tools / image builders in the archive would be affected by this change. > I've cloned the bug to vmdb2, but what about others? I didn't verify it yet, but AFAICT grml-debootstrap is affected as well, since it supports installing older Debian releases from within more recent Debian/Grml environments and uses mkfs.ext4 as default. BTW, we had a similar situation already in the past when mkfs.ext4 of e2fsprogs >=1.43~WIP.2015.05.18-1 enabled the "metadata_csum" feature, while this was unsupported on jessie and older releases. (grml-debootstrap provides a workaround for this.) regards -mika- signature.asc Description: PGP signature
Bug#1030227: rtpengine: please use dkms packaging helpers
Hi! * Andreas Beckmann [Wed Feb 01, 2023 at 12:19:40PM +0100]: > src:rtpengine is the only package in the archive the builds a -dkms > package without using the dkms packaging helpers. > Please switch to dh-sequence-dkms instead of using handcrafted code, > a patch doing this is attached. > This also enables the dkms autopkgtest for this package, s.t. building > the kernel module is tested whenever a new kernel version gets uploaded. Thanks for both the bug report and the PR! This is pending code review internally at upstream already, and I've also prepared the according change at https://salsa.debian.org/pkg-voip-team/rtpengine/-/merge_requests/1 for review by pkg-voip-team, specifically Victor Seva. regards -mika- signature.asc Description: PGP signature
Re: [ovs-discuss] ovsdb-idl: concurrency / race condition with IDL split into two layers?
Hi!
* Ilya Maximets [Thu Feb 09, 2023 at 09:44:41PM +0100]:
> On 1/31/23 16:37, Michael Prokop via discuss wrote:
> > On a Proxmox VE cluster using openvswitch v2.15.0 (as present in
> > Debian/bullseye[1]) we ran into a serious problem: after the
> > openvswitch-switch/ovs-vswitchd service restart the OVS bridge lost
> > its IP address and the interface stayed down.
> >
> > As it turned out this issue got already fixed by Ilya Maximets with
> > https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86
> > ("ovsdb-idl: Fix the database update signaling if it has never been
> > connected.")
> >
> > What was special about this issue for us is that we noticed
> > the problem *only* on multi-CPU systems (systems with >=2 CPUs).
> > Furthermore the issue didn't show up on any of our systems running
> > with Intel CPUs, but only on systems running with AMD CPUs. :)
> >
> > I'm curious, is this related to a concurrency/race condition?
> > And I'd like to understand whether this Intel vs. AMD behavior is
> > only coincidence related to different kernel/userland/libdpdk/...
> > environments, or if that could really show up as vendor specific
> > behavior as we saw it? :)
> Hi. I don't think it's vendor-specific. There is nothing really
> vendor-specific here. There might be a slight race window, IIRC,
> i.e. how many main loop iterations ovs-vswitchd does before getting
> database updates, so the number of CPU cores (1 vs 2) may play
> some role. But even that is unlikely. In general, you should be
> able to reproduce the issue on any system.
I see, we'll keep an eye on it, thanks for your feedback and
estimation, Ilya - much appreciated!
regards
-mika-
signature.asc
Description: PGP signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Bug#1030113: bullseye-pu: package openvswitch/2.15.0+ds1-2+deb11u2
* Thomas Goirand [Tue Jan 31, 2023 at 09:26:16AM +0100]: > We would like to fix https://bugs.debian.org/1008684. > Michael Prokop found the matching patch, and we would like to > apply it to Bullseye. > > [ Reason ] > As per #1008684, restarting OVS in Bullseye makes the computer > loose network. [...] > [ Changes ] > * Just the patch as per: > https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86 I hereby confirm that this patch fixes the issue. We've verified this several times and I would like to express my urge and +1 to get this fixed in bullseye. I'm aware of several users who also ran into this problem already. Thanks Thomas for taking care of the upload! regards -mika- signature.asc Description: PGP signature
Bug#1030113: bullseye-pu: package openvswitch/2.15.0+ds1-2+deb11u2
* Thomas Goirand [Tue Jan 31, 2023 at 09:26:16AM +0100]: > We would like to fix https://bugs.debian.org/1008684. > Michael Prokop found the matching patch, and we would like to > apply it to Bullseye. > > [ Reason ] > As per #1008684, restarting OVS in Bullseye makes the computer > loose network. [...] > [ Changes ] > * Just the patch as per: > https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86 I hereby confirm that this patch fixes the issue. We've verified this several times and I would like to express my urge and +1 to get this fixed in bullseye. I'm aware of several users who also ran into this problem already. Thanks Thomas for taking care of the upload! regards -mika- signature.asc Description: PGP signature
[ovs-discuss] ovsdb-idl: concurrency / race condition with IDL split into two layers?
Hi!
On a Proxmox VE cluster using openvswitch v2.15.0 (as present in
Debian/bullseye[1]) we ran into a serious problem: after the
openvswitch-switch/ovs-vswitchd service restart the OVS bridge lost
its IP address and the interface stayed down.
As it turned out this issue got already fixed by Ilya Maximets with
https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86
("ovsdb-idl: Fix the database update signaling if it has never been connected.")
What was special about this issue for us is that we noticed
the problem *only* on multi-CPU systems (systems with >=2 CPUs).
Furthermore the issue didn't show up on any of our systems running
with Intel CPUs, but only on systems running with AMD CPUs. :)
I'm curious, is this related to a concurrency/race condition?
And I'd like to understand whether this Intel vs. AMD behavior is
only coincidence related to different kernel/userland/libdpdk/...
environments, or if that could really show up as vendor specific
behavior as we saw it? :)
Thanks!
[1] We reported this also towards Debian, full details at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008684#52 and a
fixed openvswitch package is on its way towards Debian/bullseye now,
see https://bugs.debian.org/1030113).
regards
-mika-
signature.asc
Description: PGP signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Bug#1029768: fence-agents: Broken python library due to incomplete --plug-separator support
Package: fence-agents
Version: 4.12.0-1
Severity: important
Hi,
the 4.12.0 release includes a broken python library,
caused by an incomplete change in PR
https://github.com/ClusterLabs/fence-agents/pull/514
This causes major problems for any fence users of the python library,
due to:
| def fence_action(connection, options, set_power_fn, get_power_fn,
get_outlet_list=None, reboot_cycle_fn=None, sync_set_power_fn=None):
| result = 0
|
| try:
| if "--plug" in options:
| options["--plugs"] =
options["--plug"].split(options["--plug-separator"])
… resulting in:
| pacemaker-fenced[39541] (log_op_output) […] error output [ Traceback
(most recent call last): ]
| pacemaker-fenced[39541] (log_op_output) […] error output [ File
"/usr/sbin/fence_ngcp", line 56, in ]
| pacemaker-fenced[39541] (log_op_output) […] error output [ main()
]
| pacemaker-fenced[39541] (log_op_output) […] error output [ File
"/usr/sbin/fence_ngcp", line 49, in main ]
| pacemaker-fenced[39541] (log_op_output) […] error output [ result
= fence_action( ]
| pacemaker-fenced[39541] (log_op_output) […] error output [ File
"/usr/share/fence/fencing.py", line 944, in fence_action ]
| pacemaker-fenced[39541] (log_op_output) […] error output [
options["--plugs"] = options["--plug"].split(options["--plug-separator"]) ]
| pacemaker-fenced[39541] (log_op_output) […] error output [ KeyError:
'--plug-separator' ]
The new v4.12.1 release includes the corresponding fix for this:
| commit 0f280ea4a299037a7d4e99d80b0193fd6fcdbd79
| Author: Oyvind Albrigtsen
| Date: Tue Jan 24 12:19:41 2023 +0100
|
| fencing: add plug_separator to default DEPENDENCY_OPT
|
| diff --git lib/fencing.py.py lib/fencing.py.py
| index cf1c48e7..c5b5e94a 100644
| --- lib/fencing.py.py
| +++ lib/fencing.py.py
| @@ -494,7 +494,7 @@ DEPENDENCY_OPT = {
| "version", "action",
"agent", "power_timeout",
| "shell_timeout",
"login_timeout", "disable_timeout",
| "power_wait",
"stonith_status_sleep", "retry_on", "delay",
| -"quiet"],
| +"plug_separator", "quiet"],
| "passwd" : ["passwd_script"],
| "sudo" : ["sudo_path"],
| "secure" : ["identity_file", "ssh_options",
"ssh_path", "inet4_only", "inet6_only"],
| [...]
Please let's make sure that v4.12.1 ends up in bookworm. :)
regards
-mika-
Bug#1008684: openvswitch-switch update leaves interfaces down
idges and
ports, but IP addresses can not be restored.
.
While splitting out ovsdb-cs from ovsdb-idl one part of the logic
was lost. Particularly, before the split, ovsdb-idl updated
change_seqno only in MONITORING state.
.
Restoring the logic by updating the change_seqno only if may send
transaction, i.e. lock is ours and ovsdb-cs is in the MONITORING
state. This matches with the main purpose of increasing change_seqno
at this point, i.e. to force the client to re-try the transaction.
With this change ovsdb_idl_has_ever_connected() remains 'false'
until the first monitor reply with the actual data received.
.
This issue was reported several times during the last couple of weeks.
.
Reported-at: https://bugzilla.redhat.com/1968445
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383512.html
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2021-June/051222.html
Fixes: 1c337c43ac1c ("ovsdb-idl: Break into two layers.")
Signed-off-by: Ilya Maximets
Acked-by: Dumitru Ceara
Author: Ilya Maximets
Date: Tue, 8 Jun 2021 15:17:23 +0200
Origin: upstream, https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86.patch
Applied-Upstream: 2.15.1
Bug-Debian: https://bugs.debian.org/1008684
Last-Update: 2023-01-26
---
lib/ovsdb-idl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git lib/ovsdb-idl.c lib/ovsdb-idl.c
index 2c8a0c9..6241fb4 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -401,9 +401,15 @@ ovsdb_idl_run(struct ovsdb_idl *idl)
break;
case OVSDB_CS_EVENT_TYPE_LOCKED:
-/* If the client couldn't run a transaction because it didn't have
- * the lock, this will encourage it to try again. */
-idl->change_seqno++;
+if (ovsdb_cs_may_send_transaction(idl->cs)) {
+/* If the client couldn't run a transaction because it didn't
+ * have the lock, this will encourage it to try again. */
+idl->change_seqno++;
+} else {
+/* We're setting up a session, so don't signal that the
+ * database changed. Finalizing the session will increment
+ * change_seqno anyhow. */
+}
break;
case OVSDB_CS_EVENT_TYPE_UPDATE:
--
2.30.2
diff -Nru openvswitch-2.15.0+ds1/debian/changelog
openvswitch-2.15.0+ds1/debian/changelog
--- openvswitch-2.15.0+ds1/debian/changelog 2022-10-03 12:59:27.0
+0200
+++ openvswitch-2.15.0+ds1/debian/changelog 2023-01-26 17:17:41.0
+0100
@@ -1,3 +1,12 @@
+openvswitch (2.15.0+ds1-2+deb11u3) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply upstream fix
+ https://github.com/openvswitch/ovs/commit/bc0aa785a83c1
+(Closes: #1008684)
+
+ -- Michael Prokop Thu, 26 Jan 2023 17:17:41 +0100
+
openvswitch (2.15.0+ds1-2+deb11u2) bullseye-security; urgency=medium
* Fix ovs-dpctl-top by removing 3 wrong hunks in py3-compat.patch.
diff -Nru
openvswitch-2.15.0+ds1/debian/patches/fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch
openvswitch-2.15.0+ds1/debian/patches/fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch
---
openvswitch-2.15.0+ds1/debian/patches/fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch
1970-01-01 01:00:00.0 +0100
+++
openvswitch-2.15.0+ds1/debian/patches/fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch
2023-01-26 17:17:30.0 +0100
@@ -0,0 +1,102 @@
+From: Ilya Maximets
+Subject: ovsdb-idl: Fix the database update signaling if it has never been
connected
+ The symptom of this issue is that OVS bridge looses its IP address on
+ restart.
+ .
+ Simple reproducer:
+ 0. start ovsdb-server and ovs-vswitchd
+ 1. ovs-vsctl add-br br0
+ 2. ifconfig br0 10.0.0.1 up
+ 3. ovs-appctl -t ovs-vswitchd exit
+ 4. start ovs-vswitchd back.
+ .
+ After step #3 ovs-vswitchd is down, but br0 interface exists and
+ has configured IP address. After step #4 there is no IP address
+ on the port br0.
+ .
+ What happened:
+ 1. ovsdb-cs connects to the database via ovsdb-idl and requests
+ database lock.
+ --> get_schema for _Server database
+ --> lock request
+ .
+ 2. ovsdb-cs receives schema for the _Server database. And sends
+ monitor request.
+ <-- schema for _Server
+ --> monitor_cond for _Server
+ .
+ 3. ovsdb-cs receives lock reply.
+ <-- locked
+ At this point ovsdb-cs generates OVSDB_CS_EVENT_TYPE_LOCKED
+ event and passes it to ovsdb-idl. ovsdb-idl increases change_seqno.
+ .
+ 4. ovsdb_idl_has_ever_connected() is 'true' now, because change_seqno
+ is not zero.
+ .
+ 5. ovs-vswitchd decides that it has connection with database and
+ all the initial data,
Bug#1029149: openvswitch-switch: openvswitch-switch systemd unit file relies on non-existing script
Package: openvswitch-switch
Version: 2.15.0+ds1-2+deb11u2
Severity: important
Hi,
with the update to openvswitch v2.15.0+ds1-2+deb11u2 we also ran
into the same situation that's reported as #1008684
("openvswitch-switch update leaves interfaces down").
While debugging this we stumbled upon this:
| % systemctl cat openvswitch-switch
| # /lib/systemd/system/openvswitch-switch.service
| [Unit]
| Description=Open vSwitch
| Before=network.target
| After=network-pre.target ovsdb-server.service ovs-vswitchd.service
| PartOf=network.target
| Requires=ovsdb-server.service
| Requires=ovs-vswitchd.service
|
| [Service]
| Type=oneshot
| ExecStart=/bin/true
| ExecReload=/usr/share/openvswitch/scripts/ovs-systemd-reload
| ExecStop=/bin/true
| RemainAfterExit=yes
|
| [Install]
| WantedBy=multi-user.target
But /usr/share/openvswitch/scripts/ovs-systemd-reload doesn't exist
in that package:
| % ls -la /usr/share/openvswitch/scripts/ovs-systemd-reload
| ls: cannot access '/usr/share/openvswitch/scripts/ovs-systemd-reload': No
such file or directory
And of course a "systemctl reload openvswitch-switch" therefor fails:
| Jan 18 15:36:29 36cad9a1a6cc systemd[3685]: openvswitch-switch.service:
Failed to locate executable /usr/share/openvswitch/scripts/ovs-systemd-reload:
No such file or directory
| Jan 18 15:36:29 36cad9a1a6cc systemd[3685]: openvswitch-switch.service:
Failed at step EXEC spawning /usr/share/openvswitch/scripts/ovs-systemd-reload:
No such file or directory
| Jan 18 15:36:29 36cad9a1a6cc systemd[1]: openvswitch-switch.service: Control
process exited, code=exited, status=203/EXEC
FTR, the script is part of the openvswitch-switch package
v3.1.0~git20230108.006e1c6-1 as present in current unstable and
bookworm, but the version in bullseye/stable is broken.
regards
-mika-
Bug#1027270: guymager doesn't require libprocps
Hi Craig, * Craig Small [Sat Dec 31, 2022 at 04:47:36PM +1100]: > I checked the build logs, the source code and even the current binary > packages. guymager does not need libprocps. > A simple removal of libprocps-dev from debian/control is all that is needed. Indeed, thanks for checking, appreciated! I just uploaded guymager v0.8.13-2 which takes care of this. regards -mika- signature.asc Description: PGP signature
Bug#1027270: guymager doesn't require libprocps
Hi Craig, * Craig Small [Sat Dec 31, 2022 at 04:47:36PM +1100]: > I checked the build logs, the source code and even the current binary > packages. guymager does not need libprocps. > A simple removal of libprocps-dev from debian/control is all that is needed. Indeed, thanks for checking, appreciated! I just uploaded guymager v0.8.13-2 which takes care of this. regards -mika- signature.asc Description: PGP signature
Bug#1007954: [debian-mysql] Bug#1007954: galera-4 FTBFS on IPV6-only buildds
[Looked briefly into this, since this is a RC bug] * Otto Kekäläinen [Sat Mar 19, 2022 at 09:04:21AM -0700]: > Thanks for looking into this. Can you elaborate why you filed this on > 26.4.8 and not latest 26.4.10? > > Builds are passing. Thus tests indicate that there is no issue. What is the > broken thing exactly and since tests are passing, how will we verify that > the broken thing is fixed or still broken? The problems seems to to present also in version 26.4.11-1+b1: | Running suite(s): gu::asio | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | 94%: Checks: 77, Failures: 0, Errors: 4 | ./galerautils/tests/gu_asio_test.cpp:1811:E:test_datagram_open:test_datagram_open:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1820:E:test_datagram_connect:test_datagram_connect:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1829:E:test_datagram_open_connect:test_datagram_open_connect:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1894:E:test_datagram_send_to_and_async_read:test_datagram_send_to_and_async_read:0: (after this point) Received signal 6 (Aborted) | Running suite(s): gu::DeqMap | 100%: Checks: 11, Failures: 0, Errors: 0 | Total tests failed: 4 -- https://buildd.debian.org/status/fetch.php?pkg=galera-4=amd64=26.4.11-1%2Bb1=1652901726=0 Looking at https://buildd.debian.org/status/logs.php?pkg=galera-4=amd64 it seems to be failing always at the x86-conova-01 builders, which means that it seems to be environment specific. AFAICS x86-conova-01 is IPv6 only, and this is also what "FTBFS on IPV6-only buildds" in the original bug report was about. Possibly useful for further information/reproducing: * https://lists.debian.org/debian-devel/2020/07/msg00070.html * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740 HTH && regards -mika- signature.asc Description: PGP signature
Bug#1007954: [debian-mysql] Bug#1007954: galera-4 FTBFS on IPV6-only buildds
[Looked briefly into this, since this is a RC bug] * Otto Kekäläinen [Sat Mar 19, 2022 at 09:04:21AM -0700]: > Thanks for looking into this. Can you elaborate why you filed this on > 26.4.8 and not latest 26.4.10? > > Builds are passing. Thus tests indicate that there is no issue. What is the > broken thing exactly and since tests are passing, how will we verify that > the broken thing is fixed or still broken? The problems seems to to present also in version 26.4.11-1+b1: | Running suite(s): gu::asio | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | terminate called after throwing an instance of 'gu::Exception' | what(): error opening datagram socketudp://127.0.0.1:0: 1 (Operation not permitted) | at ./galerautils/src/gu_asio_datagram.cpp:resolve_and_open():107 | 94%: Checks: 77, Failures: 0, Errors: 4 | ./galerautils/tests/gu_asio_test.cpp:1811:E:test_datagram_open:test_datagram_open:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1820:E:test_datagram_connect:test_datagram_connect:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1829:E:test_datagram_open_connect:test_datagram_open_connect:0: (after this point) Received signal 6 (Aborted) | ./galerautils/tests/gu_asio_test.cpp:1894:E:test_datagram_send_to_and_async_read:test_datagram_send_to_and_async_read:0: (after this point) Received signal 6 (Aborted) | Running suite(s): gu::DeqMap | 100%: Checks: 11, Failures: 0, Errors: 0 | Total tests failed: 4 -- https://buildd.debian.org/status/fetch.php?pkg=galera-4=amd64=26.4.11-1%2Bb1=1652901726=0 Looking at https://buildd.debian.org/status/logs.php?pkg=galera-4=amd64 it seems to be failing always at the x86-conova-01 builders, which means that it seems to be environment specific. AFAICS x86-conova-01 is IPv6 only, and this is also what "FTBFS on IPV6-only buildds" in the original bug report was about. Possibly useful for further information/reproducing: * https://lists.debian.org/debian-devel/2020/07/msg00070.html * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740 HTH && regards -mika- signature.asc Description: PGP signature
Bug#1026822: dkms: dkms status reporting wrong information as of v3.0.9
Package: dkms Version: 3.0.9-1 Severity: important Hi, this seems to be a regression introduced with v3.0.9: | # dkms --version | dkms-3.0.8 | # dkms status | ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc, 6.0.0-6-amd64, x86_64: installed vs: | # dkms --version | dkms-3.0.9 | # dkms status | ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc, 6.0.0-6-amd64, x86_64: installed (WARNING! Diff between built and installed module!) Executing `dkms status` under `bash -x` shows: | [...] | ++ compare_module_version /var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | ++ for l in $locations | +++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64/extra xt_RTPENGINE | +++ local test1=/lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko | +++ local test2=/lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko | +++ [[ -e /lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko ]] | +++ [[ -e /lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko ]] | ++ installed= | ++ [[ -n '' ]] | + real_dest= | ++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64 xt_RTPENGINE | ++ local test1=/lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko | ++ local test2=/lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko | ++ [[ -e /lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko ]] | ++ [[ -e /lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko ]] | + real_dest_mod= | + diff -q /var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko '' | + echo -n ' (WARNING! Diff between built and installed module!)' | (WARNING! Diff between built and installed module!)+ (( count++ )) | + (( count < 1 )) | + echo | [...] Note the `diff -q /var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko ''` which clearly is wrong and can't work as-is, while the underlying modules are identical: | # md5sum /var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | 73c0b2503d9981d64df89aa9aadefd68 /var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko | 73c0b2503d9981d64df89aa9aadefd68 /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko When running `dkms status` under `bash -x` with dkms v3.0.8 it's fine: | ++ diff /var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | ++ echo /updates/dkms | ++ return 0 | + real_dest=/updates/dkms | ++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64/updates/dkms xt_RTPENGINE | ++ local test1=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | ++ local test2=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | ++ [[ -e /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko ]] | ++ echo /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | + real_dest_mod=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | + diff -q /var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko | + (( count++ )) | + (( count < 1 )) So something about setting the $real_dest_mod seems to have been broken with latest version. regards -mika-
Bug#1026353: mariadb-server: mariadb does not start after bullseye point release 11.6
* Matt Zagrabelny [Mon Dec 19, 2022 at 08:51:07AM -0600]: > On Mon, Dec 19, 2022 at 4:02 AM Michael Prokop wrote: > > * Matthew P Zagrabelny [Sun Dec 18, 2022 at 04:11:54PM -0600]: > > Same here, check whether you have any non-existent SSL keys or alike > > referenced in your configuration, like: > > > > | [mysqld] > > | [...] > > | ssl = false > > | ssl-ca = /etc/mysql/cacert.pem > > | ssl-cert = /etc/mysql/server-cert.pem > > | ssl-key = /etc/mysql/server-key.pem > > | [...] > > > > So while it was even set to `ssl = false` on this system, it now > > fails with: > > > > | 2022-12-19 10:33:24 0 [ERROR] Failed to setup SSL > > | 2022-12-19 10:33:24 0 [ERROR] SSL error: > > SSL_CTX_set_default_verify_paths failed > > | 2022-12-19 10:33:24 0 [ERROR] Aborting > > > > (FTR, removing the ssl-ca/ssl-cert/ssl-key settings fixed it for me, > > those settings came from defaults of > > https://github.com/puppetlabs/puppetlabs-mysql so I'm sure more > > folks will be affected.) > > Exactly. We're using that module. A potential fix is to set: > > 'ssl-disable' => true > > in the puppet manifest, but that generates spurious warnings and mysqld > refreshes: > > # puppet agent -t [...] > So... I'm not sure what the best way forward is. [...] See e.g. https://github.com/puppetlabs/puppetlabs-mysql/issues/1509, so make sure to update to latest https://github.com/puppetlabs/puppetlabs-mysql, which also includes https://github.com/puppetlabs/puppetlabs-mysql/pull/1513 and takes care of this, at least to get a working default again. (While I still think that a stable update shouldn't include such a behavior change. :)) HTH && regards -mika- signature.asc Description: PGP signature
Bug#1026353: mariadb-server: mariadb does not start after bullseye point release 11.6
* Matthew P Zagrabelny [Sun Dec 18, 2022 at 04:11:54PM -0600]: > Package: mariadb-server > Version: 1:10.5.18-0+deb11u1 > Severity: important > > Unattended upgrade upgraded mariadb this morning and now the service does not > start: > [...] > Dec 18 15:25:36 mariadb-test-system systemd[1]: Starting MariaDB 10.5.18 > database server... > Dec 18 15:25:37 mariadb-test-system mariadbd[604]: 2022-12-18 15:25:37 0 > [Note] /usr/sbin/mariadbd (mysqld 10.5.18-MariaDB-0+deb11u1) starting as > process 604 ... > Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Main process > exited, code=exited, status=1/FAILURE > Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Failed with > result 'exit-code'. > Dec 18 15:25:38 mariadb-test-system systemd[1]: Failed to start MariaDB > 10.5.18 database server. Same here, check whether you have any non-existent SSL keys or alike referenced in your configuration, like: | [mysqld] | [...] | ssl = false | ssl-ca = /etc/mysql/cacert.pem | ssl-cert = /etc/mysql/server-cert.pem | ssl-key = /etc/mysql/server-key.pem | [...] So while it was even set to `ssl = false` on this system, it now fails with: | 2022-12-19 10:33:24 0 [ERROR] Failed to setup SSL | 2022-12-19 10:33:24 0 [ERROR] SSL error: SSL_CTX_set_default_verify_paths failed | 2022-12-19 10:33:24 0 [ERROR] Aborting (FTR, removing the ssl-ca/ssl-cert/ssl-key settings fixed it for me, those settings came from defaults of https://github.com/puppetlabs/puppetlabs-mysql so I'm sure more folks will be affected.) This used to be a warning only until and including mariadb version 1:10.5.15-0+deb11u1: | 2022-11-22 7:42:46 0 [Warning] Failed to setup SSL | 2022-11-22 7:42:46 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed | 2022-11-22 7:42:46 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory | 2022-11-22 7:42:46 0 [Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file | 2022-11-22 7:42:46 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib Now as of mariadb 1:10.5.18-0+deb11u1 (as present in bullseye as of the latest point release) this ends up as hard failure: | 2022-12-18 6:42:14 0 [ERROR] Failed to setup SSL | 2022-12-18 6:42:14 0 [ERROR] SSL error: SSL_CTX_set_default_verify_paths failed | 2022-12-18 6:42:14 0 [ERROR] Aborting Possibly related to the OpenSSL 3.0 support introduced with 10.5.17 (see https://mariadb.com/kb/en/mariadb-10517-release-notes/), but IMO this is a regression. regards -mika- signature.asc Description: PGP signature
[PATCH 1/1] DOC/CLEANUP: fix typos
s/algorithmm/algorithm/ s/an other/another/ s/certicates/certificates/ s/exemples/examples/ s/informations/information/ s/optionnal/optional/ --- doc/design-thoughts/config-language.txt | 4 ++-- doc/internals/http-parsing.txt | 4 ++-- doc/management.txt | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git doc/design-thoughts/config-language.txt doc/design-thoughts/config-language.txt index 510ada68e..20c4fbd2b 100644 --- doc/design-thoughts/config-language.txt +++ doc/design-thoughts/config-language.txt @@ -24,9 +24,9 @@ Pour les filtres : = [ == | =~ | =* | =^ | =/ | != | !~ | !* | !^ | !/ ] = "" = [ allow | permit | deny | delete | replace | switch | add | set | redir ] - = optionnal action args + = optional action args -exemples: +examples: req in URI =^ "/images" switch images req in h(host) =* ".mydomain.com" switch mydomain diff --git doc/internals/http-parsing.txt doc/internals/http-parsing.txt index 494558baa..8b3f23960 100644 --- doc/internals/http-parsing.txt +++ doc/internals/http-parsing.txt @@ -325,11 +325,11 @@ Unfortunately, some products such as Apache allow such characters :-/ - each http_txn has 1 request message (http_req), and 0 or 1 response message (http_rtr). Each of them has 1 and only one http_txn. An http_txn holds - informations such as the HTTP method, the URI, the HTTP version, the + information such as the HTTP method, the URI, the HTTP version, the transfer-encoding, the HTTP status, the authorization, the req and rtr content-length, the timers, logs, etc... The backend and server which process the request are also known from the http_txn. -- both request and response messages hold header and parsing informations, such +- both request and response messages hold header and parsing information, such as the parsing state, start of headers, start of message, captures, etc... diff --git doc/management.txt doc/management.txt index c93bff5db..b2a34fb9c 100644 --- doc/management.txt +++ doc/management.txt @@ -208,7 +208,7 @@ list of options is : tokenized, so comments are stripped and indenting is forced. If a non-zero key is specified, lines are truncated before sensitive/confidential fields, and identifiers and addresses are emitted hashed with this key using the -same algorithmm as the one used by the anonymized mode on the CLI. This +same algorithm as the one used by the anonymized mode on the CLI. This means that the output may safely be shared with a developer who needs it to figure what's happening in a dump that was anonymized using the same key. Please also see the CLI's "set anon" command. @@ -1690,7 +1690,7 @@ add server / [args]* add ssl ca-file Add a new certificate to a ca-file. This command is useful when you reached - the buffer size limit on the CLI and want to add multiple certicates. + the buffer size limit on the CLI and want to add multiple certificates. Instead of doing a "set" with all the certificates you are able to add each certificate individually. A "set ssl ca-file" will reset the ca-file. @@ -2964,7 +2964,7 @@ show resolvers [] other: any other DNS errors invalid: invalid DNS response (from a protocol point of view) too_big: too big response -outdated: number of response arrived too late (after an other name server) +outdated: number of response arrived too late (after another name server) show servers conn [] Dump the current and idle connections state of the servers belonging to the -- 2.30.2
[Grml] Grml - new stable release 2022.11 available
Hi, we said we'll release by the end of November, and here we are! The stable release of Grml version 2022.11 with codename 'MalGuckes' is available and hitting our mirrors. More information about this release is available in the release notes of Grml 2022.11: https://grml.org/changelogs/README-grml-2022.11/ Grab the latest Grml ISO(s) and spread the word: https://grml.org/download/ If you should notice any bugs please let us know: https://grml.org/bugs/ We welcome constructive feedback, suggestions for improvement and your contributions, please just reach out to us: https://grml.org/contact/ Thanks to everyone contributing to Grml and this release! Take care and happy Grml-ing! -mika- - for the Grml project signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
[Grml-devel] Grml - new stable release 2022.11 available
Hi, we said we'll release by the end of November, and here we are! The stable release of Grml version 2022.11 with codename 'MalGuckes' is available and hitting our mirrors. More information about this release is available in the release notes of Grml 2022.11: https://grml.org/changelogs/README-grml-2022.11/ Grab the latest Grml ISO(s) and spread the word: https://grml.org/download/ If you should notice any bugs please let us know: https://grml.org/bugs/ We welcome constructive feedback, suggestions for improvement and your contributions, please just reach out to us: https://grml.org/contact/ Thanks to everyone contributing to Grml and this release! Take care and happy Grml-ing! -mika- - for the Grml project signature.asc Description: PGP signature ___ Grml-devel mailing list Grml-devel@ml.grml.org http://ml.grml.org/mailman/listinfo/grml-devel
Bug#1024589: dislocker: FTBFS with ruby3.1: mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such file or directory
* Lucas Kanashiro [Mon Nov 21, 2022 at 05:11:55PM -0300]: > Source: dislocker > Version: 0.7.3-2.1 > Severity: important > Justification: FTBFS > Tags: bookworm sid ftbfs > User:debian-r...@lists.debian.org > Usertags: ruby3.1 > > We are about to start the ruby3.1 transition in unstable. While trying to > rebuild dislocker with ruby3.1 enabled, the build failed. Thanks for doing this! I tried to reproduce it with only the following change applied: | --- debian/control | +++ debian/control | @@ -7,7 +7,7 @@ Build-Depends: cmake, | debhelper-compat (=13), | libfuse-dev | libfuse-hurd-dev, | libmbedtls-dev, | - ruby-dev | + ruby-dev (>= 1:3.1~0) But it works fine for me when building this in a cowbuilder experimental environment on amd64. > Relevant part of the build log (hopefully): > >debian/rules override_dh_install-arch > make[1]: Entering directory '/<>' > dh_install > mv /<>/debian/tmp/usr/lib/libdislocker* \ >/<>/debian/libdislocker0.7/usr/lib/ > mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such > file or directory > make[1]: *** [debian/rules:16: override_dh_install-arch] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:12: binary] Error 2 > > The full build log is available from: > > https://people.debian.org/~kanashiro/ruby3.1/20/dislocker/dislocker_0.7.3-2.1+rebuild1667925374_amd64-2022-11-08T16:36:15Z.build So quoting from your *full* build log: | Install the project... | /usr/bin/cmake -P cmake_install.cmake | -- Install configuration: "None" | -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so.0.7.2 | -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so.0.7 | -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so | -- Installing: /<>/debian/tmp/usr/bin/dislocker-fuse | -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-fuse" to "" | -- Installing: /<>/debian/tmp/usr/share/man/man1/dislocker-fuse.1.gz | -- Installing: /<>/debian/tmp/usr/bin/dislocker-file | -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-file" to "" | -- Installing: /<>/debian/tmp/usr/share/man/man1/dislocker-file.1.gz | -- Installing: /<>/debian/tmp/usr/bin/dislocker-metadata | -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-metadata" to "" | -- Installing: /<>/debian/tmp/usr/bin/dislocker-bek | -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-bek" to "" | -- Installing: /<>/debian/tmp/usr/bin/dislocker-find | -- Installing: /<>/debian/tmp/usr/share/man/man1/dislocker-find.1.gz | make[1]: Leaving directory '/<>' |debian/rules override_dh_install-arch | make[1]: Entering directory '/<>' | dh_install | mv /<>/debian/tmp/usr/lib/libdislocker* \ |/<>/debian/libdislocker0.7/usr/lib/ | mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such file or directory So that feels like a problem between /usr/lib64 vs /usr/lib on your system? My experimental environment has merged-usr layout: | # ls -la /var/cache/pbuilder/base-exp-amd64.cow/ | total 300 | drwxr-xr-x 18 root root 4096 Nov 25 17:02 . | drwxr-xr-x 24 root root 4096 Nov 25 17:03 .. | -rw-r--r-- 1 root root 232304 Nov 25 17:02 .ilist | lrwxrwxrwx 1 root root 7 Sep 19 08:53 bin -> usr/bin | drwxr-xr-x 2 root root 4096 Jan 14 2018 boot | drwxr-xr-x 2 root root 4096 Jul 13 2018 build | drwxr-xr-x 4 root root 4096 Nov 25 17:02 dev | drwxr-xr-x 32 root root 4096 Nov 25 17:02 etc | drwxr-xr-x 2 root root 4096 Jan 14 2018 home | lrwxrwxrwx 1 root root 7 Sep 19 08:53 lib -> usr/lib | lrwxrwxrwx 1 root root 9 Sep 19 08:53 lib32 -> usr/lib32 | lrwxrwxrwx 1 root root 9 Sep 19 08:53 lib64 -> usr/lib64 | lrwxrwxrwx 1 root root 10 Sep 19 08:53 libx32 -> usr/libx32 | [...] Might this be related? regards -mika- signature.asc Description: PGP signature
Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
* Marco d'Itri [Sun Oct 23, 2022 at 12:05:18AM +0200]: > On Oct 22, Andras Korn wrote: > > nfs-kernel-server, for example, the 'install' command wants to invoke > > sysctl --pattern, but the busybox sysctl installed in the initramfs by > > default doesn't support --pattern. So the package would need to force > > initramfs to include the /sbin/sysctl from procps, and maybe also any > > pertinent files from /etc/sysctl.d. > Looks like this is a different problem. FYI: I reported this one as #1024082, looks like the new /lib/modprobe.d/50-nfs.conf file is causing quite some problems. (FTR, this showed up at the Grml live system, see e.g. https://github.com/grml/grml/issues/193 ) regards -mika- signature.asc Description: PGP signature
Re: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
* Marco d'Itri [Sun Oct 23, 2022 at 12:05:18AM +0200]: > On Oct 22, Andras Korn wrote: > > nfs-kernel-server, for example, the 'install' command wants to invoke > > sysctl --pattern, but the busybox sysctl installed in the initramfs by > > default doesn't support --pattern. So the package would need to force > > initramfs to include the /sbin/sysctl from procps, and maybe also any > > pertinent files from /etc/sysctl.d. > Looks like this is a different problem. FYI: I reported this one as #1024082, looks like the new /lib/modprobe.d/50-nfs.conf file is causing quite some problems. (FTR, this showed up at the Grml live system, see e.g. https://github.com/grml/grml/issues/193 ) regards -mika- signature.asc Description: PGP signature
Bug#1024082: nfs-kernel-server: /lib/modprobe.d/50-nfs.conf causing problems with sysctl from busybox and with kmod
Package: nfs-kernel-server
Version: 1:2.6.2-1+b1
Severity: important
Hi,
as of git rev 87de072e in nfs-utils.git (which is shipped as of
nfs-kernel-server >=1:2.6.2-1), there's a new file
/lib/modprobe.d/50-nfs.conf, which seems to cause quite some
problems, see e.g. https://bugs.debian.org/1022172
("/lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop
including sunrpc module for nfs").
Furthermore, it also ends up during bootup like this:
| /sbin/sysctl: unrecognized option '--pattern'
| BusyBox v1.35.0 (Debian 1:1.35.0-4) multi-call binary.
|
| Usage: sysctl [-enq] { -a | -p [FILE]... | [-w] [KEY[=VALUE]]... }
|
| Show/set kernel parameters
|
| -e Don't warn about unknown keys
| -n Don't show key names
| -q Quiet
| -a Show all values
| -p Set values from FILEs (default /etc/sysctl.conf)
| -w Set values
(Admittedly, this was detected in the Grml live system, see
https://github.com/grml/grml/issues/193 - but I'm pretty sure plain
Debian systems will be also affected.)
regards
-mika-
[Grml] First Release Candidate of Grml version 2022.11 available
Hi, our first release candidate of the upcoming Grml version 2022.11, code-named 'MalGuckes' is available and is just hitting our mirrors. This Grml release provides fresh software packages from Debian bookworm. As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release. For detailed information about the changes between 2021.07 and 2022.11-rc1 have a look at the official release announcement: https://grml.org/changelogs/README-grml-2022.11-rc1/ You can download Grml 2022.11-rc1 from: https://grml.org/download/prerelease/ Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of November (2022! :)). Thanks to all our contributors! regards, -mika- - for the Grml.org project signature.asc Description: PGP signature ___ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
[Grml-devel] First Release Candidate of Grml version 2022.11 available
Hi, our first release candidate of the upcoming Grml version 2022.11, code-named 'MalGuckes' is available and is just hitting our mirrors. This Grml release provides fresh software packages from Debian bookworm. As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release. For detailed information about the changes between 2021.07 and 2022.11-rc1 have a look at the official release announcement: https://grml.org/changelogs/README-grml-2022.11-rc1/ You can download Grml 2022.11-rc1 from: https://grml.org/download/prerelease/ Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of November (2022! :)). Thanks to all our contributors! regards, -mika- - for the Grml.org project signature.asc Description: PGP signature ___ Grml-devel mailing list Grml-devel@ml.grml.org http://ml.grml.org/mailman/listinfo/grml-devel
Bug#965786: pppoeconf: Removal of obsolete debhelper compat 5 and 6 in bookworm
* Niels Thykier [Mon Jul 20, 2020 at 07:35:34PM +]: > Source: pppoeconf > Version: 1.21 > Severity: normal > Usertags: compat-5-6-removal > > The package pppoeconf uses debhelper with a compat level of 5 or 6, > which is deprecated and scheduled for removal[1]. [...] This bug is still present and caused the package to be removed from testing. Gregory, can you please take of this, so pppoeconf has the chance to be present in the upcoming bookworm release? regards -mika- signature.asc Description: PGP signature
Bug#965786: pppoeconf: Removal of obsolete debhelper compat 5 and 6 in bookworm
* Niels Thykier [Mon Jul 20, 2020 at 07:35:34PM +]: > Source: pppoeconf > Version: 1.21 > Severity: normal > Usertags: compat-5-6-removal > > The package pppoeconf uses debhelper with a compat level of 5 or 6, > which is deprecated and scheduled for removal[1]. [...] This bug is still present and caused the package to be removed from testing. Gregory, can you please take of this, so pppoeconf has the chance to be present in the upcoming bookworm release? regards -mika- signature.asc Description: PGP signature
Bug#985047: ipxe: New upstream release v1.21.1 available
* Michael Prokop [Fri Mar 12, 2021 at 09:55:40AM +0100]: > Package: ipxe > Version: 1.0.0+git-20190125.36a4c85-5.1 > Severity: wishlist > according to https://github.com/ipxe/ipxe/releases there's > v1.21.1 available since 2020-12-31. > Would be nice to see a new version in Debian as well. :) Gentle ping, would be nice to have a more recent version in bookworm. regards -mika- signature.asc Description: PGP signature
Bug#1023638: memtest86+: README.Debian: wrong file names for EFI images
Package: memtest86+ Version: 6.00-1 Severity: minor Quoting from /usr/share/doc/memtest86+/README.Debian: | Multiple binary images are provided: | | - A legacy bios 32bit /boot/memtest86+x32.bin that uses Linux zImage | boot protocol. | | - A legacy bios 64bit /boot/memtest86+x64.bin that uses Linux zImage | boot protocol. | | - A 32bit EFI Image /boot/memtest86+x32.bin | | - A 64bit EFI Image /boot/memtest86+x64.bin Those are twice the same file names (e.g. /boot/memtest86+x64.bin), I suppose the later ones are meant to refer to /boot/memtest86+x32.efi + /boot/memtest86+x64.efi? regards -mika-
Bug#1022758: [Pkg-zsh-devel] Bug#1022758: zsh doesn't recognise double quotes with an exclamation mark
close 1022758
thanks
Hi,
* Tanmay [Tue Oct 25, 2022 at 03:20:54PM +0530]:
> When I type `echo 'Hello!'`, it prints `Hello` but when I use double quotes
> instead of single quotes, there is no output and the shell waits for the
> quote to end.
> Here is a transcript!
>
> $ echo 'Hello!'
> Hello
> $ echo "Hello!"
> dquote>
>
> I suggest that the shell should recognise the quotes.
> I am using Ubuntu 20.04 and kernel 5.15.0-52-generic.
"!" has a special meaning in zsh, so this behaves as expected and
documented. You need to use single quotes or drop "!" from
$histchars, if you want to disable this behavior.
See section `QUOTING` in `man zshall`, quoting from there
| Inside double quotes (""), parameter and command substitution occur,
| and `\' quotes the characters `\', ``', `"', `$', and the first
| character of $histchars (default `!').
regards
-mika-
signature.asc
Description: PGP signature
Bug#1022045: fio: New upstream version 3.32 available
Package: fio Version: 3.30-1+b1 Severity: wishlist Hi, fio v3.32 is available since 2022-08-30, and while the Github releases for 3.31 + 3.32 mention only "fio Windows installer", looking at the actual git history, there are some further changes/fixes. Would be great to have most current version available for Debian/bookworm. :) Thanks for maintaining fio! regards -mika-
Bug#1021520: guymager: reproducible-builds: date in guymager manpage
Hi Vagrant! * Vagrant Cascadian [Sun Oct 09, 2022 at 05:41:19PM -0700]: > The date is embedded in /usr/share/man/man1/guymager.1.gz: > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/guymager.html > > TH·guymager·1·"2023-11-10"·"version·0.8.13-1 > vs. > TH·guymager·1·"2022-10-09"·"version·0.8.13-1 > > The attached patch to the upstream manuals/rebuild.sh file fixes this by > using SOURCE_DATE_EPOCH to determine the date to embed in the manpage. > > According to my local tests, with this patch applied guymager should > build reproducibly on tests.reproducible-builds.org once it migrates to > bookworm/testing! There are other outstanding issues with build-paths, > which are only tested on unstable/experimental. Thanks for your patch, Vagrant. I applied it and added another change on top of yours, so manually invoking manuals/rebuild.sh still works, and converted it into a quilt patch. Would you mind taking a quick look at https://salsa.debian.org/pkg-security-team/guymager/-/merge_requests/1 to check, whether this makes sense for you? (The failing reprotest in the pipeline seems to come from the guymager binary itself, AFAICS) Thanks! regards -mika- signature.asc Description: PGP signature
Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0
* Antoine Beaupré [Mon Oct 03, 2022 at 12:28:06PM -0400]: > On 2022-10-03 18:21:46, Michael Prokop wrote: > > AFAICT (thanks to our daily Grml ISO builds) this RC bug caused > > puppet to get removed from Debian/testing, so unless this gets fixed > > we won't have puppet in bookworm? Is anyone taking care of this? > > Puppet 5 has been EOL for years. It's a good thing it's gone from > bookworm, and a deliberate act on part of the Puppet package > maintainers. ACK :) > We've packaged puppet-agent 7 and uploaded to unstable, it should > trickle down in bookworm in a day or two if all goes well. Oh, that's great news! :) > We're working on packaging puppetserver 7. You can follow that work and > more here: > https://wiki.debian.org/Teams/Puppet/Work Thanks, both for your fast response as well as working on the puppet packaging! \o/ regards -mika- signature.asc Description: PGP signature
Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0
* Antoine Beaupré [Mon Oct 03, 2022 at 12:28:06PM -0400]: > On 2022-10-03 18:21:46, Michael Prokop wrote: > > AFAICT (thanks to our daily Grml ISO builds) this RC bug caused > > puppet to get removed from Debian/testing, so unless this gets fixed > > we won't have puppet in bookworm? Is anyone taking care of this? > > Puppet 5 has been EOL for years. It's a good thing it's gone from > bookworm, and a deliberate act on part of the Puppet package > maintainers. ACK :) > We've packaged puppet-agent 7 and uploaded to unstable, it should > trickle down in bookworm in a day or two if all goes well. Oh, that's great news! :) > We're working on packaging puppetserver 7. You can follow that work and > more here: > https://wiki.debian.org/Teams/Puppet/Work Thanks, both for your fast response as well as working on the puppet packaging! \o/ regards -mika- signature.asc Description: PGP signature
Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0
Hi! * Antoine Beaupré [Tue Aug 30, 2022 at 05:15:58PM -0400]: > On 2022-08-25 14:19:42, Antoine Beaupré wrote: > > > For what it's worth, I have tested lavamind's Puppet 7 package from > > experimental, on bookworm, and it works fine: > > > > https://tracker.debian.org/pkg/puppet-agent > > > > ... I am not sure how to express this in the BTS here, because it's a > > different source package, so I can't mark it as fixed there without > > first marking it as affecting that other package, but it never affected > > it. > > The correct way seems to be to move this bug report back to src:puppet > where it belongs, which this message should do. AFAICT (thanks to our daily Grml ISO builds) this RC bug caused puppet to get removed from Debian/testing, so unless this gets fixed we won't have puppet in bookworm? Is anyone taking care of this? regards -mika- signature.asc Description: PGP signature
Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0
Hi! * Antoine Beaupré [Tue Aug 30, 2022 at 05:15:58PM -0400]: > On 2022-08-25 14:19:42, Antoine Beaupré wrote: > > > For what it's worth, I have tested lavamind's Puppet 7 package from > > experimental, on bookworm, and it works fine: > > > > https://tracker.debian.org/pkg/puppet-agent > > > > ... I am not sure how to express this in the BTS here, because it's a > > different source package, so I can't mark it as fixed there without > > first marking it as affecting that other package, but it never affected > > it. > > The correct way seems to be to move this bug report back to src:puppet > where it belongs, which this message should do. AFAICT (thanks to our daily Grml ISO builds) this RC bug caused puppet to get removed from Debian/testing, so unless this gets fixed we won't have puppet in bookworm? Is anyone taking care of this? regards -mika- signature.asc Description: PGP signature
