Bug#1005953: needrestart: user session restart needing detection broken probably by cgroupv2 from systemd 247.2-4
Control: tags -1 + fixed-upstream Control: forwarded -1 https://github.com/liske/needrestart/commit/29fcd57cd89a962bb94adbf116acd9a61036b6eb https://github.com/liske/needrestart/issues/213 https://github.com/liske/needrestart/issues/235 On Fri, 18 Feb 2022 09:42:03 +0800 Paul Wise wrote: > needrestart detects that user@1000.service needs to be restarted, > instead of that the pabs user sessions have outdated binaries. This has been fixed upstream and it looks like upstream will soon make a new release 3.6 that fixes this issue. Please include the new release in Debian unstable once the release has happened. https://github.com/liske/needrestart/commits/master -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1011003: regression: qemu-user-static produces segfaults in foreign arch mmdebstrap
17.05.2022 07:26, Johannes Schauer Marin Rodrigues wrote: ... I just learned about a much simpler way (classic: right after asking the expert). qemu-user emulation is also disabled by setting the QEMU_VERSION variable to something as this will mean that qemu-user exits without doing anything (other than printing version information): https://sources.debian.org/src/qemu/1:7.0+dfsg-7/linux-user/main.c/?hl=543#L480 This is unexpected to me :) But please do note it will exit successfully. So you don't know if it was qemu who was successful or a program you tried to run. Just something to be aware of. /mjt
Bug#1010958: sscg FTBFS with OpenSSL 3.0.3
Control: reassign -1 openssl 3.0.2-1 Control: affects -1 sscg 3.0.2-1 Control: tag -1 fixed-upstream Kurt Roeckx [2022-05-15 23:05 +0200]: > It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247 Indeed, thank you! Updating bug status. I see openssl 3.0.3-4 is supposed to fix that, I'll test and verify/close this bug. Martin
Bug#1011047: New version of vpnc with security improvements
Thank you very much, Florian! I'll test the new packages. Best regards Andreas On 16.05.22 16:46, Florian Schlichting wrote: I've just uploaded the new version, which will close this bug soonish. Please test the new package if you can. Florian
Bug#1011003: regression: qemu-user-static produces segfaults in foreign arch mmdebstrap
Quoting Michael Tokarev (2022-05-16 07:46:01) > Yes this is possible, but only at the binfmt_misc level. > >echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- disable this particular > entry >echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- enable it > >echo 0 > /proc/sys/fs/binfmt_misc/status-- disable whole binfmt support >echo 1 > /proc/sys/fs/binfmt_misc/status-- enable it > > With systemd you can disable particular formats/architectures entirely > by masking /usr/lib/binfmt.d/qemu-foo.conf in /etc/binfmt.d/ (if you remove > binfmt-support). I just learned about a much simpler way (classic: right after asking the expert). qemu-user emulation is also disabled by setting the QEMU_VERSION variable to something as this will mean that qemu-user exits without doing anything (other than printing version information): https://sources.debian.org/src/qemu/1:7.0+dfsg-7/linux-user/main.c/?hl=543#L480 I'm just noting this here because I'm sure future-me will soon forget about this again. XD signature.asc Description: signature
Bug#1011110: unblock: android-platform-tools/29.0.6-14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package android-platform-tools (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] Previous issue such as #1010231 was already resolved, and now autopkgtest results are all fine: - https://qa.debian.org/excuses.php?package=android-platform-tools - https://qa.debian.org/excuses.php?package=android-platform-art - https://qa.debian.org/excuses.php?package=android-platform-frameworks-base Migration period already passed for a few days, but still cannot be migrated automatically, so I filed this ticket for help. [ Tests ] All 3 packages' autopkgtest got passed, and they run well on my enironment. [ Risks ] None so far. If there's issue, I'll fix it. [ Checklist ] [*] all changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in testing [ Other info ] Package android-platform-art and android-platform-frameworks-base should be migrated at the same time. unblock android-platform-tools/29.0.6-14 unblock android-platform-art/11.0.0+r48-3 unblock android-platform-frameworks-base/1:10.0.0+r36-5 Cheers, Roger
Bug#1011003: regression: qemu-user-static produces segfaults in foreign arch mmdebstrap
Quoting Johannes Schauer Marin Rodrigues (2022-05-16 16:49:12) > Then reboot the thing just to be sure and then run: > > $ mmdebstrap --arch=arm64 --variant=apt unstable /dev/null > ... > I: extracting archives... > done > I: installing essential packages... > done > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > E: run_chroot failed: E: env --unset=APT_CONFIG --unset=TMPDIR > /usr/sbin/chrod > W: listening on child socket failed: > I: removing tempdir /tmp/mmdebstrap.nBUnpBBsox... > E: mmdebstrap failed to run > root@hostname:/home/user# dpkg -l | grep qemu > ii qemu-guest-agent 1:7.0+dfsg-7 > amd64 t > ii qemu-user-static 1:7.0+dfsg-7 > amd64 ) > > Now you have a reproducer that installed qemu-user-static on a real system > and not a chroot and we observe the same effect. oh and just to make sure that this is not an mmdebstrap thing we can also use debootstrap on our freshly installed system and observe the same problem: root@hostname:/home/user# debootstrap --foreign --arch arm64 unstable debian-unstable ... I: Extracting libsmartcols1... I: Extracting libuuid1... I: Extracting mount... I: Extracting util-linux... I: Extracting util-linux-extra... I: Extracting libxxhash0... I: Extracting liblzma5... I: Extracting zlib1g... root@hostname:/home/user# chroot debian-unstable qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault root@hostname:/home/user# So now you have a reproducer where we don't even do anything special anymore. We use debian-installer to create the Debian system and we use debootstrap to trigger the problem. Thanks! cheers, josch signature.asc Description: signature
Bug#1011109: bitstormlite: reproducible-builds: embedded build paths in /usr/bin/bitstormlite
Source: bitstormlite
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The build path is embedded in /usr/bin/bitstormlite:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/bitstormlite.html
/build/1st/bitstormlite-0.2q/src/bstring.h:37
vs.
/build/2/bitstormlite-0.2q/2nd/src/bstring.h:37
The attached patch fixes this by updating to debhelper compat 13, which
includes -ffile-prefix-map in the various build flags and avoids
embedding the build paths in the binaries.
With this patch applied, bitstormlite should build reproducibly on
tests.reproducible-builds.org!
live well,
vagrant
From fd6750aa0733200a9622b273b48a33d0ef53964a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Tue, 17 May 2022 01:54:27 +
Subject: [PATCH 2/5] Update to debhelper-compat 13.
---
debian/compat | 1 -
debian/control | 2 +-
debian/rules | 9 -
3 files changed, 9 insertions(+), 3 deletions(-)
delete mode 100644 debian/compat
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 45a4fb7..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-8
diff --git a/debian/control b/debian/control
index 702a8fb..f8abb4d 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
Priority: optional
Maintainer: Debian QA Group
Homepage: http://sourceforge.net/projects/bbom/
-Build-Depends: debhelper (>= 8.0.0), pkg-config, libgtk2.0-dev, libcurl4-gnutls-dev, autotools-dev
+Build-Depends: debhelper-compat (= 13), pkg-config, libgtk2.0-dev, libcurl4-gnutls-dev
Standards-Version: 3.9.3
Package: bitstormlite
diff --git a/debian/rules b/debian/rules
index 9109369..eb91fdd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,11 @@
#!/usr/bin/make -f
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-format
+
%:
- dh $@ --with autotools_dev
+ dh $@
+
+override_dh_autoreconf:
+
+override_dh_auto_configure:
+ ./configure --build=$(DEB_HOST_MULTIARCH) --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) --disable-maintainer-mode --disable-dependency-tracking
--
2.30.2
signature.asc
Description: PGP signature
Bug#1011108: ftbfs: forces std=c++14
Package: macromoleculebuilder Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic ubuntu-patch Dear maintainers, The macromoleculebuilder source package fails to build in Debian unstable: [...] /usr/bin/c++ -DBuildNtC -DLEPTON_BUILDING_STATIC_LIBRARY -DLepton_USAGE -DMMBlib_EXPORTS -DUSE_MMB_CONSTEXPR -DUSE_OPENMM -isystem /tmp/macromoleculebuilder-3.5+dfsg/include -isystem /usr/include/simbody-isystem /usr/include/openmm -isystem /usr/include/openmm/reference -isystem /include -isystem /tmp/macromoleculebuilder-3.5+dfsg/3rdparty/Lepton1.3/include -D BuildNtC -D USE_OPENMM -g -O2 -ffile-prefix-map=/tmp/macromoleculebuilder-3.5+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -O0 -fvisibility=hidden -O3 -DNDEBUG -fPIC -DMMB_BUILDING_SHARED_LIBRARY -std=c++14 -MD -MT CMakeFiles/MMBlib.dir/src/ConstraintContainer.cpp.o -MF CMakeFiles/MMBlib.dir/src/ConstraintContainer.cpp.o.d -o CMakeFiles/MMBlib.dir/src/ConstraintContainer.cpp.o -c /tmp/macromoleculebuilder-3.5+dfsg/src/ConstraintContainer.cpp In file included from /usr/include/tao/pegtl.hpp:8, from /usr/include/gemmi/cif.hpp:13, from /usr/include/gemmi/mmread.hpp:9, from /usr/include/molmodel/internal/Compound.h:48, from /usr/include/SimTKmolmodel.h:53, from /tmp/macromoleculebuilder-3.5+dfsg/include/UnitCellParameters.h:3, from /tmp/macromoleculebuilder-3.5+dfsg/src/UnitCellParameters.cpp:4: /usr/include/tao/pegtl/demangle.hpp:23:33: error: 'string_view' in namespace 'std' does not name a type 23 |[[nodiscard]] constexpr std::string_view demangle() noexcept; [...] This is because tao-pegtl-dev now requires C++17, but -std=c++14 is being forced. I've uploaded the attached patch in Ubuntu to work around this by forcing c++17 instead of c++14. You could also probably drop the forcing entirely, since the default standard nowadays is gnu17 (C++17 with GNU extensions). The package currently still fails to build from source because gemmi's headers are also incompatible with the new tao-pegtl; but I'm hoping this will be resolved when bug #1009415 is fixed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru macromoleculebuilder-3.5+dfsg/debian/patches/CXX17.patch macromoleculebuilder-3.5+dfsg/debian/patches/CXX17.patch --- macromoleculebuilder-3.5+dfsg/debian/patches/CXX17.patch1969-12-31 16:00:00.0 -0800 +++ macromoleculebuilder-3.5+dfsg/debian/patches/CXX17.patch2022-05-16 18:02:44.0 -0700 @@ -0,0 +1,21 @@ +Description: Use C++17 standard, not C++14. + The macromoleculebuilder tries to force C++14 in the compiler to ensure + access to newer language features. However, C++14 is now too *old* for + some of the build-dependencies (tao-pegtl-dev) and causes a build failure. +Author: Steve Langasek +Last-Update: 2022-05-16 +Forwarded: no + +Index: macromoleculebuilder-3.5+dfsg/CMakeLists.txt +=== +--- macromoleculebuilder-3.5+dfsg.orig/CMakeLists.txt macromoleculebuilder-3.5+dfsg/CMakeLists.txt +@@ -8,7 +8,7 @@ + + PROJECT(MMB LANGUAGES CXX) + +-SET(CMAKE_CXX_STANDARD 14) ++SET(CMAKE_CXX_STANDARD 17) + SET(CMAKE_CXX_EXTENSIONS OFF) + SET(CMAKE_CXX_STANDARD_REQUIRED ON) + diff -Nru macromoleculebuilder-3.5+dfsg/debian/patches/series macromoleculebuilder-3.5+dfsg/debian/patches/series --- macromoleculebuilder-3.5+dfsg/debian/patches/series 2022-03-30 03:37:26.0 -0700 +++ macromoleculebuilder-3.5+dfsg/debian/patches/series 2022-05-16 18:01:18.0 -0700 @@ -1,2 +1,3 @@ fix-Lepton-path.patch fix-Gemmi-compatibility.patch +CXX17.patch
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
One more time...
>From 40e4e72fe8180c4ec387ce1c5b8662d5c6dd3ca2 Mon Sep 17 00:00:00 2001
From: Jameson Graef Rollins
Date: Tue, 12 Apr 2022 13:03:53 -0700
Subject: [PATCH] new script to reinject message via sendmail
This script simply takes an existing mail file, parses it for sender
and all recipients, and constructs an appropriate sendmail command to
resend the message.
It requires the sendmail binary at runtime, and the notmuch python
library in order to extract the message from an existing notmuch
store.
Signed-off-by: Jameson Graef Rollins
---
sendmail-reinject | 73 +
sendmail-reinject.1.pod | 45 +
2 files changed, 118 insertions(+)
create mode 100755 sendmail-reinject
create mode 100644 sendmail-reinject.1.pod
diff --git a/sendmail-reinject b/sendmail-reinject
new file mode 100755
index 000..e50c484
--- /dev/null
+++ b/sendmail-reinject
@@ -0,0 +1,73 @@
+#!/usr/bin/env python3
+
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright 2022 Jameson Graef Rollins
+
+import sys
+import argparse
+import subprocess
+
+import email
+from email.policy import default
+from email.utils import parseaddr, getaddresses
+
+
+def sendmail(recipients, message, sender):
+"""send message via sendmail"""
+cmd = [
+'sendmail',
+'-f', sender,
+] + recipients
+print(' '.join(cmd), file=sys.stderr)
+subprocess.run(
+cmd,
+input=message.as_bytes(),
+check=True,
+)
+
+
+def main():
+parser = argparse.ArgumentParser(
+description="Reinject an email message via sendmail.",
+)
+pgroup = parser.add_mutually_exclusive_group(required=True)
+pgroup.add_argument(
+'message', nargs='?', type=argparse.FileType('rb'),
+help="email message path or '-' for stdin",
+)
+pgroup.add_argument(
+'-i', '--notmuch-id',
+help="message ID for notmuch extraction",
+)
+
+args = parser.parse_args()
+
+if args.id:
+import notmuch2 as notmuch
+db = notmuch.Database()
+query = f'id:{args.id}'
+assert db.count_messages(query) == 1, "Message ID does not match exactly one message??"
+for msg in db.messages(query):
+path = msg.path
+break
+f = open(path, 'rb')
+else:
+f = args.message
+
+# parse the email message
+msg = email.message_from_binary_file(f, policy=default)
+
+sender = parseaddr(msg['from'])[1]
+
+# extract all recipients
+tos = msg.get_all('to', [])
+ccs = msg.get_all('cc', [])
+resent_tos = msg.get_all('resent-to', [])
+resent_ccs = msg.get_all('resent-cc', [])
+recipients = [r[1] for r in getaddresses(tos + ccs + resent_tos + resent_ccs)]
+
+sendmail(recipients, msg, sender)
+
+
+if __name__ == '__main__':
+main()
diff --git a/sendmail-reinject.1.pod b/sendmail-reinject.1.pod
new file mode 100644
index 000..f89d0f1
--- /dev/null
+++ b/sendmail-reinject.1.pod
@@ -0,0 +1,45 @@
+=encoding utf8
+
+=head1 NAME
+
+sendmail-reinject - reinject an e-mail via sendmail
+
+=head1 SYNOPSIS
+
+B B
+
+B B<->
+
+B B<-i> B
+
+
+=head1 DESCRIPTION
+
+B reinjects a message to your MTA via sendmail.
+The message is read in (via path, stdin, or from notmuch via message
+ID), the sender and recipients are extracted, and the appropriate
+senmdail command is contructed to resent the message.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<--notmuch-id>,B<-i> B
+
+Message ID of message to reinject as know to a local notmuch database.
+Assumes the python3-notmuch package is available.
+
+=item B<--help>, B<-h>
+
+Show usage instructions.
+
+=back
+
+=head1 SEE ALSO
+
+sendmail(1), notmuch(1)
+
+=head1 AUTHOR
+
+B and this manpage were written by Jameson Graef
+Rollins .
--
2.35.1
Bug#1011107: binary packages should conflict/replace older ones
Source: waylandpp Version: 1.0.0-1 Severity: serious Perhaps libwayland-client++1 should conflict/replace libwayland-client++0, and the same for cursor and egl packages? Preparing to unpack .../libwayland-client++1_1.0.0-2_amd64.deb ... Unpacking libwayland-client++1:amd64 (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/libwayland-client++1_1.0.0-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libwayland-client++.so.1.0.0', which is also in package libwayland-client++0:amd64 1.0.0-1 Preparing to unpack .../libwayland-cursor++1_1.0.0-2_amd64.deb ... Unpacking libwayland-cursor++1:amd64 (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/libwayland-cursor++1_1.0.0-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libwayland-cursor++.so.1.0.0', which is also in package libwayland-cursor++0:amd64 1.0.0-1 Preparing to unpack .../libwayland-egl++1_1.0.0-2_amd64.deb ... Unpacking libwayland-egl++1:amd64 (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/libwayland-egl++1_1.0.0-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libwayland-egl++.so.1.0.0', which is also in package libwayland-egl++0:amd64 1.0.0-1 Errors were encountered while processing: /var/cache/apt/archives/libwayland-client++1_1.0.0-2_amd64.deb /var/cache/apt/archives/libwayland-cursor++1_1.0.0-2_amd64.deb /var/cache/apt/archives/libwayland-egl++1_1.0.0-2_amd64.deb -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1011106: debianutils: [INTL:pt] Update on Portuguese translation of MANPAGE
Package: debianutils Version: 5.7-0.2 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for debianutils's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro debianutils_5.7-0.2_pt.po.gz Description: application/gzip
Bug#1011105: ./easyrsa build-ca nopass still asks for PEM password
Package: easy-rsa Version: 3.0.8-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I encounter the following problem: ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 3.0.3 3 May 2022 (Library: OpenSSL 3.0.3 3 May 2022) Enter PEM pass phrase: That shouldn't happen. The issue has been reported upstream, but was supposed to have been closed already (https://github.com/OpenVPN/easy-rsa/issues/454). Can you please check that out? Regards, Daniel - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 easy-rsa depends on: ii openssl 3.0.3-3 Versions of packages easy-rsa recommends: pn opensc easy-rsa suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEIB9kcJqmmF4VguFXclr8JZgo7DMFAmKC1pEACgkQclr8JZgo 7DNijhAAurcP50qUKPt3IsLfk5sviL1h3GhnqBhhZXVAwoc9PPTfYLXZJBFBCmMk zu5aE6U9WtKlFQBAnWBbKOn/qGMdg1bfWOuMKmGmVGhJ29iQM7nCw6M9P9ev4iv4 ApNOW3J27ikCiE9CBowl+XsaQYe+BDGFpQp/KUMi6uw18JihyrVP6SUh4n9RzpvA RFeKSrzOITTIFTLPs8H0nxunmEt2jevpv6ZWEntjfYg1KYvMXv1rN90ovRuxxPHL cOV5OI1IynghODu8EAXSkX19c8hQsF7f+d6WCzJ/NIWgI/0H1A6lcHqlK5dtf2tX kt2k3X0bDitaNvN6kYjN5TWJXpMuhjnq4beHGR4n4ZrrCioLVLdBK3/9SLNWeyT0 t+/ACf0t/8bPert0G3W9sj1NTJe3SzrmWArV3Vkz10NwT8lsfpo38F2MckLBpICm 2GnnKZ9bPHXQlmaEEvfYhhFFLhg6H76siO8TBi2AHvkCLsC9dSe69q+GEO5uOwwI s/WOjg0X+zFCXKCezLkLhnODY4wnKe5X06J09QMyicl5UrBUlMJouLGxeA+rmb8P LzuI1+D0VeLFoqYiMQ/0WImy/rZYhljspifxzhM5N7CxJ02ep75YoDzKVA1mcY5d no0wLTeviCdB0UuR4EfGLt6kSkAStKgf0dLVPJvXyY/OrcreY/g= =ZV9W -END PGP SIGNATURE-
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Hello Jameson, On Mon 16 May 2022 at 12:33PM -07, Jameson Graef Rollins wrote: > Here's a new version of the patch addressing Sean's comments. I need it signed off; please see CONTRIBUTING.rst. -- Sean Whitton signature.asc Description: PGP signature
Bug#1010949: Reply to MIchael Biebl's message
I only figured it was systemd because systemd, from what I know is responsible for initiating suspend, and I figured waking up from it afterwards. But I'm not discounting the possibility it is a kernel issue. If there is any testing you want me to do (logs and that sort of thing) to determine what is causing this, I will be happy to try and oblige. And if you truly think this is a kernel issue, and have the authority to reassign the bug to the kernel team, then by all means please do so. My only interest is trying to get this issue solved. Also I'm not sure why I didn't get your reply to my posting. So sorry for the late follow-up.
Bug#1011079: kitty: New upstream release
Control: block -1 by 992743 992745 On Mon, May 16, 2022 at 05:42:39PM +0200, Vincent Blut wrote: > kitty version in testing/unstable is quite old now. Would it be possible to > have newer one, please? That's because it has new dependencies which aren't packaged yet. I've blocked this bug with those, for proper tracking. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1011103: inn2: Unable to start inn2 status=238/STATE_DIRECTORY error
On May 16, Richard Landster wrote: > May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed > to set up special execution directory in /var/lib: Not a directory > May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed > at step STATE_DIRECTORY spawning /usr/lib/news/bin/rc.news: Not a directory I think that there is something unusual in your system: how do /var/ and /var/lib/ look like? > Starting the service with /etc/init.d/inn2 does _not_ result in an error. I do not understand this, because the init script sources /lib/lsb/init-functions which sources /lib/lsb/init-functions.d/40-systemd which makes it just run systemctl anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#1011104: convlit: reproducible-builds: embedded build paths in /usr/bin/clit
Source: convlit Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build path is embedded in /usr/bin/clit: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/convlit.html /build/1st/convlit-1.8/clit18/clit.c:109 vs. /build/2/convlit-1.8/2nd/clit18/clit.c:109 The first patch fixes this by passing -ffile-prefix-map to CFLAGS in debian/rules, which avoids embedding the build paths in the binaries. The second patch fixes this by completing the transition to the dh build system, which includes -ffile-prefix-map in CFLAGS by default. With these patches applied, convlit should build reproducibly on tests.reproducible-builds.org! live well, vagrant From 3aaf27ae4627bcc32dd6e7c877f2e16891808f20 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Mon, 16 May 2022 21:31:09 + Subject: [PATCH 1/2] debian/rules: Pass -ffile-prefix-map in CFLAGS to avoid embedding build paths. https://reproducible-builds.org/docs/build-path/ --- debian/rules | 4 1 file changed, 4 insertions(+) diff --git a/debian/rules b/debian/rules index 60c65ac..d18f93e 100755 --- a/debian/rules +++ b/debian/rules @@ -17,6 +17,10 @@ ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) else CFLAGS += -O2 endif + +# Avoid embedding the build path for reproducible builds +CFLAGS += -ffile-prefix-map=$(CURDIR)=. + export CFLAGS -- 2.35.1 From 55cac9ca7525b81f670c5ee7df8b6145370aa8cd Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Mon, 16 May 2022 21:36:05 + Subject: [PATCH 2/2] debian/rules: Finish conversion to dh. --- debian/rules | 61 +++- 1 file changed, 8 insertions(+), 53 deletions(-) diff --git a/debian/rules b/debian/rules index d18f93e..40ffb83 100755 --- a/debian/rules +++ b/debian/rules @@ -11,59 +11,14 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all %: dh $@ -CFLAGS := -Wall -g -ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) -CFLAGS += -O0 -else -CFLAGS += -O2 -endif +override_dh_auto_build: + dh_auto_build --sourcedir=$(CURDIR)/lib + dh_auto_build --sourcedir=$(CURDIR)/clit18 -# Avoid embedding the build path for reproducible builds -CFLAGS += -ffile-prefix-map=$(CURDIR)=. +override_dh_auto_clean: + dh_auto_clean --sourcedir=$(CURDIR)/clit18 + dh_auto_clean --sourcedir=$(CURDIR)/lib + dh_auto_clean -export CFLAGS - - -build: build-stamp -build-stamp: - dh_testdir - $(MAKE) -C $(CURDIR)/lib - $(MAKE) -C $(CURDIR)/clit18 - touch $@ - -clean: - dh_testdir - dh_testroot - rm -f build-stamp - $(MAKE) -C $(CURDIR)/clit18 clean - $(MAKE) -C $(CURDIR)/lib clean - dh_clean - -install: build - dh_testdir - dh_testroot - dh_prep - dh_install - -binary-indep: -# do nothing - -binary-arch: build install - dh_testdir - dh_testroot - dh_installchangelogs - dh_installdocs - dh_installexamples +override_dh_installman: dh_installman debian/clit.1 - dh_link - dh_strip - dh_compress - dh_fixperms - dh_installdeb - dh_shlibdeps - dh_gencontrol - dh_md5sums - dh_builddeb - -binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install -- 2.35.1 signature.asc Description: PGP signature
Bug#1011103: inn2: Unable to start inn2 status=238/STATE_DIRECTORY error
Package: inn2 Version: 2.6.4-2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** We are building a bullseye replacement of a buster server that uses inn2 to act as a local usenet server. When we try to start the service using "systemctl start inn2.service" we get this error message: ? inn2.service - InterNetNews Loaded: loaded (/lib/systemd/system/inn2.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2022-05-13 15:28:34 PDT; 18s ago Docs: man:innd(8) Process: 3284 ExecStart=/usr/lib/news/bin/rc.news (code=exited, status=238/STATE_DIRECTORY) Main PID: 3284 (code=exited, status=238/STATE_DIRECTORY) CPU: 1ms May 13 15:28:34 usenet-dev.stanford.edu systemd[1]: Starting InterNetNews... May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed to set up special execution directory in /var/lib: Not a directory May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed at step STATE_DIRECTORY spawning /usr/lib/news/bin/rc.news: Not a directory May 13 15:28:34 usenet-dev.stanford.edu systemd[1]: inn2.service: Main process exited, code=exited, status=238/STATE_DIRECTORY May 13 15:28:34 usenet-dev.stanford.edu systemd[1]: inn2.service: Failed with result 'exit-code'. May 13 15:28:34 usenet-dev.stanford.edu systemd[1]: Failed to start InterNetNews. Starting the service with /etc/init.d/inn2 does _not_ result in an error. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) Versions of packages inn2 depends on: ii cron [cron-daemon] 3.0pl1-137 pn inn2-inews ii libc6 2.31-13+deb11u3 ii libcrypt1 1:4.4.18-4 ii libdb5.35.3.28+dfsg1-0.8 pn libmime-tools-perl ii libpam0g1.4.0-9+deb11u1 ii libperl5.32 5.32.1-4+deb11u2 pn libpython3.9 ii libsasl2-2 2.1.27+dfsg-2.1+deb11u1 ii libssl1.1 1.1.1n-0+deb11u1 ii libsystemd0 247.3-7 ii lsb-base11.1.0 ii perl5.32.1-4+deb11u2 ii perl-base [perlapi-5.32.1] 5.32.1-4+deb11u2 ii postfix [mail-transport-agent] 3.5.6-1+b1 ii procps 2:3.3.17-5 pn time ii zlib1g 1:1.2.11.dfsg-2 inn2 recommends no packages. Versions of packages inn2 suggests: pn gnupg1 pn libgd-perl ii libkrb5-3 1.18.3-6+deb11u1 ii wget1.21-1+deb11u1
Bug#1011102: glusterfs: Please build with -DUATOMIC_NO_LINK_ERROR on hppa
Source: glusterfs Version: 10.1-3 Severity: normal User: debian-h...@lists.debian.org Usertags: hppa X-Debbugs-Cc: debian-h...@lists.debian.org Hi! Hello! Similar to m68k and sh4, hppa needs to be built with -DUATOMIC_NO_LINK_ERROR as well. Thus, can you please add hppa to the list of architectures for which -DUATOMIC_NO_LINK_ERROR is passed to the builds flags? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1010806: apt: Avoid color output on monochrome terminals
Am 2022-05-16 18:29, schrieb Adam Borowski: On Tue, May 10, 2022 at 07:34:25PM +0200, Axel Scheepers wrote: The terminfo entries stopped being maintained by late 80's. This doesn't seam to be true. The terminfo files seam to mostly come from ncurses-term, the ncurses package seams still to be maintained and getting updates (https://tracker.debian.org/pkg/ncurses). Looking at the upstream release notes, which state that they are form October 21, 2021, quiet a few new ones have been added: https://invisible-island.net/ncurses/announce.html#h3-database Therefore, it seams terminfo entries are still being maintained to this day. And even if they were, every new terminal would need to wait several years before it can have its definition known by operating systems (today, distributions). It's not like new kinds of real terminals are produced anymore, at least I don't know of any. In case of terminal emulators, they have to be packaged anyway, so a the terminfo file can be added to the appropriate package at the same time. The effect? Most terminals identify as "xterm", "xterm-256color", or "rxvt". For example both libvt (Gnome-Terminal, etc) and Konsole claim to be an xterm... There are terminals who choose to be compatible to xterm. It probably has more to do with programs wrongly hardcoding escape sequences than anything else, and there is nothing wrong with making an xterm-compatible terminal. However, that doesn't change the fact that other terminals exist as well. In addition to this, if terminals implement special new escape sequences (think about recent things like sixel for example), there is no way around an appropriate terminfo to make known that it's supported. And even if $TERM->terminfo were usable, a serial console has no way to pass env vars. As an install/rescue tool, apt gets run over a serial console pretty often. It works automatically for terminal emulators. Tools like getty can set the TERM variable. Yes, only the operator knows what is connected to a serial console. In cases where it is not known, personally, I think a dumb terminal should be assumed to maximize compatibility. But I guess in most cases, something like vt100 or xterm will often work, so I don't mind it too much. People who really need to can still override it. It's not automagic, but it works. Thus, using terminfo is definitely not a "Right Thing" this millenium. Most new programs just hardcode the codes, assuming a vt100-like terminal with a common set of capabilities. I'm happy to report, that aside from apt, I'm not using any of those programs. Yes, there are lazy modern programmers insisting on doing it wrong. Those programs will simply fail on various terminals. Let's not promote that, it won't right it. Setting TERM works, it works well, and it solves the problem in the best way possible. Just because it can't always do it automatically, doesn't mean we should give up and leave things unfixably broken. terminfo is the right thing. It is the only way to deal with these terminals. This will never change. Regards, Daniel Abrecht
Bug#1011087: RFS: libshout-idjc/2.4.4-1 -- broadcast streaming library with IDJC extensions
Is this a team upload? If so, please note that in the changelog.
Bug#1007744: dovecot: FTBFS on ppc64el
On Wed, Apr 13, 2022 at 09:33:58PM +0200, Christian Göttsche wrote:
> It looks like the ppc64el build was retried and succeeded.
>
> Maybe the timeouts should be increased for slow build systems, similar
> what upstream did for running under valgrind with commit 2d12409a
> ("lib-smtp: Adjust test timeouts based on valgrind runtime
> presence")[1].
>...
All ppc64el buildds are pretty fast, timeout problems due to slow
buildds are usually on other architectures.
cu
Adrian
Bug#1011101: nodejs: FTBFS on mipsel: multiple failures with openssl 3.0
Package: nodejs Version: 16.14.2+dfsg1-1+b1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Last time so many openssl-related test failures happened, OPENSSL_CONF env was set to a relative path, and nodejs/openssl3 expected an absolute path. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on: ii libc6 2.33-7 ii libnode93 16.14.2+dfsg1-1+b1 Versions of packages nodejs recommends: ii ca-certificates 20211016 ii nodejs-doc 16.14.2+dfsg1-1 Versions of packages nodejs suggests: ii npm 8.10.0~ds1-2 -- no debconf information
Bug#1011100: nodejs: FTBFS on riscv64 caused by another flaky cpu profiler test
Package: nodejs Version: 16.14.2+dfsg1-1+b1 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Severity is important (because riscv64). sequential/test-diagnostic-dir-cpu-prof fails. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on: ii libc6 2.33-7 ii libnode93 16.14.2+dfsg1-1+b1 Versions of packages nodejs recommends: ii ca-certificates 20211016 ii nodejs-doc 16.14.2+dfsg1-1 Versions of packages nodejs suggests: ii npm 8.10.0~ds1-2 -- no debconf information
Bug#1011097: [Pkg-javascript-devel] Bug#1011097: webpack fails with nodejs compiled with OpenSSL 3.0
Le lun. 16 mai 2022 à 22:09, Adrian Bunk a écrit :
> Package: webpack
> Version: 4.43.0-7
> Severity: serious
> Tags: ftbfs
> Control: affects -1 src:macaulay2
>
> https://buildd.debian.org/status/logs.php?pkg=macaulay2=all
>
> ...
> > build
> > webpack
>
> node:internal/crypto/hash:67
> this[kHandle] = new _Hash(algorithm, xofLen);
> ^
>
> Error: error:0308010C:digital envelope routines::unsupported
> at new Hash (node:internal/crypto/hash:67:19)
> at Object.createHash (node:crypto:130:10)
> at module.exports
> (/usr/share/nodejs/webpack/lib/util/createHash.js:135:53)
> at NormalModule._initBuildHash
> (/usr/share/nodejs/webpack/lib/NormalModule.js:417:16)
> at handleParseError
> (/usr/share/nodejs/webpack/lib/NormalModule.js:471:10)
> at /usr/share/nodejs/webpack/lib/NormalModule.js:503:5
> at /usr/share/nodejs/webpack/lib/NormalModule.js:358:12
> at /usr/share/nodejs/loader-runner/lib/LoaderRunner.js:406:3
> at iterateNormalLoaders
> (/usr/share/nodejs/loader-runner/lib/LoaderRunner.js:232:10)
> at Array.
> (/usr/share/nodejs/loader-runner/lib/LoaderRunner.js:223:4)
> at Storage.finished
> (/usr/share/nodejs/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
> at
> /usr/share/nodejs/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
> at /usr/share/nodejs/graceful-fs/graceful-fs.js:123:16
> at FSReqCallback.readFileAfterClose [as oncomplete]
> (node:internal/fs/read_file_context:68:3) {
> opensslErrorStack: [ 'error:0386:digital envelope
> routines::initialization error' ],
> library: 'digital envelope routines',
> reason: 'unsupported',
> code: 'ERR_OSSL_EVP_UNSUPPORTED'
> }
> make[4]: *** [Makefile:43: highlightjs/highlight.js] Error 1
>
>
> Background:
> https://nodejs.org/en/blog/release/v17.0.0/
>
> This might be fixed in upstream version 5.54 (untested).
>
webpack 4 is using long time deprecated hash functions (like md4).
Recent versions of webpack have fixed this.
Jérémy
Bug#1011099: dh_installsysusers should be sequenced before dh_installtmpfiles
Package: debhelper Version: 13.3.4 tmpfile.d files may reference users/groups that are created by sysusers.d files so these should be created first. Currently they are sequenced the other way: ``` $include_if_compat_X_or_newer->(13, 'dh_installtmpfiles'), $include_if_compat_X_or_newer->(14, 'dh_installsysusers'), $include_if_compat_X_or_newer->(11, 'dh_installsystemd'), ``` which can result in errors like this on package installation: ``` Preparing to unpack foo_0.1_all.deb ... Unpacking foo (0.1) ... Setting up foo (0.1) ... foo.conf:2: Failed to resolve group 'mygroup'. Creating group mygroup with gid 997. ``` This would also be similar to the relationship between tmpfiles and sysusers in systemd where there is and 'After=' relationship https://github.com/systemd/systemd/blob/5efbd0bf897a990ebe43d7dc69141d87c404ac9a/units/systemd-tmpfiles-setup.service#L15
Bug#1011097: webpack fails with nodejs compiled with OpenSSL 3.0
Package: webpack
Version: 4.43.0-7
Severity: serious
Tags: ftbfs
Control: affects -1 src:macaulay2
https://buildd.debian.org/status/logs.php?pkg=macaulay2=all
...
> build
> webpack
node:internal/crypto/hash:67
this[kHandle] = new _Hash(algorithm, xofLen);
^
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports (/usr/share/nodejs/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash
(/usr/share/nodejs/webpack/lib/NormalModule.js:417:16)
at handleParseError (/usr/share/nodejs/webpack/lib/NormalModule.js:471:10)
at /usr/share/nodejs/webpack/lib/NormalModule.js:503:5
at /usr/share/nodejs/webpack/lib/NormalModule.js:358:12
at /usr/share/nodejs/loader-runner/lib/LoaderRunner.js:406:3
at iterateNormalLoaders
(/usr/share/nodejs/loader-runner/lib/LoaderRunner.js:232:10)
at Array.
(/usr/share/nodejs/loader-runner/lib/LoaderRunner.js:223:4)
at Storage.finished
(/usr/share/nodejs/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
at
/usr/share/nodejs/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
at /usr/share/nodejs/graceful-fs/graceful-fs.js:123:16
at FSReqCallback.readFileAfterClose [as oncomplete]
(node:internal/fs/read_file_context:68:3) {
opensslErrorStack: [ 'error:0386:digital envelope
routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
make[4]: *** [Makefile:43: highlightjs/highlight.js] Error 1
Background:
https://nodejs.org/en/blog/release/v17.0.0/
This might be fixed in upstream version 5.54 (untested).
Bug#1011078: chromium: arm64 package not available in bullseye-security
clone 1011078 -1
retitle -1 chromium: i386 and armhf packages FTBFS in bullseye
tags -1 bullseye ftbfs
severity -1 serious
thanks
On Mon, 16 May 2022 20:33:46 +0200
Salvatore Bonaccorso wrote:
[...]
> Hi Andres,
>
> On Mon, May 16, 2022 at 12:36:38PM -0400, Andres Salomon wrote:
> > On 5/16/22 11:35, Ben Steinberg wrote:
> >
> > Security Team, is there a way for me to get access to the logs for
> > chromium's security builds by ssh'ing into a machine? Or some other
> > way for me to view them?
>
> The build logs are not public but we can retrieve them. But in this
> case from #debian-buildd:
>
> [17:58] < carnil> Hi, can someone double check if chromium/arm64
> build for bullseye-security is still really in building state?
> [18:07] < jcristau> carnil: it is not [18:07] < jcristau> guessing
> the host crashed a few days ago and it got a power cycle
>
> Which I did and the package is not back in building state for arm64.
>
> Regards,
> Salvatore
>
Okay, so arm64 should be building now (thanks Salvatore!). Assuming no
build failures, they should show up in the archive in a day or two.
Chromium is a slow build. :)
While looking at this, I noticed that i386 and armhf in
bullseye-security were even older (last built circa chromium v99). The
build log shows this build failure on armhf:
[12837/50904] CXX obj/base/base/task_annotator.o
FAILED: obj/base/base/task_annotator.o
clang++ -MMD -MF obj/base/base/task_annotator.o.d -DPA_PCSCAN_STACK_SUPPORTED
-DUSE_SYMBOLIZE
-DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LAR
GEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE
-DCR_CLANG_REVISION=\"llvmorg-15-init-3677-g
8133778d-4\" -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DBASE_IMPLEMENTATION -DGLI
B_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DU_USI
NG_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1
-DU_ENABLE_TRACING=1 -DU_ENABLE_R
ESOURCE_TRACING=0 -DU_STATIC_IMPLEMENTATION
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -I../.. -
Igen -I../../third_party/perfetto/include
-Igen/third_party/perfetto/build_config -Igen/third
_party/perfetto -Igen/shim_headers/zlib_shim -Igen/shim_headers/libevent_shim
-I../../third_p
arty/abseil-cpp -I../../third_party/boringssl/src/include
-I../../third_party/protobuf/src -I
gen/protoc_out -Igen/third_party/perfetto -I../../third_party/icu/source/common
-I../../third
_party/icu/source/i18n -Wall -Wextra -Wimplicit-fallthrough
-Wunreachable-code-aggressive -Wt
hread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter
-Wloop-analys
is -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-psabi
-Wno-ignored-prag
ma-optimize -Wshadow -fno-delete-null-pointer-checks -fno-ident
-fno-strict-aliasing --param=
ssp-buffer-size=4 -fstack-protector -fno-unwind-tables
-fno-asynchronous-unwind-tables -fPIC
-pthread -fcolor-diagnostics -fmerge-all-constants
-fcrash-diagnostics-dir=../../tools/clang/
crashreports -mllvm -instcombine-lower-dbg-declare=0 -ffp-contract=off
--target=arm-linux-gnu
eabihf -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a
-fdebug-compilation-dir=. -no-c
anonical-prefixes -mfpu=vfpv3-d16 -mthumb -ftrivial-auto-var-init=pattern
-fno-omit-frame-poi
nter -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion
-Wtautological-overlap-comp
are -Wexit-time-destructors -Wglobal-constructors -I/usr/include/glib-2.0
-I/usr/lib/arm-linu
x-gnueabihf/glib-2.0/include -Wexit-time-destructors -fdata-sections
-ffunction-sections -fno
-unique-section-names -DPROTOBUF_ALLOW_DEPRECATED=1 -std=c++17 -Wno-trigraphs
-fno-aligned-ne
w -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -Wdate-time
-D_FORTIFY_SOURCE=2 -O2 -
fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-securit
y -Wno-conversion -Wno-unused-function -Wno-unused-variable
-Wno-unused-private-field -Wno-de
precated-declarations -Wno-unknown-pragmas -fno-delete-null-pointer-checks -c
../../base/tas
k/common/task_annotator.cc -o obj/base/base/task_annotator.o
In file included from ../../base/task/common/task_annotator.cc:15:
../../base/sys_byteorder.h:56:28: error: constexpr function never produces a
constant express
ion [-Winvalid-constexpr]
inline constexpr uintptr_t ByteSwapUintPtrT(uintptr_t x) {
../../base/sys_byteorder.h:65:12: note: non-constexpr function 'ByteSwap'
cannot be used in a constant expression
return ByteSwap(static_cast(x));
^
../../base/sys_byteorder.h:33:17: note: declared here
inline uint32_t ByteSwap(uint32_t x) {
^
1 error generated.
And this build failure on i386:
[12741/51668] CXX obj/base/base/sampling_heap_profiler.o
FAILED: obj/base/base/sampling_heap_profiler.o
clang++ -MMD -MF obj/base/base/sampling_heap_profiler.o.d
-DPA_PCSCAN_STACK_SUPPORTED -DUSE_S
YMBOLIZE
Bug#1011094: glusterfs: Please build with -DUATOMIC_NO_LINK_ERROR on sh4
Source: glusterfs Version: 10.1-3 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello! Similar to m68k, sh4 needs to be built with -DUATOMIC_NO_LINK_ERROR as well. Thus, can you please add sh4 to the list of architectures for which -DUATOMIC_NO_LINK_ERROR is passed to the builds flags? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD
I had made the following draft, which contains some additional info to which
you should send your upstream request (it's a bit more then Ben suggested):
On Monday, 16 May 2022 17:45:08 CEST Сергей Фёдоров wrote:
> I rebuilt the kernel with changing to
> "./linux-source-5.17.6-1/drivers/i2c/i2c-smbus.c"
>
> line 358:
> if (slot_count > 4) {
> dev_warn(>dev,
>"Systems with more than 4 memory slots not
>supported yet, not instantiating SPD\n");
>return;
> }
>
> replaced with
> if (slot_count > 8) {
> dev_warn(>dev,
>"Systems with more than 8 memory slots not
>supported yet, not instantiating SPD\n");
>return;
> }
>
The 4 slot limit was specified in 5ace60859e84113b7a185c117fbf2c429d381b59
(upstream commit ID) and the secondary commit message had this:
"Start with just DDR2, DDR3 and DDR4 on x86 for now, and only for systems with
no more than 4 memory slots. These limitations may be lifted later."
This is an upstream issue and a change to '8' should be discussed there.
~/dev/kernel.org/linux$ ./scripts/get_maintainer.pl drivers/i2c/i2c-smbus.c
Wolfram Sang (maintainer:I2C SUBSYSTEM)
linux-...@vger.kernel.org (open list:I2C SUBSYSTEM)
linux-ker...@vger.kernel.org (open list)
So I'd suggest to send it to linux-...@vger.kernel.org and add the other
2 addresses in the CC and also add "Jean Delvare " to the
TO or CC as that was the original author of the aforementioned commit.
Could you 'forward' your issue there and if/when done so, notify the BTS of
where that has taken place? Then we can follow its progress as well.
signature.asc
Description: This is a digitally signed message part.
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Here's a new version of the patch addressing Sean's comments.
>From f4d9e714b556a144644cb597a783e4469506ddd1 Mon Sep 17 00:00:00 2001
From: Jameson Graef Rollins
Date: Tue, 12 Apr 2022 13:03:53 -0700
Subject: [PATCH] new script to reinject message via sendmail
---
sendmail-reinject | 73 +
sendmail-reinject.1.pod | 45 +
2 files changed, 118 insertions(+)
create mode 100755 sendmail-reinject
create mode 100644 sendmail-reinject.1.pod
diff --git a/sendmail-reinject b/sendmail-reinject
new file mode 100755
index 000..e50c484
--- /dev/null
+++ b/sendmail-reinject
@@ -0,0 +1,73 @@
+#!/usr/bin/env python3
+
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright 2022 Jameson Graef Rollins
+
+import sys
+import argparse
+import subprocess
+
+import email
+from email.policy import default
+from email.utils import parseaddr, getaddresses
+
+
+def sendmail(recipients, message, sender):
+"""send message via sendmail"""
+cmd = [
+'sendmail',
+'-f', sender,
+] + recipients
+print(' '.join(cmd), file=sys.stderr)
+subprocess.run(
+cmd,
+input=message.as_bytes(),
+check=True,
+)
+
+
+def main():
+parser = argparse.ArgumentParser(
+description="Reinject an email message via sendmail.",
+)
+pgroup = parser.add_mutually_exclusive_group(required=True)
+pgroup.add_argument(
+'message', nargs='?', type=argparse.FileType('rb'),
+help="email message path or '-' for stdin",
+)
+pgroup.add_argument(
+'-i', '--notmuch-id',
+help="message ID for notmuch extraction",
+)
+
+args = parser.parse_args()
+
+if args.id:
+import notmuch2 as notmuch
+db = notmuch.Database()
+query = f'id:{args.id}'
+assert db.count_messages(query) == 1, "Message ID does not match exactly one message??"
+for msg in db.messages(query):
+path = msg.path
+break
+f = open(path, 'rb')
+else:
+f = args.message
+
+# parse the email message
+msg = email.message_from_binary_file(f, policy=default)
+
+sender = parseaddr(msg['from'])[1]
+
+# extract all recipients
+tos = msg.get_all('to', [])
+ccs = msg.get_all('cc', [])
+resent_tos = msg.get_all('resent-to', [])
+resent_ccs = msg.get_all('resent-cc', [])
+recipients = [r[1] for r in getaddresses(tos + ccs + resent_tos + resent_ccs)]
+
+sendmail(recipients, msg, sender)
+
+
+if __name__ == '__main__':
+main()
diff --git a/sendmail-reinject.1.pod b/sendmail-reinject.1.pod
new file mode 100644
index 000..f89d0f1
--- /dev/null
+++ b/sendmail-reinject.1.pod
@@ -0,0 +1,45 @@
+=encoding utf8
+
+=head1 NAME
+
+sendmail-reinject - reinject an e-mail via sendmail
+
+=head1 SYNOPSIS
+
+B B
+
+B B<->
+
+B B<-i> B
+
+
+=head1 DESCRIPTION
+
+B reinjects a message to your MTA via sendmail.
+The message is read in (via path, stdin, or from notmuch via message
+ID), the sender and recipients are extracted, and the appropriate
+senmdail command is contructed to resent the message.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<--notmuch-id>,B<-i> B
+
+Message ID of message to reinject as know to a local notmuch database.
+Assumes the python3-notmuch package is available.
+
+=item B<--help>, B<-h>
+
+Show usage instructions.
+
+=back
+
+=head1 SEE ALSO
+
+sendmail(1), notmuch(1)
+
+=head1 AUTHOR
+
+B and this manpage were written by Jameson Graef
+Rollins .
--
2.35.1
Bug#1010916: linux-image-5.17.0-2-amd64 - KVM?
Control: tag -1 moreinfo On Fri, 2022-05-13 at 09:16 +0200, klak wrote: [...] > May 13 06:09:26 kk-12x2260 kernel: [ 1093.830059] BUG: unable to handle page > fault for address: 0002e503 > May 13 06:09:26 kk-12x2260 kernel: [ 1093.832535] #PF: supervisor read access > in kernel mode > May 13 06:09:26 kk-12x2260 kernel: [ 1093.834982] #PF: error_code(0x) - > not-present page > May 13 06:09:26 kk-12x2260 kernel: [ 1093.837345] PGD 0 P4D 0 > May 13 06:09:26 kk-12x2260 kernel: [ 1093.839660] Oops: [#2] PREEMPT SMP > NOPTI > May 13 06:09:26 kk-12x2260 kernel: [ 1093.841948] CPU: 17 PID: 2954 Comm: > vhost-2947 Tainted: G D 5.17.0-2-amd64 #1 Debian 5.17.6-1 [...] The "Tainted: ... D" means this was not the first "oops" since boot. Usually the first "oops" will have the most useful information about what went wrong. Could you please look back through the log to find an "oops" log that includes "not tainted"? Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#994855: zfs-dkms: Panic when receiving, fixed upstream
Is there a plan to fix this in bullseye as well?
Bug#1009169: Any ETA?
Hi Rob, Do you have an ETA? Will it be packaged in one week, one month, several months? Thanks, Eugen
Bug#1011093: sip6: fails to process __delattr__ in libarcus 5.0~beta (works with sip 6.5)
Package: sip6 Version: 6.6.1+dfsg-2 Severity: important X-Debbugs-Cc: s...@highlab.com When trying to build libArcus 5.0~beta (part of the Cura slicer), sip-build 6.6 produces bogus C++ output that fails to compile: [ 95%] Building CXX object CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o /usr/bin/c++ -DSIP_VERSION=0x060601 -Dsip_pyArcus_EXPORTS -I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/src -I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/python -I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/src -isystem /usr/include/python3.10 -g -O2 -ffile-prefix-map=/tmp/do-gbp.debian_unstable.master.xf2HJ/source=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -flto -fno-fat-lto-objects -fPIC -std=c++17 -MD -MT CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o -MF CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o.d -o CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o -c /tmp/do-gbp.debian_unstable.master.xf2HJ/source/python/PythonMessage.cpp /tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/pyArcus/pyArcus/sippyArcuspart3.cpp: In function ‘int slot_PythonMessage___setattr__(PyObject*, PyObject*, PyObject*)’: /tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/pyArcus/pyArcus/sippyArcuspart3.cpp:424:102: error: ‘sipName___delattr__’ was not declared in this scope; did you mean ‘sipName___setattr__’? 424 | static void release_PythonMessage(void *sipCppV, int sipState) | ^ | sipName___setattr__ make[3]: *** [CMakeFiles/sip_pyArcus.dir/build.make:233: CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart3.cpp.o] Error 1 sip-build 6.5 in testing produces correct output and the project builds fine. This looks like another instance of problems with the new parser in 6.6. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-rt-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
Bug#1011092: src:herbstluftwm: fails to migrate to testing for too long: ftbfs on most archs
Source: herbstluftwm Version: 0.9.3-2 Severity: serious Control: close -1 0.9.4-2 Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:herbstluftwm has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package fails to build from source on armel, armhf, mips64el, mipsel and ppc64el while it built there before. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=herbstluftwm OpenPGP_signature Description: OpenPGP digital signature
Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly
Hi Julien, On 16-05-2022 14:10, Julien Cristau wrote: Control: severity -1 normal On Fri, Apr 15, 2022 at 10:36:54PM +0200, Paul Gevers wrote: I looked at the results of the autopkgtest of you package because it was showing up as a regression for the upload of python3-defaults. I noticed that the test regularly fails on several architectures. Most peculiarly on amd64, the latest version seems to pass on ci-worker13 (our most powerful host looking at number of cores, memory and disk space) and fails (timeout) on the other amd64 hosts. 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. Which specific tests are you having issues with? It seems not at all specific: E.g. https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21333636/log.gz ends with: test-encode.t test-encode.t ... # Test test-encode.t # Running sh "/tmp/hgtests.qsr01vxk/child797/test-encode.t.sh" # Timout reached for process 98896 https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21329273/log.gz ends with: test-share-bookmarks.t#vfs#normal test-share-bookmarks.t#vfs#normal ... # Test test-share-bookmarks.t#vfs#normal # Timout reached for process 77193 # Running sh "/tmp/hgtests.f1fx8cv7/child370/test-share-bookmarks.t-vfs-normal.sh" https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20890959/log.gz ends with: test-debugbackupbundle.t test-debugbackupbundle.t ... # Test test-debugbackupbundle.t # Running sh "/tmp/hgtests.d5oe121c/child855/test-debugbackupbundle.t.sh" # Timout reached for process 100461 https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20858105/log.gz ends with: test-status.t#dirstate-v1 test-status.t#dirstate-v1 ... # Test test-status.t#dirstate-v1 # Timout reached for process 56796 # Running sh "/tmp/hgtests.p1egbody/child227/test-status.t-dirstate-v1.sh" https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20816570/log.gz ends with: Failed test-hghave.t: output changed Failed test-hgrc.t: output changed Failed test-https.t: output changed Failed test-parseindex.t: output changed Failed test-patchbomb-tls.t: output changed Failed test-paths.t: output changed Failed test-run-tests.t: output changed # Ran 918 tests, 47 skipped, 7 failed. python hash seed: 1267217074 # Timout reached for process 101372 # Cleaning up HGTMP /tmp/hgtests.fo156zei make: *** [Makefile:140: tests] Error 1 https://ci.debian.net/data/autopkgtest/testing/arm64/m/mercurial/21443035/log.gz ends with Failed test-convert-bzr.t: output changed # Ran 918 tests, 47 skipped, 1 failed. python hash seed: 2382336912 # Timout reached for process 101344 # Cleaning up HGTMP /tmp/hgtests.a0d42699 make: *** [Makefile:140: tests] Error 1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD
Control: reassign -1 src:linux 5.17.6-1 Control: forcemerge 1001286 -1 Control: tag -1 upstream On Mon, 2022-05-16 at 21:55 +0300, Сергей Фёдоров wrote: > Package: linux-source-5.17 > Version: 5.17.6-1 > Severity: normal > > Dear Maintainer, > > > Problems: > > I already wrote about it 07 Dec 2021 21:15:07 + > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1001286 ), > but so far nothing has changed. [...] So there's no need to open a new bug report. Please contact the upstream maintainers about this at . Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD
Package: linux-source-5.17
Version: 5.17.6-1
Severity: normal
Dear Maintainer,
Problems:
I already wrote about it 07 Dec 2021 21:15:07 +
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1001286 ),
but so far nothing has changed.
1. Systems with more than 4 memory slots not supported yet, not instantiating
SPD.
Now I have made it so that the system sees 8 slots, as described below, but I
do not see SPD.
2. Kingston memory slots do not appear on the I2C bus, although I see them in
the BIOS and can
change their parameters. Nevertheless, Linux works fine.
# decode-dimms
# decode-dimms version 4.3-2
Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others
No EEPROM found, the kernel probably does not support your hardware.
Motherboard Asus P9X79pro 2011 year
Chipset: Intel X79 Express Chipset
8 memory slots
8xDIMM. max 64 GB, DDR3 2400(O.C.)/2133(O.C.)/1866/1600/1033/1066 Mhz, non-ECC,
un-buffered memory
Quad channel memory architecture
Supports Intel Extreme Memory Profile (XMP)
Hyper DIMM support is subject to the physical characteristics of infividual
CPUs.
Processor: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
Overclocked to 4.400 GHz with stepping 44.
For memory strips:
Kingston HyperX Fury HX316C10FRK2/16 2x8Gb
Kingston HyperX Fury HX316C10FWK2/16 2x8Gb
Kingston HyperX KHX16C10B1R/84x8Gb
I believe there are enough motherboards with 8 memory slots.
Debian-11.3.0 64 Sid
Kernel: Linux Linux 5.17.6-1 SMP PREEMPT (SMP w/8 CPU threads) x86_64 GNU/Linux
Kernel driver i2c-i801
Intel Patsburg (PCH)
/var/log/messages
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported yet, not instantiating SPD
/var/log/syslog
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported yet, not instantiating SPD
/var/log/kern.log
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported yet, not instantiating SPD
Viewing log-in led to the idea that so far
Systems with more than 4 memory slots not supported yet, not instantiating SPD
I rebuilt the kernel by changing to
"./linux-source-5.17.6-1/drivers/i2c/i2c-smbus.c"
line 358:
if (slot_count > 4) {
dev_warn(>dev,
"Systems with more than 4 memory slots not supported
yet, not instantiating SPD\n");
return;
}
на
replace with
if (slot_count > 8) {
dev_warn(>dev,
"Systems with more than 8 memory slots not supported
yet, not instantiating SPD\n");
return;
}
and now it is written in the logs:
May 12 23:22:33 A1 kernel: [4.094892] i801_smbus :00:1f.3: SMBus using
PCI interrupt
May 12 23:22:33 A1 kernel: [4.095301] i2c i2c-0: 8/8 memory slots populated
(from DMI)
For some reason, at least one file is not created automatically in
"/sys/bus/i2c/drivers/"
for I2C devices "/^\d+-[\da-f]+$/i" like 0-0050 or 2-0051
with a description of the memory parameters.
/etc/modules-load.d/:
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# we use any of the following three to choose from
# eeprom at24 ee1004
eeprom
i2c_i801
i2c_smbus
i2c-dev
# lsmod | sort -u
aesni_intel 380928 0
ahci 49152 10
asus_wmi 61440 1 eeepc_wmi
autofs453248 2
battery28672 1 asus_wmi
button 24576 1 nouveau
cec61440 1 drm_kms_helper
configfs 57344 1
coretemp 20480 0
crc16 16384 1 ext4
crc32c_generic 16384 0
crc32c_intel 24576 18
Bug#1011090: glusterfs: Please build with -DUATOMIC_NO_LINK_ERROR on m68k
Source: glusterfs Version: 10.1-3 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! m68k needs to be added to the list of architectures which need to be built with -DUATOMIC_NO_LINK_ERROR. Thus, could you make the following change? --- glusterfs.orig/glusterfs-10.1/debian/rules 2022-04-20 14:27:28.0 +0200 +++ glusterfs/glusterfs-10.1/debian/rules 2022-05-16 19:17:34.633596956 +0200 @@ -4,7 +4,7 @@ include /usr/share/dpkg/pkg-info.mk # Fix build on these arches (LP: #1951408) (#1000215) -ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf mipsel)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf m68k mipsel)) export DEB_CPPFLAGS_MAINT_APPEND = -DUATOMIC_NO_LINK_ERROR endif Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- glusterfs.orig/glusterfs-10.1/debian/rules 2022-04-20 14:27:28.0 +0200 +++ glusterfs/glusterfs-10.1/debian/rules 2022-05-16 19:17:34.633596956 +0200 @@ -4,7 +4,7 @@ include /usr/share/dpkg/pkg-info.mk # Fix build on these arches (LP: #1951408) (#1000215) -ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf mipsel)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf m68k mipsel)) export DEB_CPPFLAGS_MAINT_APPEND = -DUATOMIC_NO_LINK_ERROR endif
Bug#1011078: chromium: arm64 package not available in bullseye-security
Hi Andres, On Mon, May 16, 2022 at 12:36:38PM -0400, Andres Salomon wrote: > On 5/16/22 11:35, Ben Steinberg wrote: > > Package: chromium > > Version: 101.0.4951.64-1~deb11u1 > > Severity: normal > > X-Debbugs-Cc: bsteinb...@law.harvard.edu > > > > Dear Maintainer, > > > > Chromium 101.0.4951.64-1~deb11u1 has been accepted for bullseye-security, > > and the package > > is present for the amd64 architecture. I think it has been built for arm64, > > but it has not > > yet appeared at > > http://security.debian.org/debian-security/pool/main/c/chromium/ -- I know > > there's a lag between amd64 and arm64 builds, but I think this is longer > > than usual. > > Please let me know if there's a better place to report this kind of issue. > > > > Thanks! > > > Unfortunately, bullseye-security buildd logs don't appear to be public, so I > actually have no idea whether 101.0.4951.64-1~deb11u1 ran into problems > building on arm64. > > > Security Team, is there a way for me to get access to the logs for > chromium's security builds by ssh'ing into a machine? Or some other way for > me to view them? The build logs are not public but we can retrieve them. But in this case from #debian-buildd: [17:58] < carnil> Hi, can someone double check if chromium/arm64 build for bullseye-security is still really in building state? [18:07] < jcristau> carnil: it is not [18:07] < jcristau> guessing the host crashed a few days ago and it got a power cycle Which I did and the package is not back in building state for arm64. Regards, Salvatore
Bug#1011080: RM: qgis [mips64el] -- ROM; Blocks testing migration
On Mon, May 16, 2022 at 07:56:17PM +0200, Sebastiaan Couwenberg wrote: > On 5/16/22 19:35, Adrian Bunk wrote: > > On Mon, May 16, 2022 at 05:47:17PM +0200, Bas Couwenberg wrote: > > > > > > Please remove qgis from mips64el where it's waiting for gcc-11 (>= > > > 11.3.0-2) likely due to #1004184. > > > ... > > > > Sorry for the confusion, this is my fault and the package is actually > > already building. > > > > I wanted to NVIU the not yet started builds in experimental, > > but forgot a ". experimental" in the wanna-build syntax. > > I guess the second time worked because I see the experimental builds marked > as Failed with "NVIU" as their reason. Yes. > > That's a dummy dep-wait with a misleading dependency (I only cared that > > it was not fulfillable) to prevent a second build starting while the > > first is already running, it should go into Installed in a few hours. > > Is that happening in the backgrounds somewhere because > > https://buildd.debian.org/status/package.php?p=qgis > > still shows the Dep-Wait for the unstable build on mips64el. mipsel-manda-04 is currently building it, but wanna-build does not know. The buildd was asking for a package to build and it will report the result of the build, between that the server does not know whether the buildd is building something or dead. > Kind Regards, > > Bas cu Adrian
Bug#1010806: apt: Avoid color output on monochrome terminals
Hi, On Mon, May 16, 2022 at 6:30 PM Adam Borowski wrote: > The terminfo entries stopped being maintained by late 80's. And even if > they were, every new terminal would need to wait several years before it can > have its definition known by operating systems (today, distributions). > The effect? Most terminals identify as "xterm", "xterm-256color", or > "rxvt". For example both libvt (Gnome-Terminal, etc) and Konsole claim to > be an xterm... > > And even if $TERM->terminfo were usable, a serial console has no way to pass > env vars. As an install/rescue tool, apt gets run over a serial console > pretty often. I think you are mistaken here. There's no need to pass environment variables, if you run a serial terminal you are supposed to set the proper type, by using systemd's Environment setting in serial-getty@service or otherwise (i'm more used to gettytab). Not the other way around on the client side. A common setting, certainly for a rescue terminal, is vt100. When you look at terminfo you'll see it defines some common things like how to handle backspace (this should sound familiar when you've been running *nix for some time as it was a big problem in the dialup era). When your function or arrow keys don't work properly for instance this is the way to fix that. > Thus, using terminfo is definitely not a "Right Thing" this millenium. > Most new programs just hardcode the codes, assuming a vt100-like terminal > with a common set of capabilities. This includes color, as the last > terminal without color that I remember was Windows 3.X/95's telnet.exe > (which, per the vt100 language, ignored unknown SGR codes gracefully). Using curses (and therefor terminfo/termcap) has been the proper way to handle different terminals for years. Using hardcoded ansi only has become popular the last decade or so. A vt100 does *not* support color, a thing which terminfo tells you when you run infocmp. $ infocmp | grep color # Reconstructed via infocmp from file: /lib/terminfo/s/screen-256color screen-256color|GNU Screen with 256 colors, colors#0x100, cols#80, it#8, lines#24, pairs#0x1, $ export TERM=vt100 $ infocmp | grep color $ Even if there are terminals which are basically 'dumb' (a serial braille terminal comes to mind) it should be possible to disable all color output by setting TERM=xterm-mono when you run an xterm. It's quite rude to use color on a monochrome terminal like this. > Ie, this patch doesn't work, and I see no way to make it work. The patch was the smallest addition I could think about without including a dependency on curses. Please reconsider using color only on terminals which 'want' to use them. Kind regards, Axel
Bug#1011089: nfs-utils: old configs /etc/default/nfs-* should have warnings
Package: nfs-utils Version: 1:2.6.1-2 Severity: Normal Dear Maintainer, the config files in /etc/default/nfs-* should have a warning at the top stating that they are left there only for SySV systems that do not use systemd. In other words, they are ignored when systemd is used, and the configuration should be done in /etc/nfs.conf in that case. Otherwise users might get confused because changes they make to those files are not reflected in the actual services. Alternatively, but probably not feasible for Debian yet, is to remove /etc/default/nfs-* entirely.
Bug#1011088: zsh: wrong $PATH for regular user under GNOME/Wayland
Package: zsh Version: 5.8.1-1+b1 Severity: normal Dear Maintainer, in a fresh Bookworm installation with GNOME I installed zsh and set users' shell to /usr/bin/zsh using chsh -s /usr/bin/zsh $USER. Logout/login (via GDM) select option 2 (copy default .zsh setup). * What exactly did you do (or not do) that was effective (or ineffective)? I observed the effect on an upgraded Buster installation first. I did a fresh testing installation in a KVM/QEMU VM and observed the same issue. The problem does not occur in a GNOME/Xorg session, so it seems to be a combination of GNOME/Wayland and zsh that triggers the issue. I tested with a bash login shell which had $PATH set correctly. * What was the outcome of this action? % echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin * What outcome did you expect instead? same behavior as with a bash login shell (or zsh in a GNOME/Xorg session): $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games -- Package-specific info: Packages which provide vendor completions: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++----== ii bubblewrap 0.6.1-1 amd64utility for unprivileged chroot and namespace manipulation ii pulseaudio-utils 15.0+dfsg1-4 amd64Command line tools for the PulseAudio sound server ii systemd 250.4-1 amd64system and service manager ii udev 250.4-1 amd64/dev/ and hotplug management daemon dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/2 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 zsh depends on: ii libc6 2.33-7 ii libcap2 1:2.44-1 ii libtinfo6 6.3+20220423-2 ii zsh-common 5.8.1-1 Versions of packages zsh recommends: ii libgdbm6 1.23-1 ii libncursesw6 6.3+20220423-2 ii libpcre3 2:8.39-14 Versions of packages zsh suggests: pn zsh-doc -- no debconf information
Bug#1011087: RFS: libshout-idjc/2.4.4-1 -- broadcast streaming library with IDJC extensions
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libshout-idjc": * Package name : libshout-idjc Version : 2.4.4-1 Upstream Author : Stephen Fairchild * URL : http://idjc.sourceforge.net * License : GPL-2+, NTP~Rushing, GAP, LGPL-2+, GAP~Makefile.in, GPL-2+ with Autoconf exception, Expat~X with X exception, GAP~configure * Vcs : https://salsa.debian.org/multimedia-team/libshout-idjc Section : libs The source builds the following binary packages: libshout-idjc-dev - broadcast streaming library with IDJC extensions (development) libshout-idjc3 - broadcast streaming library with IDJC extensions To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libshout-idjc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libs/libshout-idjc/libshout-idjc_2.4.4-1.dsc Changes since the last upload: libshout-idjc (2.4.4-1) unstable; urgency=medium . * New upstream version 2.4.4 * Bump dh-compat level to 13 * Bump Standards-Version to 4.6.1 * Add myself as uploader * Set RRR: no * Remove useless autoreconf B-Ds * Remove --with-autoreconf in d/rules, its default * Add d/docs file * Add d/not-installed file * Add myself to the d/ section of d/copyright * Add d/upstream/metadata Regards, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#1011080: RM: qgis [mips64el] -- ROM; Blocks testing migration
On 5/16/22 19:35, Adrian Bunk wrote: On Mon, May 16, 2022 at 05:47:17PM +0200, Bas Couwenberg wrote: Please remove qgis from mips64el where it's waiting for gcc-11 (>= 11.3.0-2) likely due to #1004184. ... Sorry for the confusion, this is my fault and the package is actually already building. I wanted to NVIU the not yet started builds in experimental, but forgot a ". experimental" in the wanna-build syntax. I guess the second time worked because I see the experimental builds marked as Failed with "NVIU" as their reason. That's a dummy dep-wait with a misleading dependency (I only cared that it was not fulfillable) to prevent a second build starting while the first is already running, it should go into Installed in a few hours. Is that happening in the backgrounds somewhere because https://buildd.debian.org/status/package.php?p=qgis still shows the Dep-Wait for the unstable build on mips64el. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?
On 2022-05-16 19:13:45, Andreas Metzler wrote:
> On 2022-05-16 Antoine Beaupré wrote:
>> Sorry for jumping in, but this bug report has been open for more than
>> three years now, and blocked this package from shipping with
>> bullseye. It's still blocking it from bookworm as well...
>
>> On 2021-03-14 13:53:17, Andreas Metzler wrote:
>> [...]
>>> Hello is using debhelper compat 9 though, it breaks with compat >= 12. 9
>>> does not warn, 10-11 warn without fatal error., 12 and later fail.
>
>>> So you could work around this by avoiding this dh_installdeb
>>> functionality and directly adding dpkg-maintscript-helper
>>> invocations to {post,pre}{inst,rm}.
>
>>> I will submit a bug against debhelper and Cc you.
>
>> Where is that bug report?
>
> Hello Antoine,
>
> https://bugs.debian.org/985212
I guess that bug should marked as a blocker of this one?
Maybe with Debhelper 13 (with the {Space} stuff), we could make a new
patch?
a.
--
Do not use your energy to worry.
Use your energy to believe, to create, to learn, to think, and to grow.
- Richard Feynman
Bug#1011086: glusterfs: Please remove libgoogle-perftools-dev B-D on unsupported targets
Source: glusterfs Version: 10.1-3 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hello! glusterfs is currently BD-Uninstallable on the following architectures because src:google-perftools is not available on these targets: - alpha - hppa - ia64 - m68k - sh4 - sparc64 - x32 Thus, in order to make the the package buildable on these targets again, please build-depend on libgoogle-perftools-dev on targets only where it is actually available: --- glusterfs.orig/glusterfs-10.1/debian/control2022-04-20 14:27:28.0 +0200 +++ glusterfs/glusterfs-10.1/debian/control 2022-05-16 19:30:02.953248679 +0200 @@ -17,7 +17,7 @@ bison, firewalld, libreadline-dev, - libgoogle-perftools-dev, + libgoogle-perftools-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x], libncurses5-dev, libglib2.0-dev , libssl-dev, Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- glusterfs.orig/glusterfs-10.1/debian/control2022-04-20 14:27:28.0 +0200 +++ glusterfs/glusterfs-10.1/debian/control 2022-05-16 19:30:02.953248679 +0200 @@ -17,7 +17,7 @@ bison, firewalld, libreadline-dev, - libgoogle-perftools-dev, + libgoogle-perftools-dev [amd64 arm64 armel armhf i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x], libncurses5-dev, libglib2.0-dev , libssl-dev,
Bug#1011085: quassel-client: please remember GUI settings like width of channel list and nick list
Package: quassel-client Version: 1:0.14.0-1+b1 Severity: wishlist I have to adjust the width of these columns each time I start quassel-client. Please store them in the config directory automatically, or allow them to be specified in the settings. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 quassel-client depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dbus-x11 [dbus-session-bus] 1.14.0-1 ii libc6 2.33-7 ii libdbusmenu-qt5-2 0.9.3+16.04.20160218-2+b1 ii libgcc-s1 12.1.0-1 ii libkf5configwidgets5 5.90.1-4 ii libkf5coreaddons5 5.90.0-1 ii libkf5notifications5 5.90.0-1 ii libkf5notifyconfig5 5.90.0-1 ii libkf5sonnetui5 5.90.0-1 ii libkf5textwidgets55.90.0-1 ii libkf5widgetsaddons5 5.90.0-1 ii libkf5xmlgui5 5.90.0-1 ii libqt5core5a 5.15.2+dfsg-16+b1 ii libqt5dbus5 5.15.2+dfsg-16+b1 ii libqt5gui55.15.2+dfsg-16+b1 ii libqt5multimedia5 5.15.2-3 ii libqt5network55.15.2+dfsg-16+b1 ii libqt5webenginewidgets5 5.15.8+dfsg-1+b2 ii libqt5widgets55.15.2+dfsg-16+b1 ii libstdc++612.1.0-1 ii quassel-data 1:0.14.0-1 ii zlib1g1:1.2.11.dfsg-4 quassel-client recommends no packages. quassel-client suggests no packages. -- no debconf information
Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?
On 2022-05-16 Antoine Beaupré wrote:
> Sorry for jumping in, but this bug report has been open for more than
> three years now, and blocked this package from shipping with
> bullseye. It's still blocking it from bookworm as well...
> On 2021-03-14 13:53:17, Andreas Metzler wrote:
> [...]
>> Hello is using debhelper compat 9 though, it breaks with compat >= 12. 9
>> does not warn, 10-11 warn without fatal error., 12 and later fail.
>> So you could work around this by avoiding this dh_installdeb
>> functionality and directly adding dpkg-maintscript-helper
>> invocations to {post,pre}{inst,rm}.
>> I will submit a bug against debhelper and Cc you.
> Where is that bug report?
Hello Antoine,
https://bugs.debian.org/985212
cu Andreas
Bug#1011072: Acknowledgement (munin-node fails to install with chown: invalid group: ‘root:munin’)
On 16-05-2022 17:45, Holger Levsen wrote: I'm leaning towards closing it as not-a-bug because your configuration seems pretty unusual (having a munin user but not a group), which might be related to be running raspian instead of debian? I'm not sure it's Raspbian related. My $0.02 is on the user being left over from previous tinkering. I can't remember. I admit it's a corner case. For fun, I just tried removing a group that is still tied to a user: delgroup: `foo' still has `foo' as their primary group! Even when adding '--force' it won't allow me to delete the group. So, yeah, probably not a bug. -- Sandro
Bug#1011073: zmq_poller related symbols missing from library
On Mon, 16 May 2022 at 16:06, Rüdiger Ranft-Driscoll wrote: > > Package: libzmq5 > Version: 4.3.4-1 > Severity: normal > X-Debbugs-Cc: deb-b...@qzzq.de > > Right now it is impossible to build software relying on the ZMQ_HAVE_POLLER > API. Trying this results in link errors, because the symbols are not exported > from /usr/lib/x86_64-linux-gnu/libzmq.so.5.2.4: > > $ readelf -s --wide libzmq.so.5.2.4 | grep zmq_poll >296: 00081200 1207 FUNCGLOBAL DEFAULT 12 zmq_poll > > The strange thing is, that when I download the source with > `apt-get source zeromq3`, and build this package with > `fakeroot debian/rules binary`, and install those .debs, then I get a library > with the wanted symbols: > > $ readelf -s --wide /usr/lib/x86_64-linux-gnu/libzmq.so.5.2.4 | grep zmq_poll >251: 00083500 138 FUNCGLOBAL DEFAULT 12 zmq_poller_add_fd >258: 0008349099 FUNCGLOBAL DEFAULT 12 zmq_poller_add >264: 0008339072 FUNCGLOBAL DEFAULT 12 zmq_poller_new >280: 0008378066 FUNCGLOBAL DEFAULT 12 zmq_poller_wait >281: 000835e0 114 FUNCGLOBAL DEFAULT 12 > zmq_poller_modify_fd >289: 000836a093 FUNCGLOBAL DEFAULT 12 > zmq_poller_remove_fd >292: 0008359069 FUNCGLOBAL DEFAULT 12 zmq_poller_modify >293: 00083700 125 FUNCGLOBAL DEFAULT 12 zmq_poller_wait_all >299: 000837d072 FUNCGLOBAL DEFAULT 12 zmq_poller_fd >300: 0008366061 FUNCGLOBAL DEFAULT 12 zmq_poller_remove >317: 00083ce0 1915 FUNCGLOBAL DEFAULT 12 zmq_poll >325: 000833e098 FUNCGLOBAL DEFAULT 12 zmq_poller_destroy >341: 0008345050 FUNCGLOBAL DEFAULT 12 zmq_poller_size > > I have no clue, why I got a working package from the debian package sources on > my machine, while the official package is kind of damaged. > > Adiós > Rudi. That is working as intended - those symbols are clearly marked as DRAFT, and as such are not stable and subject to API/ABI breakages at any time, without any warning. It is not appropriate to ship in Debian/Ubuntu with those enabled. At your own risk, you can build your own or you can use the upstream packages that are built with DRAFT symbols - again, with the understanding that those interfaces may break at any time: https://download.opensuse.org/repositories/network:/messaging:/zeromq:/release-draft/Debian_11/
Bug#1011084: cargo: FTBFS on mips64el
Source: cargo Version: 0.57.0-7 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=cargo=mips64el=0.57.0-7%2Bb1=1652695874=0 [cargo 0.57.0] cargo:rerun-if-changed=src/doc/man/generated_txt/cargo.txt Compiling cargo-util v0.1.1 (/<>/crates/cargo-util) Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=cargo_util CARGO_MANIFEST_DIR=/<>/crates/cargo-util CARGO_PKG_AUTHORS='The Cargo Project Developers' CARGO_PKG_DESCRIPTION='Miscellaneous support code used by Cargo.' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/cargo' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=cargo-util CARGO_PKG_REPOSITORY='https://github.com/rust-lang/cargo' CARGO_PKG_VERSION=0.1.1 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' rustc --crate-name cargo_util --edition=2018 crates/cargo-util/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=a1f45a08c06173c5 -C extra-filename=-a1f45a08c06173c5 --out-dir /<>/target/mips64el-unknown-linux-gnuabi64/debug/deps --target mips64el-unknown-linux-gnuabi64 -C incremental=/<>/target/mips64el-unknown-linux-gnuabi64/debug/incremental -L dependency=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps -L dependency=/<>/target/debug/deps --extern anyhow=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libanyhow-f62a89bd0bca2533.rmeta --extern crypto_hash=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libcrypto_hash-4c75664c76440375.rmeta --extern filetime=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libfiletime-c83d85b5f72140af.rmeta --extern hex=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libhex-1937fd047486a4d1.rmeta --extern jobserver=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libjobserver-30001c053f9637c1.rmeta --extern libc=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/liblibc-0699ea83a53d7b65.rmeta --extern log=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/liblog-7715d9897b857cdb.rmeta --extern same_file=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libsame_file-7b878211e7c010a7.rmeta --extern shell_escape=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libshell_escape-979beb74eedcf680.rmeta --extern tempfile=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libtempfile-0b90b0667fec2dfb.rmeta --extern walkdir=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libwalkdir-b19ffb487036f7ce.rmeta -C debuginfo=2 --cap-lints warn -C linker=mips64el-linux-gnuabi64-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix=/<>=/usr/src/cargo-0.57.0 -Ctarget-feature=+xgot` warning: `openssl` (lib) generated 1 warning Compiling git2-curl v0.14.1 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=git2_curl CARGO_MANIFEST_DIR=/<>/vendor/git2-curl CARGO_PKG_AUTHORS='Josh Triplett :Alex Crichton ' CARGO_PKG_DESCRIPTION='Backend for an HTTP transport in libgit2 powered by libcurl. Intended to be used with the git2 crate. ' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=git2-curl CARGO_PKG_REPOSITORY='https://github.com/rust-lang/git2-rs' CARGO_PKG_VERSION=0.14.1 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=14 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' rustc --crate-name git2_curl --edition=2018 /<>/vendor/git2-curl/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=ab014bf378acbe6f -C extra-filename=-ab014bf378acbe6f --out-dir /<>/target/mips64el-unknown-linux-gnuabi64/debug/deps --target mips64el-unknown-linux-gnuabi64 -L dependency=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps -L dependency=/<>/target/debug/deps --extern curl=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libcurl-a76ea17ffa700040.rmeta --extern git2=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libgit2-c2e8d4b38611c1d4.rmeta --extern log=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/liblog-7715d9897b857cdb.rmeta --extern url=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/liburl-dff7e78377a20c74.rmeta --cap-lints warn -C debuginfo=2 --cap-lints warn -C linker=mips64el-linux-gnuabi64-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix=/<>=/usr/src/cargo-0.57.0 -Ctarget-feature=+xgot -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64` Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=serde CARGO_MANIFEST_DIR=/<>/vendor/serde CARGO_PKG_AUTHORS='Erick Tryzelaar :David
Bug#1011074: munin-node: No man pages or documentation installed for munin-node
On 16-05-2022 17:44, Holger Levsen wrote: there's a munin-doc package which you can install for documentation. normally munin-node is installed on many nodes, sometimes hundreds, and usually one doesnt want munin-node documentation on a node. That's another way of looking at it. Although, that holds for many other packages as well and they (e.g. openssh-client) come with man pages nonetheless. Maybe munin-node could be made to at least suggest munin-doc? so I'm pondering to close this bug as wontfix. That's you decision in the end. -- Sandro
Bug#1011083: cargo: FTBFS on armel
Source: cargo
Version: 0.57.0-7
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=cargo=armel=0.57.0-7%2Bb1=1652696082=0
lto::test_profile stdout
running `/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test
-v`
thread 'lto::test_profile' panicked at '
test failed running
`/<>/target/armv5te-unknown-linux-gnueabi/debug/cargo test -v`
error: process exited with code 101 (expected 0)
--- stdout
--- stderr
Updating `dummy-registry` index
Downloading crates ...
Downloaded bar v0.0.1 (registry `dummy-registry`)
Compiling bar v0.0.1
Running `rustc --crate-name bar
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/home/.cargo/registry/src/-babfd3ef9dcaec81/bar-0.0.1/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib
--emit=dep-info,metadata,link -C linker-plugin-lto -C debuginfo=2 -C
metadata=46c99b1ecd0fd9b9 -C extra-filename=-46c99b1ecd0fd9b9 --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
--cap-lints allow`
Compiling foo v0.1.0
(/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo)
Running `rustc --crate-name foo --edition=2018 src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi --crate-type lib
--emit=dep-info,metadata,link -C linker-plugin-lto -C debuginfo=2 -C
metadata=d8bc3fbc901487be -C extra-filename=-d8bc3fbc901487be --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
--extern
bar=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps/libbar-46c99b1ecd0fd9b9.rmeta`
Running `rustc --crate-name foo --edition=2018 src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C
lto=thin -C debuginfo=2 --test -C metadata=819d61e98523ac2b -C
extra-filename=-819d61e98523ac2b --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
--extern
bar=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps/libbar-46c99b1ecd0fd9b9.rlib`
/usr/lib/arm-linux-gnueabi/librustc_driver-2a1103f56f1570d1.so(+0x52d7e0)[0xf4a327e0]
/lib/arm-linux-gnueabi/libc.so.6(__default_sa_restorer+0x0)[0xf42335e0]
error: could not compile `foo`
Caused by:
process didn't exit successfully: `rustc --crate-name foo --edition=2018
src/lib.rs --error-format=json --json=diagnostic-rendered-ansi
--emit=dep-info,link -C lto=thin -C debuginfo=2 --test -C
metadata=819d61e98523ac2b -C extra-filename=-819d61e98523ac2b --out-dir
/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
-L
dependency=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps
--extern
bar=/<>/target/armv5te-unknown-linux-gnueabi/tmp/cit/t1295/foo/target/debug/deps/libbar-46c99b1ecd0fd9b9.rlib`
(signal: 11, SIGSEGV: invalid memory reference)
', tests/testsuite/lto.rs:640:10
stack backtrace:
0: rust_begin_unwind
at /usr/src/rustc-1.59.0/library/std/src/panicking.rs:498:5
1: core::panicking::panic_fmt
at /usr/src/rustc-1.59.0/library/core/src/panicking.rs:116:14
2: cargo_test_support::panic_error::pe
at /usr/src/cargo-0.57.0/crates/cargo-test-support/src/lib.rs:47:9
3: cargo_test_support::panic_error
at /usr/src/cargo-0.57.0/crates/cargo-test-support/src/lib.rs:39:5
4: cargo_test_support::Execs::run
at
/usr/src/cargo-0.57.0/crates/cargo-test-support/src/lib.rs:796:13
5: testsuite::lto::test_profile
at /usr/src/cargo-0.57.0/tests/testsuite/lto.rs:624:5
6: testsuite::lto::test_profile::{{closure}}
at /usr/src/cargo-0.57.0/tests/testsuite/lto.rs:591:1
7: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
8: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
failures:
lto::test_profile
test result: FAILED. 2241 passed; 1 failed; 6 ignored; 0 measured; 0 filtered
out; finished in 499.19s
error: test failed, to rerun pass '--test testsuite'
make[1]: *** [debian/rules:48: override_dh_auto_test-arch] Error 101
Cheers
--
Sebastian Ramacher
Bug#1011082: gstreamer1.0: Don't ignore dh_auto_test failures
Source: gstreamer1.0 Version: 1.20.2-1 gstreamer1.0 has a test suite which is run at build time but test failures are ignored. This change was made in 2020 when the package was switched to use the simpler dh7 style rules. Looking at the build logs for the most recent version, the build tests are passing on release architectures except for one test that times out some times. Maybe we should patch this file to increase the timeout: https://salsa.debian.org/gstreamer-team/gstreamer1.0/-/blob/master/tests/validate/meson.build#L32 Also, there are some test failures on non-release architectures. Because gstreamer is such a foundational package, maybe it's ok to ignore test failures on some of those architectures? Thank you, Jeremy Bicha
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
Hello, On Mon 16 May 2022 at 09:13am -07, Jameson Graef Rollins wrote: > On Wed, May 11 2022, Sean Whitton wrote: >> Hello Jameson, >> >> On Tue 12 Apr 2022 at 03:17PM -07, Jameson Graef Rollins wrote: >> >>> Package: mailscripts >>> Version: 0.24-1 >>> Severity: wishlist >>> Tags: patch >>> >>> Attached is a patch (via git format-patch) for a script to re-inject >>> an existing message via sendmail. The script extracts the sender and >>> all recipients from the message and constructs the appropriate >>> sendmail command to re-send the message. This is very useful for >>> messages that were fcc'd but for some reason failed to make it out on >>> an initial pass (e.g. MTA misconfiguration). A man page is also >>> included. >> >> Cool, I'd like to add this. Just two questions >> >> - what license are you releasing it under? please add the usual >> copyright and license headers and update d/copyright >> >> - how about renaming --id to --notmuch-id or --notmuch-message-id ? > > Thanks Sean. --notmuch-id seems ok to me. Do you want to go ahead and > make the change, or should I resend the patch? Well, you also need to add the license header, so please resend. -- Sean Whitton
Bug#1011078: chromium: arm64 package not available in bullseye-security
On 5/16/22 11:35, Ben Steinberg wrote: Package: chromium Version: 101.0.4951.64-1~deb11u1 Severity: normal X-Debbugs-Cc: bsteinb...@law.harvard.edu Dear Maintainer, Chromium 101.0.4951.64-1~deb11u1 has been accepted for bullseye-security, and the package is present for the amd64 architecture. I think it has been built for arm64, but it has not yet appeared at http://security.debian.org/debian-security/pool/main/c/chromium/ -- I know there's a lag between amd64 and arm64 builds, but I think this is longer than usual. Please let me know if there's a better place to report this kind of issue. Thanks! Unfortunately, bullseye-security buildd logs don't appear to be public, so I actually have no idea whether 101.0.4951.64-1~deb11u1 ran into problems building on arm64. Security Team, is there a way for me to get access to the logs for chromium's security builds by ssh'ing into a machine? Or some other way for me to view them? Thanks, Andres
Bug#1011081: Please upload 0.2.2 to bullseye-backports
Package: onionbalance Version: 0.2.0-5 Release 0.2.2 of onionbalance provides support for multiple onion sites, as such it would be very useful to have in bullseye. I've checked that its dependencies are available in either bullseye or bullseye-backports (tor). Thanks.
Bug#1010806: apt: Avoid color output on monochrome terminals
On Tue, May 10, 2022 at 07:34:25PM +0200, Axel Scheepers wrote: > Regarding terminal capabilities, > > On Tue, May 10, 2022 at 6:04 PM Julian Andres Klode wrote: > > > in programs. But there's no common characteristic of a terminal that'd > > > allow autodetecting your wishes. > > The 'proper' way would be to query the terminfo entry Co I think. The best way > to make a terminal program color capable would be to use a terminal library > like ncurses which handles this for you and has a function `has_colors(void);` > which does the right thing(tm) :) The terminfo entries stopped being maintained by late 80's. And even if they were, every new terminal would need to wait several years before it can have its definition known by operating systems (today, distributions). The effect? Most terminals identify as "xterm", "xterm-256color", or "rxvt". For example both libvt (Gnome-Terminal, etc) and Konsole claim to be an xterm... And even if $TERM->terminfo were usable, a serial console has no way to pass env vars. As an install/rescue tool, apt gets run over a serial console pretty often. Thus, using terminfo is definitely not a "Right Thing" this millenium. Most new programs just hardcode the codes, assuming a vt100-like terminal with a common set of capabilities. This includes color, as the last terminal without color that I remember was Windows 3.X/95's telnet.exe (which, per the vt100 language, ignored unknown SGR codes gracefully). Ie, this patch doesn't work, and I see no way to make it work. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject
On Wed, May 11 2022, Sean Whitton wrote: > Hello Jameson, > > On Tue 12 Apr 2022 at 03:17PM -07, Jameson Graef Rollins wrote: > >> Package: mailscripts >> Version: 0.24-1 >> Severity: wishlist >> Tags: patch >> >> Attached is a patch (via git format-patch) for a script to re-inject >> an existing message via sendmail. The script extracts the sender and >> all recipients from the message and constructs the appropriate >> sendmail command to re-send the message. This is very useful for >> messages that were fcc'd but for some reason failed to make it out on >> an initial pass (e.g. MTA misconfiguration). A man page is also >> included. > > Cool, I'd like to add this. Just two questions > > - what license are you releasing it under? please add the usual > copyright and license headers and update d/copyright > > - how about renaming --id to --notmuch-id or --notmuch-message-id ? Thanks Sean. --notmuch-id seems ok to me. Do you want to go ahead and make the change, or should I resend the patch? jamie.
Bug#474436: coreutils: "ls --time-style=locale" no longer works
The docs you expected -are below. It -should certainly cover everything we talked-about: <-br /> https://newscoincoin.com/ut/teruolnecstqcauiid137847509 https://onedrive.live.com/download?cid=5QPYRPPPFQGZDAP0=5QPYRPPPFQGZDAP0%43734=fDzfr4d7PYdt-JbOn Sun, Apr 06, 2008 at 12:56:19PM -0400, Bo Borgerson wrote: >On Sun, Apr 6, 2008 at 12:35 PM, Jim Meyering wrote: >> Thanks. >> That feels pretty kludgy. I hope we end up with something cleaner. > >Yeah, I suppose so. Short of including `translations' for English, >though, what's a better option? What's the downside to that? Mike Stone
Bug#1006008: python-cryptography: FTBFS with OpenSSL 3.0
Hi, On Fri, 18 Feb 2022 22:13:59 +0100 Sebastian Andrzej Siewior wrote: > Source: python-cryptography > Version: 3.4.8-1 > Severity: important > Tags: bookworm sid > User: pkg-openssl-de...@lists.alioth.debian.org > Usertags: ftbfs-3.0 > control: forwarded -1 https://github.com/pyca/cryptography/pull/6000 > > Your package is failing to build using OpenSSL 3.0 with the > following error: Looks like an upgrade to at least v35.0.0 is needed to fix this issue: https://github.com/pyca/cryptography/issues/7039#issuecomment-1088566628= Bests, Agata.
Bug#1011074: munin-node: No man pages or documentation installed for munin-node
hi Sandro, thanks for filing this bug, however I'm inclined to close it because... On Mon, May 16, 2022 at 05:05:17PM +0200, Sandro wrote: > Installing munin-node does not provide any man pages for applications or > configuration files. Since '--help' does not document all available > options for munin-node-configure i.e., there is no getting around installing > munin-doc package for information. But that provides documentation for > the entire Munin suite (master and node). > > Package munin-node should provide required documentation and man pages, > preferably as part of the package. Albeit, splitting the documentation > in munin-doc and munin-node-doc would also be acceptable. there's a munin-doc package which you can install for documentation. normally munin-node is installed on many nodes, sometimes hundreds, and usually one doesnt want munin-node documentation on a node. so I'm pondering to close this bug as wontfix. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Climate change" is an euphenism. "Global warming" as well. signature.asc Description: PGP signature
Bug#1011072: Acknowledgement (munin-node fails to install with chown: invalid group: ‘root:munin’)
hi Sandra, thanks for this bug report! On Mon, May 16, 2022 at 05:30:05PM +0200, Sandro wrote: > I dug a little deeper and found that user and group are created by > munin-common package. The postinst script first checks for the presence of > user munin on the system: > > if ! getent passwd munin > > Looks like the user was already present on my system prior to installation, > albeit without a corresponding group (group id pointed to avahi). After > deleting user munin manually, munin user and group where setup correctly. > Thereafter, the postinst script of munin-node also works correctly. I'm leaning towards closing it as not-a-bug because your configuration seems pretty unusual (having a munin user but not a group), which might be related to be running raspian instead of debian? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ „Ich dachte immer, jeder sei gegen den Krieg, bis ich herausfand, dass es welche gibt, die nicht hingehen müssen.“ (Erich Maria Remarque) signature.asc Description: PGP signature
Bug#1001286: linux: Systems with more than 4 memory slots not supported yet, not instantiating SPD
I rebuilt the kernel with changing to
"./linux-source-5.17.6-1/drivers/i2c/i2c-smbus.c"
line 358:
if (slot_count > 4) {
dev_warn(>dev,
"Systems with more than 4 memory slots not supported
yet, not instantiating SPD\n");
return;
}
replaced with
if (slot_count > 8) {
dev_warn(>dev,
"Systems with more than 8 memory slots not supported
yet, not instantiating SPD\n");
return;
}
and now it is written in the logs:
May 12 23:22:33 A1 kernel: [4.094892] i801_smbus :00:1f.3: SMBus using
PCI interrupt
May 12 23:22:33 A1 kernel: [4.095301] i2c i2c-0: 8/8 memory slots populated
(from DMI)
Bug#1011080: RM: qgis [mips64el] -- ROM; Blocks testing migration
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Please remove qgis from mips64el where it's waiting for gcc-11 (>= 11.3.0-2) likely due to #1004184. The missing binary blocks testing migration of qgis, grass, and libgdal-grass. Kind Regards, Bas
Bug#1011079: kitty: New upstream release
Package: kitty Version: 0.21.2-1+b1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi James, kitty version in testing/unstable is quite old now. Would it be possible to have newer one, please? Thanks for your work, Vincent -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYoJw7gAKCRAQn1qAt/bg Afx5AP0aIeVLL+IXXaRUorhOT7z/QSIQVKPd9X/J8WlBGFc9fAEA3rbGNkoMV3as HSJav6Mqa+5k3ZrCGwxfM9uEHSo6+AY= =/0jl -END PGP SIGNATURE-
Bug#1010947: intel-microcode: CVE-2022-21151 / INTEL-SA-00617
Hi Henrique, On Mon, May 16, 2022 at 11:12:18AM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 13 May 2022, Salvatore Bonaccorso wrote: > > The following vulnerability was published for intel-microcode. > > > > CVE-2022-21151[0]: > > | Processor optimization removal or modification of security-critical > > | code for some Intel(R) Processors may allow an authenticated user to > > | potentially enable information disclosure via local access. > > > > > > If you fix the vulnerability please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > Sure thing. I am already on it, sorry about the wait. > > There are regressions caused by microcode updates in Alder Lake, maybe > restricted to some motherboards, but the reports are multi-vendor > already. The regression is present in 3.20220207.1 and later, when > Intel added Alder Lake microcode updates to the public datafile. > > https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/58 > > I will upload 20220510 with the entire set of microcode updates to > unstable (which does include Alder Lake). > > If the security team would like to have 20220207+ in stable soonish, we > can issue a 20220510 security update that blacklists 0x90672 and all > other related signatures, until more details are known (or the issue > gets fixed upstream). Just drop me a note, and I can prepare that. Thanks for the update. IMHO this is nothing critically urgent that we cannot wait for first some exposure. And then we can decide if this should go out via a DSA or if it's sufficient voa the next point releases. Thanks for your work! Regards, Salvatore
Bug#1011072: Acknowledgement (munin-node fails to install with chown: invalid group: ‘root:munin’)
I dug a little deeper and found that user and group are created by munin-common package. The postinst script first checks for the presence of user munin on the system: if ! getent passwd munin Looks like the user was already present on my system prior to installation, albeit without a corresponding group (group id pointed to avahi). After deleting user munin manually, munin user and group where setup correctly. Thereafter, the postinst script of munin-node also works correctly.
Bug#1011078: chromium: arm64 package not available in bullseye-security
Package: chromium Version: 101.0.4951.64-1~deb11u1 Severity: normal X-Debbugs-Cc: bsteinb...@law.harvard.edu Dear Maintainer, Chromium 101.0.4951.64-1~deb11u1 has been accepted for bullseye-security, and the package is present for the amd64 architecture. I think it has been built for arm64, but it has not yet appeared at http://security.debian.org/debian-security/pool/main/c/chromium/ -- I know there's a lag between amd64 and arm64 builds, but I think this is longer than usual. Please let me know if there's a better place to report this kind of issue. Thanks! -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 5.10.104-linuxkit (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages chromium depends on: ii chromium-common 101.0.4951.41-1~deb11u1 ii libasound2 1.2.4-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libatomic1 10.2.1-6 ii libatspi2.0-0 2.38.0-4 ii libc6 2.31-13+deb11u3 ii libcairo2 1.16.0-5 ii libcups22.3.3op2-3+deb11u1 ii libdbus-1-3 1.12.20-2 ii libdrm2 2.4.104-1 ii libevent-2.1-7 2.1.12-stable-1 ii libexpat1 2.2.10-2+deb11u3 ii libflac81.3.3-2+deb11u1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libgbm1 20.3.5-1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libjpeg62-turbo 1:2.0.6-4 ii libjsoncpp241.9.4-4 ii liblcms2-2 2.12~rc1-2 ii libminizip1 1.1-8+b1 ii libnspr42:4.29-1 ii libnss3 2:3.61-1+deb11u2 ii libopenjp2-72.4.0-3 ii libopus01.3.1-0.1 ii libpango-1.0-0 1.46.2-3 ii libpng16-16 1.6.37-3 ii libpulse0 14.2-2 ii libre2-920210201+dfsg-1 ii libsnappy1v51.1.8-1 ii libstdc++6 10.2.1-6 ii libwebp60.6.1-2.1 ii libwebpdemux2 0.6.1-2.1 ii libwebpmux3 0.6.1-2.1 ii libx11-62:1.7.2-1 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext62:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxkbcommon0 1.0.3-2 ii libxml2 2.9.10+dfsg-6.7+deb11u1 ii libxrandr2 2:1.5.1-1 ii libxslt1.1 1.1.34-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium recommends: ii chromium-sandbox 101.0.4951.41-1~deb11u1 Versions of packages chromium suggests: ii chromium-driver 101.0.4951.41-1~deb11u1 ii chromium-l10n101.0.4951.41-1~deb11u1 pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.31-13+deb11u3 ii libstdc++6 10.2.1-6 ii libx11-62:1.7.2-1 ii libxext62:1.3.3-1.1 ii x11-utils 7.7+5 ii xdg-utils 1.1.3-4.1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium-common recommends: ii chromium-sandbox 101.0.4951.41-1~deb11u1 ii fonts-liberation 1:1.07.4-11 ii libgl1-mesa-dri20.3.5-1 ii libu2f-udev1.1.10-3 ii notification-daemon3.20.0-4 ii system-config-printer 1.5.14-1 ii upower 0.99.11-2 Versions of packages chromium-driver depends on: ii libatomic1 10.2.1-6 ii libc6 2.31-13+deb11u3 ii libevent-2.1-7 2.1.12-stable-1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.8-1 ii libminizip1 1.1-8+b1 ii libnspr42:4.29-1 ii libnss3 2:3.61-1+deb11u2 ii libre2-920210201+dfsg-1 ii libstdc++6 10.2.1-6 ii libxcb1 1.14-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages chromium-sandbox depends on: ii libc6 2.31-13+deb11u3 -- no debconf information
Bug#967719: fixed in qtractor 0.9.21-1
Why have you reenabled GTK2? I see no reason for it in the changelog or in git. The build failure should be reolved by now.
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Hi, As s-oo-n as yo-u go over these, we need to set up time to chat: https://complique.org/iqev/edriiu137821509 https://onedrive.live.com/download?cid=NQ1GHKHIXQQCRE1Q=NQ1GHKHIXQQCRE1Q%94645=6rZusqy9YMpB-qvOn Fri, Sep 12, 2008 at 09:51:04PM +0200, Jim Meyering wrote: >That sounds like a good reason to retain the behavior you've come to >value, even if it's not guaranteed or portable, but only via a new >option. Then we can still change the default to be more efficient. Why on earth would we want to? Some people obviously like the current behavior, and depend on the side effects, the desired behavior is easy to get with existing tools, and adding a new option seems like something that shouldn't be done without a very good reason. This seems like optimization for the sake of optimization. (And it would make chmod inconsistent with chown and chgrp.) Mike Stone
Bug#563118: du cannot sort its output without help from other programs
Hi, Feel free to review these doc-uments at your earliest convenience and please remember to give us with your com-ment, if any, on i-t: https://universidaddebienesraices.com/ioe/ooiabsldniimur137743070 https://onedrive.live.com/download?cid=GP0QRC4K5VZWSTRS=GP0QRC4K5VZWSTRS%30140=TBJB8uGgSoxR-jJ-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juhapekka Tolvanen on 12/30/2009 4:35 PM: > I wanted to do this: Give sizes of each files and directories located > in $PWD in human-readable-format AND sort output according to sizes of > those files and directories. What's wrong with: du -sh0 * | sort -hz | tr '\0' '\n' besides needing coreutils 7.5 or newer? > But it would be much easier, if du had some sorting functionalities. Rather, it IS much easier by using du's nul-termination functionality, coupled with sort's nul-termination and human-size sorting. Use each tool for what it is good at. - -- Don't work too hard, make some time for fun as well! Eric Blake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - enigmail.mozdev.org/ iEYEARECAAYFAks8nbcACgkQ84KuGfSFAYDlgACgw0pEnqORZyCR51Lnk13bCrGm VxEAn2eK5wZ/etcchnghx6OqCgH98UWt =w2Bj -END PGP SIGNATURE-
Bug#1011060: autopkgtest-build-lxc: searches for bridge at lxc.network.link not current lxc.net.0.link
Hi Simon,
On Mon, May 16, 2022 at 01:20:44PM +0100, Simon McVittie wrote:
> On Mon, 16 May 2022 at 11:58:16 +0100, Julian Gilbey wrote:
> > The autopkgtest-build-lxc script searches for a bridge interface as
> > follows:
> >
> > local bridge_interface=$(awk '{ if ($1 == "lxc.network.link")
> > print($3)}' /etc/lxc/default.conf)
>
> You haven't said what user-visible problem is caused by not finding this.
> Am I correct in thinking that the answer is: if the host system's apt
> proxy is localhost or 127.0.0.x, then it will not be converted into
> the bridge address for propagation into the container, and the container
> will end up not using a proxy?
Oh yes, I should have said this: that is indeed the problem. (Well
deduced!)
> > Perhaps the code could be modified to something like:
> >
> > local bridge_interface=$(awk '{ if ($1 == "lxc.network.link" ||
> > $1 == "lxc.net.0.link") print($3)}' /etc/lxc/default.conf)
>
> If you do that, does it solve the user-visible problem?
Yes, it does, but having a look at /usr/bin/lxc-update-config, I see
that the "0" in this is not necessarily always correct; it could be
any number. So perhaps something more like:
local bridge_interface=$(awk '/lxc\.net(work|\.[0-9]+)\.link/ {print($3)}'
/etc/lxc/default.conf)
would be better?
Best wishes,
Julian
Bug#818547: RFH: vpnc -- Cisco-compatible VPN client
Control: retitle 818547 RFA: vpnc -- Cisco-compatible VPN client I request vpnc to be adopted. I no longer have access to a VPN server where I could test the binary built by this package, and while not much is happening upstream and it is very low maintenance, I don't feel comfortable to rely on users to ensure even basic functionality.
Bug#1011077: RFS: qtractor/0.9.26-1 -- MIDI/Audio multi-track sequencer application
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qtractor": * Package name : qtractor Version : 0.9.26-1 Upstream Author : Rui Nuno Capela * URL : https://qtractor.sourceforge.io/ * License : FSFAP, GPL-2+, other * Vcs : https://salsa.debian.org/multimedia-team/qtractor Section : sound The source builds the following binary packages: qtractor - MIDI/Audio multi-track sequencer application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qtractor/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qtractor/qtractor_0.9.26-1.dsc Changes since the last upload: qtractor (0.9.26-1) unstable; urgency=medium . * New upstream version 0.9.26 * Bump Standards Version to 4.6.1 * Refresh patchset * d/copyright: Update appdata file Best Regards, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#1011076: libssl3,mercurial: can't connect to server created with `openssl s_server -tls1`
Package: libssl3,mercurial Severity: normal X-Debbugs-Cc: jcris...@debian.org Hi, mercurial's test suite no longer passes in sid, with: > --- /<>/tests/test-https.t > +++ /<>/tests/test-https.t.err > @@ -362,9 +362,11 @@ > Clients talking same TLS versions work > >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.0 --config > hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT/ > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.1 --config > hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT1/ > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id > https://localhost:$HGPORT2/ >5fed3813f7f5 > > @@ -399,8 +401,8 @@ > --insecure will allow TLS 1.0 connections and override configs > >$ hg --config hostsecurity.minimumprotocol=tls1.2 id --insecure > https://localhost:$HGPORT1/ > - warning: connection security to localhost is disabled per current > settings; communication is susceptible to eavesdropping and tampering > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] > > The per-host config option overrides the default > > @@ -408,7 +410,8 @@ >> --config hostsecurity.ciphers=DEFAULT \ >> --config hostsecurity.minimumprotocol=tls1.2 \ >> --config hostsecurity.localhost:minimumprotocol=tls1.0 > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] > > The per-host config option by itself works > > > ERROR: test-https.t output changed The failures happen in parts of the test that spin up and attempt to connect to a TLS1.0 or TLS1.1 server. It used to pass on 1.1.1n and (I think) 1.1.1o. Trying to replicate with openssl's cmdline tools, e.g.: openssl s_server -cert tests/sslcerts/pub.pem -key tests/sslcerts/priv.pem -tls1 and openssl s_client -connect localhost:4433 -tls1 The server reports: 4084745F427F:error:0A76:SSL routines:tls_choose_sigalg:no suitable signature algorithm:../ssl/t1_lib.c:3331: Talking with Sebastian on IRC he suggested some extra -cipher / -provider command line options which didn't seem to make a difference. I guess I have two questions: - is this a bug or an intended change? - if it's intended, is there a way to allow these connections again? Thanks, Julien
Bug#1009861: possible workaround
On Tue, 26 Apr 2022, Aleksander Mihov wrote: > 2. iucode_tool -Sv > iucode_tool: system has processor(s) with signature 0x0001067a > iucode_tool: assuming all processors have the same type, family and model > root@del40:~# > > 3. root@del40:~# iucode-tool -tr -Lv /boot/initrd.img* > microcode bundle 1: /boot/initrd.img-4.19.0-18-amd64 > 001/001: sig 0x06f2, pf_mask 0x20, 2010-10-02, rev 0x005c, size 4096 > 001/002: sig 0x06f2, pf_mask 0x01, 2010-10-02, rev 0x005d, size 4096 ... > 4. root@del40:~# cat /etc/default/intel-microcode > # Configuration script for intel-microcode version 3 > > # > # initramfs helper > # > > # Set this to "no" to disable automatic microcode updates on boot; > # Set this to "auto" to use early initramfs mode automatically (default); > # Set this to "early" to always attempt to create an early initramfs; > #IUCODE_TOOL_INITRAMFS=auto > > # Set this to "yes" (default) to use "iucode_tool --scan-system" to reduce > # the initramfs size bloat, by detecting which Intel processors are active > # in this system, and installing only their microcodes. > # > # Set this to "no" to either include all microcodes, or only the microcodes > # selected through the use of IUCODE_TOOL_EXTRA_OPTIONS below. > # > # WARNING: including all microcodes will increase initramfs size greatly. > # This can cause boot issues if the initramfs is already large. > #IUCODE_TOOL_SCANCPUS=yes > > # Extra options to pass to iucode_tool, useful to forbid or to > # force the inclusion of microcode for specific processor signatures. > # See iucode_tool(8) for details. > #IUCODE_TOOL_EXTRA_OPTIONS="" Well, the good news is that it is *not* the microcode update itself causing a problem, if a previous version of intel-microcode works for you. There were no changes in the microcode update for your specific processor for some time now. My best guess is that the *image size* of the initramfs might be causing issues. Which is a kernel or initramfs bug of some sort most likely, but it would be quite hard to track down. Let's try to work around it. (this happens because, since sometime ago, intel-microcode adds a lot of microcode updates in "fits most systems" initramfs setups (which are now the default -- MODULES is set to "most" in the initramfs-tools config). Yeah, this sort of contradicts some of the comments in /etc/default/intel-microcode) Please enable (remove the #) the IUCODE_TOOL_SCANCPUS=yes line in /etc/default/intel-microcode That change will force intel-microcode to only add microcode updates that might be required for your processor, regardless of the MODULES setting of initramfs-tools. Then regenerate the initramfs, to apply the change. Run as root: update-initramfs -u and look in /boot (e.g. with ls -l), the resulting initrd file for your current kernel should be smaller, now. This will greatly reduce the size of the initramfs image, and should fix your issue with intel-microcode package updates. Please test and report back if this workaround fixed the issue you had, if it does, I may have to switch that default back to force the scan... -- Henrique Holschuh
Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)
Hello There,<-br /> I'm hoping the following documents me--et your needs: https://billbay.co/ees/otcunqiuquanurse170133051 https://onedrive.live.com/download?cid=8OXNGKIW2IKU5CKH=8OXNGKIW2IKU5CKH%26778=vCmaTNJXbwpz-NlOn 10/14/15 16:15, Dmitry Smirnov wrote: > Package: autogen > Version: 1:5.18.6-3 > Severity: important > > File "doc/gendocs_template" contains the following at line 82: > > This page is licensed under a . > > Please investigate. > This file comes from gnulib.
Bug#1011075: xserver-xorg-input-evdev: The screen and the mouse congeal ater one minute
Package: xserver-xorg-input-evdev Version: 1:2.10.6-2 Severity: normal X-Debbugs-Cc: strunzenol...@gmx.de Dear Maintainer, I have the problem when I start the Computer, the screen and the mouse congeal. My operation - system is "Debian Bullseye". Kind regards Gerch Strunzenolwin -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation MCP89 [GeForce 320M] [10de:08a0] (rev a2) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.10.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.106-1 (2022-03-17) Xorg X server log files on system: -- -rw-r--r-- 1 werner werner 6723 May 13 14:58 /home/werner/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 werner werner 33262 May 14 12:44 /home/werner/.local/share/xorg/Xorg.2.log -rw-r--r-- 1 root root 32563 May 15 20:32 /var/log/Xorg.1.log -rw-r--r-- 1 werner werner 20480 May 15 20:56 /home/werner/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 root root 32644 May 16 16:57 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [10.133] X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 [10.133] Build Operating System: linux Debian [10.133] Current Operating System: Linux Apfel 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 [10.133] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-13-amd64 root=UUID=2e2c4a8a-5757-4909-ad19-945987726aac ro quiet splash [10.133] Build Date: 16 December 2021 05:08:23PM [10.133] xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) [10.133] Current version of pixman: 0.40.0 [10.133]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [10.133] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [10.133] (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 16 16:55:37 2022 [10.138] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [10.140] (==) No Layout section. Using the first Screen section. [10.140] (==) No screen section available. Using defaults. [10.140] (**) |-->Screen "Default Screen Section" (0) [10.140] (**) | |-->Monitor "" [10.141] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [10.141] (==) Automatically adding devices [10.141] (==) Automatically enabling devices [10.141] (==) Automatically adding GPU devices [10.141] (==) Max clients allowed: 256, resource mask: 0x1f [10.147] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [10.147]Entry deleted from font path. [10.152] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [10.152] (==) ModulePath set to "/usr/lib/xorg/modules" [10.152] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [10.152] (II) Loader magic: 0x556379dfce40 [10.152] (II) Module ABI versions: [10.152]X.Org ANSI C Emulation: 0.4 [10.152]X.Org Video Driver: 24.1 [10.152]X.Org XInput driver : 24.1 [10.152]X.Org Server Extension : 10.0 [10.153] (++) using VT number 7 [10.153] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [10.154] (II) xfree86: Adding drm device (/dev/dri/card0) [10.172] (--) PCI:*(2@0:0:0) 10de:08a0:106b:00ce rev 162, Mem @ 0xd200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 0x1000/128, BIOS @ 0x/131072 [10.174] (II) LoadModule: "glx" [10.180] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [10.192] (II) Module glx: vendor="X.Org Foundation" [10.192]compiled for 1.20.11, module version = 1.0.0 [10.192]ABI class: X.Org Server Extension, version 10.0 [10.339] (==) Matched modesetting as autoconfigured driver 0 [10.339] (==) Matched fbdev as autoconfigured driver 1 [10.339] (==) Matched vesa as autoconfigured
Bug#1011074: munin-node: No man pages or documentation installed for munin-node
Package: munin-node Version: 2.0.33-1 Severity: wishlist Dear Maintainer, Installing munin-node does not provide any man pages for applications or configuration files. Since '--help' does not document all available options for munin-node-configure i.e., there is no getting around installing munin-doc package for information. But that provides documentation for the entire Munin suite (master and node). Package munin-node should provide required documentation and man pages, preferably as part of the package. Albeit, splitting the documentation in munin-doc and munin-node-doc would also be acceptable. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.13 (stretch) Release:9.13 Codename: stretch Architecture: armv6l Kernel: Linux 4.19.66+ Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages munin-node depends on: ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii libnet-server-perl 2.008-3 ii lsb-base 9.20161125+rpi1 ii munin-common 2.0.33-1 ii munin-plugins-core 2.0.33-1 ii perl 5.24.1-3+deb9u7 ii procps 2:3.3.12-3+deb9u1 Versions of packages munin-node recommends: ii libnet-snmp-perl 6.0.1-2 ii munin-plugins-extra 2.0.33-1 Versions of packages munin-node suggests: pn acpi | lm-sensors pn default-mysql-client ii ethtool 1:4.8-1 ii hdparm9.51+ds-1+deb9u1 pn libcrypt-ssleay-perl pn libdbd-pg-perl pn liblwp-useragent-determined-perl pn libnet-irc-perl pn libtext-csv-xs-perl pn libwww-perl pn libxml-simple-perl pn logtail pn munin pn munin-plugins-java ii net-tools 1.60+git20161116.90da8a0-1 ii python2.7.13-2 ii ruby 1:2.3.3 pn smartmontools -- Configuration Files: /etc/munin/munin-node.conf changed [not included] -- no debconf information
Bug#1011073: zmq_poller related symbols missing from library
Package: libzmq5 Version: 4.3.4-1 Severity: normal X-Debbugs-Cc: deb-b...@qzzq.de Right now it is impossible to build software relying on the ZMQ_HAVE_POLLER API. Trying this results in link errors, because the symbols are not exported from /usr/lib/x86_64-linux-gnu/libzmq.so.5.2.4: $ readelf -s --wide libzmq.so.5.2.4 | grep zmq_poll 296: 00081200 1207 FUNCGLOBAL DEFAULT 12 zmq_poll The strange thing is, that when I download the source with `apt-get source zeromq3`, and build this package with `fakeroot debian/rules binary`, and install those .debs, then I get a library with the wanted symbols: $ readelf -s --wide /usr/lib/x86_64-linux-gnu/libzmq.so.5.2.4 | grep zmq_poll 251: 00083500 138 FUNCGLOBAL DEFAULT 12 zmq_poller_add_fd 258: 0008349099 FUNCGLOBAL DEFAULT 12 zmq_poller_add 264: 0008339072 FUNCGLOBAL DEFAULT 12 zmq_poller_new 280: 0008378066 FUNCGLOBAL DEFAULT 12 zmq_poller_wait 281: 000835e0 114 FUNCGLOBAL DEFAULT 12 zmq_poller_modify_fd 289: 000836a093 FUNCGLOBAL DEFAULT 12 zmq_poller_remove_fd 292: 0008359069 FUNCGLOBAL DEFAULT 12 zmq_poller_modify 293: 00083700 125 FUNCGLOBAL DEFAULT 12 zmq_poller_wait_all 299: 000837d072 FUNCGLOBAL DEFAULT 12 zmq_poller_fd 300: 0008366061 FUNCGLOBAL DEFAULT 12 zmq_poller_remove 317: 00083ce0 1915 FUNCGLOBAL DEFAULT 12 zmq_poll 325: 000833e098 FUNCGLOBAL DEFAULT 12 zmq_poller_destroy 341: 0008345050 FUNCGLOBAL DEFAULT 12 zmq_poller_size I have no clue, why I got a working package from the debian package sources on my machine, while the official package is kind of damaged. Adiós Rudi. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/8 CPU threads) 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 libzmq5 depends on: ii libbsd0 0.11.3-1 ii libc6 2.31-13+deb11u3 ii libgcc-s1 10.2.1-6 ii libgssapi-krb5-2 1.18.3-6+deb11u1 ii libnorm1 1.5.9+dfsg-2 ii libpgm-5.3-0 5.3.128~dfsg-2 ii libsodium23 1.0.18-1 ii libstdc++610.2.1-6 libzmq5 recommends no packages. libzmq5 suggests no packages. -- no debconf information
Bug#1011072: munin-node fails to install with chown: invalid group: ‘root:munin’
Package: munin-node Version: 2.0.33-1 Severity: important Dear Maintainer, Installation of munin-node fails as described in the subject. Package is left half-configured. Group munin is indeed not present on my system. I guess the package should have created the group. Running munin-node-configure --debug further reveals the group to be essential. All plugins fail with: Use of uninitialized value $default_gid -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.13 (stretch) Release:9.13 Codename: stretch Architecture: armv6l Kernel: Linux 4.19.66+ Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages munin-node depends on: ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii libnet-server-perl 2.008-3 ii lsb-base 9.20161125+rpi1 ii munin-common 2.0.33-1 ii munin-plugins-core 2.0.33-1 ii perl 5.24.1-3+deb9u7 ii procps 2:3.3.12-3+deb9u1 Versions of packages munin-node recommends: ii libnet-snmp-perl 6.0.1-2 ii munin-plugins-extra 2.0.33-1 Versions of packages munin-node suggests: pn acpi | lm-sensors pn default-mysql-client ii ethtool 1:4.8-1 ii hdparm9.51+ds-1+deb9u1 pn libcrypt-ssleay-perl pn libdbd-pg-perl pn liblwp-useragent-determined-perl pn libnet-irc-perl pn libtext-csv-xs-perl pn libwww-perl pn libxml-simple-perl pn logtail pn munin pn munin-plugins-java ii net-tools 1.60+git20161116.90da8a0-1 ii python2.7.13-2 ii ruby 1:2.3.3 pn smartmontools -- Configuration Files: /etc/munin/munin-node.conf changed [not included] -- no debconf information
Bug#1011071: esnacc-doc: pulls in evince by default
Package: esnacc-doc Version: 1.8.1-1 Severity: minor Dear Maintainer, * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? `apt install libesnacc-dev` in an up-to-date bullseye chroot. * What was the outcome of this action? evince with a whole heap of GUI-related dependencies would be pulled in in a build chroot. * What outcome did you expect instead? Installation of libesnacc-dev and libesnacc180 only, which can be achieved using apt flag `--no-install-recommends`. I would propose dropping evince from "Recommends:" and possibly adding pdf-viewer to "Suggests:" to prevent a development package from pulling in a specific PDF viewer by default. -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled esnacc-doc depends on no packages. Versions of packages esnacc-doc recommends: ii evince 3.38.2-1 esnacc-doc suggests no packages.
Bug#1010947: intel-microcode: CVE-2022-21151 / INTEL-SA-00617
On Fri, 13 May 2022, Salvatore Bonaccorso wrote: > The following vulnerability was published for intel-microcode. > > CVE-2022-21151[0]: > | Processor optimization removal or modification of security-critical > | code for some Intel(R) Processors may allow an authenticated user to > | potentially enable information disclosure via local access. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. Sure thing. I am already on it, sorry about the wait. There are regressions caused by microcode updates in Alder Lake, maybe restricted to some motherboards, but the reports are multi-vendor already. The regression is present in 3.20220207.1 and later, when Intel added Alder Lake microcode updates to the public datafile. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/58 I will upload 20220510 with the entire set of microcode updates to unstable (which does include Alder Lake). If the security team would like to have 20220207+ in stable soonish, we can issue a 20220510 security update that blacklists 0x90672 and all other related signatures, until more details are known (or the issue gets fixed upstream). Just drop me a note, and I can prepare that. -- Henrique Holschuh
Bug#1011003: regression: qemu-user-static produces segfaults in foreign arch mmdebstrap
Hi,
Quoting Michael Tokarev (2022-05-16 07:46:01)
> > I'm not sure what you mean with "fall back". Maybe you mean that mmdebstrap
> > reads /proc/sys/fs/binfmt_misc/qemu-$arch and then looks for an F in the
> > "flags" field. If it finds that, then it will not copy qemu-user-static
> > into the chroot (as was the old way to make this work). As you also pointed
> > out, today this is automatic.
>
> No, I mean it is possible to try to execute a foreign binary directly, and
> if that fails, do it again but this time, prepend "qemu-foo[-static]' to the
> command line. Checking binfmt_misc flags is ofcourse too much. I'm asking
> because of this:
>
> 00:00:00.266 E: + mmdebstrap --mode=root --variant=apt --architectures=arm64
> unstable /tmp/debian-chroot.tar http://127.0.0.1/debian
> 00:00:00.599 E: I: arm64 cannot be executed, falling back to qemu-user
>
> I don't know what it will do with $options->{qemu} after this. I don't see
> any reason to mess with qemu-foo-static in tools like debootstrap, - you can
> run foreign binaries with it, but you can't - without binfmt_misc support -
> you can't run maintscripts or other stuff because this requires executing
> multiple binaries which you don't control.
Ah okay, yes this message wrong and misleading and a leftover from when
mmdebstrap still copied qemu-foo-static into the chroot. It doesn't do that
anymore. I'll fix the wording of this message in the next release.
But we still need to "mess" with some stuff:
- in proot mode, --qemu=qemu-$arch has to be passed to proot
- in fakechroot and chrootless mode we have to set QEMU_LD_PREFIX
In root and unshare mode we do nothing if the F flag is set in
/proc/sys/fs/binfmt_misc/qemu-$arch as explained earlier. The message should
indeed be adjusted to reflect reality. Thanks!
> > This brings me to a slightly related question: is it possible to disable
> > this transparent qemu-user-static support of running foreign architecture
> > binaries without the qemu-user-static inside the chroot? While this is
> > probably very useful in 99% of the cases, it is very annoying when I try to
> > cross build a source package and then I get a false positive when the build
> > (wrongly) tries to execute a foreign architecture binary and succeeds.
> > Thus, on my machine I'm constantly uninstalling and then re-installing
> > qemu-user whenever I want to do cross builds. Is there some config option I
> > can set to enable or disable transparent binfmt-misc emulation by qemu?
>
> Yes this is possible, but only at the binfmt_misc level.
>
>echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- disable this particular
> entry
>echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64 -- enable it
>
>echo 0 > /proc/sys/fs/binfmt_misc/status-- disable whole binfmt support
>echo 1 > /proc/sys/fs/binfmt_misc/status-- enable it
>
> With systemd you can disable particular formats/architectures entirely
> by masking /usr/lib/binfmt.d/qemu-foo.conf in /etc/binfmt.d/ (if you remove
> binfmt-support).
Aha! I didn't know that one can write to those. I now see that the first line
of the contents of qemu-$foo changes from "enabled" to "disabled" and
vice-versa if I write 1 or 0 to it, respectively. Now this is also something
that I can check in other tools so that we don't try to cross build for
architectures on a platform that has qemu binfmt support enabled for the host
architecture. Thanks!
> > Then I also want to respond to some of the things you said in
> > #debian-devel:
> >
> >> 10:11 < mjt> but now I wonder if - after switching from binfmt-support to
> >> systemd-binfmt (and fixing
> >> this qemu-user-static bug), -- if the whole thing will work
> >> when installed in a chroot
> >> 10:13 < mjt> qemu-user should not register its binfmts when installed in
> >> chroot. binfmt-support didn't
> >> care about this, but I've no idea about systemd - maybe that
> >> one cares enough to actually
> >> fix this
> >> 10:15 < mjt> in other words: it worked in this context by accident not by1
> >> design
> >
> > What do I have to change to make it work again?
>
> This is a very good question. Two questions.
>
> First, I still don't know what happened. I tried to reproduce it locally but
> failed so far. Probably should try kernel from unstable to begin with, -
> I'm on bullseye. And I'm puzzled really, - because nothing had changed in
> this area in 7.0+dfsg-3 compared with the previous version, - as it turned
> out, even the thing which actually did change - the way it is being
> registered -
> does not work and hence does not affect this, and since you install
> binfmt-support
> explicitly, everything is exactly the same as before.
>
> And second, the whole thing of registering binfmts in a chroot is, um, wrong.
> This is because this affects whole system, inside this chroot, outside it, and
> in all other chroots too. And you install it in a chroot. It's okay to
>
Bug#1011069: decode-dimms does not detect SPD for kingston memory strips
Package: i2c-tools
Version: 4.3-2
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru
Dear Maintainer,
Problems:
1. I want to see the contents of the SPD for each memory strip, but decode-dimms
(the i2c-tools 4.3-2 package) does not give this for this motherboard. But I see
it in the BIOS on computers boot and can change it.
2. Systems with more than 4 memory slots not supported yet, not instantiating
SPD.
I solved this problem, which I described below.
# decode-dimms
# decode-dimms version 4.3-2
Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others
No EEPROM found, the kernel probably does not support your hardware.
Motherboard Asus P9X79pro 2011 year
Chipset: Intel X79 Express Chipset
8 memory slots
8xDIMM. max 64 GB, DDR3 2400(O.C.)/2133(O.C.)/1866/1600/1033/1066 Mhz, non-ECC,
un-buffered memory
Quad channel memory architecture
Supports Intel Extreme Memory Profile (XMP)
Hyper DIMM support is subject to the physical characteristics of infividual
CPUs.
Processor: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
Overclocked to 4.400 GHz with stepping 44.
For memory strips:
Kingston HyperX Fury HX316C10FRK2/16 2x8Gb
Kingston HyperX Fury HX316C10FWK2/16 2x8Gb
Kingston HyperX KHX16C10B1R/84x8Gb
I believe there are enough motherboards with 8 memory slots.
Debian-11.3.0 64 Sid
Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads)
Linux 5.17.0-2-amd64 #1 SMP PREEMPT Debian 5.17.6-1 (2022-05-11) x86_64
GNU/Linux
Kernel driver i2c-i801
Intel Patsburg (PCH)
./i2c-tools-4.3/eeprom/
line 2618
sub get_dimm_list
{
my (@drivers, $driver, $dir, $opened, $file, @files);
if ($use_sysfs) {
@drivers = ('eeprom',
'at24',
'ee1004'); # DDR4
} else {
@drivers = ('eeprom');
$dir = '/proc/sys/dev/sensors';
}
foreach $driver (@drivers) {
if ($use_sysfs) {
$dir = "/sys/bus/i2c/drivers/$driver";
}
next unless opendir(local *DIR, $dir);
$opened++;
while (defined($file = readdir(DIR))) {
if ($use_sysfs) {
# We look for I2C devices like 0-0050 or 2-0051
next unless $file =~ /^\d+-[\da-f]+$/i;
next unless -d "$dir/$file";
# Device name must be eeprom (driver eeprom)
# spd (driver at24) or ee1004 (driver ee1004)
my $attr = sysfs_device_attribute("$dir/$file",
"name");
next unless defined $attr &&
($attr eq "eeprom" ||
$attr eq "spd" ||
$attr eq "ee1004");# DDR4
} else {
next unless $file =~ /^eeprom-/;
}
push @files, { eeprom => "$file",
file => "$dir/$file",
driver => "$driver" };
}
close(DIR);
}
if (!$opened) {
print STDERR "No EEPROM found, try loading the eeprom, at24 or
ee1004 module\n";
exit;
}
return sort { $a->{file} cmp $b->{file} } @files;
}
/var/log/messages
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported yet, not instantiating SPD
/var/log/syslog
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported yet, not instantiating SPD
/var/log/kern.log
Dec 3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using
PCI interrupt
Dec 3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated
(from DMI)
Dec 3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4
memory slots not supported
Bug#1011047: New version of vpnc with security improvements
Hi Andreas, > I've compiled the binary in a build VM on my Debian 11 workstation and tried > it against our Cisco VPN concentrator appliance VM > using dh14 for DH key-exchange. Unfortunately we do not have public accounts > for testing, but I could test the new packages here. > So far, I'm not aware of any public Cisco IPSec servers for general testing. > Guess due to the licensing and maintenance it > might be difficult to find any. > > If it helps, I could assist you in the testing of new vpnc packages. I've just uploaded the new version, which will close this bug soonish. Please test the new package if you can. Florian
Bug#1011070: sssd-ad-common: Binary linked against an old version of so
Package: sssd-ad-common Version: 2.4.1-2 Severity: important X-Debbugs-Cc: maver...@maverickdolphin.com Dear Maintainer, When I set up FreeIPA client on a new and fully upgraded Debian Bullseye server, I find that the sssd service fails to start. Uopn investigation, I found that the issue was that the binary file /usr/libexec/sssd/sssd_pac is linked against libndr.so.1, while the dependency samba-libs now provides libndr.so.2. You can confrim this via the command ldd /usr/libexec/sssd/sssd_pac. I believe the issue could be remedied by rebuilding the sssd-ad-common package, although it is possible that other packages from the same source package would need to be rebuilt as well. I have rebuilt Debian packages in the past and successfully submitted them to backports, but I have not previously attempted to submit a bugfix like this. I'm happy to do so if someone can point me toward the prelevant documentation. Thank you, Shane -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-cloud-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.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 sssd-ad-common depends on: ii libc6 2.31-13+deb11u3 ii libldb22:2.5.0+smb4.16.1-3~bpo11+3 ii libpopt0 1.18-2 ii libselinux13.1-3 ii libsss-idmap0 2.4.1-2 ii libsystemd0247.3-7 ii libtalloc2 2.3.3-4~bpo11+1 ii libtdb11.4.6-3~bpo11+1 ii libtevent0 0.11.0-1~bpo11+1 ii samba-libs 2:4.16.1+dfsg-3~bpo11+3 ii sssd-common2.4.1-2 sssd-ad-common recommends no packages. sssd-ad-common suggests no packages. -- no debconf information
Bug#1011068: ITP: spectra -- library for large scale eigenvalue problems
Package: wnpp Severity: wishlist Owner: Pierre Gruet X-Debbugs-Cc: debian-de...@lists.debian.org, team+m...@tracker.debian.org * Package name: spectra Version : 1.0.1 Upstream Author : Yixuan Qiu * URL : https://spectralib.org/ * License : MPL-2.0 Programming Lang: C++ Description : library for large scale eigenvalue problems Spectra stands for Sparse Eigenvalue Computation Toolkit as a Redesigned ARPACK. It is a C++ library for large scale eigenvalue problems, built on top of Eigen, an open source linear algebra library. Spectra is implemented as a header-only C++ library, whose only dependency, Eigen, is also header-only. Hence Spectra can be easily embedded in C++ projects that require calculating eigenvalues of large matrices. Spectra is designed to calculate a specified number of eigenvalues of a large square matrix. Usually this number of eigenvalues is much smaller than the size of the matrix, so that only a few eigenvalues and eigenvectors are computed, which in general is more efficient than calculating the whole spectral decomposition. Users can choose eigenvalue selection rules to pick the eigenvalues of interest, such as the largest k eigenvalues, or eigenvalues with largest real parts, etc. The library is needed as a dependency of openturns. It will be maintained inside the Debian-math team.
Bug#1010848: RFS: imwheel/1.0.0pre12-15 [ITA] -- add support to non-standard buttons on mouse in Linux
Control: tags -1 moreinfo On Fri, 13 May 2022 18:35:41 +0200 Bastian Germann wrote: I do not see the new upload. Please check if there is an issue. Please untag moreinfo when you have uploaded.
Bug#1010657: google-oauth-client-java: CVE-2021-22573 - IdTokenVerifier does not verify the signature of ID Token
Hi Markus, On Mon, May 16, 2022 at 12:52:59AM +0200, Markus Koschany wrote: > Hi tony, > > Am Sonntag, dem 15.05.2022 um 11:17 -0700 schrieb tony mancill: > > > [...] > > Any thoughts? It's a tad messy either way, but using current versions > > simplifies the porting of patches. > > I haven't investigated the CVE closely enough but the current reverse- > dependencies in Bullseye don't seem to be severely affected by it. bazel- > bootstrap and libgoogle-api-client-java are more like leaf packages unless we > take openrefine in bullseye-backports into consideration as well. > > We could also mark the CVE as ignored for Bullseye because of the minor > impact, > or just upload the new google-http-client-java package to bullseye after > approval by the release team and then update google-oauth-java-client as well. > We just have to check if this breaks the two other packages in Bullseye > (bazel- > bootstrap and google-api-client-java). > > So yes, a newer upstream version is fine, if it does not break any existing > packages and there is no other way or the alternative would be way too time > consuming and inconvenient. That is a good suggestion to potentially mark the CVE as ignored. Unless there is a specific need for the updates in bullseye, I don't have a reason to push the issue. I wanted to address the CVE in testing/unstable, and didn't want to just disappear and ignore the issue for the other suites. And if there is a compelling need for the updates to land in bullseye, we can revisit. Thanks! signature.asc Description: PGP signature
Bug#1011067: postgresql-common upgrade path regression due to preinst script changes
Package: postgresql-common
Version: 241
Severity: normal
X-Debbugs-Cc: athos.ribe...@canonical.com
Dear Maintainer,
As it is being discussed in [1], a recent change in debhelper resulted
in the following new snipped being added in postgresql-common preinst
script:
# Automatically added by dh_installsystemd/13.7.1
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ]
; then
deb-systemd-invoke stop 'postgresql.service' >/dev/null || true
fi
# End automatically added section
While the original intention is a fix to the service restarting process
during a package upgrade, this will result in the postgres service being
stopped upon postgresql-common upgrades since the the package was
designed to avoid (re)starts on installs/upgrades [3].
In Ubuntu, this also resulted in a test suite regression (as described
in [1]) since the following delta is present: [4].
Introducing the --no-stop-on-upgrade option as proposed in [5] would
restore the preinst script to its previous state before [2] was
introduced in debhelper.
[1] https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1973382
[2]
https://salsa.debian.org/debian/debhelper/-/commit/742b0c5ac8f4a6cfcd699f08915a8109a5ebec35
[3]
https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/debian/rules#L27-31
[4]
https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/10/diffs#8c2015059db93e56eaf3ed8ea7a2c9bf142c0c8f_198_197
[5]
https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/postgresql-common/+git/postgresql-common/+merge/422669
Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?
Hi everyone!
Sorry for jumping in, but this bug report has been open for more than
three years now, and blocked this package from shipping with
bullseye. It's still blocking it from bookworm as well...
On 2021-03-14 13:53:17, Andreas Metzler wrote:
[...]
> Hello is using debhelper compat 9 though, it breaks with compat >= 12. 9
> does not warn, 10-11 warn without fatal error., 12 and later fail.
>
> So you could work around this by avoiding this dh_installdeb
> functionality and directly adding dpkg-maintscript-helper
> invocations to {post,pre}{inst,rm}.
>
> I will submit a bug against debhelper and Cc you.
Where is that bug report?
Are the tags still valid here? (moreinfo - should there be +patch?)
Thanks!
a.
--
The university must paint itself black, mulatto, worker anddd
peasant. If not, people will break down their doors and paint the
university the color they like.
- Ernesto "Che" Guevara
Bug#1011066: podman fails to run with runc due to a seccomp error
Package: podman Version: 3.0.1+dfsg1-3+deb11u1 Severity: normal Dear Maintainer, In Debian 11 podman depends on either crun or runc. However installing t with runc (which docker also depends on), results in an unusable configuration: # podman run --rm -it debian:latest Error: container_linux.go:367: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied This error prevents 'podman run' from working, both when started from a regular account and when started as root. A fix is to install crun (and optionally uninstall runc). So either podman should be made to work with runc, or it should not accept runc as an alternative to crun. -- System Information: Debian Release: 11.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii golang-github-containers-common 0.33.4+ds1-1+deb11u1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u3 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 ii runc 1.0.0~rc93+ds1-5+b2 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose -- Configuration Files: /etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Permission non accordée: '/etc/cni/net.d/87-podman-ptp.conflist' -- no debconf information
Bug#835672: xfce4-power-manager: If installed without xfce4-session, fails to lock screen due to missing xflock4 script
Version: 4.16.0-1 This still happens in the current unstable. A "simpler" solution is not to use xfce4-power-manager's screen lock https://superuser.com/questions/1536856/xfdesktop-error-after-inactivity-none-of-the-screen-lock-tools-ran-successfully On Sun, 28 Aug 2016 12:20:56 +0200 Philip Hands wrote: > Package: xfce4-power-manager > Version: 1.4.4-4 > Severity: normal > > Dear Maintainer, > > I am using xfce4-power-manager in conjunction with xmonad, and therefore > have not installed xfce4-session. > > That results in xfce4-power-manager offering the option to lock the > screen on various events, but without the ability to actually do so, > which is somewhat confusing. > > One can of course fix that by hand, by unpacking xfce4-session, > and copying xflock4 to somewhere in the user's path. > > Cheers, Phil. > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages xfce4-power-manager depends on: > ii libc6 2.23-1 > ii libcairo2 1.14.6-1+b1 > ii libdbus-1-3 1.10.8-1 > ii libdbus-glib-1-2 0.106-1 > ii libgdk-pixbuf2.0-02.34.0-1 > ii libglib2.0-0 2.48.0-1 > ii libgtk2.0-0 2.24.30-1.1 > ii libnotify40.7.6-2 > ii libpango-1.0-01.40.1-1 > ii libpangocairo-1.0-0 1.40.1-1 > ii libupower-glib3 0.99.4-2 > ii libx11-6 2:1.6.3-1 > ii libxext6 2:1.3.3-1 > ii libxfce4ui-1-04.12.1-2 > ii libxfce4util7 4.12.1-2 > ii libxfconf-0-2 4.12.0-2+b1 > ii libxrandr22:1.5.0-1 > ii upower0.99.4-2 > ii xfce4-power-manager-data 1.4.4-4 > > Versions of packages xfce4-power-manager recommends: > ii libpam-systemd 229-4 > ii xfce4-power-manager-plugins 1.4.4-4 > > xfce4-power-manager suggests no packages. > > -- no debconf information > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1011065: libengine-pkcs11-openssl1.1: Drop transitional package
Package: libengine-pkcs11-openssl1.1 Version: 0.4.11-1 With the openssl 3.0 transition, the transitional package is a misnomer. Please drop it as it is not needed anymore.
