Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > Source: dhcpcd > Version: 1:10.0.8-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package because it > was tested for glibc. I noticed that it regularly fails. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. This is a non-bug. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Additionally, looking at the tracker for this package, amd64 always passes. Martin-Éric
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit : > On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote: > > During a rebuild of all packages in unstable, your package failed to build: > … > > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed: > > 0) > > Non-zero exit status: 255 > > Parse errors: No plan found in TAP output > > On the face of it this looks to be a result of po4a changes. I'm not > sure if the root cause is the same as #1072643 yet; further > investigation is required. These two bugs are unrelated. The failure on goobox (#1072643) is linked to the fact that po4a is now much less forgiving about charsets. It now supposes UTF encoding unless specified otherwise. Before, it was relying on the default Perl behavior, which tries to do "the right thing" even if the user does something wrong. This is why previously, the ISO-8859-15 files were accepted without additional configuration while now po4a reports that it's not UTF. Fixing this simply requires to specify the encoding using the -M flag. The question may be about why we changed this. The answer is that the default Perl behavior was not always right leading to messy failures (in particular with gettext which makes things even more complex when msgids contain non-ascii chars), while the new behavior gives us more control. I'll try to improve the error messages to make things more explicit. On its side, the failure on ikiwiki (#1072760) is related to the fact that ikiwiki is using a function that I consider as a private API in po4a and recently changed. The fix is simply to update the the calls of that API in ikiwiki's code, and the update is trivial (simply give the filename twice to use it as refname). Sorry about the inconvenience, but please people, do not CC both bugs as they are unrelated. Sorry again about the inconvenience, Mt signature.asc Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit :
> On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> …
> > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed:
> > 0)
> > Non-zero exit status: 255
> > Parse errors: No plan found in TAP output
>
> On the face of it this looks to be a result of po4a changes. I'm not
> sure if the root cause is the same as #1072643 yet; further
> investigation is required.
>
I think that the relevant part of the logs is here:
---
Cannot write to a file without refname at
/usr/share/perl5/Locale/Po4a/TransTractor.pm line 444.
Locale::Po4a::TransTractor::read(Locale::Po4a::Text=HASH(0x559ec7d9f248),
"/tmp/ikiwiki-test-po.nKtVlhHS3_/src/index.mdwn") called at /build/ikiwiki-
3.20200202.4/blib/lib/IkiWiki/Plu
gin/po.pm line 907
IkiWiki::Plugin::po::refreshpot("/tmp/ikiwiki-test-
po.nKtVlhHS3_/src/index.mdwn") called at t/po.t line 225
main::refresh_n_scan("index.mdwn", "translatable.mdwn",
"nontranslatable.mdwn") called at t/po.t line 233
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 38.
t/po.t .
-
That's really astonishing for me. I could not imagine that this function is
called by someone else than po4a itself...
This bug is related to https://github.com/mquinson/po4a/issues/504 which
requires a documentation improvement in po4a, but the bug to fix is in ikiwiki.
You should update your calls to this function to follow the prototype
modification. I'm sorry about that, but I fail to see another option.
Sorry for the inconvenience,
Mt
signature.asc
Description: This is a digitally signed message part
Bug#1072996: cryptmount: No longer working with current sid (e2fsck error)
Package: cryptmount
Version: 6.2.0-2
Severity: normal
Dear Maintainer,
I have noticed that cryptmount is no longer working well with current
sid in my box. This happened recently, although I do not know where
this started to happen,
$ cryptmount LUKS-test
...
e2fsck 1.47.1 (20-May-2024)
Error determining size of the physical device: No such file or directory
unable to stat() device node
Failed to remove device-mapper target "LUKS-test"
If I add the noextfsck flag to cmtab, mount succeeds,
$ cryptmount LUKS-test
However, I have problems when unmounting,
$ cryptmount -u LUKS-test
Target "LUKS-test" does not appear to be mounted
although device is mounted and accesible,
I noticed that when using cryptmount /dev/mapper/LUKS-test seems not
present, although device is mounted. When using the normal cryptsetup close flow
# umount /media/luks-testdir
# /sbin/cryptsetup close LUKS-test
device is properly unmounted.
If I follow the cryptsetup flow for opening
# /sbin/cryptsetup open /dev/sdc1 LUKS-test
# mount /dev/mapper/LUKS-test /media/luks-testdir/
/dev/mapper/LUKS-test is present and 'cryptmount -u LUKS-test' works.
LUKS-test {
keyformat=luks
dev=/dev/sdc1
keyfile=/dev/sdc1
dir=/media/luks-testdir
flags=nofsck
fstype=ext4
}
Thanks for your work on cryptmount.
Regards,
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (50, 'testing'), (50, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptmount depends on:
ii libc6 2.38-13
ii libcryptsetup12 2:2.7.2-2
ii libdevmapper1.02.1 2:1.02.196-1+b1
ii libgcrypt20 1.10.3-3
ii libudev1256~rc4-1
Versions of packages cryptmount recommends:
ii e2fsprogs 1.47.1-1
ii udev 256~rc4-1
Versions of packages cryptmount suggests:
ii dmsetup 2:1.02.196-1+b1
-- Configuration Files:
/etc/cryptmount/cmtab changed [not included]
-- no debconf information
Bug#1072978: rdate: please implement ifup script
Package: rdate Version: 1:1.11-3 Severity: normal The Hurd port still depends on the deprecated reference 'ntpdate' to sync clocks at bootup. That reference NTP implementation was replaced by ntpsec in Debian a long time ago. The only NTP client that still builds for Hurd is rdate. What is missing is an ifup script to issue the following command whenever the network is up: rdate -n debian.pool.ntp.org You may want to use an /etc/default/rdate to source the command options and the server. You may check <https://ftp.debian.org/debian-ports/pool-hurd-i386/main/n/ntp/ntp_4.2.8p15+dfsg-2~1.2.2+dfsg1-2+hurd.1.dsc> for ideas on how to implement this. Once rdate has implemented such an ifup script, the Hurd port will finally be able to retire its obsolete fork of ntpdate. Thanks! Martin-Éric -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.8+git20240406-up-486/Hurd-0.9 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages rdate depends on: ii libbsd0 0.12.2-1 ii libc0.3 2.38-13 rdate recommends no packages. rdate suggests no packages. -- no debconf information
Bug#1072973: ntpdate: please drop transitional package
Package: ntpdate Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The ntpdate package nowadays merely is a transitional package. Keeping it no longer serves a purpose. Meanwhile, the Hurd port still depends on the original University of Delaware NTP implementation that provided ntpdate. Since that codebase is now obsolete, the plan would be to re-introduce ntpdate as a wrapper for rdate that can be launched upon bootup the same way the original ntpdate did. Once ntpsec has dropped its ntpdate transitional package, the new wrapper could be introduced with the next rdate upload. Thanks! Martin-Éric - -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ntpdate depends on: pn ntpsec-ntpdate ntpdate recommends no packages. ntpdate suggests no packages. -BEGIN PGP SIGNATURE- iQIyBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZn/b4ACgkQrh+Cd8S0 17YMrQ/2LhYwIgm06/HN8KzeuxeeG7cgH7v0L+QEUU0La/Jdyboi9L6dp7QX78bN SIGIjJfXnXU8mEIb02hAs9taQW813xh14RjH73KC55TjYtn3UruPFovHw8UsXG77 VYS/wuV7Rwh7A2IayxNj+1NoRG+cKURZ1Uf6hKAbm0qjQdvTr5+XMLFyDx5GOPGU DHRzp5RGOTfBiC30cInHGpjTPgoqeaMSY1j19FwgqnDpWWIvx+vHRLRuBv9P+miT 7DrEIOejl6Y8UaW4LgJIeR7fA3JfcLAkZTvIwJRVV4mWF8UiJAN6KRFlR5Dav+ZP 1crgp7yIl1exWZP8ewMzVrK8MkkRZouzUMuAxpO4I9D+lqMfOI67v1+5N0v+S9tu 8M/ID3FLUm4qC0Gi1GBE1sQ8IfBZ9PKjPkY4C19UQTWNOhZ9y0sasTPHcmQE8deM /ePzJufY/x7ZG9B/jAfOFynKUnUIMHfvmNqBVXpbfxtbIfOBftCMoGPxmchc1Lfo i8qgsAimp/39CESsko+1jqBAkVzHF2kaDJmqV5gz1hi35CEcHbuFOrP/0uSc02Hb SnhUA1Xlpc86MUK+PhJxx7kIUAV7MRulfD2aoUzrHvE1td6rJPmtmPVPRP/VXce0 NShUqW5xj8bjbSYchWGb80ksDd2v/6QizotlvEzENt737yFYfQ== =vRjx -END PGP SIGNATURE-
Bug#1072749: [INTL:sv] Swedish strings for powerline debconf
On 2024-06-08 01:42, Anders Jonsson wrote: Hi Martin, did a small typofix in this one. (användaer -> använder) tack. thank you. nice. -- brother
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
ma 10. kesäk. 2024 klo 2.18 Ben Finney (bign...@debian.org) kirjoitti: > > Howdy Martin-Éric, > > On 09-Jun-2024, Martin-Éric Racine wrote: > > > Incorrect delayed argument: ValueError: delayed days value must be a > > decimal integer: > > > > I did not specify any delayed queue, so I am perplexed as to what > > produced this. > > You did not specify a command-line option for the delayed queue; but your > configuration file does specify a value. > > […] > > So, that configuration section overrides default behaviour and specifies > empty-string values for many options that would otherwise have no value > defined. The script ANDs /etc/dput.cf and the user's own. My config actually is much shorter than that. Martin-Éric
Bug#1036448: debhelper: please add helper for autoconf 2.71 autoupdate
Fair enough. Could the dh-autoreconf maintainer acknowledge this bug and tell us his intentions? Martin-Éric On Mon, 22 May 2023 09:30:55 +0200 Niels Thykier wrote: > Control: reassign -1 dh-autoreconf > > The dh-autoreconf tool is maintained in a separate package; re-assigning. > > Best regards, > Niels > > Martin-Éric Racine: > > Package: debhelper > > Version: 13.11.4 > > Severity: wishlist > > > > Possibly related to dh_autoreconf: > > > > Since autoconf 2.71 has entered the archive, it often complains about > > outdated macros, asking for 'autoupdate' to be run. Example: > > > > dh binary --builddirectory=build/ > > dh_update_autotools_config -O--builddirectory=build/ > > dh_autoreconf -O--builddirectory=build/ > > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'. > > libtoolize: copying file 'build-aux/ltmain.sh' > > libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. > > libtoolize: copying file 'm4/libtool.m4' > > libtoolize: copying file 'm4/ltoptions.m4' > > libtoolize: copying file 'm4/ltsugar.m4' > > libtoolize: copying file 'm4/ltversion.m4' > > libtoolize: copying file 'm4/lt~obsolete.m4' > > configure.ac:42: warning: The macro `AC_PROG_LIBTOOL' is obsolete. > > configure.ac:42: You should run autoupdate. > > m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from... > > configure.ac:42: the top level > > configure.ac:48: warning: The macro `AC_PROG_CC_C99' is obsolete. > > configure.ac:48: You should run autoupdate. > > ./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from... > > aclocal.m4:1899: XORG_COMPILER_BRAND is expanded from... > > aclocal.m4:2018: XORG_COMPILER_FLAGS is expanded from... > > aclocal.m4:2190: XORG_DEFAULT_OPTIONS is expanded from... > > configure.ac:48: the top level > > configure.ac:52: warning: The macro `AC_PROG_LIBTOOL' is obsolete. > > configure.ac:52: You should run autoupdate. > > m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from... > > configure.ac:52: the top level > > > > Running 'autoupdate' indeed makes autoconf stop complaining, but it also > > results in dpkg forcing us to create a patch against autoconf.ac, which is > > IMHO the wrong approach. > > > > Unless I'm mistaken, this is a case similar to updating config.guess and > > config.sub, so there should be a way to tell dh_autoreconf to run > > 'autoupdate' without making dkpg complain. > > > > Martin-Éric > > > > [...] > > > >
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
Package: dput Version: 1.2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 $ dput mentors ../xserver-xorg-video-geode_2.11.21-4_source.changes Checking signature on .changes gpg: ../xserver-xorg-video-geode_2.11.21-4_source.changes: Valid signature from AE1F8277C4B4D7B6 Checking signature on .dsc gpg: ../xserver-xorg-video-geode_2.11.21-4.dsc: Valid signature from AE1F8277C4B4D7B6 Incorrect delayed argument: ValueError: delayed days value must be a decimal integer: I did not specify any delayed queue, so I am perplexed as to what produced this. Martin-Éric - -- Package-specific info: - -- /etc/dput.cf -- # Example dput.cf that defines the host that can be used # with dput for uploading. [DEFAULT] login = * method = ftp hash= md5 allow_unsigned_uploads = 0 allow_dcut = 0 run_lintian = 0 run_dinstall= 0 check_version = 0 scp_compress= 0 post_upload_command = pre_upload_command = passive_ftp = 1 default_host_main = allowed_distributions = (?!UNRELEASED) [ftp-master] fqdn= ftp.upload.debian.org incoming= /pub/UploadQueue/ login = anonymous allow_dcut = 1 method = ftp # Please, upload your package to the proper archive # https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload allowed_distributions = (?!UNRELEASED|.*-security) # https://lists.debian.org/debian-project/2009/05/msg00036.html [ftp-eu] fqdn= ftp.eu.upload.debian.org method = ftp incoming= /pub/UploadQueue/ login = anonymous allow_dcut = 1 # Please, upload your package to the proper archive # https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload allowed_distributions = (?!UNRELEASED|.*-security) # https://lists.debian.org/debian-devel-announce/2008/09/msg7.html [ssh-upload] login = * # login = another_username fqdn= ssh.upload.debian.org method = scp incoming= /srv/upload.debian.org/UploadQueue/ allow_dcut = 1 # Please, upload your package to the proper archive # https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload allowed_distributions = (?!UNRELEASED|.*-security) # And if you want to override one of the defaults, add it here. # For example, comment out the next line # post_upload_command = /path/to/some/script # pre_upload_command= /path/to/some/script [security-master] fqdn= ftp.security.upload.debian.org method = ftp incoming= /pub/SecurityUploadQueue login = anonymous allow_dcut = 1 # This has been added at the request of the security team. # Please be sure to know what you are doing before taking it out. pre_upload_command = /usr/share/dput/helper/security-warning [security-master-unembargoed] fqdn= ftp.security.upload.debian.org method = ftp incoming= /pub/OpenSecurityUploadQueue login = anonymous allow_dcut = 1 # This has been added at the request of the security team. # Please be sure to know what you are doing before taking it out. pre_upload_command = /usr/share/dput/helper/security-warning [ubuntu] fqdn= upload.ubuntu.com method = ftp incoming= / login = anonymous [ppa] fqdn= ppa.launchpad.net method = ftp # replace with your Launchpad ID incoming= ~/ubuntu login = anonymous [mentors] method = ftp fqdn= mentors.debian.net incoming= /pub/UploadQueue login = anonymous [local] method = local incoming= ~/public_html/debian/mini-dinstall/incoming run_dinstall= 0 post_upload_command = /usr/bin/mini-dinstall --batch # Local variables: # coding: utf-8 # mode: conf # End: # vim: fileencoding=utf-8 filetype=config : - -- /home/perkelix/.config/dput/dput.cf -- - -- /home/perkelix/.dput.cf -- [mentors-ftp] fqdn = mentors.debian.net incoming = /pub/UploadQueue/ method = ftp allow_unsigned_uploads = 0 run_lintian = 1 passive_ftp = 1 login = anonymous [mentors-https] fqdn = mentors.debian.net incoming = /upload method = https allow_unsigned_uploads = 0 run_lintian = 1 [ppa] fqdn = ppa.launchpad.net incoming = ~q-funk/ppa/ubuntu/ method = ftp allow_unsigned_uploads = 0 run_lintian = 1 login = anonymous [esteid] fqdn = ppa.launchpad.net incoming = ~esteid/ppa/ubuntu/ method = ftp allow_unsigned_uploads = 0 run_lintian = 1 login = anonymous [x-swat] fqdn
Bug#1072846: asio breaks the widelands package on hurd-i386
Source: asio Version: 1:1.28.1-0.2 Severity: normal Tags: ftbfs X-Debbugs-Cc: debian-h...@lists.debian.org Dear maintainers, the latest version of widelands fails on the hurd-i386 architecture, because of a syntax error in the /usr/include/asio/signal_set_base.hpp system file. I don't think that widelands is involved in any way: from /<>/src/network/network.h:24, from /<>/src/network/nethost_interface.h:24, from /<>/src/network/gamehost.h:28, from /<>/src/wui/game_client_disconnected.cc:24: /usr/include/asio/signal_set_base.hpp:65:21: error: ‘SA_NOCLDWAIT’ was not declared in this scope; did you mean ‘SA_NOCLDSTOP’? 65 | no_child_wait = ASIO_OS_DEF(SA_NOCLDWAIT), | ^~~ make[3]: *** [src/wui/CMakeFiles/wui.dir/build.make:233: src/wui/CMakeFiles/wui.dir/game_client_disconnected.cc.o] Error 1 - The full logs are here: https://buildd.debian.org/status/fetch.php?pkg=widelands=hurd-i386=2%3A1.2-2=1717876058=0 The hurd porters are in CC, because I must confess I have no idea about how this should be fixed. Thanks for your help, Mt signature.asc Description: PGP signature
Bug#1072750: [INTL:sv] Swedish strings for python-certbot debconf
package: python-certbot severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of python-certbot debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the python-certbot package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: python-certbot\n" "Report-Msgid-Bugs-To: python-cert...@packages.debian.org\n" "POT-Creation-Date: 2020-06-21 21:24-0400\n" "PO-Revision-Date: 2024-06-07 15:15+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../certbot.templates:1001 msgid "You have unexpired certs; do you still want to purge?" msgstr "" "Det finns certifikat som ännu ej har gått ut, är du säker på att du vill " "rensa allt?" #. Type: boolean #. Description #: ../certbot.templates:1001 msgid "" "The certbot configuration directory /etc/letsencrypt still contains " "unexpired certificates that may be live on your system. If you choose this " "option, the purge will continue and delete those certificates, potentially " "breaking services which depend on them." msgstr "" "Sökvägen för certbots inställningar, /etc/letsencrypt, innehåller " "fortfarande certifikat som inte har gått ut ännu och dessa kanske används. " "Går du vidare med rensningen kommer filerna att raderas och därmed kan " "tjänster som använder dessa gå sönder." #. Type: boolean #. Description #: ../certbot.templates:1001 msgid "" "If you have already installed different certificates in your services, or " "you have confirmed you don't have any services depending on these " "certificates, you should choose this option. To cancel and manually delete " "the /etc/letsencrypt directory, you should refuse this option." msgstr "" "Om du redan har installerat andra certifikat i dina tjänster eller bekräftat " "att inga tjänster använder dessa certifikat så kan du gå vidare med " "rensningen. Alternativet är att avbryta och manuellt städa upp /etc/" "letsencrypt."
Bug#1072749: [INTL:sv] Swedish strings for powerline debconf
package: powerline severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of powerline debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the powerline package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: powerline\n" "Report-Msgid-Bugs-To: powerl...@packages.debian.org\n" "POT-Creation-Date: 2018-07-24 06:14+0200\n" "PO-Revision-Date: 2024-06-07 14:58+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: title #. Description #: ../powerline.templates:1001 msgid "powerline: Setup" msgstr "powerline: Installation" #. Type: multiselect #. Description #: ../powerline.templates:2001 msgid "Enable powerline globally?" msgstr "Ska powerline aktiveras globalt?" #. Type: multiselect #. Description #: ../powerline.templates:2001 msgid "" "powerline can be enabled globally for all users of certain applications on " "this system." msgstr "" "Powerline kan aktiveras globalt för alla som användaer vissa applikationer " "på detta system."
Bug#1072714: ITP: odin-lang -- Compiler and runtime for the Odin programming language
Package: wnpp Severity: wishlist Owner: Martin Quinson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : odin-lang Version : O.0.dev2024.06 Upstream Contact: (this community goes over Discord, not emails) * URL : https://odin-lang.org * License : BSD-3-Clause Programming Lang: C++ for the compiler, and Odin for the stdlib Description : Compiler and runtime for the Odin programming language # Package description Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming. Odin is the C alternative for the Joy of Programming. # Why is this package useful? Because this language is nice and elegant. I plan to use it, and according to upstream, they are getting close to a v1 version (the language and compiler are ready, they are working on the standard library) # How do you plan to maintain it? I don't need a sponsor, but I'd like to have co-maintainers, if possible. I guess I could find some help with upstream. I already started packaging it, mostly to see whether it's doable given my free time, and I found an helping hand upstream in the person of the maintainer of the homebrew package. Cheers, Mt signature.asc Description: This is a digitally signed message part
Bug#1072517: /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0'
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/20543 Control: tag -1 patch pending Hello Michael, Michael Biebl [2024-06-03 14:39 +0200]: > Jun 03 14:35:42 mars apparmor.systemd[1026]: AppArmor-Analysefehler f?r > /etc/apparmor.d in profile /etc/apparmor.d/cockpit-desktop in Zeile 1: Could > not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden Argh, thanks for spotting! I have a fix for this, sent upstream and I'll cherry-pick it now. Martin
Bug#1072496: download file forbidden
Hi, Please check https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646897 qcad is not distributable and therefore can not be downloaded from snapshot.d.o. This is why you see the http 403. Best regards, Martin > Am 02.06.2024 um 23:24 schrieb Boyuan Yang : > > Package: snapshot.debian.org > Severity: normal > > Hi, > > 在 2024-06-02星期日的 22:49 +0200，jiri ht写道： >> >> Good morning >> I tried to download qcad >> >> https://snapshot.debian.org/archive/debian/20060824T00Z/pool/main/q/qcad/qcad_2.0.5.0-1-2_amd64.deb >> >> and this was answer: >> Forbidden >> You don't have permission to access this resource. >> >> Apache Server at snapshot.debian.org Port 80 >> >> >> >> >> >> This file and too source and diff files cannot be downloaded. >> >> I tried to download other files and this is working. >> >> >> Can You answer me or repair it please ? > > You are reaching the debian-www mailing list, which is not in charge of the > maintenance > of snapshot.debian.org. > > The bottom of snapshot.debian.org website says: "Please report bugs against > the snapshot.debian.org package." > I am doing you a favor to forward your report to a standalone bug report for > snapshot.debian.org. > Next time, please submit your bug report following the instructions on > https://www.debian.org/Bugs/Reporting . > > Thanks, > Boyuan Yang >
Bug#1063630: Upload?
Is there any reason blocking to upload the update package? Best regards, Martin signature.asc Description: PGP signature
Bug#1070664: emacs: ELPA key needs update in Debian 12
Package: emacs Version: 1:28.2+1-15 Severity: important Dear Maintainer, Just to confirm that this bug is distracting (especially for new users…): - if we install GNU Emacs on Debian 12, - assuming ~/.emacs and ~/.emacs.d are empty, - running emacs and `M-x package-refresh-contents` just raises the error: "Failed to download ‘nongnu’ archive." Failed to verify signature archive-contents.sig: No public key for 645357D2883A0966 created at 2024-05-31T23:05:08+0200 using EDDSA Command output: gpg: Signature made ven. 31 mai 2024 23:05:08 CEST gpg:using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966 gpg: Can't check signature: No public key Sure, we can find workarounds in https://emacs.stackexchange.com/q/233 or add in one's init.el a snippet similar to inasprecali's suggestion: (unless (package-installed-p 'gnu-elpa-keyring-update) (let ((package-check-signature nil)) (package-refresh-contents) (package-install 'gnu-elpa-keyring-update))) But it'd be way better to benefit from a (security?) update to properly fix this issue with the obsolete public key. Thanks for your time Best, Erik -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-15 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1071731: [INTL:sv] Swedish strings for eviacam debconf
On 2024-05-24 17:48, Anders Jonsson wrote: Hi Martin, fixed a typo in this translation (resposivitet -> responsivitet). Thnx didn't even want to write that word but could come up with anything better... and then I misspelled it. Thanks a bunch for proof reading, as always! -- brother
Bug#1072289: [INTL:sv] Swedish strings for postsrsd debconf
package: postsrsd severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of postsrsd debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the postsrsd package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: postsrsd\n" "Report-Msgid-Bugs-To: posts...@packages.debian.org\n" "POT-Creation-Date: 2015-09-30 06:57+0200\n" "PO-Revision-Date: 2024-05-31 16:06+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: string #. Description #: ../postsrsd.templates:2001 msgid "Local domain name to use as origin:" msgstr "Lokalt domännamn att använda som ursprung:" #. Type: string #. Description #: ../postsrsd.templates:2001 msgid "" "Please enter the domain name to use in rewritten addresses of forwarded " "mail. The SPF policy for that domain should allow this mail server to send " "mail." msgstr "Ange domännamnet som ska användas i den omskrivna adressen för vidaresända e-post-meddelanden. SPF-policyn för det domännamnet bör tillåta denna mailserver att skicka e-post." #. Type: string #. Description #: ../postsrsd.templates:2001 msgid "Without a configured local domain name, postsrsd will not start." msgstr "Saknas lokalt domännamn så kommer postsrsd inte starta."
Bug#1072288: [INTL:sv] Swedish strings for munin debconf
package: munin severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of munin debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the munin package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: munin\n" "Report-Msgid-Bugs-To: mu...@packages.debian.org\n" "POT-Creation-Date: 2019-08-04 17:40+0200\n" "PO-Revision-Date: 2024-05-31 16:03+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../munin.templates:1001 msgid "Remove all RRD database files?" msgstr "Ska alla RRD-databas-filer tas bort?" #. Type: boolean #. Description #: ../munin.templates:1001 msgid "" "The /var/lib/munin directory which contains the RRD files with the data " "accumulated by munin is about to be removed." msgstr "" "I katalogen /var/lib/munin finns RRD-filerna med data som samlats in av " "munin, den kan tas bort automatiskt." #. Type: boolean #. Description #: ../munin.templates:1001 msgid "" "If you want to install munin later again or if you want to use the content " "of the RRD files for other purposes, the data should be kept." msgstr "" "Om du vill installera munin senare eller om du vill använda innehållet i RRD-" "filerna för andra ändamål så ska dessa filer behållas."
Bug#1036826: Please start handling \c
reopen 1036826 thanks Hello, Le jeudi 30 mai 2024 à 19:05 +, Helge Kreutzmann a écrit : > > I checked with the documentation base from manpages-l10n. The > > following pages are failing (with the current po4a): > > > > * groff (as reported) > > * credentials.7 (as of Debian unstable) > > * mkosi.1 (only from OpenSUSE tumbleweed, page attached (compressed)) > > * afmtodit.1 (as of Debian unstable) > > > > * And it also fail(ed) in mkpasswd.1 (as of Debian unstable), see > > Debian #1036908 > > Groff.1 works now, but all others listed here still fail. Is this > expected? No it's not. I'll look into it. Sorry, Mt signature.asc Description: This is a digitally signed message part
Bug#1072066: systemd: upgrade to 256~rc3-3: legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
Package: systemd Version: 256~rc3-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Setting up systemd (256~rc3-3) ... /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring. - -- Package-specific info: - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages systemd depends on: ii libacl12.3.2-2 ii libapparmor1 3.0.13-2 ii libaudit1 1:3.1.2-2.1 ii libblkid1 2.40.1-2 ii libc6 2.38-11 ii libcap21:2.66-5 ii libcryptsetup122:2.7.2-2 ii libfdisk1 2.40.1-2 ii libmount1 2.40.1-2 ii libpam0g 1.5.3-7 ii libseccomp22.5.5-1 ii libselinux13.5-2+b2 ii libssl3t64 3.2.1-3 ii libsystemd-shared 256~rc3-3 ii libsystemd0256~rc3-3 ii mount 2.40.1-2 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii libzstd1 1.5.5+dfsg2-2 ii systemd-timesyncd [time-daemon] 256~rc3-3 Versions of packages systemd suggests: ii libgcrypt20 1.10.3-3 ii libidn2-0 2.3.7-2 ii liblz4-1 1.9.4-2 ii liblzma5 5.6.1+really5.4.5-1 pn libtss2-rc0t64 pn libtss2-tcti-device0 pn polkitd pn systemd-boot pn systemd-container pn systemd-homed pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.10-4+b1 pn dracut pn initramfs-tools ii libnss-systemd 256~rc3-3 ii libpam-systemd 256~rc3-3 pn udev - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZVThMACgkQrh+Cd8S0 17Yj1w//TvIy5IYO9yHe1FPWTzerSTwgIeSjkaYD9Ch0yHzz0vtKWFW0EaQq4b/s QzELfhVMDVhfwIKWCIiOB0LSk5i6MXkWIwmUU2c5uXRaRfirRG5jS8ItG+ZEibbr MGh2JtOYIxpKPnScubx/lprjeWJDVehQJ6P6xEjZ2bE4n7+Y9MLWt/Nx1dk4a1Ix dpN45g1iSybbs/KKvg0Fx8KI46gdn+K8hf9dp06khiQTgOYwIuMnU5p1hvNgHlyu z3ezNOw4jKlugyJPnYYTTyrGk89rFJTA+omGh6Z4dhf/v8j0flZRnj31DPkeICKo hNk2h0u0moD01D5E/OXpwvHdMIwmFH0A7bqUEieYAAcls7mZCHgX7hMRiE/8qOFv DfTy9STAJO0Xm9Y5mvRCovCmrEmJ5AePZavm8ymdmA/m1ApIMAUz/+nk0CyLwnL4 /7Oa+kektmgG4Dp+XxK2lOjVd40duQ7HRNs2mpFcJ9yBWya1+gv3Lf/utt9uuGk2 VqVetoLl/0AYlP9g0PSdFxdqXZ7cbCVAC8TzLTPXu3UOlhBXziAxi/fQgCAYtDow 8Dj0MVv5uzd43m+4AGL7q7SaPkZMH2/Isl/VbnaJuirfpOXAq6/b85JALGd10Jg2 fkKwxphsZT4UjAfYsSUOLumLfe/3s8KuiVCLsJ4SL6jbpcIeJoM= =M99n -END PGP SIGNATURE-
Bug#1019922: debian-archive-keyring: Machine-readable copyright conversion
Package: debian-archive-keyring Version: 2023.4 Followup-For: Bug #1019922 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alternately, please find attached this other version of a DEP-5 copyright. Also included in the diff are automated improvements by 'routine-update'. You're welcome to further edit as desired before merging. Martin-Éric - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZS27wACgkQrh+Cd8S0 17ZM2g/+KUeBgou27VU2K37JxGAcpCifgKlWVN2rFaGBkqYzxp/xg9eh1WKA8HVC 9M9xT3EBR1qhSgcckOmzySnEETVR1ItWeYqpi6MlpCCOZTmiBECn8M4XNEPxwbvA CsX4WCA8Qkrw3aBmS28IthKukmexHRVktIoDPc2/xdxTG8LlHJ5wSlaOJLd8vqYm 90S7kHAbSNquk2SC1bB2Nn9KMNAjkI55wkqPxoXZiqC5Ue+dZwhdzRQc9W2iUS71 qFc7np2BdIZVz3Nv9IbgpT6BYq7y8HfHBnljSIib0T8HsYW/C1VlXzL3/4+PUO+G tt4lOUp4u6IfB+02XCGQGhUjj0rUbNWTyINlkx9ZQEqDdEuwqnes0udRMXQRZWcR QjtvQsMFvnjunEYQn5NncHtJAxgJ1jBZIomf3bviUTACn9d6pLv5zonLj7irozdJ rKEFIEpta7STBKmVcrk9KiobFgX1By7+X+/iPEM/rkIs4NWOxGGHWNEj7ZAAzW/4 5+vGVSxihs9zgJIxcgz4aQjHAFSdyglCBSVBXmLRh76xANptfIIZHfP1uw3eNvbR O4KwKJ5LESRnEP4xs3rVySWTfp9BDlBdJaEkapygTYBmrK1NBcqoYzqUaCaVfavx 6Zmsl/Qd2QjstGMX5N31oSSG1+xQ97htAGFc0pqqtGHiUihm9SQ= =65gg -END PGP SIGNATURE- diff --git a/debian/changelog b/debian/changelog index a3dd09e..86e4967 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +debian-archive-keyring (2023.4+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Standards-Version: 4.7.0 (routine-update). + * debhelper-compat 13 (routine-update). + * Remove trailing whitespace in debian/copyright (routine-update). + * Remove 7 obsolete maintscript entries in 1 files (routine-update). + * Migrated debian/copyright to DEP-5. + + -- Martin-Éric Racine Sun, 26 May 2024 09:36:32 +0300 + debian-archive-keyring (2023.4) unstable; urgency=medium * Clean up leftover keyrings in trusted.gpg.d diff --git a/debian/compat b/debian/compat deleted file mode 100644 index f599e28..000 --- a/debian/compat +++ /dev/null @@ -1 +0,0 @@ -10 diff --git a/debian/control b/debian/control index 6af283a..b5450d5 100644 --- a/debian/control +++ b/debian/control @@ -3,10 +3,10 @@ Priority: important Section: misc Maintainer: Debian Release Team Uploaders: Niels Thykier , - Jonathan Wiltshire , -Build-Depends: debhelper (>= 10), jetring, gnupg + Jonathan Wiltshire +Build-Depends: debhelper-compat (= 13), gnupg, jetring Rules-Requires-Root: no -Standards-Version: 4.6.0 +Standards-Version: 4.7.0 Vcs-Browser: https://salsa.debian.org/release-team/debian-archive-keyring Vcs-Git: https://salsa.debian.org/release-team/debian-archive-keyring.git diff --git a/debian/copyright b/debian/copyright index d934ced..e2c7a1b 100644 --- a/debian/copyright +++ b/debian/copyright @@ -1,27 +1,19 @@ -This is Debian GNU's GnuPG keyrings of archive keys. - -This package was originally put together by Michael Vogt - - -The keys in the keyrings don't fall under any copyright. Everything -else in the package is covered by the GNU GPL. - -Debian support files Copyright (C) 2006 Michael Vogt -based on the debian-keyring package maintained by James Troup - -Debian support files for debian-archive-keyring are free software; you -can redistribute them and/or modify them under the terms of the GNU -General Public License as published by the Free Software Foundation; -either version 2, or (at your option) any later version. - -Debian support files for debian-archive-keyring are distributed in the -hope that they will be useful, but WITHOUT ANY WARRANTY; without even -the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR -PURPOSE. See the GNU General Public License for more details. - -You should have received a copy of the GNU General Public License with -your Debian system, in /usr/share/common-licenses/GPL, or with the -Debian GNU debian-archive-keyring source package as the file COPYING. -If not, write to the Free Software Foundation, Inc., 51 Franklin Street, -Fifth Floor, Boston, MA 02110-1301 USA. +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Source: https://salsa.debian.org/release-team/debian-archive-keyring +Upstream-Name: debian-archive-keyring +Upstream-Contact: Debian Release Team +Files: * +Copyright: © 2024 Martin-Éric Racine + © 2021-2023 Jonathan Wiltshire + © 2017-2018 Niels Thykier + © 2014-2017 Adam D. Barratt + © 2010-2014 Philipp Kern + © 2008 Bastian Blank + © 2008-2009 Luk Claes + © 2007 Joey Hess + © 2006 Anthony Towns + © 2006-2007 Michael Vogt +License: GP
Bug#1071823: console-setup: [Hurd i386] debconf: lsmod: not found
Package: console-setup Version: 1.223 Severity: important While upgrading from 1.223 to 1.226 on Hurd i386: Fetched 32.4 MB in 23s (1429 kB/s) Extracting templates from packages: 100% Preconfiguring packages ... /var/cache/debconf/tmp.ci/console-setup.config.otOVsK: 1196: lsmod: not found -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.8+git20231217-486/Hurd-0.9 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages console-setup depends on: ii debconf [debconf-2.0] 1.5.85 ii hurd1:0.9.git20231217-1 ii keyboard-configuration 1.223 ii xkb-data2.38-2 console-setup recommends no packages. Versions of packages console-setup suggests: iu locales2.38-11 ii sysvinit-utils [lsb-base] 3.08-6 Versions of packages keyboard-configuration depends on: ii debconf [debconf-2.0] 1.5.85 ii liblocale-gettext-perl 1.07-6+b1 ii xkb-data2.38-2 Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center pn kbd pn systemd -- debconf information: * keyboard-configuration/variant: Finnish * keyboard-configuration/optionscode: * keyboard-configuration/modelcode: pc105 * console-setup/codesetcode: guess * console-setup/charmap47: UTF-8 * keyboard-configuration/compose: No compose key * keyboard-configuration/model: Generic 105-key PC * console-setup/store_defaults_in_debconf_db: false * keyboard-configuration/store_defaults_in_debconf_db: false * keyboard-configuration/toggle: No toggling console-setup/guess_font: * console-setup/fontface47: Fixed debian-installer/console-setup-udeb/title: * keyboard-configuration/other: console-setup/framebuffer_only: * keyboard-configuration/altgr: The default for the keyboard layout * console-setup/fontsize-text47: 8x16 * keyboard-configuration/layout: keyboard-configuration/unsupported_options: true * console-setup/fontsize: 8x16 keyboard-configuration/unsupported_config_layout: true * keyboard-configuration/ctrl_alt_bksp: false * console-setup/codeset47: Guess optimal character set console-setup/use_system_font: keyboard-configuration/unsupported_layout: true * keyboard-configuration/switch: No temporary switch * keyboard-configuration/layoutcode: fi * keyboard-configuration/xkb-keymap: fi keyboard-configuration/unsupported_config_options: true * keyboard-configuration/variantcode: * console-setup/fontsize-fb47: 8x16
Bug#1048703: NMU pushed to DELAYED/10
Hello Pierre, many many thanks for the upload. You just did what I was supposed to do, thanks for that. If you still have your PLM tree around, I'd appreciate if you could push them to the salsa git too. If you don't have that, that's not a problem. I'll try to fulfill my role at some point. Thanks again for your good work, Mt Le mercredi 22 mai 2024 à 23:08 +0200, Pierre Gruet a écrit : > Dear Maintainer, > > I have just uploaded fixes for bugs 1048703 and 1071082 to DELAYED/10. > This is to prevent testing autoremoval of plm on June, 11th. > > Enclosed is the source debdiff of this NMU. It is strictly based upon > the patches I submitted in the two bug logs. > > Please tell me if I should delay or cancel the foreseen NMU. > > Best wishes, > > -- > Pierre signature.asc Description: This is a digitally signed message part
Bug#1071732: [INTL:sv] Swedish strings for mailman-hyperkitty debconf
package: mailman-hyperkitty severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of mailman-hyperkitty debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the mailman-hyperkitty package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: mailman-hyperkitty\n" "Report-Msgid-Bugs-To: mailman-hyperki...@packages.debian.org\n" "POT-Creation-Date: 2018-03-14 12:21+0100\n" "PO-Revision-Date: 2024-05-24 12:43+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../templates:1001 msgid "Failed to determine MAILMAN_ARCHIVER_KEY" msgstr "Kunde inte fastställa MAILMAN_ARCHIVER_KEY" #. Type: note #. Description #: ../templates:1001 msgid "" "The Mailman3 Hyperkitty plugin needs an archiver key to authenticate against " "the Hyperkitty archiver. If 'mailman3-web' is installed locally, the " "archiver key is derived automatically from the setup." msgstr "" "Hyperkitty för Mailman3 behöver en akrivnyckel för att låsa upp Hyperkitty-" "arkiveraren. Om \"mailman3-web\" är installerad lokalt levereras " "arkivnyckeln automatiskt från den installationen." #. Type: note #. Description #: ../templates:1001 msgid "" "Please either install 'mailman3-web' and run 'dpkg-reconfigure python3-" "mailman-hyperkitty' afterwards, or configure the archiver key manually at '/" "etc/mailman3/mailman-hyperkitty.cfg'." msgstr "" "IAntingen installerar du \"mailman3-web\" och kör sedan 'dpkg-reconfigure " "python3-mailman-hyperkitty' eller anger nyckeln manuellt i /etc/mailman3/" "mailman-hyperkitty.cfg."
Bug#1071731: [INTL:sv] Swedish strings for eviacam debconf
package: eviacam severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of eviacam debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the eviacam package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: eviacam\n" "Report-Msgid-Bugs-To: evia...@packages.debian.org\n" "POT-Creation-Date: 2016-03-07 06:59+0100\n" "PO-Revision-Date: 2024-05-24 12:37+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:2001 msgid "Should eviacamloader be installed \"setuid root\"?" msgstr "Ska eviacamloader installeras med \"setuid root\"?" #. Type: boolean #. Description #: ../templates:2001 msgid "" "Installing eviacamloader with the set-user-ID bit set enables all users who " "have been added to the group \"eviacam\" to launch eviacam with a modified " "scheduling priority for better responsiveness." msgstr "" "Genom att installera eviacamloader med set-user-ID-biten aktiverad så kommer " "alla användare i gruppen \"eviacam\" kunna starta eviacam med justerad " "schemaläggningsprioritet för bättre resposivitet." #. Type: boolean #. Description #: ../templates:2001 msgid "" "Since this setting allows eviacamloader to be run with superuser privileges, " "it may have security implications in the case of vulnerabilities in " "eviacamloader's code." msgstr "" "I och med att denna inställning tillåter eviacamloader att köra med super-" "rättigheter kan det leda till säkerhetsbesvär om någon sårbarhet uppdagas i " "programkoden för eviacamloader."
Bug#1071730: [INTL:sv] Swedish strings for isa-support debconf
package: isa-support severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of isa-support debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the isa-support package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: isa-support\n" "Report-Msgid-Bugs-To: isa-supp...@packages.debian.org\n" "POT-Creation-Date: 2022-08-17 11:25+\n" "PO-Revision-Date: 2024-05-24 12:39+0200\n" "Last-Translator: Martin Bagge / \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../@n...@-support.templates.in:1001 msgid "Support for @NAME@ required" msgstr "Stöd för @NAME@ krävs" #. Type: note #. Description #: ../@n...@-support.templates.in:1001 msgid "" "Alas, your machine doesn't support the @NAME@ instruction set. It is needed " "by software that depends on this dummy package. Sorry." msgstr "" "Din maskin har inte stöd för instruktionssettet @NAME@. Detta behövs av " "mjukvara som har angivit detta paket som beroende." #. Type: note #. Description #: ../@n...@-support.templates.in:1001 msgid "Aborting installation." msgstr "Installationen avbryts."
Bug#1071729: [INTL:sv] Swedish strings for byobu debconf
package: byobu severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of byobu debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the byobu package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: byobu\n" "Report-Msgid-Bugs-To: by...@packages.debian.org\n" "POT-Creation-Date: 2013-01-24 18:31-0600\n" "PO-Revision-Date: 2024-04-29 11:10+0200\n" "Last-Translator: Martin Bagge \n" "Language-Team: Swedish \n" "Language: sv \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Do you want to launch Byobu at shell login for all users?" msgstr "Ska Byobu starta vid inlogg via skal för alla användare?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Byobu can launch automatically at login (e.g. console, ssh), providing an " "attachable/detachable window manager on the command line." msgstr "" "Byobu kan starta automatiskt vid inlogg via skalet (konsollen, SSH osv) och " "på så sätt tillhandahålla en fönsterhanterare för kommandoraden som går att " "lämna och återansluta till." #. Type: boolean #. Description #: ../templates:1001 msgid "" "If you select this option, Byobu will install a symlink in /etc/profile.d. " "This setting is system-wide, for all users logging into the system. " "Individual users can disable this by touching ~/.byobu/disable-autolaunch, " "or configuring with 'byobu-config'." msgstr "" "Väljer du att aktivera detta alternativ kommer Byobu installera en symbolisk " "länk i /etc/profile.d. Denna inställning slår då igenom på hela systemet för " "alla användare som loggar in. Enskilda användare kan stänga av detta genom " "att röra filen ~/.byobu/disable-autolaunch eller via inställningarna i " "'byobu-config'."
Bug#1071687: It's the lib
The bug is in python3-tvdb-api, not tvnamer as building a backport of 3.1-4 for bookworm makes tvnamer work again. apt list -a python3-tvdb-api Auflistung… Fertig python3-tvdb-api/now 3.1-4~bpo12+1 all [Installiert,lokal] python3-tvdb-api/stable,stable 3.1-2 all Would you consider uploading a backport of 3.1-4 to bookworm-backports to get tvnamer working again? Best regards, Martin signature.asc Description: PGP signature
Bug#1071687: tvnamer: Tvnamer throws traceback
Package: tvnamer
Version: 3.0.4-1
Severity: normal
Dear Maintainer,
when trying to use tvnamer it throws a traceback:
```
tvnamer --dry-run --name="The Rookie" --lang="de" Am\ Limit\
\[201027_0220_sendung_roo\].mkv
Loading config: /home/martin/.config/tvnamer/tvnamer.json
# Starting tvnamer
# Found 1 episode
# Processing file: Am Limit [201027_0220_sendung_roo].mkv
# Detected series: The Rookie (season: 2, episode: 20)
Traceback (most recent call last):
File "/usr/bin/tvnamer", line 6, in
tvnamer.main.main()
File "/usr/share/tvnamer/main.py", line 474, in main
tvnamer(paths = sorted(args))
File "/usr/share/tvnamer/main.py", line 370, in tvnamer
processFile(tvdb_instance, episode)
File "/usr/share/tvnamer/main.py", line 175, in processFile
episode.populateFromTvdb(tvdb_instance, force_name=Config['force_name'],
series_id=Config['series_id'])
File "/usr/share/tvnamer/utils.py", line 641, in populateFromTvdb
show = tvdb_instance[force_name or self.seriesname]
~^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1152, in __getitem__
sid = self._nameToSid(key)
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1136, in _nameToSid
selected_series = self._getSeries(name)
^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 935, in _getSeries
all_series = self.search(series)
^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 914, in search
series_resp = self._getetsrc(self.config['url_getSeries'] % (series))
^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 874, in _getetsrc
src = self._loadUrl(url, language=language)
^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 811, in _loadUrl
self.authorize()
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 859, in authorize
r = self.session.post(
^^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 635, in post
return self.request("POST", url, data=data, json=json, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 115, in
request
return super().request(method, url, *args, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 587, in
request
resp = self.send(prep, **send_kwargs)
^^
File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 127, in
send
cache_key = self.cache.create_key(request, **kwargs)
TypeError: create_key() got an unexpected keyword argument 'timeout'
```
Best regards,
Martin
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tvnamer depends on:
ii python33.11.2-1+b1
ii python3-pkg-resources 66.1.1-1
ii python3-tvdb-api 3.1-2
tvnamer recommends no packages.
tvnamer suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#1071591: CantPackException: bad DT_HASH nbucket=0x7
Package: upx-ucl Version: 4.2.2-3 Severity: normal Dear Maintainer, When trying to compress a golang linux/amd64 binary I get `CantPackException: bad DT_HASH nbucket=0x7 len=0xc6960`, see [here](https://salsa.debian.org/mdosch/go-sendxmpp/-/jobs/5756033#L53). This happens with bookworm-backports (see linked CI job) as well as with sid. Binary to reproduce: https://salsa.debian.org/mdosch/go-sendxmpp/-/jobs/5756033/artifacts/raw/linux-amd64/go-sendxmpp?inline=false Best regards, Martin -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages upx-ucl depends on: ii libc6 2.38-11 ii libgcc-s1 14.1.0-1 ii libstdc++6 14.1.0-1 upx-ucl recommends no packages. upx-ucl suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1071562: nfsd blocks indefinitely in nfsd4_destroy_session
Package: nfs-kernel-server Version: 1:2.6.2-4 Package: linux-image-6.1.0-21-amd64 Version: 6.1.90-1 During our tests of Proxmox VE with Debian NFS server as a shared storage we've noticed that nfsd sometimes becomes unresponsive and it's necessary to reboot the server. Probably the same error is reported here: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2062568 NFS server: * DELL PowerEdge R730xd, 2x 10C XEON E5-2640, Samsung SM863 SSDs, 8 GB RAM * fresh installation of Debian Bookworm * Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux * connected using 10GE link * nfsd.conf configured with nthreads=16 (also tested with 8 and 4), other options left on defaults * XFS mount exported with options: rw,sync,no_root_squash,no_subtree_check,no_wdelay NFS client: * DELL PowerEdge FC630, 2x 14C Xeon E5-2680 v4, 256 GB RAM * fresh installation of Proxmox VE 8.2 * Proxmox Linux 6.8.4-3-pve kernel * connected using 10GE link * nfs client mount options: rw,noatime,nodiratime,vers=4.2,rsize=1048576,wsize=1048576, namlen=255,hard,proto=tcp,nconnect=8,max_connect=16,timeo=600,retrans=2,sec=sys, clientaddr=10.xx.xx.xx,local_lock=none,addr=10.xx.xx.xx Dmesg on nfsd server side (repeats forever): [ 3142.693181] INFO: task nfsd:1035 blocked for more than 120 seconds. [ 3142.693217] Not tainted 6.1.0-21-amd64 #1 Debian 6.1.90-1 [ 3142.693239] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 3142.693264] task:nfsdstate:D stack:0 pid:1035 ppid:2 flags:0x4000 [ 3142.693273] Call Trace: [ 3142.693275] [ 3142.693279] __schedule+0x34d/0x9e0 [ 3142.693288] schedule+0x5a/0xd0 [ 3142.693294] schedule_timeout+0x118/0x150 [ 3142.693301] wait_for_completion+0x86/0x160 [ 3142.693307] __flush_workqueue+0x152/0x420 [ 3142.693317] nfsd4_destroy_session+0x1b6/0x250 [nfsd] [ 3142.693379] nfsd4_proc_compound+0x355/0x660 [nfsd] [ 3142.693433] nfsd_dispatch+0x1a1/0x2b0 [nfsd] [ 3142.693478] svc_process_common+0x289/0x5e0 [sunrpc] [ 3142.693551] ? svc_recv+0x4e5/0x890 [sunrpc] [ 3142.693631] ? nfsd_svc+0x360/0x360 [nfsd] [ 3142.693676] ? nfsd_shutdown_threads+0x90/0x90 [nfsd] [ 3142.693720] svc_process+0xad/0x100 [sunrpc] [ 3142.693790] nfsd+0xd5/0x190 [nfsd] [ 3142.693836] kthread+0xda/0x100 [ 3142.693843] ? kthread_complete_and_exit+0x20/0x20 [ 3142.693849] ret_from_fork+0x22/0x30 [ 3142.693858] Dump of nfsd threads: /proc/1032/stack: [<0>] svc_recv+0x7f3/0x890 [sunrpc] [<0>] nfsd+0xc3/0x190 [nfsd] [<0>] kthread+0xda/0x100 [<0>] ret_from_fork+0x22/0x30 /proc/1033/stack: [<0>] svc_recv+0x7f3/0x890 [sunrpc] [<0>] nfsd+0xc3/0x190 [nfsd] [<0>] kthread+0xda/0x100 [<0>] ret_from_fork+0x22/0x30 /proc/1034/stack: [<0>] svc_recv+0x7f3/0x890 [sunrpc] [<0>] nfsd+0xc3/0x190 [nfsd] [<0>] kthread+0xda/0x100 [<0>] ret_from_fork+0x22/0x30 /proc/1035/stack: [<0>] __flush_workqueue+0x152/0x420 [<0>] nfsd4_destroy_session+0x1b6/0x250 [nfsd] [<0>] nfsd4_proc_compound+0x355/0x660 [nfsd] [<0>] nfsd_dispatch+0x1a1/0x2b0 [nfsd] [<0>] svc_process_common+0x289/0x5e0 [sunrpc] [<0>] svc_process+0xad/0x100 [sunrpc] [<0>] nfsd+0xd5/0x190 [nfsd] [<0>] kthread+0xda/0x100 [<0>] ret_from_fork+0x22/0x30 /proc/130/stack: [<0>] rpc_shutdown_client+0xf2/0x150 [sunrpc] [<0>] nfsd4_process_cb_update+0x4c/0x270 [nfsd] [<0>] nfsd4_run_cb_work+0x9f/0x150 [nfsd] [<0>] process_one_work+0x1c7/0x380 [<0>] worker_thread+0x4d/0x380 [<0>] kthread+0xda/0x100 [<0>] ret_from_fork+0x22/0x30 On NFS client side, there's a number of backchannel reply errors: [78636.676789] RPC: Could not send backchannel reply error: -110 [78647.905675] RPC: Could not send backchannel reply error: -110 [78675.207201] RPC: Could not send backchannel reply error: -110 [78744.201603] RPC: Could not send backchannel reply error: -110 [78784.138769] RPC: Could not send backchannel reply error: -110 We're able to reproduce this bug quite often (several times a day) when restoring a 500GB virtual machine image from Proxmox Backup Server to NFS shared storage. On the other hand, we cannot trigger it by other ways like random and/or sequential I/O fio stress tests. According to iostat, the VM restore job writes to NFS server in 300-400 MiB batches separated by 3-4 secs of inactivity. Interestingly, this issue probably occurs only when using a recent kernel on NFS client side. We're able to hit this bug only with Proxmox Linux 6.8.4-3-pve kernel on NFS client side. When using Proxmox 6.5.13-5-pve kernel there're no client-side backchannel reply errors and nfsd server runs without any hungs. It seems to me that changes in NFS client code between 6.5.x and 6.8.x accidentally uncovered a race in nfsd server code. Based on the bug report #2062568 in Ubuntu I assume this is not a Proxmox-specific issue but Proxmox VM restore workload together with our testing hardware setup makes it easier to hit. Regards, Martin
Bug#1071489: tracker.debian.org: please upgrade Lintian to the latest
ma 20. toukok. 2024 klo 18.09 Lucas Nussbaum (lu...@debian.org) kirjoitti: > On 20/05/24 at 08:39 +0300, Martin-Éric Racine wrote: > > Package: tracker.debian.org > > Severity: important > > > > The Lintian on tracker.debian.org complains that 4.7.0 is > > newer-standards-version. > > > > Can you please upgrade it to the latest version? > > I think that tracker.d.o gets its lintian information from UDD (so the > data is the same as one available from > https://udd.debian.org/lintian/?email1=martin-eric.racine%40iki.fi=html_error=on_warning=on_tag=#all > ) > > As you can see in the footer of that page, UDD runs lintian 2.117.0. > That's the latest lintian version. > > So the real problem is that the lintian version in the archive doesn't > know about the debian-policy version in the archive... Noted. This really needs to become a streamlined process i.e. whenever a new policy is published, debian-policy and lintian get pushed into Unstable at the same time, and Lintian immediately updated on all applicable hosts. Otherwise, Lintian generates false positives on newer-standards-version and also misses new things it should check to match compliance with the new standard, all of which needlessly complicates package maintainers' job. Martin-Éric
Bug#1071489: tracker.debian.org: please upgrade Lintian to the latest
Package: tracker.debian.org Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The Lintian on tracker.debian.org complains that 4.7.0 is newer-standards-version. Can you please upgrade it to the latest version? Thanks! Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZK4hAACgkQrh+Cd8S0 17ZFURAAp9KXen+WQbxVK+guJxZGlyounwk1mUh/Y1wU1nTNkYZUc4FiUmUbboo+ suzPRjMaovnsXZtDkhBWaz0jLRf/F4ZleLW2WoEgd9t61+PnAOJ2J3GR4kfoYTT0 Dh/jBX6IWVGfhcT7U7rcrfIZHrn7Vi1+58T9mN4WnW6ja19M5ruBbmOik9Bt+zol pBKEdSFdlNORt+b1yO7Kvz/vQOaOUZrtOUfEBl8L23LPJPger1P0BVcl1410hHXs I1kq3fHT7+2wzpEaiziTbVH/eLWaOEAZCIkvqbKXfQbS5n8GvaIXFhcYN3PtEJJO qfcrSZth7fMH0YOd9klkQ4i4C8SFI5R6FqPUIkifTb4xKfAa6GBU8tG7WxGz8Sja rqSWr1A4uw+Q8A1MAjlLOVZGNYx71tN25nGcYdWtwnW0sYxTouAbsl+c7iLSIPu5 MIuNtnPb4kB1iSVJdF4vgfZ5DVk9THh72neCUe40tiq3IlPA1qjFs8Gzstr7V6UX m9wbqxHAAhVwQt/fIlRd0cFcWkq2/1de3Fpi4BabC6M8RtiXvD7tDG4eBv/m7gfc OFLqhzHIcA72rLs4SoIiaFkMO1YiHgnP1Ko301crS92gfZdTgLBG8ofbaE9PbkuY 8MNjLtPPBrQUWuj6w/7cGsK6u7he0qCEjK7+fP4b6dXz49axuIw= =hj3T -END PGP SIGNATURE-
Bug#1070726: nvidia-kernel-dkms wont build with latest bullseye kernel 5.10.0-29-amd64
> There is already a newer driver version in oldstable-proposed-updates. > Does it fix the issue? Perhaps that was just a question out of politeness, and I’m not the OP, but it did for me. Thank you both - so much easier when a search engine query shows that someone else has gone first.
Bug#1070891: apt-show-versions: Permission denied on a bad pathname
Am 14.05.24 um 10:39 schrieb Vincent Lefevre: This could explain the error. I'm wondering why apt plays with the permissions. This is confusing. Or should there be a locking mechanism? This reminds me about the long due rewrite to use the apt-API to access these files and not read them directly. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070891: apt-show-versions: Permission denied on a bad pathname
Hi Vincent, Am 13.05.24 um 19:59 schrieb Vincent Lefevre: On 2024-05-13 17:12:57 +0200, Christoph Martin wrote: Please try to access the file e.g. 'less /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease' No problems. You could try to prepend strace to your cron call like: strace -o /tmp/asv.$$ -e trace=file apt-show-versions -u and look for the failed syscall. Did you look for selinux or apparmor messages in syslog? Christoph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071093: libc6: [adequate] undefined-symbol
Package: libc6 Version: 2.38-11 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 $ adequate --all --tags -py-file-not-bytecompiled libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_pdwrite libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_pglobal_lookup libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_lsetregs libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_getpid libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_lgetfpregs libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_lsetfpregs libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_lgetregs libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_pdread - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages libc6 depends on: ii libgcc-s1 14-20240429-1 Versions of packages libc6 recommends: ii libidn2-0 2.3.7-2 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.86 pn glibc-doc ii libc-l10n 2.38-11 pn libnss-nis pn libnss-nisplus ii locales2.38-11 - -- debconf information excluded -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDD1wACgkQrh+Cd8S0 17ZR7w/+OsMP7IW5GyIghTc+CkaIYuD6qT0a4v8SeNtfER5h1Y5THEx7Nylp02yz fkS3RdsDa+GK3kMxOLK/OgNJ5Xv46ULX0/Dov+2OSHXcSMIuq3GwBwy4IZWN22WU TDLwTl9+CPY3yX6v+03CpyoJTvb7dT2g4tgCamR1lOTwpmwg2gO9O5QBhB3gYGCb i9+LatQMKWTnPc3MOKiVR3ABSGRGvoUB0Re51qdRyojq1w8cgzzCQeHsZYsM7ovX oLMcMBXlvyL4/nQYkI+CMZwHabCM0RLCrUsb2lowcHi3bs66nK/p4LkiO68Za2vH /kp7vykd5Sd+M08PatNxHQSUujmXPj+fQb6DwQtRVI85BlrSnUcuAOis/OUnk8uM fjloB0svB47BFH4RGcggYGn5lTKKDoLRo1qxx1f3PLdvxyFqhliBL5ZJDu5ETi94 1QRmV8MfnSpGA1I1VSSPlmTjs9NiNMK0hJMGHVmQVzq/xmAt+m4ITbc6iyxs4mzu bRdNRmkfhaJid+RZhkzwkIX77SlgvQXnN/ujvo/T2Q/xIgXoTCGgRnVf9IkglfmK AcrH8CrkEr0KxDnlHWidSx5kiEmdUYavslAxROnDrSLTSk/Dnx8qSv65l6oBfr2f Eq+83yv7BGHzjuu0T0tsIyGhYB+M0zgKD5nTCoUWTDtaWH/MEt0= =xNVU -END PGP SIGNATURE-
Bug#1071091: systemd: installs broken symbolic links
Package: systemd Version: 255.5-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 $ adequate --all --tags -py-file-not-bytecompiled systemd: broken-symlink /etc/modules-load.d/modules.conf -> ../modules - -- Package-specific info: - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages systemd depends on: ii libacl12.3.2-2 ii libapparmor1 3.0.13-2 ii libaudit1 1:3.1.2-2.1 ii libblkid1 2.40-8 ii libc6 2.38-11 ii libcap21:2.66-5 ii libcryptsetup122:2.7.2-2 ii libfdisk1 2.40-8 ii libgcrypt201.10.3-2+b1 ii libkmod2 32-1 ii liblz4-1 1.9.4-2 ii liblzma5 5.6.1+really5.4.5-1 ii libmount1 2.40-8 ii libpam0g 1.5.3-7 ii libseccomp22.5.5-1 ii libselinux13.5-2+b2 ii libssl3t64 3.2.1-3 ii libsystemd-shared 255.5-1 ii libsystemd0255.5-1 ii libzstd1 1.5.5+dfsg2-2 ii mount 2.40-8 ii systemd-dev255.5-1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii systemd-timesyncd [time-daemon] 255.5-1 Versions of packages systemd suggests: ii libbpf1 1:1.4.1-1 ii libfido2-11.14.0-1+b2 ii libip4tc2 1.8.10-3 ii libp11-kit0 0.25.3-5 pn libpwquality1 pn libqrencode4 pn libtss2-esys-3.0.2-0 pn libtss2-mu-4.0.1-0 pn libtss2-rc0 pn libtss2-tcti-device0 pn polkitd pn systemd-boot pn systemd-container pn systemd-homed pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.10-4+b1 pn dracut pn initramfs-tools ii libnss-systemd 255.5-1 ii libpam-systemd 255.5-1 pn udev - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDDsEACgkQrh+Cd8S0 17ashA//VRcFHX1hLvzXIS1nF3+EnHkKgtllDpQwQbyjtSYZqcfyQ33LAPWdLAQB cqyUhc8+Swm5vksaBQPv2tGt2wrCft8UAhFiBWLTsrC2vD4R6bRr8+CcNboj3AWH 7XOpQf/h8Ow9NIjhhy97gF3njBBrsl4g5zhrgWweL9QTlQCvfxwaYEt3dv11+dJq x2EfXTf5jpKHnHXHTIA51rqzrlDOLBwpchQ123Pmw1Wo6QXYNkfyQqbhjFW0Ne9+ PB/dHsiq9hkBOuhQYjdQ75RfuYqoGN+QK5tVpBTotOu4z+t0sDwOsvlbz/Q5uBMn UXlORLWb/LYahGO1+HCEgGKif0pb8HL69MA/GC6qSF/rRyDlr7JE7yLeqb2ac2z8 HmHwAfG5CVEI7PuOwCN9b+YBz5d798KkuEJRdP64pczxAr9Bk2QA/nnjWz+SQlLZ FJ0N30mqi1/4kQPu9KHChBR0vzTt1vUYtY+qun6kWvb2poScfyfMSbQo1rN8/B4B Ls89uAzUmj03LKOisXeWLDgBoqKg/Nvj4/P8Ydoluy4lvY9BqK/4OWwVwXBwoXHi IwV57IAveVx9/Mgqg/Rcik5l+9iiEdnXgHv1N6jTmTTA2+JMTnEqN8ihAeo3otmW UwFBnsIPn4zbKBr2cjw3+l86oR/txkGtDUbGcHYvhjh5tBwjne4= =Zkx7 -END PGP SIGNATURE-
Bug#1071090: iso-codes: installs broken symbolic links
Package: iso-codes Version: 4.16.0-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 $ adequate --all --tags -py-file-not-bytecompiled iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166.mo -> iso_3166-1.mo iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166_2.mo -> iso_3166-2.mo - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect iso-codes depends on no packages. iso-codes recommends no packages. Versions of packages iso-codes suggests: pn isoquery - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDDl8ACgkQrh+Cd8S0 17ZYLhAAsnzBthGEae4tlpZAjIy6yZ9LDDo4Pgujlz7br1cqKm19fHqd3Di/7W0N qaNS5zFG86hEvDe5UClmTVIx40yI6r+LsKc6tHMLfVZc25cSYEkKG/RhquNF7H5X eDXfPwXDhv85CrvHjW4fA1DlRK5lcjEie7WjVK9p2sl+BzmkCbARiopRnD2YIqzs sp0lzWz0w6Lryv8COJOJ6PV3i27WHL4WZVPedSyOkHkHEb4rrpAja59Xr3s37cas VV1zrjtnreQU7hbQsQjMUeLlC2v0I+/pQNIArFrz8dXxBuYr63xCZE7TPU3j9ANt jC2UrmPGgrm0JuXtcwoeLPbhR7rVhXLhfw64hl21IAVOHJg4E6QkhdvrYO8MIKLk 9m9Sc9KiSU4TodrXDdaNoY/vBqhGNnUakZA2O5+LQTGCcagaOv0nni8D3h8YbKng 5HzDcn2dz+qbtrCGFlm7sjn7Pb3oydXzVJgr9EpRDljzps2+/00wg2RG9XSGTC4e nHhOHnODQlropYkT46kCUD40bFvAgwZ41iykYHAHAJW1/C8dDvPH7OyzFDB3296Q Rpx9YY0CLVRj9otwrcj9Si2ZPx9SD6JXExt0PQ51dFD/VoZIq9hVtnJyV4Te3y6o Brofp0caZHJt7XBwHAtGe1nRk/9iKc+pGA37FKIWY8X5E0S7xZ0= =bqAZ -END PGP SIGNATURE-
Bug#1070891: apt-show-versions: Permission denied on a bad pathname
Hi Vincent, Am 13.05.24 um 15:34 schrieb Vincent Lefevre: I don't know why could cause the error, but the pathname with "//" is incorrect. // in the path should not be a problem. zsh completion cannot handle it, so I was wondering. Please try to access the file e.g. 'less /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease' Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions? lrwxrwxrwx 1 root root 25 2024-05-11 22:36:06 _var_local_apt_._Packages -> /var/local/apt/./Packages drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles -rw-r--r-- 1 root root52957 2024-05-11 16:15:34 debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease -rw-r--r-- 1 root root 308541 2024-05-08 22:34:42 debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages -rw-r--r-- 1 root root49779 2024-02-10 12:17:11 debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease -rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages What is _var_local_apt_._Packages? Can you access this files content? Apart from that, I can't spot a problem. Christoph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1070891: apt-show-versions: Permission denied on a bad pathname
Hi Vincent, Am 11.05.24 um 11:53 schrieb Vincent Lefevre: Package: apt-show-versions Version: 0.22.15 Severity: normal When running "apt-show-versions -u" in a cron script, I got Failed to open file /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease for reading: Permission denied I don't know why could cause the error, but the pathname with "//" is incorrect. // in the path should not be a problem. Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions? Which user does the cronjob run with? Christoph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1036826: Please start handling \c
Le dimanche 12 mai 2024 à 17:26 +, Helge Kreutzmann a écrit : > > Did you receive my e-mail from this morning, where I compiled the > remaining examples I'm aware of? Yes I did (sorry for answering earlier before reading all mails in inbox), but I did not dig into it yet. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1036826: Please start handling \c
Hello Helge, Le samedi 11 mai 2024 à 03:31 +, Helge Kreutzmann a écrit : > Hello Martin, > Am Fri, May 10, 2024 at 06:55:38PM +0200 schrieb Martin Quinson: > > > > If you have other failures from other pages, please tell me so that I can > > check > > whether my fix is enough even before the release. > > I can do so tomorrow afternoon, if this has time until then (I have > limited access atm). No rush. If some problems presist, I'll try to fix it afterward. Enjoy your stay, Mt signature.asc Description: This is a digitally signed message part
Bug#1036826: Please start handling \c
tag 1036826 fixed-upstream thanks Hello Helge, I think I fixed this bug upstream, and it will be part of the next release, later this month. I did not implement a full support for \c since it's difficult in the current code base, but at least the groff.1 page proceeds. If you have other failures from other pages, please tell me so that I can check whether my fix is enough even before the release. Thanks for your help and patience, Mt Le jeudi 14 mars 2024 à 19:56 +, Helge Kreutzmann a écrit : > Hello Martin, > Am Sun, Mar 10, 2024 at 10:14:20PM +0100 schrieb Martin Quinson: > > Instead, I'd appreciate if you could do a merge request with a test file, > > along > > with the expected output. It'd save me the time to dig into the discussion > > of > > this bug. > > > > I'm not saying that I won't fix it w/o this test case. I'm just saying that > > providing a test case is a better approach to speedup the fix than severity > > abuse. > > I hope explaining the test file in this bug is fine as well, because > I'm not sure what to do exactly merge and how. > > The test case is groff(1) as it is in Debian unstable: > > $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim > --option generated --option > untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U > NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master groff.1 -M > utf-8 -p test.pot > groff.1:2279: (po4a::man) > Escape sequence \c encountered. This is not completely > handled yet. > > And there is no output. > > If I do a crude preprocessing, it kind of works: > > $ cat groff.1 | perl -p -e 's/\\c\n//' > groff.test.1 > $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim > --option generated --option > untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U > NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master > groff.test.1 -M utf-8 -p test.pot > $ wc -l test.pot > 3157 test.pot > > I hope this helps you working on this, together with the discussion in > this bug. > > Thanks for your support! > > Greetings > > Helge signature.asc Description: This is a digitally signed message part
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
Hi Tobias, hi Lorenzo. Tobias, thanks for looking into this sponsoring request! I appreciate it. Tobias Frost - 11.05.24, 10:24:31 CEST: > On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote: > > Control: block -1 by 1067525 > > > > this fix need to go to unstable because elogind 255.4.1 is already > > there, but runit-services depends on runit > 2.1.2-56 (unstable is at > > 2.1.2-54) so 1067525 needs to be uploaded first or together with this > > one, otherwise runit-services is not installable > > Ok, just saw that one. > Please note that this fact must be stated in d/changelog, something like > "Upload to unstable." FWIW I run runit 2.1.2-59 and runit-services together with elogind 255.5-2 on two Devuan Ceres systems with KDE's Plasma desktop. One I had patched manually, but I made sure the package version of the run dir for elogind was installed after the upgrade. The other one was upgraded regularly from elogind 252 and older runit / runit-services packages. Runsvdir starts elogind correctly from the new path. I also reviewed the changes to the package for the updated path for elogind and I think they are correct. I am certainly no expert with runit, but as I contributed zcfan service dir at least I know something. Devuan uses the upstream packages for runit, runit-services, dash, bash so I expect that runit-services 0.7.2 will work just fine on Debian, too. It would unbreak running elogind for runit users that did not patch their systems manually already. I bet most of them did by now, as many desktop environments do not work well, if at all, without some systemd-logind replacement. And the timeouts with login into a TTY or SSH session without some systemd-logind replacement are quite annoying as well. Sure we are still talking about a (small) minority of Debian users here. Hope this helps regarding the review of the package and the sponsoring. In case any further changes need to be tested before upload, I am willing to do that. Best, -- Martin
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hi Lorenzo. Lorenzo - 11.05.24, 02:16:15 CEST: > On Tue, 07 May 2024 15:08:37 +0200 > Martin Steigerwald wrote: > >[...] > > Are init scripts supposed to be started with PATH variable set up and > > exported or not? How is it done with SysVInit? I bet it would be best > > to match as close as possible what SysVInit is doing to be as > > compatible as possible. > > I checked this and in sysvinit you don't have this bug because during > boot sysvscripts are run via /etc/ini.d/rc script, and there is an > 'export PATH' there. It could probably be triggered by calling the > script directly during runtime. > In runit we are calling scripts directly in stage1 so we have this bug I see. > > Otherwise it might be challenging to chase and find all the corner > > cases with existing setups. And as there is no issue initializing the > > network in the container with SysVInit instead of Runit used as PID > > 1, I'd consider a change in Runit. At least it could be challenging > > to find whether networking inside a container is the only thing that > > breaks. > > I want to dig this further, I don't recall broken network under docker > and I don't think is broken under qemu, but I can be wrong or remember > something from before /etc/init.d/rc usage was dropped from stage1 Could have something to do with Incus / LXD then. I used Incus in Devuan testing (upcoming Excalibur), which is based on Debian testing (upcoming Trixie). In case it is helpful for you I could post a step to step guide for a minimal Incus setup and/or at least some pointers. > > > > I just wonder why stage 2 contains /usr/local bin directories. I > > > > think that should not be the case. Shall I report this as a > > > > different issue? > > > > > > PATH is passed to env call for runsvdir, so I guess one can exec a > > > bin from local as runscript (not sure) without setting the PATH. I > > > can't think of other use cases.. […] > > Hmm, I get that. I am just a bit concerned as it may be a security > > issue. > > not urgent, but could you elaborate this (security implications)? is > something like an attacker placing a modified foo in /usr/local/ that > overrides the legit foo in /usr/bin or is something else? one still > needs root privileges to write to /usr/local.. Good question. It is how I learned it. :) Yes, usually /usr/local is only writable by root, however… maybe an admin or user with root privileges put some own version of say coreutils or whatever in there for whatever reason and forgot about it. And later on it has some security whole that remains unpatched. With PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin a vulnerable command might be picked up from /usr/local's s(bin) as it is even before the regular system managed (s)bin directories. Yes, you can consider that an user error, but there might even be other scenarios, like an user or admin installed some special version of ls or some other command in there as they prefer it. Even if the behavior or such a special replacement command is only slightly different than of the original system default command it could cause all kinds of trouble. I believe this may be some of the reasoning behind the rule I learned about to only have system directories in PATH for system provided scripts and programs. It at least appears to me like the approach of least surprise. /usr/local, only root-writable or not, is user managed. There could be anything in there causing all kinds of various trouble. A compromise here would be to change the path like this: PATH=/usr/sbin:/sbin:/usr/bin:/bin:/usr/local/sbin:/usr/local/bin With that order at least a modified "ls" from /usr/local/bin would not be picked up as there is a system managed one available. But a command that is not available in system managed directories would still be picked up from /usr/local directories. As one point of practical experience, I changed path to PATH=/sbin:/usr/sbin:/bin:/usr/bin in one Incus managed Devuan container which runs a Wordpress blog on Apache and PHP FPM and I see no issues. However as I also don't have anything in /usr/local that is to be expected. One approach could be to just change the path to the above system managed directories only path, add some NEWS.Debian entry about it and see whether someone complains :) I do think this discussion belongs into a different bug report though. I am willing to open a low priority report about this and include the previous relevant discussion to it, so it does not get lost and you can take your time to ponder about it. There is no need to rush it. Have a great weekend! -- Martin
Bug#1036826: Please start handling \c
tag 1036826 fixed-upstream thanks Hello Helge, I think I fixed this bug upstream, and it will be part of the next release, later this month. I did not implement a full support for \c since it's difficult in the current code base, but at least the groff.1 page proceeds. If you have other failures from other pages, please tell me so that I can check whether my fix is enough even before the release. Thanks for your help and patience, Mt Le jeudi 14 mars 2024 à 19:56 +, Helge Kreutzmann a écrit : > Hello Martin, > Am Sun, Mar 10, 2024 at 10:14:20PM +0100 schrieb Martin Quinson: > > Instead, I'd appreciate if you could do a merge request with a test file, > > along > > with the expected output. It'd save me the time to dig into the discussion > > of > > this bug. > > > > I'm not saying that I won't fix it w/o this test case. I'm just saying that > > providing a test case is a better approach to speedup the fix than severity > > abuse. > > I hope explaining the test file in this bug is fine as well, because > I'm not sure what to do exactly merge and how. > > The test case is groff(1) as it is in Debian unstable: > > $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim > --option generated --option > untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U > NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master groff.1 -M > utf-8 -p test.pot > groff.1:2279: (po4a::man) > Escape sequence \c encountered. This is not completely > handled yet. > > And there is no output. > > If I do a crude preprocessing, it kind of works: > > $ cat groff.1 | perl -p -e 's/\\c\n//' > groff.test.1 > $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim > --option generated --option > untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U > NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master > groff.test.1 -M utf-8 -p test.pot > $ wc -l test.pot > 3157 test.pot > > I hope this helps you working on this, together with the discussion in > this bug. > > Thanks for your support! > > Greetings > > Helge signature.asc Description: This is a digitally signed message part
Bug#1070735: micro-httpd: debian/copyright update attached
Source: micro-httpd Version: 20140814-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Authors for the Debian folder content are updated. See attachment. Martin-Éric - -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmY7HcoACgkQrh+Cd8S0 17aT7A//QBnHF7BnwdrluacAzTnY+0GY5sNFTG42RRnL/s3VU3aNetQLQCJGz1ow RZ/je9Jr8JzMtR6usv/eoRyH3YhrDwzu8ZjDm5/395tVNAgJPEBzl1NtDfGMujMT JRY04EtdcSvj0rSXF0jxHauI+tARvtGyiNTS95cUEB9Tyb0dEz5F+II41aEJwjN6 8YjMYBzTgQxAho/vDFVUzazinFCmBJiHMoqxHz85wNXaG2tdckwI6L4zI+UWoW9P 2BaT6nDcwkahiUZ/Ry1QnNdK5e720dshfaFE22+5Rem4U1zmxz8v/vzFGWelB4+8 6c8IU19aiVLNnQbGp7zlFukB2jkyqHdO9veBmxZfzP0cdaECbhdUGwSPWLuySiTD ZCHjiiCBsLMEx+1gIwGiPvKx1L0Dhc3m1hIrB3KHBo51ZIV/9ZfyOCJDvJ0VDNWC 5gJrkKT6LDSYXGOeIkmpAh1hFe1LqNtAW8ovQhh+EWh0gjeqS2GxHaC+C3RDDCFn 26Fb2oXg4UjEd0LrH2sJKTZQrdzhjuuHim3qkVJOgjyCKYmv6H3VRI/9AW23EB7L xbyNKpmFysZlfsIMExBzPyLB4wf9Z5C18oA+9n0vo9TPDzRwtLpkif+zIaZfYt66 UTF1Kr0jTu9r+70P5eOxx2RMjkwAToy9iBwPjyc0k1bHNkgl8W4= =/kLu -END PGP SIGNATURE- --- a/debian/copyright 2024-05-04 14:01:59.0 +0300 +++ b/debian/copyright 2024-05-08 09:34:55.977467089 +0300 @@ -10,6 +10,9 @@ License: BSD-2-Clause Files: debian/* Copyright: + 2021-2024 Martin-Éric Racine + 2019-2024 Sudip Mukherjee + 2016 Christian Hofstaedtler 2009-2012 Jari Aalto 2004-2007 Daniel Baumann License: BSD-2-Clause
Bug#1070734: micro-httpd: Lintian-brush fixes attached
Source: micro-httpd Version: 20140814-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please find attached some minor fixes performed by Lintian-brish. Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmY7Gj0ACgkQrh+Cd8S0 17b09g/8CSJpwhTaLIQryL66OUUV2GaAzkr6Q+aTDFH7jhLG+gB3vEAkzJAEetgg NiNGRQ0eDeYef1EGvAQmnmDbVCiNQPQYAHyHgnivFnawk5bGrHGqS83d3yuSO9rw 6ayFDuameg4gAZ+IXdWm9xjk9U/AXc7cOyVyg+vpG+gq2VworPjAg1smCCXcfw/Y 8O24SxIR0NekVW3i936Tov7/VfN2pnMEJICiAnagIS6f/OITrl0BW9bYWi0YGoYN 22siaPW2Ha6VQOkgeRQotDsXFig0KRHNfAfu18rvCOzoZIlYF99G/2VnbJj0c+VX xKeABJBoZcsl/aCNOx/3ljRLdrMgsUg4ejXgGqzlql2+UkROGWfraVUkZ/XYfKHC 1HntIh7JOO2fvbaa+S6dzC25Wc9imTD6fS+1hX7nsy9N0i7W1E3GkqwG9r94NJll mLhnHNAf3KR7UCeNE4m07F9f0zwHtFbhC0zkbI9uFbH2zf+LyQ/s2+HOl+YHixvj srKlZWxGYCOZazdn0JTp8fCszgc8hbuHHKfX1NUBgvdK27ePaTy/BRKFQ9Bc+QTB LjioSER1B0Il+zWAZ8B1yo/85xHxui1G/f1ft6+tyrPTv4nRhKQbTC8JUkE5PASJ BVssPL6+4Vg5T/4+Go5abFHx8vfiHJNpHQff8HYGhIt+s+q7sVE= =Q5j4 -END PGP SIGNATURE- diff --git a/debian/changelog b/debian/changelog index 40bbe2b..1a9fcf6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +micro-httpd (20140814-4) unstable; urgency=low + + [ Debian Janitor ] + * Update watch file format version to 4. + * Avoid explicitly specifying -Wl,--as-needed linker flag. + + -- Sudip Mukherjee Mon, 06 May 2024 16:34:16 +0300 + micro-httpd (20140814-3) unstable; urgency=medium [ Martin-Éric Racine ] diff --git a/debian/rules b/debian/rules index 14be6bb..9f3b272 100755 --- a/debian/rules +++ b/debian/rules @@ -8,7 +8,6 @@ include debian/debian-vars.mk export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic -export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed man: # target: man -- convert *.pod to manual page diff --git a/debian/watch b/debian/watch index 77f22e8..65061e7 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,2 @@ -version=3 +version=4 https://www.acme.com/software/micro_httpd/ .*micro_httpd_(.+).tar.gz
Bug#1026061: [+externe Mail+] Re: Bug#1026061: bart: FTBFS randomly in bullseye (failing test)
Am Dienstag, dem 07.05.2024 um 19:23 +0200 schrieb Santiago Vila: > El 7/5/24 a las 18:50, Uecker, Martin escribió: > > Am Dienstag, dem 07.05.2024 um 17:59 +0200 schrieb Santiago Vila: > > > El 1/1/23 a las 16:55, Uecker, Martin escribió: > > > In the meantime, I became member of debian-med, so in theory, > > > I could fix this myself via team upload. Would you prefer > > > that I take care of this myself that way? > > > > I wouldn't mind if you did. There are some other bugs > > which could easily be fixed with a new upload (i.e. with > > minor patches in the bug tracker) > > > > > > (I would also handle bart-cuda, also affected but not reported yet) > > > > bart-cuda needs to be updated to 0.9.00 which should > > be straightforward in principle but need more work > > and a binary upload. > > Well, just in case: I'm talking about making an upload > for bullseye, using the same fix in bookworm, then > sending a bug to release.debian.org explaining the > issue, etc. > > That's mainly bureaucratic and will not interfere with your normal > work in unstable regarding new upstream releases and such (which > I still prefer not to handle myself). > Yes, if you do not mind to do the work, please update bullseye. That would be much appreciated. Martin
Bug#1026061: [+externe Mail+] Re: Bug#1026061: bart: FTBFS randomly in bullseye (failing test)
Am Dienstag, dem 07.05.2024 um 17:59 +0200 schrieb Santiago Vila: > El 1/1/23 a las 16:55, Uecker, Martin escribió: > > I can apply the patch, but I do not have much time now. > > Is there some urgency? > > Hello. A lot of time passed without activity on this bug. > > In the meantime, I became member of debian-med, so in theory, > I could fix this myself via team upload. Would you prefer > that I take care of this myself that way? I wouldn't mind if you did. There are some other bugs which could easily be fixed with a new upload (i.e. with minor patches in the bug tracker) > > (I would also handle bart-cuda, also affected but not reported yet) bart-cuda needs to be updated to 0.9.00 which should be straightforward in principle but need more work and a binary upload. Otherwise, I would have more time in July to do some work. Martin > > (Yes, I still think it would be worthy to fix this in bullseye, > for posterity and before it becomes LTS). > > Thanks.
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hi Lorenzo. Sorry for late answer. Lorenzo - 14.04.24, 11:36:32 CEST: > On Sat, 13 Apr 2024 15:05:41 +0200 > > Martin Steigerwald wrote: > > Martin Steigerwald - 13.04.24, 14:32:16 CEST: > > > Any idea how to find the cause of what is happening here? > > > > I found the cause: > > > > The container starts out with an almost empty environment. In > > [...] > > > > root@zdevuan:~# cat rcS.log > > > > >> environment > > > > container=lxc > > PWD=/ > > > > >> end of environment > > > > No PATH defined. > > > > The script defines it. See line 8 in my changed script. However it > > > > does not export it. Thus adding line 9 fixes the bug I reported: > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > > 9 export PATH > > > > The network is configured just fine after adding that line. > > > > Same goes for stage 2. In /etc/runit/2 I added: > >[...] > > > > Exporting the PATH there as well like > > > > 1 #!/bin/sh > > 2 > > 3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin > > 4 export PATH > > 5 SVDIR=/etc/service > > > > fixes > > > > root@zdevuan:~# cat /etc/boot.d/network > > #!/usr/bin/env sh > > > > /etc/init.d/networking restart > > > > The network is configured even without the "export PATH" fix in > > /etc/runit/1. > > OK, so if I undertand correctly we either export PATH in the > /etc/init.d/networking script or we export PATH both in stage 1 and 2 > (so the script does not fail during boot and can be called during > runtime): is that correct? In case it is called during both stage 1 and stage 2, yes. And yes, it appears there is a link to the networking script in /etc/rcS.d which would be called in stage 1. > If yes I think it's better to fix the networking script (ifupdown pkg) > so that the fix works for sysvinit users too. Yeah, I would think so to, but: % grep PATH /etc/init.d/networking PATH="/sbin:/bin:/usr/sbin:/usr/bin" Yet, it has no export statement, it just defines the variable. What may be happening here is that something called from the script requires a valid path, but without export the variable would not be exported to that something. So it might be that the networking script needs an "export PATH" added to it. However: > Different story if multiple scripts fails during boot because of empty > PATH; many scripts in /etc/rc.S/ set their PATH but others don't.. > Could you confirm that no other scripts fails in your container setup > when PATH is not exported in stage 1 ? There are some script which do not set a command search path: % grep -L "PATH" * README brightness checkroot-bootclean.sh hwclock.sh mariadb mountall-bootclean.sh mountnfs-bootclean.sh mountnfs.sh procps rcS sudo I am not sure whether those work correctly or not. Some are not even supposed to work inside a container at all. What I wonder: What is the supposed default or standard here? Are init scripts supposed to be started with PATH variable set up and exported or not? How is it done with SysVInit? I bet it would be best to match as close as possible what SysVInit is doing to be as compatible as possible. Otherwise it might be challenging to chase and find all the corner cases with existing setups. And as there is no issue initializing the network in the container with SysVInit instead of Runit used as PID 1, I'd consider a change in Runit. At least it could be challenging to find whether networking inside a container is the only thing that breaks. Of course in case PATH variable needs to be setup, one might argue that Incus/LXC needs to do it, cause networking is setup just fine even with Runit in physical machines or VMs. So far the container appears to be working, but I did not check whether every single init script works correctly. Partly due to bootlogd not working inside the container. > > I just wonder why stage 2 contains /usr/local bin directories. I think > > that should not be the case. Shall I report this as a different issue? > > PATH is passed to env call for runsvdir, so I guess one can exec a bin > from local as runscript (not sure) without setting the PATH. I can't > think of other use cases.. > I'm fine with removing, just a bit wary, I'm afraid to break some custom > setup Hmm, I get that. I am just a bit concerned as it may be a security issue. > > I added empty "debug" and "verbose" files in /etc/runit but did not > > find any debug output. Maybe those files needed to have some content. > > Maybe it requires bootlogd. > > those files only work for runit stuff (runscripts and the sv trigger), > boot scripts are for sysvinit and do not obey to runit settings :( > perhaps it's time to roll some native runit bootscripts.. I see. Well that would be great. But also would require a lot of work and testing I bet. Best, -- Martin
Bug#1070680: freeipa-client: unable to convert the attribute 'cacertificate;binary' value
Package: python3-ipaclient
Severity: important
Version: 4.11.1-2
Tags: upstream, fixed-upstream
Forwarded:
https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/thread/PLR7R2FIZXNOQFMT3XWMBK3UYI7FWVMY/
Hello,
A few days ago, python-cryptography 42.0 entered Debian testing. This
unfortunately breaks FreeIPA. When joining an existing IPA server (running on
CentOS 8, but doesn't matter much), joining the domain fails with
| unable to convert the attribute 'cacertificate;binary' value b'0\x82[...]' to
type
| Cannot obtain CA certificate
| 'ldap://f0.cockpit.lan' doesn't have a certificate.
/var/log/ipaclient-install.log has a very long traceback, excerpts:
| 2024-05-07T04:16:52Z DEBUG Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1031, in
decode
| return x509.load_der_x509_certificate(val)
|^^^
| File "/usr/lib/python3/dist-packages/ipalib/x509.py", line 445, in
load_der_x509_certificate
| return IPACertificate(
|^^^
| TypeError: Can't instantiate abstract class IPACertificate with abstract
methods not_valid_after_utc, not_valid_before_utc
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 374, in
_sync_attr
| value = self._conn.decode(value, name)
| ^^
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1037, in
decode
| raise ValueError(msg)
| ValueError: unable to convert the attribute 'cacertificate;binary' value
b'[...]' to type
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line
1739, in get_certs_from_ldap
| certs = certstore.get_ca_certs(conn, base_dn, realm, ca_enabled)
|
| File "/usr/lib/python3/dist-packages/ipalib/install/certstore.py", line
310, in get_ca_certs
| for cert in entry.get('cACertificate;binary', []):
| ^
| File "", line 774, in get
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 510, in
__getitem__
| return self._get_nice(name)
|
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 485, in
_get_nice
| self._sync_attr(name)
| File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 376, in
_sync_attr
| raise ValueError("{error} in LDAP entry '{dn}'".format(
| ValueError: unable to convert the attribute 'cacertificate;binary' value [...]
This was already reported upstream (see "Forwarded:" above), and fixed in
upstream git 4 months ago:
https://pagure.io/freeipa/c/a45a7a20d96af51d463a285cb9318582720be708?branch=master
Unfortunately there hasn't been a new release since then. But I applied the
patch straight to /usr/lib/python3/dist-packages/ , it applies with some fuzz,
and joining the domain works fine afterwards.
Thanks,
Martin
Bug#1070663: Unable to lock an existing session
Package: xautolock Version: 1:2.2-8 Severity: critical This may be related to #1022781 or not. I have xautolock running: % ps -fC xautolock UID PIDPPID C STIME TTY TIME CMD madduck 27332421 0 May05 ?00:00:53 xautolock -time 3 -locker xsecurelock && autorandr -- … and yet: % xautolock -locknow % echo $? 0 It exits 0, but nothing happens. If I use strace on the main process, there is also zero activity reported. Moreover, despite being set to lock after 3 minutes, the main xautolock process does not lock the display. This has happened multiple times, and each time, only a restart of the main xautolock process makes things work again. So if I don't restart the process regularly (daily? hourly?), then occasionally, the system will not lock as expected, and that is a huge security problem, hence the critical severity. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xautolock depends on: ii libc6 2.37-17 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxss1 1:1.2.3-1 Versions of packages xautolock recommends: ii suckless-tools 47-1 xautolock suggests no packages. -- debconf-show failed -- .''`. martin f. krafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems
Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0
Martin Steigerwald - 02.05.24, 16:43:28 CEST: > Work-around for affected users: Of course this work-around is no longer necessary. Thank you for the quick fix, Laszlo. I appreciate it. -- Martin
Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc
On 2024-05-03 16:43, Sean Whitton wrote: > Yes, the source package would need to be emacs-casual. I still think it > should be suggested upstream. Yes, different names in Debian and upstream can be confusing. But I'll leave that to whoever might like to package it.
Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc
On 2024-05-03 10:28, Sean Whitton wrote:
> Hmm, have you considered asking upstream to rename it? "casual-calc"
> being the obvious, much less generic choice.
It didn't occur to me, that the name is pretty generic, indeed. OTOH,
I'm not aware of any other (existing or requested) package named
"*casual*". And the fact, that the name is not really telling what
it is about, is common among almost all Debian and Emacs packages :-(
If I were to package this, I would now consider naming the source
package "emacs-casual{-calc}" and the binary package
"elpa-casual{-calc}", but I guess, it is easy enough to find by the
short description anyway, which mentions "Emacs Calc".
Cheers
Bug#1070276: RFP: elpa-casual -- a transient-based porcelain for Emacs Calc
Package: wnpp Severity: wishlist * Package name: elpa-casual Version : 1.5.0 Upstream Author : Charles Y. Choi * URL or Web page : https://github.com/kickingvegas/Casual/ * License : GPL-3 Description : a transient-based porcelain for Emacs Calc Casual is an opinionated Transient-based porcelain to support the casual usage of Emacs Calc. While Emacs Calc has an embarrassingly rich feature set, for many users this capability is inaccessible due the overwhelming number of keybindings used to access them. These keybindings have a steep learning curve that is quickly lost if not in constant use. Menus are a user interface (UI) affordance that offer users discoverability and recall. Providing a hierarchical menu UI over Calc greatly improves its casual use. Here is a nice introduction into casual: http://yummymelon.com/devnull/
Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0
Work-around for affected users: Download and install libsnappy1v5_1.1.10-1+b1_amd64.deb from https://snapshot.debian.org/archive/debian/20240210T223313Z/pool/main/s/snappy/ Temporary protection: % cat /etc/apt/preferences.d/libsnappy Explanation: Debian#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0 Explanation: https://bugs.debian.org/1070217 Package: libsnappy1v5 Pin: version * Pin-Priority: -3 Please remove once bug is fixed. Thanks, -- Martin
Bug#1070200: ejabberd: Please package 24.02
Source: ejabberd Version: 23.01-1 Severity: wishlist Dear Maintainer, please consider packaging 24.02 (if possible it would be great if you'd also backport it to bookworm). Ejabberd < 24.02 has an issue with channel binding and TLSv1.3. When using channel binding (e.g. SCRAM mechanism SCRAM-SHA-1-PLUS) with TLSv1.3 tls-exporter must be used but ejabberd < 24.02 uses tls-unique (which should only be used for < TLSv1.3). [1] Due to the recent MITM on jabber.ru many clients and servers have enabled SCRAM mechanisms with channel binding to mitigate MITM attacks. But due to the linked issue authenticating will fail when using a SCRAM mechanism with channel binding and TLSv1.3, therefore it would be awesome if Debian would provide ejabberd 24.02 and enable ejabberd operators using Debian to upgrade to a fixed version. Best regards, Martin [1] https://github.com/processone/ejabberd/issues/4105 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories
ma 29. huhtik. 2024 klo 20.59 Sudip Mukherjee (sudipm.mukher...@gmail.com) kirjoitti: > > On Mon, 29 Apr 2024 at 09:00, Martin-Éric Racine > wrote: > > > > On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert > > wrote: > > > Package: micro-httpd > > > Version: 20140814-2.1+b2 > > > Severity: normal > > > Tags: patch > > > X-Debbugs-Cc: report...@duvert.net > > > > I have an NMU ready to cover this, debdiff attached. > > Thanks for the debdiff. But the diff is removing few of the Depends: > > micro-inetd | netcat-traditional | systemd-sysv > > Was that intentional or did you miss them? If intentional, then can > you please explain why those are not needed now. What is currently there is exactly what Lintian wants to see for any package that updates any variant of inetd. Any additional alternative makes Lintian barf, and overriding this particular one would not make sense. Meanwhile, systemd-sysv has a priority:important so it comes installed by default on Linux-based hosts. If the Depends was only there because you ship a systemd unit, it's not needed. Martin-Éric
Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories
On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert wrote:
> Package: micro-httpd
> Version: 20140814-2.1+b2
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: report...@duvert.net
I have an NMU ready to cover this, debdiff attached.
Martin-Éric
diff -Nru micro-httpd-20140814/debian/changelog
micro-httpd-20140814/debian/changelog
--- micro-httpd-20140814/debian/changelog 2021-10-14 16:02:47.0
+0300
+++ micro-httpd-20140814/debian/changelog 2024-04-29 10:01:57.0
+0300
@@ -1,3 +1,15 @@
+micro-httpd (20140814-2.2) unstable; urgency=medium
+
+ * Non-Maintainer Upload.
+ * Bump debhelper-compat to 13.
+ * Fix Lintian override syntax.
+ * Fix "Lintian: W: missing Depends on update-inetd" (Closes: #997691).
+ * Fix "sends invalid HTTP when listing unreadable dirs" (Closes: #1027978).
+Implemented the first alternative proposed in the bug report i.e.
+redirect standard error to systemd journal.
+
+ -- Martin-Éric Racine Mon, 29 Apr 2024 10:01:57
+0300
+
micro-httpd (20140814-2.1) unstable; urgency=medium
* Non-Maintainer Upload.
diff -Nru micro-httpd-20140814/debian/control
micro-httpd-20140814/debian/control
--- micro-httpd-20140814/debian/control 2020-02-06 01:14:09.0 +0200
+++ micro-httpd-20140814/debian/control 2024-04-29 10:01:15.0 +0300
@@ -2,7 +2,7 @@
Section: httpd
Priority: optional
Maintainer: Sudip Mukherjee
-Build-Depends: debhelper-compat (= 12)
+Build-Depends: debhelper-compat (= 13)
Standards-Version: 4.5.0
Rules-Requires-Root: no
Vcs-Browser: https://github.com/sudipm-mukherjee/micro-httpd.git
@@ -11,7 +11,7 @@
Package: micro-httpd
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, openbsd-inetd | inet-superserver
| micro-inetd | netcat-traditional | systemd-sysv
+Depends: update-inetd | inet-superserver | openbsd-inetd | inetutils-inetd |
rlinetd | xinetd, ${misc:Depends}, ${shlibs:Depends}
Suggests: micro-proxy
Provides: httpd
Description: really small HTTP server
diff -Nru micro-httpd-20140814/debian/micro-httpd.lintian-overrides
micro-httpd-20140814/debian/micro-httpd.lintian-overrides
--- micro-httpd-20140814/debian/micro-httpd.lintian-overrides 2020-02-06
01:14:09.0 +0200
+++ micro-httpd-20140814/debian/micro-httpd.lintian-overrides 2024-04-29
09:59:40.0 +0300
@@ -1,3 +1,3 @@
# Using var/www/html/ as a new default document root
# See #730372 and https://lists.debian.org/debian-devel/2012/04/msg00301.html
-micro-httpd: dir-or-file-in-var-www var/www/html/
+dir-or-file-in-var-www *var/www/html/*
diff -Nru micro-httpd-20140814/debian/micro-httpd@.service
micro-httpd-20140814/debian/micro-httpd@.service
--- micro-httpd-20140814/debian/micro-httpd@.service2021-10-14
16:02:47.0 +0300
+++ micro-httpd-20140814/debian/micro-httpd@.service2024-04-29
09:38:36.0 +0300
@@ -7,3 +7,4 @@
Group=www-data
ExecStart=-/usr/sbin/micro-httpd /var/www/html
StandardInput=socket
+StandardError=journal
Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories
On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert wrote: > When micro-httpd tries to list the contents of a directory but fails (if the > directory is not readable, for instance), an invalid HTTP response is > returned: > > > GET /.well-known/ HTTP/1.0 > > > < scandir: Permission denied > < HTTP/1.0 200 Ok > < Server: micro_httpd > < ... > > Looking at the source code, micro-httpd calls perror( "scandir" ); after > sending the HTTP headers, but due to standard output buffering, the error > message ends up being sent first. > > An easy fix is to change micro-httpd@.service so micro-httpd's standard error > is sent to the logs instead of the connection socket: > > [Service] > StandardError=journal I can implement this in an NMU. > A more complete fix would be to move the call to scandir (line 119) just > before > the call to send_headers(200, ...) (line 108), and to call send_error if > scandir > fails. This one needs to be sent to upstream. If you do so, please take the opportunity to ask him to consider using e.g. micro-httpd_2024-04-29.tar.xz as his tarball name. Tracking dates in ISO format is a lot easier to implement than e.g. 14Aug2014. Martin-Éric
Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti: > > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote: > > > I hereby propose bin:dhcpcd-base: > > > > > > 1) already supported by ifupdown. > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > separation. > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > configure both stacks. > > > > > > > why not switch to systemd-networkd + networkmanager for gui installs? > > NM already is pulled by most desktop environments. > > Meanwhile a bare minimal system needs a non-GUI solution and swaping > which DHCP client gets pulled by ifupdown is the simplest, least > disruptive way of accomplishing this. This bug is almost one year old. Are we going ahead with this or not? Martin-Éric
Bug#1069870: linux-image-6.7.7-686-pae: please enable i915 mtl_* modules
Package: src:linux Version: 6.7.7-1 Severity: normal W: Possible missing firmware /lib/firmware/i915/mtl_gsc_1.bin for module i915 W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for module i915 W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin for module i915 -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 6.7.7-686-pae (SMP w/1 CPU thread; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.7.7-686-pae depends on: ih initramfs-tools [linux-initramfs-tool] 0.142 ii kmod31+20240202-2 ii linux-base 4.9 Versions of packages linux-image-6.7.7-686-pae recommends: ii apparmor 3.0.13-2 ii firmware-linux-free 20200122-4 Versions of packages linux-image-6.7.7-686-pae suggests: pn debian-kernel-handbook ii grub-pc 2.12-2~deb13u1 pn linux-doc-6.7 Versions of packages linux-image-6.7.7-686-pae is related to: ii firmware-amd-graphics 20230625-2 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20230625-2 pn firmware-libertas ii firmware-linux-nonfree20230625-2 ii firmware-misc-nonfree 20230625-2 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20230625-2 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#1067884: KiCad no longer seems to recognize any of the built-in libraries
On Fri, 12 Apr 2024 08:45:34 + Erich Minderlein wrote: > I must correct my self: This was an update from devuan chimaera and > an old history concerning $HOME, which lives with me since years > > Today I made a fresh install in a virtual machine and every thing > works fine. > > Then I deleted directories > rm -r $HOME/.config/kicad $HOME/.cache/kicad $HOME/.local/share/kicad > > I started KiCad again as $USER and it acknowledged the libraries. > > This is an aide at least for those who do not have a valuable history > in KiCad > > For the others the problem remains to be solved I beg to differ. You upgraded to Devuan Daedalus which is based on Debian bookworm, aka Debian stable. However, the original bug report concerns in Debian trixie, i.e. Debian testing. In current testing the package kicad depends on kicad-libraries with a version string >=7.0.1~ , which in turn depends on kicad-footprints, kicad-symbols, kicad-templates and kicad-packages3d, again with version string >=7.0.1~ . About two weeks ago, the packages or symbols, footprints, etc. were upgraded to version 8.0.1-1 in testing. So an 'apt upgrade' on debian testing happily pulls these v8 kicad libraries. However, kicad still remains on v7.0.1 . Since kicad libraries are explicitly not downward compatible across major versions, the 7.0.1 kicad binary refuses to load any element from a 8.0.1 library. This makes the package virtually unusable for its intended purpose. I got bitten by the bug, too. Unfortunately, a downgrade to stable is no option, since kicad is on v6.0 over there. All my kicad projects are on v7.0 already and will not open with kicad6. Unfortunately, I found no way to make apt downgrade to version 7.0 of the libraries. Luckily, I was able to regained access to my projects by manually replacing the upgraded v8 libraries with v7 versions from a backup. The upgrade of the package kicad is blocked until until gtk+3.0, libgllib2.0t64, python3.11, curl, opencascade and wywidgets3.2 have all received a successful upgrade. This will probably take a few days. How about adding '<8.0' to the version requirement for the time being? Best regards, ---<)kaimartin(>--- -- Kai-Martin Knaak kn...@iqo.uni-hannover.de Universität Hannover, Inst. für Quantenoptik tel: +49-511-762-2895 Welfengarten 1, 30167 Hannover fax: +49-511-762-2211 PGP-Key: https://keys.openpgp.org/search?q=kn...@iqo.uni-hannover.de pgpQBpw2EC1l5.pgp Description: OpenPGP digital signature
Bug#1069692: nfs-ganesha: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
Hi Sebastian, this is interesting. If you take a look into the commandline you see -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 there is -D_FILE_OFFSET_BITS=64 even twice. .. But the GPFS code has: /* _FILE_OFFSET_BITS macro causes F_GETLK/SETLK/SETLKW to be defined to * F_GETLK64/SETLK64/SETLKW64. Currently GPFS kernel module doesn't work * with these 64 bit macro values through ganesha interface. Undefine it * here to use plain F_GETLK/SETLK/SETLKW values. */ #undef _FILE_OFFSET_BITS I'll exclude the GPFS module for armel and armhf. Regards Christoph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.
su 21. huhtik. 2024 klo 14.59 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti: > > > > Source: dhcpcd > > Version: 1:10.0.6-1 > > Severity: important > > User: debian...@lists.debian.org > > Usertags: isolation-machine > > > > Dear maintainer(s), > > > > Your package has an autopkgtest, great. I recently added support for > > isolation-machine tests on ci.debian.net for amd64 and added your > > package to the list to use that. However, it fails. Can you please > > investigate the situation and fix it? I copied some of the output at the > > bottom of this report. > > [...] > > > 29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp: > > [--- > > 30s Preparing virtual interfaces... > > 30s Actual changes: > > 30s tx-checksum-ip-generic: off > > 30s tx-tcp-segmentation: off [not requested] > > 30s tx-tcp-ecn-segmentation: off [not requested] > > 30s tx-tcp-mangleid-segmentation: off [not requested] > > 30s tx-tcp6-segmentation: off [not requested] > > 30s tx-checksum-sctp: off > > 30s Preparing dnsmasq configuration... > > 35s Obtaining network configuration for veth1 via dhcp... > > 37s RA from non local address fdae:9322:f1cc::1 > > 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit > > systemd-timesyncd.service not found. > > 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit > > systemd-timesyncd.service not found. > > 48s Check if the NTP server is made available to daemon...Failed to > > parse bus message: No route to host > > 49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp: > > ---] > > That service unit is provided by systemd-timesyncd, which systemd > recommends. Basically, unless your testing environment explicitly > installs another package providing time-daemon, this shouldn't happen, > since systemd would have pulled systemd-timesyncd by default. Anyhow, no harm done. The following commit should fix it: https://salsa.debian.org/debian/dhcpcd/-/commit/55e588b0d7561c697f3fedfddef3feeb6c8b34b9 Martin-Éric
Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.
su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti: > > Source: dhcpcd > Version: 1:10.0.6-1 > Severity: important > User: debian...@lists.debian.org > Usertags: isolation-machine > > Dear maintainer(s), > > Your package has an autopkgtest, great. I recently added support for > isolation-machine tests on ci.debian.net for amd64 and added your > package to the list to use that. However, it fails. Can you please > investigate the situation and fix it? I copied some of the output at the > bottom of this report. [...] > 29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp: > [--- > 30s Preparing virtual interfaces... > 30s Actual changes: > 30s tx-checksum-ip-generic: off > 30s tx-tcp-segmentation: off [not requested] > 30s tx-tcp-ecn-segmentation: off [not requested] > 30s tx-tcp-mangleid-segmentation: off [not requested] > 30s tx-tcp6-segmentation: off [not requested] > 30s tx-checksum-sctp: off > 30s Preparing dnsmasq configuration... > 35s Obtaining network configuration for veth1 via dhcp... > 37s RA from non local address fdae:9322:f1cc::1 > 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit > systemd-timesyncd.service not found. > 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit > systemd-timesyncd.service not found. > 48s Check if the NTP server is made available to daemon...Failed to > parse bus message: No route to host > 49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp: > ---] That service unit is provided by systemd-timesyncd, which systemd recommends. Basically, unless your testing environment explicitly installs another package providing time-daemon, this shouldn't happen, since systemd would have pulled systemd-timesyncd by default. Martin-Éric
Bug#1069162: Problem starting at boot, MAINPID to kill is a root-owned java process
Package: puppetserver
Version: 7.9.5-2
Severity: normal
I found puppetserver failing to boot, because the `ExecStartPost`
line fails:
```
[Service]
ExecStartPost=sh -c "while ! head -c1 ${RUNTIME_DIRECTORY}/restart | grep -q
'^1'; do kill -0 $MAINPID && sleep 1 || exit 1; done"
```
Adding a little debugging output, I find `$MAINPID` pointing to the wrong
process, and the `kill` failing:
```
sh[653]: + ps -fp 652
sh[653]: UID PIDPPID C STIME TTY TIME CMD
sh[653]: root 652 1 0 10:34 ?00:00:00 (java)
sh[653]: + kill -0 652 Apr 17 10:18:27
sh[653]: sh: 1: kill: Operation not permitted
```
It's unclear to me why `$MAINPID` points at the root-owned `java` process, or
why that process is even started as root, given that `User=puppet` is
specified.
This only happens during boot, and not 100% of the time. When the service is
restarted later, it works fine.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages puppetserver depends on:
ii default-jre-headless 2:1.17-75
pn jruby
pn libclj-time-clojure
pn libclojure-java
pn libcomidi-clojure
pn libcommons-exec-java
ii libcommons-io-java 2.16.0-1
pn libcommons-lang-java
pn libdropwizard-metrics-java
pn libdujour-version-check-clojure
pn libjruby-utils-clojure
pn libkitchensink-clojure
pn libliberator-clojure
pn libprismatic-schema-clojure
pn libpuppetlabs-http-client-clojure
pn libpuppetlabs-i18n-clojure
pn libpuppetlabs-ring-middleware-clojure
pn libraynes-fs-clojure
pn librbac-client-clojure
pn libsemver-clojure
pn libshell-utils-clojure
pn libslingshot-clojure
pn libssl-utils-clojure
pn libtrapperkeeper-authorization-clojure
pn libtrapperkeeper-clojure
pn libtrapperkeeper-comidi-metrics-clojure
pn libtrapperkeeper-filesystem-watcher-clojure
pn libtrapperkeeper-metrics-clojure
pn libtrapperkeeper-scheduler-clojure
pn libtrapperkeeper-status-clojure
pn libtrapperkeeper-webserver-jetty9-clojure
pn libyaml-snake-java
ii procps 2:4.0.4-4
pn puppet-agent
ii ruby 1:3.1+nmu1
ii ruby-concurrent 1.2.3-2
pn ruby-deep-merge
pn ruby-fast-gettext
pn ruby-gettext
pn ruby-hocon
ii ruby-locale 2.1.3-1
pn ruby-puppet-resource-api
pn ruby-puppetserver-ca-cli
pn ruby-semantic-puppet
pn ruby-text
Versions of packages puppetserver recommends:
pn puppet-module-puppetlabs-mailalias-core
puppetserver suggests no packages.
--
.''`. martin f. krafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)
Control: tag -1 upstream fixed-upstream patch
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19790
Hello Salvatore and Santiago,
Salvatore Bonaccorso [2024-04-15 19:28 +0200]:
> The update for cockpit in DSA 5655-1 had problems with the
> test-sshbridge test, causing FTBFS:
>
> >From the tail of the test failure:
>
> # cockpit-protocol-DEBUG: test-ssh: output queue empty
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
> (src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed:
> (ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)
>
> (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702:
> (src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed:
> (ssh_options_parse_config (data->session, NULL) == 0)
> # cockpit-protocol-DEBUG: test-ssh: reading input 1
> # cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
> # cockpit-protocol-DEBUG: test-ssh: want more data
> **
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
> assertion failed (json_object_get_string_member (init, "command") == "init"):
> ("authorize" == "init")
> Bail out!
> cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init:
> assertion failed (json_object_get_string_member (init, "command") == "init"):
> ("authorize" == "init")
> cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't
> connect: Hostname required 'some_host' '22'
> cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken pipe
> cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message:
> Inappropriate ioctl for device
> FAIL test-sshbridge (exit status: 134)
Argh, I can reproduce. The test passes with the previous
http://snapshot.debian.org/package/libssh/0.10.5-3/ but fails with current
0.10.6-0+deb12u1.
The reason is annoyingly mundane, and already got fixed upstream half a year
ago:
https://github.com/cockpit-project/cockpit/commit/518d36c3492020525
I prepared a package update with that fix cherry-picked. See attached debdiff.
It builds fine in a clean bookworm container now.
But I don't know how exactly to target and upload this: to bookworm-security or
-updates? It's a follow-up for a previous security update to make that actually
work, but not a security update in itself.
Santiago Vila [2024-04-15 20:28 +0200]:
> For completeness: this was already happening in bullseye and bookworm
> before the DSA. (Reminder for myself: report all the bugs I found
> last week while rebuilding bullseye and bookworm).
Right, that makes sense. There are no C code changes between 287 and 287.1.
Thanks, and sorry for the trouble,
Martin
diff -Nru cockpit-287.1/debian/changelog cockpit-287.1/debian/changelog
--- cockpit-287.1/debian/changelog 2024-04-02 11:11:19.0 +0200
+++ cockpit-287.1/debian/changelog 2024-04-16 09:20:17.0 +0200
@@ -1,3 +1,11 @@
+cockpit (287.1-0+deb12u2) bookworm-security; urgency=medium
+
+ * Add 0001-ssh-Use-valid-host-name-in-test-sshbridge.patch:
+Use valid host name in test-sshbridge. Fixes FTBFS due to unit test
+failure when building against libssh 0.10.6. (Closes: #1069059)
+
+ -- Martin Pitt Tue, 16 Apr 2024 09:20:17 +0200
+
cockpit (287.1-0+deb12u1) bookworm-security; urgency=medium
* New upstream security update:
diff -Nru
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
---
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
1970-01-01 01:00:00.0 +0100
+++
cockpit-287.1/debian/patches/0001-ssh-Use-valid-host-name-in-test-sshbridge.patch
2024-04-16 09:19:18.0 +0200
@@ -0,0 +1,36 @@
+From 518d36c349202052578a459872c3657760226648 Mon Sep 17 00:00:00 2001
+From: Martin Pitt
+Date: Fri, 29 Dec 2023 07:12:11 +0100
+Subject: [PATCH] ssh: Use valid host name in test-sshbridge
+
+libssh 0.10.6 made host name parsing stricter. `some_host` is not a
+valid general host name, and is rejected with the latest version.
+---
+ src/ssh/test-sshbridge.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/ssh/test-sshbridge.c b/src/ssh/test-sshbridge.c
+index e0ff9a7a9..9c561e29a 100644
+--- a/src/ssh/test-sshbridge.c
b/src/ssh/test-sshbridge.c
+@@ -323,7 +323,7 @@ setup (TestCase *tc,
+ if (!fixture->knownhosts_home)
+ g_assert_cmpint (mkdir (tc->home_ssh_dir, 0700), ==, 0);
+
+- g_string_append (content, "Host some_host\n");
++ g_string_append (content, "Host somehost\n");
+ g_string_append_printf (content, "\tHostname %s\n", hostname);
+
+ if (fixture->ssh_confi
Bug#1068969: csound-utils installs /usr/bin/extractor which has no manual page.
Package: csound-utils Version: 1:6.18.1+dfsg-1 Severity: normal X-Debbugs-Cc: martinw...@gmail.com extractor --help says --Csound version 6.18 (double samples) 2022-11-24 [commit: none] libsndfile-1.2.0 util extractor: Usage: extractor [-flags] soundfile Legal flags are: -o fnamesound output filename -N notify (ring the bell) when done -S integer sample number at which to start file -Z integer sample number at which to end file -Q integer number of samples to read -T fpnumtime in secs at which to start file -E fpnumtime in secs at which to end file -D fpnumduration in secs of extract -R Rewrite header -H Heartbeat -v verbose mode for debugging -- fnameLog output to file flag defaults: extractor -otest -S 0 extractor: error: unknown flag -- end of score. overall amps: 0.0 overall samples out of range:0 0 errors in performance Elapsed time at end of performance: real: 0.001s, CPU: 0.000s so I guess it's some kind of sound convertor. A manual page saying what it is and what it does and how to use it would be nice. -- System Information: Debian Release: 12.5 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 6.1.0-15-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages csound-utils depends on: ii csound 1:6.18.1+dfsg-1 ii libc62.36-9+deb12u4 ii libcsound64-6.0 1:6.18.1+dfsg-1 ii libsamplerate0 0.2.2-3 ii libsndfile1 1.2.0-1 csound-utils recommends no packages. csound-utils suggests no packages. -- no debconf information
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Martin Steigerwald - 13.04.24, 15:05:41 CEST: > No PATH defined. > > The script defines it. See line 8 in my changed script. However it does > not export it. Thus adding line 9 fixes the bug I reported: > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > 9 export PATH > > The network is configured just fine after adding that line. Since configuring networking works on physical machines – I know for sure with Devuan 5 aka Daedalus and Devuan Ceres which was at a similar state Devuan Excalibur is currently – regarding the right fix the question remains: What is different with the PATH in both cases and why? Why is it empty inside the (unprivileged) Incus managed LXC container? Is it empty on the physical machine? I doubt it. But where does the difference come from? And anyway the PATH is being set in both stage 1 and stage 2 scripts, just not exported. So on a physical machine it appears that PATH is being exported before already. It might be exported before already on a container as well, albeit undefined / empty. In both cases /bin/sh points to /bin/dash. Both the VM with Excalibur and the physical host with Daedalus are usrmerge'd. -- Martin
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Martin Steigerwald - 13.04.24, 14:32:16 CEST: > Any idea how to find the cause of what is happening here? I found the cause: The container starts out with an almost empty environment. In /etc/runit/1 I added lines 4 to 6: 1 #!/bin/sh 2 # system one time initialization tasks 3 4 echo ">> environment" >> /tmp/rcS.log 5 /usr/bin/env >> /tmp/rcS.log 6 echo ">> end of environment" >> /tmp/rcS.log 7 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin (For some reason using /tmp/rcS.log did not give me any output. Although /tmp is not mounted elsewhere during the boot process.) This gives me: root@zdevuan:~# cat rcS.log >> environment container=lxc PWD=/ >> end of environment No PATH defined. The script defines it. See line 8 in my changed script. However it does not export it. Thus adding line 9 fixes the bug I reported: 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin 9 export PATH The network is configured just fine after adding that line. Same goes for stage 2. In /etc/runit/2 I added: 38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log 39 echo ">> environment" >> /tmp/rc2.log 40 env >> /tmp/rc2.log >> /tmp/rc2.log 41 echo ">> end of environment" 42 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log 43 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/ no.emulate.sysv ]; then 44 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log 45 /lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d' 2>&1 >>/tmp/rc2.log 46 fi Which gives me: >> environment container=lxc PWD=/ >> end of environment Exporting the PATH there as well like 1 #!/bin/sh 2 3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin 4 export PATH 5 SVDIR=/etc/service fixes root@zdevuan:~# cat /etc/boot.d/network #!/usr/bin/env sh /etc/init.d/networking restart The network is configured even without the "export PATH" fix in /etc/runit/1. I just wonder why stage 2 contains /usr/local bin directories. I think that should not be the case. Shall I report this as a different issue? I am now undoing my debug output. I think I could provide a merge request for the fixes at a later time. For now I like to finish the Devuan template and actually use it. That bootlogd does not seem to work inside a container is a different issue I may report at another time. I added empty "debug" and "verbose" files in /etc/runit but did not find any debug output. Maybe those files needed to have some content. Maybe it requires bootlogd. But that is for another time :) Best, -- Martin
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Package: runit-init
Version: 2.1.2-54
Severity: normal
X-Debbugs-Cc: mar...@lichtvoll.de
Dear Maintainer,
Hi!
I have Devuan Excalibur with Incus (forked from LXD) managed LXC
containers. reportbug said the package is unforked and thus I agreed
to send to Debian BTS instead.
All but one of them are Alpine Linux. In there I installed dhcpcd for
dual stack DHCP from Incus managed dnsmasq.
I am currently configuring myself a Devuan template starting from
incus launch images:devuan/daedalus zdevuan
I installed runit-init and socklog-run in there.
The containers comes up but dhcpcd is not running.
It should have been started by /etc/init.d/networking due to
/etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
And indeed it is:
root@zdevuan:~# /etc/init.d/networking start
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]
However even with:
root@zdevuan:~# cat /etc/boot.d/network
#!/usr/bin/env sh
/etc/init.d/networking start
it does not work.
I looked up how runit stage 2 runs init scripts. It does so by:
root@zdevuan:/etc# grep -r "rc2.d"
runit/2:/lib/runit/async-timeout /lib/runit/run_sysv_scripts
'/etc/rc2.d'
So I ran
/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'
manually and indeed it picks up /etc/boot.d/network:
root@zdevuan:~# /lib/runit/async-timeout /lib/runit/run_sysv_scripts
'/etc/rc2.d'
dmesg: read kernel buffer failed: Operation not permitted
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]
That last line is from /etc/boot.d/network.
Thus I tried to find out whether /etc/runit/2 actually runs those scripts
on boot:
38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log
39 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log
40 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/no.emulate.sysv ];
then
41 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log
42 /lib/runit/async-timeout /lib/runit/run_sysv_scripts
'/etc/rc2.d' 2>&1 >>/tmp/rc2.log
43 fi
This gives me:
root@zdevuan:~# cat /tmp/rc2.log
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...failed.
So indeed stage 2 runs the scripts. But it cannot configure the network
interface at this time. However running
/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'
later just works okay as shown above.
Also putting "/etc/init.d/networking restart" inside
"/etc/boot.d/network" does not work:
Running /etc/init.d/networking restart is deprecated because it may not
re-enable some interfaces ... (warning).
Reconfiguring network interfaces...failed.
Not even putting
echo "ifdown eth0:"
ifdown eth0
echo "ifup eth0:"
ifup eth0
in there does work:
root@zdevuan:~# cat /tmp/rc2.log
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
ifdown eth0:
ifup eth0:
No output from "ifup eth0" which does not seem right.
However "ifdown eth0" and "ifup eth0" just works fine after booting. But
even if I insert a "sleep 10" before those, it still does not work.
I also looked for how rcS.d scripts are executed by Runit stage 0:
root@zdevuan:/etc# grep -r "rcS.d"
[…]
runit/1:for script in /etc/rcS.d/S* ; do
In there I added for debugging:
11 for script in /etc/rcS.d/S* ; do
12 path=$(realpath "$script")
13 name=${path##*/}
14 [ -e "/etc/runit/no.emulate.sysv.d/$name" ] && continue
[…]
19 echo "run $script" >>/tmp/rcS.log
20 "$script" start --force-sysv 2>&1 >>/tmp/rcS.log
21 done
And indeed stage1 runs the scripts. But configuring network interfaces
fails there as well:
root@zdevuan:~# cat /tmp/rcS.log
run /etc/rcS.d/S08mountall.sh
Mounting local filesystems...done.
Activating swapfile swap, if any...done.
run /etc/rcS.d/S09mountall-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S10brightness
run /etc/rcS.d/S10procps
Starting Setting kernel variables: sysctl is already running.
run /etc/rcS.d/S10stop-bootlogd-single
run /etc/rcS.d/S10urandom
run /etc/rcS.d/S11networking
Configuring network interfaces...failed.
run /etc/rcS.d/S12mountnfs.sh
run /etc/rcS.d/S13mountnfs-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S14bootmisc.sh
However as bootlogd is not being started and would not work inside
an LXC container anyway, I am not sure I can see any loggin
Bug#1068898: Reinstate OpenRD netboot images for bookworm
* Cyril Brulebois [2024-04-13 08:25]: > I don't mind doing that again, but what's the game plan here? If systems > are already installed and working fine, then d-i is irrelevant. Well, maybe someone wants to install Debian, either because they find an old OpenRD somewhere or because Rick's hard drive dies or something. > For any new systems people might want to deploy, installing bullseye > then upgrading to bookworm already works? Of course, but bullseye will be moved to archive.d.o at some point (I know you can install from there, but then you have to specify the mirror). Anyway, I have no game play. Like I said, it's probably all a waste of time, but Debian bookworm works on OpenRD and d-i should work if we add the image, we already have a patch... so it seems like we should just do it. My game play is that I'm a perfectionist but I am aware there are pretty much no users of Debian on OpenRD (I only know of Rick!). > So OpenRD has no future in trixie as far as I understand. At least that > would mean not having to do that again again, if we were to enable > OpenRD images again for bookworm. Yes, imho let's add the image for bookworm and let this be the end of it. ;) But if you just want to close this feature request, I doubt many people will care. -- Martin Michlmayr https://www.cyrius.com/
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Package: debian-installer Version: 20230607+deb12u5 I'm sorry to be that guy who shows up every few years to waste everyone's time... but... I was updating my Kirkwood pages for bookworm and noticed that the OpenRD images are gone. Now you may remember that we had the same situation for bullseye (#934072) and Cyril kindly restored the netboot images: https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 I guess this change never got committed to master/main because bullseye was going to be the last release for armel. But armel is still in bookworm and Rick confirmed he's running bookworm on his OpenRD, so I see no reason why d-i wouldn't work if we apply the same patch to the bookworm d-i. Honestly, I'm not sure if it's worth it as Rick is probably the one Debian on OpenRD left, but since bookworm will probably be the last release of armel (or not?) it would be nice if the installer was working on OpenRD. Cyril or Vagrant, can you easily apply the patch above and generate a test image for Rick? Sorry for creating work (again) for such a minor platform... -- Martin Michlmayr https://www.cyrius.com/
Bug#1061137: Doesn't work on SheevaPlug
* Vagrant Cascadian [2024-01-18 20:07]: > > So we need a stable update with this change. > > Thanks everyone! > > This is a pretty trivial fix, so including in the next bookworm/stable > point release should work! Is this still planned? -- Martin Michlmayr https://www.cyrius.com/
Bug#1068860: [INTL:sv] Swedish strings for libcifpp debconf
package: libcifpp severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of libcifpp debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the libcifpp package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: libci...@packages.debian.org\n" "POT-Creation-Date: 2024-04-01 18:42+\n" "PO-Revision-Date: 2024-04-12 13:15+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../libcifpp-data.templates:1001 msgid "Should mmcif_pdbx files be updated automatically?" msgstr "Ska mmcif_pdbx-filer uppdateras automatiskt?" #. Type: boolean #. Description #: ../libcifpp-data.templates:1001 msgid "" "The default mmcif_pdbx.dic file may become out-of-date over time. Using this " "option you can enable automatic weekly updating of this file." msgstr "Standardfilen mmcif_pdbx.dic kan bli utdaterad över tid. Genom att aktivera detta alternativ så uppdateras den veckovis."
Bug#1068859: [INTL:sv] Swedish strings for put-dns debconf
package: put-dns severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of put-dns debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the put-dns package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: put-dns\n" "Report-Msgid-Bugs-To: put-...@packages.debian.org\n" "POT-Creation-Date: 2021-02-22 08:32+\n" "PO-Revision-Date: 2024-04-12 13:20+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Automatically update domain in put-dns.conf?" msgstr "Uppdatera domän i put-dns.conf automatiskt?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "If enabled put-dns will, on configuration, try to detect a valid external " "domain name on the current system and update the put-dns.conf configuration " "file to use it. If disabled then the configuration will not be automatically " "updated." msgstr "Aktiveras detta alternativ kommer put-dns försöka hitta en giltig extern domän för systemet vid omkonfiguration och uppdaterar put-dns.conf så att den används. Om det inte aktiveras kommer inställningarna inte att uppdareras automatiskt."
Bug#1068858: [INTL:sv] Swedish strings for osk-sdl debconf
package: osk-sdl severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of osk-sdl debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the osk-sdl package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: osk-sdl\n" "Report-Msgid-Bugs-To: osk-...@packages.debian.org\n" "POT-Creation-Date: 2022-08-08 09:21+\n" "PO-Revision-Date: 2024-04-12 13:18+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Automatically clean crypttab?" msgstr "Ska crypttab rensas automatiskt vid avinstallation?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Selecting this will result in instances of 'osk-sdl-keyscript' being " "removed from /etc/crypttab on package removal." msgstr "Aktiveras detta alternativ så kommer osk-sdl-keyscript-instanser tas bort från /etc/crypttab automatiskt när paketet tas bort."
Bug#1068857: [INTL:sv] Swedish strings for unl0kr debconf
package: unl0kr severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of unl0kr debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the unl0kr package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: unl...@packages.debian.org\n" "POT-Creation-Date: 2024-04-01 23:38+\n" "PO-Revision-Date: 2024-04-12 13:26+0200\n" "Last-Translator: Martin Bagge \n" "Language-Team: Swedish \n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Automatically clean crypttab?" msgstr "Ska crypttab städas upp automatiskt?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Selecting this will result in instances of 'unl0kr-keyscript' being removed " "from /etc/crypttab on package removal." msgstr "Aktiveras detta alternativ så kommer instancer av unl0kr-keyscript tas bort från /etc/crypttab när paketet tas bort."
Bug#1068856: [INTL:sv] Swedish strings for qcumber debconf
package: qcumber severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. I did the translation to the best of my abilities. In the following English text I think it is hard to understand the exact wording and what they should mean. > If you want to run QCumber the directory of the kraken database > needs to be known to the program. Maybe the template should be reviewed as we did years ago =) -- brother# Translation of qcumberX debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the qcumber package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: qcumber\n" "Report-Msgid-Bugs-To: qcum...@packages.debian.org\n" "POT-Creation-Date: 2016-11-29 14:47+0100\n" "PO-Revision-Date: 2024-04-12 13:25+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: string #. Description #: ../templates:1001 msgid "Installation directory of the minikraken database:" msgstr "Sökväg för installation av minikraken-databasen?" #. Type: string #. Description #: ../templates:1001 msgid "" "QCumber is using kraken which needs a database. To simplyfy the process of " "creating the database which requires a lot of computing power there is the " "option to download this database (see https://ccb.jhu.edu/software/; "kraken/). If you want to run QCumber the directory of the kraken database " "needs to be known to the program. Please input the directory the database " "is installed or should the database be installed by the script /usr/share/" "doc/qcumber/get-minikrakendb." msgstr "QCumber använder kraken som behöver en databas. För att förenkla processen för att skapa databasen (vilket kräver ganska mycket beräkningskraft) så erbjuds alternativet att hämta databasen (läs mer på https://ccb.jhu.edu/software/kraken/). För att kunna starta QCumber måste sökvägen till databasen vara känd av programmet. Ange var databasen finns eller kommer att finnas när scriptet /usr/share/doc/qcumber/get-minikrakendb har kört."
Bug#1068800: [INTL:sv] Swedish strings for kdump-tools debconf
package: kdump-tools severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of kdump-tools debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the kdump-tools package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: makedumpfile\n" "Report-Msgid-Bugs-To: makedumpf...@packages.debian.org\n" "POT-Creation-Date: 2016-06-10 12:46+0200\n" "PO-Revision-Date: 2024-04-11 13:12+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../kdump-tools.templates:1001 msgid "Should kdump-tools be enabled by default?" msgstr "Ska kdump-tools aktiveras?" #. Type: boolean #. Description #: ../kdump-tools.templates:1001 msgid "" "If you choose this option, the kdump-tools mechanism will be enabled. A " "reboot is still required in order to enable the crashkernel kernel parameter." msgstr "Om du väljer detta så kommer kdump-tools-mekanismen aktiveras. Systemet behöver dock startas om för att aktivera kärnflaggan crashkernel."
Bug#1068799: [INTL:sv] Swedish strings for hyperscan debconf
package: hyperscan severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of hyperscan debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the hyperscan package. # # Martin Bagge , 2024 msgid "" msgstr "" "Project-Id-Version: hyperscan\n" "Report-Msgid-Bugs-To: hypers...@packages.debian.org\n" "POT-Creation-Date: 2016-07-26 23:46+0200\n" "PO-Revision-Date: 2024-04-11 13:10+0200\n" "Last-Translator: Martin Bagge , 2024\n" "Language-Team: Swedish zdebian-l10n-swed...@lists.debian.org>\n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../libhyperscan5.templates:1001 msgid "Really install package?" msgstr "Vill du verkligen installera paketet?" #. Type: boolean #. Description #: ../libhyperscan5.templates:1001 msgid "" "This CPU lacks support for the Supplemental Streaming SIMD Extensions 3 " "(SSSE3) instruction set that is required to execute programs linked against " "hyperscan." msgstr "Denna processor (CPU) saknar stöd för instruktionssettet Supplemental Streaming SIMD Extensions 3 (SSSE3) vilket krävs för att köra program som länkar mot hyperscan."
Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support
Hi Adam, Am 08.04.24 um 19:15 schrieb Adam D. Barratt: On Mon, 2024-04-08 at 11:42 +0200, Christoph Martin wrote: Hi Sebastian, the packages are already removed from testing and unstable. Where do you see a problem? I'm not Sebastian, but the archive disagrees with you about the packages having been removed from unstable. adsb@coccia:~$ dak ls -s unstable -a armel,armhf,i386 nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rgw nfs-ganesha-ceph| 4.3-5 | unstable | armel, armhf, i386 nfs-ganesha-rados-grace | 4.3-5 | unstable | armel, armhf, i386 nfs-ganesha-rgw | 4.3-5 | unstable | armel, armhf, i386 Thanks for your reply. I only took a look at the current version in unstable and testing. And this is 4.3-8 with binaries for amd64 arm64 mips64el ppc64el riscv64 s390x. So the issue is, that the leftover binaries from version 4.3-5 are still in the archive. Regards Christoph OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support
Hi Sebastian, the packages are already removed from testing and unstable. Where do you see a problem? Regards Christoph Am 07.04.24 um 13:21 schrieb Sebastian Ramacher: Package: ftp.debian.org Severity: normal X-Debbugs-Cc: nfs-gane...@packages.debian.org, sramac...@debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:nfs-ganesha Control: block 1065470 by -1 Control: clone -1 -2 Control: clone -1 -3 Control: retitle -2 RM: nfs-ganesha-grace [armel armhf i386] -- NBS; ceph dropped 32 bit support Control: retitle -3 RM: nfs-ganesha-rgw [armel armhf i386] -- NBS; ceph dropped 32 bit support nfs-ganesha (4.3-6) unstable; urgency=medium . * only configure with ceph for some 64bit archs So please remove the old nfs-ganesha-ceoph, nfs-ganesha-rados-grace, and nfs-genesha-rgw binaries from armel, armhf and i386. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068597: quodlibet: most Explore options are brain damaged
Control: retitle -1 quodlibet: please add other, better explore options Control: severity -1 wishlist On 2024-04-07 20:42, José Luis González wrote: > Important severity because the program is unmanageable with more than > just a beginner collection. I respect your opinion, but mind, that use cases can be different. E.g. I use quodlibet for years, with more than 45k tracks, but use "Track List" and "Playlists" only, and do not care about albums at all. Your feature request might be valid for your specific use case, but to others the program is perfectly usable as it is.
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
Dear Andrey, On 06.04.2024 19:25, Andrey Rakhmatullin wrote: You need to use bash_unit from the package. Likely as simple as "./bash_unit". thanks, that's it. Just pushed the changes and uploaded to mentors. Best regards, Martin signature.asc Description: PGP signature
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
Dear Andrey, On 06.04.2024 13:36, Andrey Rakhmatullin wrote: Hi Martin, you added a B-D on itself, I assume it's to run build-time tests, buit the idea of build-time tests is to use the software being package, Do you know how to achieve this? When I remove the build-dep on itself the built fails as the test can not be performed: debian/rules override_dh_auto_test make[1]: Entering directory '/<>' bash_unit -f tap ./tests/test_* /bin/sh: 1: bash_unit: not found make[1]: *** [debian/rules:9: override_dh_auto_test] Error 127 not the version from repos (also B-D on itself orevents it from being built). Yes, as it's not yet in the repos I had to inject it locally to get it built. Best regards, Martin signature.asc Description: PGP signature
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
Dear Andrey, thank you for the valuable feedback. I hope it is all properly settled now. I just uploaded a new build to mentors and pushed the changes to the repo. Thank you very much, Martin signature.asc Description: PGP signature
Bug#1027405: regina-rexx FTCBFS: builds for the build architecture
El mar, 2 abr 2024 a las 13:49, Helmut Grohne () escribió: > On Fri, Mar 29, 2024 at 01:29:04PM +0100, Agustin Martin wrote: > > > However, there is another problem with other arches (e.g. arm64). Some > > binary files containing compiled error messages are built with a > > locally built program (msgcmp). Because of incompatible arches, it > > cannot be run and files cannot be built, and then, build fails when > > trying to install them (error is disabled during build). The first > > idea was to have a separate arch:all pakage with those messages, but > > it would not be arch:all because those messages binary files depend on > > arch endianness. > > Does that mean that it vendors a gettext rather than using the system > gettext? There is a msgcmp in the gettext package and it is Multi-Arch: > foreign. If this is something different from gettext, you should likely > use CC_FOR_BUILD as set by dpkg's buildtools.mk for compiling msgcmp.c. > I don't think it is installed into any binary package so there likely is > no need to compile it twice in a cross build. HI, Helmut, Thanks for the testing and for the info. Yes, a completely different system is used for internationalization, not gettext. By the way, upstream is active and responsive. I have recently opened a couple of tickets about different things https://sourceforge.net/p/regina-rexx/support-requests/56/ https://sourceforge.net/p/regina-rexx/support-requests/57/ and reply to first one was more than quick. The other has just been opened. -- Agustin
Bug#1068394: hunspell-it: Verb 'possedere' is in it_IT.dic, but is highlighted as error
El jue, 4 abr 2024 a las 15:33, Alessio Paonessa () escribió: > > Package: hunspell-it > Version: 1:24.2.2-1 > Severity: normal > Tags: l10n > X-Debbugs-Cc: livm...@hotmail.com > > Dear Maintainers, > > when I write the conjugations of the verb 'possedere' in a text editor, the > word is marked as an error. > > A quick check to the file it_IT.dic seems to correctly list it at line 60847. > Nonetheless, the conjugations are highlighted as incorrect. Hi, Alessio, I do not speak italian but has looked sometimes at ispell/myspell2/hunspell affix files, so here go my 2cents. First, I suggest you to send the exact words that triggered the error, to make debugging easier. From what I see, the problem might be that "È" flag is not present in aff file, but used in the dic file $ grep È /usr/share/hunspell/it_IT.dic possedere/ÈI risedere/ÈI sedere/ÈSI soprassedere/ÈI $ grep È /usr/share/hunspell/it_IT.aff TRY aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùèìjUZKHWJYQXÙÀÒÈÌÉ # Nota: non presenti nel dizionario: ÙÀÒÈÌÉ, vanno aggiunte alla TRY rigenerata MAP eéèEÉÈ "I" flag seems to work well, $ echo possedermi possederti possedervi possederci | hunspell -a -d it_IT @(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.2) * * * * Do not know what "È" flag was supposed to handle. By the way, other words in above list should show similar problems. I do not speak italian, so I suggest you to report this problem directly to the upstream email available in it_IT.aff file. E-Mail: marinalatinilibreofficeorg Hope this helps, Regards, -- Agustin
Bug#1068329: seems xz-utils 5.6.0 and 5.6.1 deb files has the backdoor, please remove both
Hi ZenWorker,Am 03.04.2024 um 15:51 schrieb ZenWalker :Package: snapshot.debian.orgSeverity: graveDebian is tracking issues related to the xz backdoor additionally at https://salsa.debian.org/ftp-team/xz-2024-incident/. I made Bastian aware of your perfect catch and this is now also https://salsa.debian.org/ftp-team/xz-2024-incident/-/issues/13.Thank you for your help!Martin
Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py
Solving this requires adding Depends: python3-libusb1
Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py
As see in <https://github.com/jliljebl/flowblade/blob/master/flowblade-trunk/docs/RELEASE_NOTES.md>: "Distro packagers, please see info on the needed configuration file addition (/etc/udev/rules.d/90-flowblade.rules) described in the link to docs above." Martin-Éric
Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py
Package: flowblade Version: 2.14.0.1-1 Severity: important $ flowblade FLOWBLADE MOVIE EDITOR 2.14.0.1 --- Launch script dir: /usr/bin Running from installation... modules path: /usr/share/flowblade/Flowblade MLT found, version: 7.12.0 Failed to import module app.py to launch Flowblade! ERROR: No module named 'usb1' Installation was assumed to be at: /usr/share/flowblade/Flowblade -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flowblade depends on: ii ffmpeg7:5.1.4-0+deb12u1 ii frei0r-plugins1.8.0-1+b1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gtk-3.03.24.38-2~deb12u1 ii gir1.2-pango-1.0 1.50.12+ds-1 ii gmic 2.9.4-4+b4 ii libmlt-data 7.12.0-1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii python3 3.11.2-1+b1 ii python3-cairo 1.20.1-5+b1 ii python3-dbus 1.3.2-4+b1 ii python3-distutils 3.11.2-3 ii python3-gi3.42.2-3+b1 ii python3-gi-cairo 3.42.2-3+b1 ii python3-mlt 7.12.0-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-opencv4.6.0+dfsg-12 ii python3-pil 9.4.0-1.1+b1 ii swh-plugins 0.4.17-2 flowblade recommends no packages. flowblade suggests no packages. -- no debconf information
