Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
Package: debianutils Version: 5.0.1-1 Severity: critical Justification: breaks unrelated software /etc/X11/XSession relies on tempfile, which is not available anymore, thus logging into an X session is broken. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.16+ (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debianutils depends on: ii libc6 2.31-15 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information
Bug#992398: Xsession requires tempfile
Source: debianutils Version: 5.0.1-1 Severity: critical X fails to start up, basically rendering the whole graphical login useless. /etc/X11/Xsession:elif ERRFILE=$(tempfile 2> /dev/null); then /etc/X11/Xsession:# error from tempfile and echo go to the error file to aid the user in /etc/X11/Xsession:WRITE_TEST=$(tempfile) Really, how did this make it in?
Bug#992397: emf2svg: typo in package description: hanlde -> handle
Package: emf2svg Version: 1.1.0+ds-2 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Long description seemingly contains a typo: > This project could be used to hanlde EMF blobs should probably instead say > This project could be used to handle EMF blobs - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEcr18ACgkQLHwxRsGg ASFOzg//fv4FmrShSaYODfYjPXwTv0D90UJ4zoICmxJJSodzz9rmQTCL9ZqH1bzL u4CvEIYC4fh5ItWCYyStoUo6o/MgF2SPb2mg4E43G2Y2Mwj5k/dCUxJLMJgdFK94 RZwgf9mtOLjlIP+xWxB0jafuigq6mhXnUEot4IFRKE+Uv0Ztwwo+wrJBt752hXbg OkupWCt7iRaLKVLyp63ZY6gA9E4Vl6YaWiIKyNSSJfrQdwsftZW7rWZmo+wdAOQ0 wEHz9L0uF9j+tU3RNEE2pU/9d+qNjrriT3KJ8FCHpOXjcF0tHjwXStu7hrS2Lmst gcZY1i+yXPmCcC33UxECo89PgVWUgLXHMlM6AULhU2+46Dq/BEYQAi6WWSZX9qc3 Z6uCjllSjWmrq4ApNNKISMsfG2lhVW9qBjVZmIXsLlhRGmWa86d2t4vHyM9dfE9B lPi/uEdYCwi5d4yX0tFS/4QusddY5z/sdDrZ7f/P8UWo77EZgfaPelkFhnv7r4UY U1xEUgzh6mHaI0IpITvqjomcGhEr6cch/x0THrHBIE4dtkj+mYFEbsl8p3D9Z1CV onDxeYivhx/br7zXqfVZ8NtEeImswtYP96Nq2S3m7sj1QIrJhZKVyb4hhb/43liz 2pbZmUAV6NZnvUSE7mXleJWwFuZ81rhSX0tPS1rQjJocaQrClSk= =i5nu -END PGP SIGNATURE-
Bug#992385: x11-common: use of deprecated tempfile breaks login
On 18.8.2021 7.34, Marc Dequènes (duck) wrote: Package: x11-common Version: 1:7.7+22 Severity: grave Quack, Since debianutils has dropped the deprecated `tempfile` in 5.0-1 /etc/X11/Xsession fails around the WRITE_TEST and this breaks graphical login completely. Commenting this section allowed me to log in. There is another call line 85 that needs to be changed too. Regards. \_o< What if you just do s/tempfile/mktemp? -- t
Bug#992362: release-notes: Out of step wuth apt maintainers
On Ma, 17 aug 21, 20:20:40, Brian Potkin wrote: > Package: release-notes > Severity: normal > > > Please see > > https://lists.debian.org/debian-doc/2021/08/msg00077.html > > Then look at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758316 > > How abut a bit of consistency? As I understand it the APT maintainers are just saying it doesn't bring much (if any) security or privacy benefit, they don't explicitly recommend against it. For the Release Notes itself there is however a real benefit in avoiding all future bug reports asking to use https:// everywhere ;) Kind regards, Andrei (just an occasional contributor to the Release Notes) -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#992385: x11-common: use of deprecated tempfile breaks login
Control: clone -1 -2 Control: reassign -2 debianutils 5.0-1 Control: retitle -2 debianutils: removes interface from essential package without proper transition Control: severity -1 important Control: retitle -1 xorg-common: please remove use of deprecated tempfile On 2021-08-18 13:34:43 +0900, Marc Dequènes wrote: > Package: x11-common > Version: 1:7.7+22 > Severity: grave > > > Quack, > > Since debianutils has dropped the deprecated `tempfile` in 5.0-1 > /etc/X11/Xsession fails around the WRITE_TEST and this breaks graphical > login completely. Commenting this section allowed me to log in. There is > another call line 85 that needs to be changed too. That's not how changes in essential packages are performed. Please coordinate a proper transition with all users of tempfile before removing it. Once that is finished in release $x, tempfile can be removed in release $x+1. Given the current state, that's not before we start development of trixie. Cheers > > Regards. > \_o< > > -- > Marc Dequènes -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#992400: fetchmail: segfault with specific .fetchmailrc
Package: fetchmail
Version: 6.4.16-4
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Maintainer,
fetchmail started SEGFAULTing after upgrading from buster to
bullseye. This is an example config which causes this:
test@canardo:~$ cat .fetchmailrc
set invisible
defaults
proto pop3
uidl
no envelope
poll pop.example.com
user foo with pass bar is test here
Note that the example can be uses as-is. The server and
user does not need to exist. fetchmail crashes on parsing
before trying to lookup servername or anything:
test@canardo:~$ strace -f fetchmail 2>&1|tail -10
openat(AT_FDCWD, "/home/test/.fetchmailrc", O_RDONLY) = 3
ioctl(3, TCGETS, 0x7ffdf5799df0)= -1 ENOTTY (Inappropriate ioctl for
device)
fstat(3, {st_mode=S_IFREG|0600, st_size=116, ...}) = 0
read(3, "set invisible\ndefaults\n proto p"..., 8192) = 116
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, TCGETS, 0x7ffdf5799df0)= -1 ENOTTY (Inappropriate ioctl for
device)
close(3)= 0
- --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0xffe0} ---
+++ killed by SIGSEGV +++
Moving the settings from "defaults" to the server section
works around the issue. But this is a regression since that
exact configuration has worked for 5+ years over several
earlier fetchmail versions. An incomplete list of versions
where this used to work:
6.3.26-1+b1
6.3.26-3
6.4.0~beta4-3
6.4.0~beta4-3+deb10u1
Bjørn
- -- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (700, 'stable'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fetchmail depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii libc6 2.31-13
ii libcom-err2 1.46.2-2
ii libgssapi-krb5-2 1.18.3-6
ii libkrb5-3 1.18.3-6
ii libssl1.1 1.1.1k-1
ii lsb-base 11.1.0
Versions of packages fetchmail recommends:
ii ca-certificates 20210119
Versions of packages fetchmail suggests:
pn fetchmailconf
pn resolvconf
ii sendmail-bin [mail-transport-agent] 8.15.2-22
- -- Configuration Files:
/etc/default/fetchmail [Errno 13] Permission denied: '/etc/default/fetchmail'
- -- no debconf information
-BEGIN PGP SIGNATURE-
iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCYRy0dw4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyVCTAJ4v7DrZ98/7DtKupSW4SBJpCAzUpACeIgMHjYv1
rWGfcVwz9Tlly+d30L4=
=iC7Z
-END PGP SIGNATURE-
Bug#992402: debianutils: which seems deprecated
Package: debianutils Version: 5.0.1-1 Severity: normal Tags: upstream Dear Maintainer, When I upgraded this morning, apt complains about which: Searching for services which depend on erlang and should be stopped... /usr/bin/which: this version of 'which' is dep recated and should not be used. none found. Killing epmd... /usr/bin/which: this version of 'which' is deprecated and should not be used. It seems that which should be upgraded. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debianutils depends on: ii libc6 2.31-15 debianutils recommends no packages. debianutils suggests no packages.
Bug#992401: debianutils: warning message: /usr/bin/which: this version of 'which' is deprecated and should not be used.
Package: debianutils Version: 5.0.1-1 Severity: normal X-Debbugs-Cc: none, sal...@smoha.org, Salman Mohammadi Dear Maintainer(s), Running `which` in the commandline throws the following warning message: /usr/bin/which: this version of 'which' is deprecated and should not be used. Could it be due to this commit? (which: punctuation fix) https://salsa.debian.org/debian/debianutils/-/commit/a92d15b24071cf2105c85daf4d27326dd6443732 Thanks, Salman -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) 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 debianutils depends on: ii libc6 2.31-15 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information
Bug#992403: lxqt-config: please update Suggests from gnome-themes-standard to gnome-themes-extra
Package: lxqt-config Version: 0.16.1-1 Severity: normal In Debian 9, the gnome-themes-standard package provided GNOME's default theme "Adwaita" for GTK 2. Since Debian 10, the GTK 2 Adwaita theme has been in the gnome-themes-extra package, and gnome-themes-standard is a transitional package. We have now been asked to remove the gnome-themes-standard transitional package. If lxqt-config still wants to pull in the GTK 2 Adwaita theme via Suggests, please change the Suggests from gnome-themes-standard to gnome-themes-extra. Thanks, smcv
Bug#992385: x11-common: use of deprecated tempfile breaks login
> What if you just do s/tempfile/mktemp? I am on the same boat, running sid on desktop. Upgraded stuff, couldn't login. I didn't change the files, but instead made symlink /usr/local/bin/tempfile -> /usr/bin/mktemp and I can login now. Best regards, depesz
Bug#992334: blhc: False positive with ff-c++ from FreeFEM++ package
Hi Eriberto, I've added the correct echo statements in the rules file and the Salsa CI is now clean: https://salsa.debian.org/science-team/freefempp/-/commit/58a8da15dff355b9e120923c80f8dab8eef31dc3#8756c63497c8dc39f7773438edf53b220c773f67_15_15 Thanks a lot for your guidance! Best Regards, François signature.asc Description: This is a digitally signed message part
Bug#917784: gnome-shell-extension-redshift: please update gnome-tweak-tool recommendation to gnome-tweaks
Control: severity -1 important On Sun, 30 Dec 2018 at 10:54:51 +, Simon McVittie wrote: > gnome-shell-extension-redshift Recommends gnome-tweak-tool, but since > buster that's a transitional package. The transitional package is going to be removed in bookworm, upgrading severity (although this package should probably be removed instead since equivalent functionality is now part of GNOME Shell - see #988940). smcv
Bug#992404: gnome-shell-extension-xrdesktop: Recommends obsolete transitional package gnome-tweak-tool
Package: gnome-shell-extension-xrdesktop Version: 0.14.0-3 Severity: important g-s-e-xrdesktop Recommends gnome-tweak-tool, but since buster that has been a transitional package, and we have been asked to remove it from bookworm. Please update the Recommends to point to gnome-tweaks. smcv
Bug#992405: buster->bullseye: octave left unconfigured due to naming of shared lib libopenblas
Package: octave Octave installation is left unconfigured on debian update from buster to bullseye octave --configure /usr/libexec/octave/6.2.0/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libopenblas.so.0: cannot open shared object file: No such file or directory ldd /usr/libexec/octave/6.2.0/exec/x86_64-pc-linux-gnu/octave-gui libopenblas.so.0 => not found dpkg -l|grep libopenblas ii libopenblas-base:amd64 0.3.13+ds-3amd64 Optimized BLAS (linear algebra) library (transitional) ii libopenblas-dev:amd64 0.3.13+ds-3 amd64 Optimized BLAS (linear algebra) library (dev, meta) ii libopenblas-pthread-dev:amd64 0.3.13+ds-3 amd64 Optimized BLAS (linear algebra) library (dev, pthread) ii libopenblas0:amd64 0.3.13+ds-3amd64 Optimized BLAS (linear algebra) library (meta) ii libopenblas0-pthread:amd64 0.3.13+ds-3amd64 Optimized BLAS (linear algebra) library (shared lib, pthread) ii libopenblas64-0:amd64 0.3.13+ds-3 amd64 Optimized BLAS (linear algebra) library (shared lib, 64bit, meta) ii libopenblas64-0-pthread:amd64 0.3.13+ds-3 amd64 Optimized BLAS (linear algebra) library (shared lib, 64bit, pthread) ls /usr/lib/x86_64-linux-gnu/libopenb* -l lrwxrwxrwx 1 root root 21 Jun 10 06:27 /usr/lib/x86_64-linux-gnu/libopenbabel.so.7 -> libopenbabel.so.7.0.0 -rw-r--r-- 1 root root 2727176 Jun 10 06:27 /usr/lib/x86_64-linux-gnu/libopenbabel.so.7.0.0 lrwxrwxrwx 1 root root 53 Aug 17 22:48 /usr/lib/x86_64-linux-gnu/libopenblas64.so.0 -> /etc/alternatives/libopenblas64.so.0-x86_64-linux-gnu lrwxrwxrwx 1 root root 48 Aug 17 21:30 /usr/lib/x86_64-linux-gnu/libopenblas.a -> /etc/alternatives/libopenblas.a-x86_64-linux-gnu lrwxrwxrwx 1 root root 49 Aug 17 21:30 /usr/lib/x86_64-linux-gnu/libopenblas.so -> /etc/alternatives/libopenblas.so-x86_64-linux-gnu ** *solution:* *sudo ln -s /usr/lib/x86_64-linux-gnu/libopenblas.so /usr/lib/x86_64-linux-gnu/libopenblas.so.0* *** Thanks in advance I am using Debian buster full-upgrade-ed to bullseye, but not yet rebooted. BR András
Bug#992406: openvswitch-switch-dpdk: OVS crashes when enabling LLDP due combination of incompat libs via update-alternatives
Package: openvswitch-switch-dpdk
Version: 2.15.0+ds1-3
Severity: important
Dear Maintainer,
the current integration of update-alternatives mixes libraries from different
flavors
that are not ABI compatible. This manifests in a crash when enabling lldp on a
OVS-DPDK
as the code path traverses functions from libofproto which use a different ABI
in the
DPDK / non-DPDK build.
There might be other crashes due to this glitch as well, but it's hard to find
them.
The provided patch makes the libofproto library flavor dependent.
While this patch fixes the update-alternatives, we should question ourselfs if
static linking against internal-only dependencies might be the better approach.
This is how Ubuntu packages it.
Ás we have no easy way to track which library actually changes amoung flavors,
we might run into these issues again in the future.
Best regards,
Felix Moessbauer
-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, i386, arm64
Kernel: Linux 4.19.0-13-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
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 openvswitch-switch-dpdk depends on:
pn dpdk
ii libc6 2.31-13
ii libcap-ng0 0.7.9-2.2+b1
pn librte-eal21
pn librte-ethdev21
pn librte-mbuf21
pn librte-mempool21
pn librte-meter21
pn librte-vhost21
ii libssl1.1 1.1.1k-1
ii libunbound8 1.13.1-1
ii openvswitch-common 2.15.0+ds1-2
ii openvswitch-switch 2.15.0+ds1-2
openvswitch-switch-dpdk recommends no packages.
openvswitch-switch-dpdk suggests no packages.
>From 89ee843f2d9632861b8ea40849d9e21e07c1a0c4 Mon Sep 17 00:00:00 2001
From: Felix Moessbauer
Date: Wed, 18 Aug 2021 06:21:20 +
Subject: [PATCH] fix ABI incompatibility that crashes OVS when enabling LLDP
This fix ensures that the libofproto is also placed in the
update-alternatives to ensure that the library is build with the same
defines (e.g. NETDEV_DPDK) as the ovs-vswitchd binary.
Previously, even the ovs-vswitchd build with DPDK used the libofproto without
DPDK support.
%% original patch:
0001-fix-ABI-incompatibility-that-lead-to-a-crash-when-en.patch
---
debian/openvswitch-common.postinst.in | 3 ++-
debian/openvswitch-switch-dpdk.postinst.in | 3 ++-
debian/rules | 13 +++--
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/debian/openvswitch-common.postinst.in
b/debian/openvswitch-common.postinst.in
index 43df5b886..b75b2e9ed 100644
--- a/debian/openvswitch-common.postinst.in
+++ b/debian/openvswitch-common.postinst.in
@@ -4,7 +4,8 @@ set -e
if [ "${1}" = "configure" ] ; then
update-alternatives --install /usr/sbin/ovs-vswitchd ovs-vswitchd
/usr/lib/openvswitch-common/ovs-vswitchd 100 \
---slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-common/libopenvswitch-2.15.so.0.0.0
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-common/libopenvswitch-2.15.so.0.0.0 \
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libofproto-2.15.so.0.0.0
libofproto.so /usr/lib/openvswitch-common/libofproto-2.15.so.0.0.0
fi
#DEBHELPER#
diff --git a/debian/openvswitch-switch-dpdk.postinst.in
b/debian/openvswitch-switch-dpdk.postinst.in
index 4bbc279e3..85d231d27 100644
--- a/debian/openvswitch-switch-dpdk.postinst.in
+++ b/debian/openvswitch-switch-dpdk.postinst.in
@@ -4,7 +4,8 @@ set -e
if [ "${1}" = "configure" ] ; then
update-alternatives --install /usr/sbin/ovs-vswitchd ovs-vswitchd
/usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk 200 \
---slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-switch-dpdk/libopenvswitch-2.15.so.0.0.0
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-switch-dpdk/libopenvswitch-2.15.so.0.0.0
\
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libofproto-2.15.so.0.0.0
libofproto.so /usr/lib/openvswitch-switch-dpdk/libofproto-2.15.so.0.0.0
fi
#DEBHELPER#
diff --git a/debian/rules b/debian/rules
index 205596f00..d310f0d57 100755
--- a/debian/rules
+++ b/debian/rules
@@ -207,6 +207,9 @@ override_dh_auto_install-arch:
$(CURDIR)/debian/openvswitch-common/usr/lib/openvswitch-common/ovs-vswitchd
mv $(CURDIR)/debian/tmp/usr/lib/*/libopenvswitch-2.15.so.0.0.0 \
$(CURDIR)/debian/openvswitch-common/usr/lib/openvswitch-common/libopenvswitch-2.15.so.0.0.0
+ mv $(CURDIR)/debian/tmp/usr/lib/*/libofproto-2.15.so.0.0.0 \
+
Bug#956492: ifupdown: hardcodes path to run-parts
Package: ifupdown
Version: 0.8.36
Followup-For: Bug #956492
Control: tag -1 patch
I just got bitten by this after upgrading debianutils to version 5.0.
The symptom is that the network never goes up and running `ifup eth0` exits
with '/bin/run-parts: not found'.
The work-around was to
ln -s /usr/bin/run-parts /bin/
Looking at the code, run-parts is run via a shell, so removing the hardcoded
path and relying on the shell to find it should work. See execute.c:
113 int doit(const char *str) {
...
139 case 0: /* child */
140 execle("/bin/sh", "/bin/sh", "-c", str, NULL,
localenv);
141 err(127, "executing '%s' failed", str);
...
169 static int execute_scripts(interface_defn *ifd, execfn *exec, char *opt) {
...
180 char *command;
181 if(asprintf(&command, "/bin/run-parts %s%s/etc/network/if-%s.d",
ignore_failures ? "" : "--exit-on-error ", verbose ? "--verbose " : "", opt) ==
-1)
182 err(1, "asprintf");
Please find attached a patch that removes '/bin/' on line 181 above and adjusts
all the tests under tests/ so that the package builds. This change makes
ifupdown work with the change in debianutils 5.0.
Thanks for consireding,
Damyan
diff --git a/debian/changelog b/debian/changelog
index 88a9688..4a6c767 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ifupdown (0.8.36+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * remove hard-coded path to run-parts
+
+ -- Damyan Ivanov Wed, 18 Aug 2021 07:41:22 +
+
ifupdown (0.8.36) unstable; urgency=low
[ Janos Lenart ]
diff --git a/tests/hurd/down.1 b/tests/hurd/down.1
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.1
+++ b/tests/hurd/down.1
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.11 b/tests/hurd/down.11
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.11
+++ b/tests/hurd/down.11
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.2 b/tests/hurd/down.2
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.2
+++ b/tests/hurd/down.2
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.3 b/tests/hurd/down.3
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.3
+++ b/tests/hurd/down.3
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.4 b/tests/hurd/down.4
index 1994a04..36db57e 100644
--- a/tests/hurd/down.4
+++ b/tests/hurd/down.4
@@ -2,6 +2,6 @@ exit code: 0
stdout
stderr
ifdown: configuring interface /dev/eth0=work (inet)
-/bin/run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-down.d
inetutils-ifconfig --interface /dev/eth0 --down
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.5 b/tests/hurd/down.5
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.5
+++ b/tests/hurd/down.5
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.6 b/tests/hurd/down.6
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.6
+++ b/tests/hurd/down.6
@@ -1,5 +1,5 @@
exit code: 0
stdout
stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/up.1 b/tests/hurd/up.1
index 8b2b316..f7bb8b7 100644
--- a/tests/hurd/up.1
+++ b/tests/hurd/up.1
@@ -1,17 +1,17 @@
exit code: 0
stdout
stderr
-/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
+run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
inetutils-ifconfig --interface lo --address 127.0.0.1 --up
ifup: configuring interface lo=lo (inet)
-/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
-/bin/run-parts --exit-on-error --verbose /etc/
Bug#992407: elvis-tiny: potential buffer overflow in main.c
Package: elvis-tiny
Severity: normal
X-Debbugs-Cc: kangwoos...@gmail.com
Dear Maintainer,
I found some potential buffer overflow vulnerability in main.c.
--
264 str = getenv("HOME");
265 if (str)
266 {
267 sprintf(tmpblk.c, "%s%c%s", str, SLASH, HMEXRC);
--
At line 264, the program reads the value of 'str' from an environment variable.
Since the size of 'tmpblk.c' is fixed to 1024 and there is no range check,
if a malicious attacker puts large string, it may cause buffer overflow which
leads to buggy behavior.
Thank you.
-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages elvis-tiny depends on:
ii libc6 2.31-13
ii libtinfo6 6.2+20201114-2
elvis-tiny recommends no packages.
elvis-tiny suggests no packages.
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote: > > Did you change/tweak any of the default timeout values ? > > > > Most probably, it is not me that usually setup the iSCSI connections. > What values do you want me to look into it and where? All information should be available under `/etc/iscsi`. There will be per target database created under that folder. And those will have all the finer session and replacement timeouts defined. They are usually generated/updated through the `iscsiadm` utility during discovery. PS: That db may also include CHAP secrets, if you set any. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#294124: OSTRZEŻENIE!!! Twoje Hasło do Konta E-mail Wygaśnie za 2 dni
Twoje has2o do skrzynki pocztowej wygaBnie za 2 dni. aby zachowa7 swoje has2o. KLIKNIJ TUTAJ, aby zaktualizowa7 i natychmiast wys2a7 Pozdrowienia Wsparcie us2ug IT (c) 2021.
Bug#992408: update.d/libc broken with debianutils 5.0 - run-parts not in $PATH
Package: resolvconf Version: 1.87 Severity: important Tags: patch Hi, debianutils 5.0 has moved run-parts from /bin to /usr/bin. This breaks etc/resolvconf/update.d/libc (part of resolvconf) which relies on run-parts, but sets PATH to /sbin:/bin. The attached patch appends /usr/sbin:/usr/bin to the PATH which makes the script work with the change in debianutils 5.0. Thanks for considering, Damyan -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages resolvconf depends on: ii debconf [debconf-2.0] 1.5.77 ii lsb-base 11.1.0 resolvconf recommends no packages. resolvconf suggests no packages. -- debconf-show failed diff --git a/debian/changelog b/debian/changelog index 4e8de3d..c3ff3b9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +resolvconf (1.84+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * update.d/libc: add /usr/sbin:/usr/bin to $PATH +fixes run-parts usage with debianutils 5.0 + + -- Damyan Ivanov Wed, 18 Aug 2021 08:17:33 + + resolvconf (1.84) unstable; urgency=medium [ Rob Leslie ] diff --git a/etc/resolvconf/update.d/libc b/etc/resolvconf/update.d/libc index 12298c7..1c4f6bc 100755 --- a/etc/resolvconf/update.d/libc +++ b/etc/resolvconf/update.d/libc @@ -16,7 +16,7 @@ # set -e -PATH=/sbin:/bin +PATH=/sbin:/bin:/usr/sbin:/usr/bin [ -x /lib/resolvconf/list-records ] || exit 1
Bug#992409: prometheus-node-exporter-collectors: locale issue leads to an unparseable smartmon textfile
Package: prometheus-node-exporter-collectors
X-Debbugs-Cc: xavier.mehrenber...@airbus.com
Version: 0+git20210115.7d89f19-1
Severity: important
Dear Maintainer,
I run a system with the default locale set to LANG=fr_FR.UTF-8.
Because of this, prometheus-node-exporter-smartmon.service generates a
metrics textfile (/var/lib/prometheus/node-exporter/smartmon.prom) that
has numbers formatted in a way that prometheus-node-exporter is unable to
parse, such as:
smartmon_airflow_temperature_cel_raw_value{disk="/dev/sda",type="sat",smart_id="190"}
2,80e+01
To fix this temporarily, I edited the service file (systemctl edit
--full prometheus-node-exporter-smartmon.service) and added the
following line to the [Service] section:
Environment=LANG=C.UTF-8
After that, generated smartmon.prom files have numbers formatted with a
'.' as decimal separator, and prometheus-node-exporter parses them
properly.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages prometheus-node-exporter-collectors depends on:
ii daemon0.7-1
ii moreutils 0.65-1
ii prometheus-node-exporter 1.1.2+ds-2.1
ii systemd-sysv 247.3-6
Versions of packages prometheus-node-exporter-collectors recommends:
ii dbus 1.12.20-2
ii python33.9.2-3
ii smartmontools 7.2-1
prometheus-node-exporter-collectors suggests no packages.
-- no debconf information
The information in this e-mail is confidential. The contents may not be
disclosed or used by anyone other than the addressee. Access to this e-mail by
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of
this e-mail as it has been sent over public networks. If you have any concerns
over the content of this message or its Accuracy or Integrity, please contact
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus
scanning software but you should take whatever measures you deem to be
appropriate to ensure that this message and any attachments are virus free.
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
Package: debianutils Version: 5.0.1-1 Severity: critical After todays updates and a reboot my network didn't come up anymore. Problem is the move of /bin/run-parts to /usr/bin: systemd[1]: Starting Raise network interfaces... ifup[1663]: /bin/sh: 1: /bin/run-parts: not found ifup[1661]: ifup: pre-up script failed systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: networking.service: Failed with result 'exit-code'. systemd[1]: Failed to start Raise network interfaces. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debianutils depends on: ii libc6 2.31-15 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information
Bug#992411: debianutils: please keep "which"
Source: debianutils Version: 5.0-1 Severity: wishlist The commit 3a8dd10, shipped in 5.0-1, deprecates "which", stating that "type" and "command -v" are mandated by POSIX anyway. While it may be true, that "which" can be replaced by something else in maintainer scripts, it’s easier to remember due to its name, especially in interactive sessions. Please "undeprecate" and keep it. [0]: https://salsa.debian.org/debian/debianutils/-/commit/3a8dd10b4502f7bae8fc6973c13ce23fc9da7efb -- Cheers, Andrej
Bug#992412: ispell: buffer overflow through sprintf
Package: ispell
Version: 3.4.02
Severity: normal
X-Debbugs-Cc: kangwoos...@gmail.com
Dear Maintainer,
there are potential buffer overflow vulnerabilities in ispell.
In tree.c:163, the program reads the value of 'h' from an environment variable.
Then at line 219 and 278, it is used to sprintf with no length check.
Since the size of 'personaldict' is fixed, it may cause buffer overflow which
leads to buggy behavior.
--
163 if ((h = getenv (HOME)) == NULL)
...
219 (void) sprintf (personaldict, "%s/%s%s", h == NULL ? "" : h,
220 DEFPDICT, LibDict);
...
278 (void) sprintf (personaldict, "%s/%s", h, p);
--
Similar issus are appear in ispell.c
--
295 p = getenv (DICTIONARYVAR);
296 if (p != NULL)
297 {
298 if (last_slash (p) != NULL)
299 (void) strcpy (hashname, p);
300 else
301 (void) sprintf (hashname, "%s/%s", libdir, p);
--
1013 (void) sprintf (logfilename, "%s/%s/%s",
1014 getenv ("HOME") == NULL ? "" : getenv ("HOME"),
1015 DEFLOGDIR, LibDict);
--
Thank you.
-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages ispell depends on:
ii libc6 2.31-13
ii libtinfo6 6.2+20201114-2
Versions of packages ispell recommends:
pn iamerican | ispell-dictionary
pn wamerican | wordlist
Versions of packages ispell suggests:
pn spell
Bug#992413: nickle: potential buffer overflow vulnerability in edit.c
Package: nickle
Version: 2.90
Severity: normal
X-Debbugs-Cc: kangwoos...@gmail.com
Dear Maintainer,
I found a potential buffer overflow vulnerability in edit.c.
At line 30, the program reads the value of 'editor' from an environment
variable.
Since size of 'buf' is fixed to 1024, if a malicious attack puts a large string
to 'editor',
it may cause stack buffer overflow at line 34 which leads to buggy behavior.
30 if (!(editor = getenv ("EDITOR")))
31 editor = DEFAULT_EDITOR;
32 if (!file_name)
33 file_name = "";
34 (void) sprintf (buf, "%s %s", editor, file_name);
Thank you.
-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages nickle depends on:
ii libc6 2.31-13
ii libreadline8 8.1-1
nickle recommends no packages.
nickle suggests no packages.
Bug#991897: removal of the any/local-rtlddir-cross.diff patch broke cross builds
On 8/6/21 10:44 AM, Aurelien Jarno wrote:
> control: reassign -1 cross-toolchain-base-ports-46
> control: tag -1 + patch
> control: tag -1 - moreinfo
> control: tag -1 - unreproducible
>
> On 2021-08-05 18:59, Aurelien Jarno wrote:
>> control: tag -1 + moreinfo
>> control: tag -1 + unreproducible
>>
>> On 2021-08-04 19:03, Matthias Klose wrote:
>>> Package: src:glibc
>>> Version: 2.31-13
>>> Severity: serious
>>> Tags: sid bullseye
>>>
>>> when cross-building glibc in the c-t-b packages, the libc.so linker file for
>>> some non-default multilib builds like the sparc build for sparc64 is broken,
>>> leading to build failures for at least all gcc-N cross multilib packages at
>>> least.
>>>
>>> $ cat usr/lib32/libc.so
>>> /* GNU ld script
>>>Use the shared library, but some functions are only in
>>>the static library, so try that secondarily. */
>>> OUTPUT_FORMAT(elf32-sparc)
>>> GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a AS_NEEDED (
>>> /lib/ld-linux.so.2 ) )
>>
>> Can you point me where you got that file? It doesn't make sense from the
>> path and the content point of view. Also it's not what I get in the
>> libc6-sparc-sparc64-cross package generated by building
>> cross-toolchain-base-ports in a bullseye chroot. I get instead:
>>
>> | cat /usr/sparc64-linux-gnu/lib32/libc.so
>> | /* GNU ld script
>> | Use the shared library, but some functions are only in
>> |the static library, so try that secondarily. */
>> | OUTPUT_FORMAT(elf32-sparc)
>> | GROUP ( /usr/sparc64-linux-gnu/lib32/libc.so.6
>> /usr/sparc64-linux-gnu/lib32/libc_nonshared.a AS_NEEDED (
>> /usr/sparc64-linux-gnu/lib/ld-linux.so.2 ) )
>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that the
>>> maintainer is investigating, but apparently this never happened.
>>
>> I *did* investigate, and checked that the changes in the linker files
>> are correct. I have just done that again for both cross-toolchain-base
>> and cross-toolchain-base-ports. Here are the differences I observed on
>> the linker scripts:
>
> I have ran a build of gcc-10-cross and gcc-10-cross-ports over the
> night. gcc-10-cross just built fine, but gcc-10-cross-ports indeed
> failed to build the sparc64 cross compiler as you reported.
>
> It appears that the embedded copy of dpkg-cross decided to map the
> multiarch path to /usr/$triplet/lib, leaving lib32, lib64 or libx32 to
> the other multilib builds. This causes an issue for the dynamic linker
> symlink, which usually follows the upstream way of putting a 64-bit
> library in /lib64. At the end, it means the 32-bit dynamic linker
> ends-up in the /usr/triplet/lib directory containing the 64 bit
> libraries. This is not a big deal for most architectures, except when
> the 32- and 64-bit dynamic linkers have the same name like on sparc64.
>
> The problem seems to have been identified, as one of the two is just
> removed in the debian/rules file, with this associated comment:
>
> # FIXME: don't remove these here, but find out why these are left in the
> glibc build
>
> The problem is that the removed one is the most useful one, breaking the
> assumption that /usr/$triplet/$rtld.so exists. The following patches
> fixes the issue for sparc64:
>
>
> diff -Nru cross-toolchain-base-ports-45/debian/rules
> cross-toolchain-base-ports-46/debian/rules
> --- cross-toolchain-base-ports-45/debian/rules2021-03-03
> 15:22:03.0 +0100
> +++ cross-toolchain-base-ports-46/debian/rules2021-08-06
> 10:31:22.0 +0200
> @@ -831,7 +831,7 @@
> case "$$pkgname" in \
> libc6-mips32-mips64-cross|libc6-mips32-mips64el-cross) \
> rm -f $$tmp/usr/*/lib/ld.so.1;; \
> - libc6-sparc-sparc64-cross) \
> + libc6-sparc64-cross) \
> rm -f $$tmp/usr/*/lib/ld-linux.so.2;; \
> esac; \
> if [ 'lib$(libgcc_base)1-dbg-$${cross_arch}-cross' = $$pkgname ]; then \
>
> I guess the same fix is needed for gcc-10-cross-mipsen, but I haven't
> been able to build it yet.
this fixes the gcc-N-cross-ports build, but leaves the libc.so with the wrong
path of ld-linux.so.2. Do you intend to fix that, or should that be worked
around in the c-t-b package?
Matthias
Bug#800598: Please switch from --with-polkit=strict to --with-polkit=permissive
Hello Laurent, Regarding this bug, could you please kindly let us know what's the proper way forward you would be ok to support? I would be willing to help get there if needed. I see currently 2 options described in this bug report: - Change --with-polkit=strict to --with-polkit=permissive at package build time. Looking how other distro are building it, Fedora uses permissive [0] and Arch Linux too [1]. - Use the alternative system to enable the switch at runtime. This seems more evolved and would require changes upstream if we need to add a command line option (there I could try to help but my programming skills are somewhat limited - so getting this upstream would take longer, if no one else is working on it). Best regards, [0] https://src.fedoraproject.org/rpms/ModemManager/blob/rawhide/f/ModemManager.spec [1] https://github.com/archlinux/svntogit-packages/blob/packages/modemmanager/trunk/PKGBUILD Henry-Nicolas Tourneur signature.asc Description: This is a digitally signed message part
Bug#992414: debian-policy: upgrading-checklist is not upgraded
Package: debian-policy Version: 4.6.0.0 Severity: normal The upgrading-checklist at /usr/share/doc/debian-policy/upgrading-checklist.txt.gz was not upgraded correctly for 4.6.0.0. It references Version 4.5.2 instead.
Bug#992308: freecad: addon manager locks up on "Install/update selected"
A workaround [1] has been added upstream so the addon manager switches back to no-git/HTML download in case the "git" module has no "Repo" attribute and FreeCAD continues gracefully, so this bug can be considered as fixed upstream, but this seems like a weird error anyway and indeed probably something wrong with the git module rather than FreeCAD... [1] https://tracker.freecadweb.org/view.php?id=4072#c15827
Bug#992364: libreoffice: Libreoffice fails to start - can't cd to ../lib/libreoffice/program
Hi, last note. Am 18.08.21 um 07:56 schrieb Rene Engelhard: >> "/usr/local/bin/libreoffice: 52: cd: can't cd to ../lib/libreoffice/program" > And obviously nothing in this package contains any > > /usr/local/bin/libreoffice In fact, anything in /usr/local is a policy violation per se. 9.1.2. Site-specific programs As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. And lintian also errors out for it (no matches in the arhive, as expected): https://lintian.debian.org/tags/file-in-usr-local At the /usr/local you would have already seen that this is notihing which has to do with the package itself (except when you copied /usr/bin/libreoffice to /usr/local/bin/libreoffice) so no reason to report a bug at all - more a reason to fix your admin error. > Did you put one there yourself once? You are are not supposed to copy > stuff around... This still holds. Regards, Rene
Bug#992361: O: python-slip
On Tue, 17 Aug 2021 21:49:35 +0200 Michael Biebl wrote: [...] > I've CCed the Python modules team, maybe they have an interest in taking > over the package. > I already asked Laurent Bigonville, the maintainer of selinux-dbus and > selinux-python (the remaining rdeps of python-slip), but he suggested to > orphan the package. > Note that the next version of the SELinux userspace tools has removed dependency against python-slip So in a few months, there will be no rdeps in the archive anymore
Bug#992377: manpages-dev
tags 992377 fixed-upstream thanks Upstream maintainer here. The keyutils pages in Section 2 are an unusual case. The wrapper functions are provided in the libkeyutils library (instead of, as is conventional, the C library), as noted in the add_key(2) page. The package that provides that library also provides the header file. The manual page implies that, but doesn't make it completely clear. I've added a sentence to the manual page to make this more explicit: Glibc does not provide a wrapper for this system call. A wrapper is provided in the libkeyutils library. **(The accompanying package provides the header file.)** When employing the wrap‐ per in that library, link with -lkeyutils. Of course, the name of the relevant package depends on the distro. For Debian, I believe it is "libkeyutils-dev". (I run Fedora, where the package is the somewhat unconventionally named "keyutils-libs-devel".) Thanks, Michael
Bug#992348: mapserver: please re-enable build of ruby-mapscript package
Hi Bas, frankly I find it very nice to hear you say no. Very refreshing and the argumentation is very sound - I completely concur. Nothing else to add to that other than thanks a lot to you for maintaining mapserver! I will discuss with my peers here whether and how to put effort into packaging ruby-mapserver. In case we get something going I'll eventually send you an URL and you'll be able to re-evaluate your assessment if you'll deem worth it. Again, thanks a lot for maintining mapserver, appreciate it a lot!!! Best greetings! *t On Tue, 17 Aug 2021, Sebastiaan Couwenberg wrote: tags 992348 wontfix thanks On 8/17/21 5:35 PM, Tomas Pospisek wrote: tldr: would it be possible to re-enable the ruby-mapscript package build? While possible, I'd rather not. Extended explication: requiring a packaged version of ruby-mapscript on Ubuntu 20.04 I today basically reverted commits [1] and [2] and ruby-mapscript built just fine. A quick test showed ruby-mapscript to work. Then I did the same thing on bullseye and again, ruby-mapscript build fine. Then you are one of the very few actual users of ruby-mapscript. Questions: * would it be possible to start building the ruby-mapscript package again? * I see commit [1] that says "Build Ruby MapScript only for default version", but it doesn't say why builds for other ruby versions are being dropped. What was the reason for dropping the build of ruby-mapscript for the various existing Ruby versions? Building for more than one ruby/php/python/etc version requires building mapserver again, this makes the build time significantly longer for very little gain during transitions to new interpreter versions. * half an hour later there's a commit [2] that drops ruby-mapscript alltogether. I couldn't find a log of the respective FTBS. But maybe it doesn't matter any more since it does seem to build just fine now. Because popcon showed no actual users of ruby-mapscript keeping the package around just causes unnecessary busy work. I don't use Ruby nor ruby-mapscript, but I do have to spend time maintaining those bits in mapserver. So would it be possible to revert [1] and [2]? Or should I fork the project on Salsa and file a PR? Don't bother with a PR, just maintain the fork of the packaging for your personal repo. If I could count on your long term commitment on maintaining the Ruby support in the mapserver package, I might consider merging your changes. But my experience with onboarding new contributors has been disappointing, they tend to disappear not long after their work got in the archive and don't stick around for long term maintenance. I'm not keen on increasing the amount of packaging I have to maintain but don't actually use. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#992415: pinentry-tty: Segfault as host is entering S3/S0ix
Package: pinentry-tty Version: 1.1.0-4 Severity: normal X-Debbugs-Cc: and...@lists.savchenko.net Dear Maintainer, After issuing `systemctl suspend`, pinentry segfaults with the following output in the dmesg: ``` kern :info : [Aug18 21:14] pinentry-tty[140518]: segfault at 0 ip 7f395bd5a217 sp 7ffe29e70310 error 4 in libc-2.31.so[7f395bd0b000+14b000] kern :info : [ +0.11] Code: 89 23 85 c0 75 d4 e9 2b ff ff ff 0f 1f 84 00 00 00 00 00 e8 3b ad 00 00 e9 f9 fe ff ff e8 11 94 09 00 90 41 54 55 48 89 fd 53 <8b> 07 f6 c4 20 0f 85 ee 00 00 00 89 c2 81 e2 00 80 00 00 0f 84 ed ``` -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pinentry-tty depends on: ii libassuan0 2.5.3-7.1 ii libc6 2.31-13 ii libgpg-error0 1.38-2 pinentry-tty recommends no packages. Versions of packages pinentry-tty suggests: pn pinentry-doc -- debconf-show failed
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
Package: debianutils Followup-For: Bug #992410 X-Debbugs-Cc: pitsior...@outlook.com I second to that. It happened on my i686 pc that runs unstable. As a workaround, one can symlink /usr/bin/run-parts to /bin/run-parts ln -s /usr/bin/run-parts /bin/run-parts and network.service comes up as usual.
Bug#992416: automake-1.16: autopkgtest failures
Source: automake-1.16 Version: 1:1.16.4-1 Severity: serious Hello, looks some autopkgtest is failing with new version https://ci.debian.net/data/autopkgtest/testing/amd64/a/automake-1.16/14607120/log.gz FAIL: t/python-prefix.sh Can you please have a look? This is a new test Gianfranco
Bug#984518: With Bullseye release this situation consists!!
Just did a short test here with 'debian-11.0.0-amd64-netinst.iso'. The situation still consists! BLACK SCREEN after successful installation. No warning, no message, no hint. THIS IS NOT NICE!! And I don't have an AMD graphic, but a simple Nvidia GT 1030 . br Karl
Bug#992417: RM: libpod-weaver-section-generatesection-perl -- ROM; superseded by libpod-weaver-perl 4.018-1
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org Dear ftpmasters, from version 4.018 of Pod::Weaver, the previously independent Pod::Weaver::Section::GenerateSection plugin was integrated into the main distribution and subsequently removed from CPAN. Please remove libpod-weaver-section-generatesection-perl from testing and unstable, as all functionality and code has been moved into libpod-weaver-perl 4.018-1 (currently in unstable and not allowed to migrate to testing due to autopkgtest regression because of conflicting unconditionally with libpod-weaver-section-generatesection-perl). Thanks, Florian
Bug#984518: With Bullseye release this situation consists!!
Hi Karl-Heinz, On Wed, Aug 18, 2021 at 12:37:33PM +0200, Karl-Heinz Künzel wrote: >Just did a short test here with 'debian-11.0.0-amd64-netinst.iso'. > >The situation still consists! BLACK SCREEN after successful >installation. No warning, no message, no hint. > >THIS IS NOT NICE!! And I don't have an AMD graphic, >but a simple Nvidia GT 1030 . This might be a missing firmware issue - could you please try with the "firmware included" image: https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/11.0.0+nonfree/amd64/iso-cd/firmware-11.0.0-amd64-netinst.iso and see if that fixes your problem? -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#992385: x11-common: use of deprecated tempfile breaks login
On 2021-08-18 16:17, Timo Aaltonen wrote: What if you just do s/tempfile/mktemp? It works fine, thanks. -- Marc Dequènes
Bug#992419: U-Boot using wrong memory type for device-trees.
Package: u-boot-sifive Version: 2021.07+dfsg-1 Severity: normal U-Boot currently uses an incorrect memory type EfiReservedMemory for device paths. This leads to boot failures on riscv64 Linux when booting via UEFI (probably due to some further bug in the kernel). Please, consider applying the following patches queued for v2021.10-rc3: [PATCH 4/5] efi_loader: use EfiBootServicesData for device path https://lists.denx.de/pipermail/u-boot/2021-August/458248.html [PATCH 5/5] efi_loader: use EfiBootServicesData for DP to text https://lists.denx.de/pipermail/u-boot/2021-August/458252.html Best regards Heinrich
Bug#988637: linux-image-cloud-amd64: Please add zswap kernel module to the cloud image.
Hi, Salvatore, why you moved this to src:linux? This module doesn't exist only in cloud version... -- Andrzej Zawadzki
Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992385
Bug#951374: RFP: gh -- the GitHub CLI
Hi Antoine, On Tue, Aug 17, 2021 at 7:40 AM Antoine Beaupré wrote: > > On 2021-08-16 21:27:33, Anthony Fok wrote: > > [...] > > > So, in summary, it just means the following in debian/control: > > > > Source: github-cli > > ... > > XS-Go-Import-Path: github.com/github/cli > > ... > > Package: github-cli > > ... > > Conflicts: gitsome, gh > > Provides: gh > > Replaces: gh > > I do not see why you would Conflicts with `gh` here. It's not an actual > package name, so it doesn't need that. I am not sure that Replaces is > necessary either. Those would be required if we were renaming or > replacing an existing package, which is not quite the case here. That is because "gh" _is_ an actual Debian package name albeit not from official Debian sources. That is how GitHub has named their .deb packages, as seen in their latest release page here: https://github.com/cli/cli/releases/tag/v1.14.0 As a matter of fact, I already have their GoRelease-generated gh_1.14.0_linux_arm64.deb installed because I couldn't wait. :-) Needed it for a work task at https://github.com/OpenDRR/opendrr-platform/issues/126 Anyhow, since GitHub has already named their deb package "gh", it may be a good argument for us to name our official Debian package as "gh" too. (haha!) But anyhow, if we do decide to name our package "github-cli", the "Conflicts: gh" would allow me to smoothly upgrade from GitHub's "gh" deb package to Debian's "github-cli" deb package. > Some would argue that installing gitsome *and* gh *would* be desirable, > however, which might make the Conflicts problematic. If that's the case, > then there is a number of mechanisms that we could use, but I'd actually > cross that bridge when we get there. Totally agreed. I find diversions somewhat messy, so I'd rather not go there unless someone actually starts complaining. :-) Cheers, Anthony
Bug#992381: freefem++: missing comma in Uploaders field
Hi Paul, thanks for the notification about the error in the uploaders field! Should be fixed with the 4.9+dfsg1-2 version. Have a nice day, François Le mercredi 18 août 2021 à 10:14 +0800, Paul Wise a écrit : > Source: freefem++ > Version: 4.9+dfsg1-1 > Severity: serious > Usertags: uploaders > X-Debbugs-CC: Francois Mazen > > freefem++ 4.9+dfsg1-1 introduced an invalid uploaders field, that is > missing a comma between Ricardo Mones & Joseph Nahmias. > > $ apt-cache showsrc freefem++ | grep -E '^$|^Version|^Uploaders' > Version: 3.61.1+dfsg1-6 > Uploaders: Christophe Trophime > , Dimitrios Eftaxiopoulos > > > Version: 4.9+dfsg1-1 > Uploaders: Christophe Trophime > , Dimitrios Eftaxiopoulos > Francois Mazen > > According to Debian policy 5.6.3 the Uploaders field must separate > individual uploaders using commas: > > List of the names and email addresses of co-maintainers of the > package, if any. ... The format of each entry is the same as that > of > the Maintainer field, and multiple entries must be comma > separated. > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders > signature.asc Description: This is a digitally signed message part
Bug#992420: typo in /usr/sbin/jk_init
Package: jailkit Version: 2.21-4 Seems there is small but crucial typo in /usr/sbin/jk_init root@syslog1:~# diff -u /usr/sbin/jk_init.orig /usr/sbin/jk_init --- /usr/sbin/jk_init.orig 2021-07-16 14:31:18.0 + +++ /usr/sbin/jk_init 2021-08-18 11:43:43.951008684 + @@ -116,7 +116,7 @@ paths = paths + jk_lib.config_get_option_as_list(cfg,section,'regularfiles') paths = paths + jk_lib.config_get_option_as_list(cfg,section,'directories') paths2 = jk_lib.find_files_in_path(paths) - self.didfiles = jk_lib.copy_binaries_and_libs(chroot, paths2, config['force'], config['verbose'], 1, try_hardlink=config['hardlink'],try_glob_matching=1,handledfiles=self.didfiles) + self.didfiles = jk_lib.copy_binaries_and_libs(chroot, paths2, config['force'], config['verbose'], check_libs=1, try_hardlink=config['hardlink'],try_glob_matching=1,handledfiles=self.didfiles) paths_w_owner = jk_lib.config_get_option_as_list(cfg,section,'paths_w_owner') if (len(paths_w_owner)>0): Peter
Bug#992421: dnslookup_relay_to_domains probably needs ignore_target_hosts
Package: exim4-config Version: 4.94.2-2~zg100+3 Severity: normal Hi, I am not sure whether this is an actual bug. I have observed this behaviod on an exim that is backup MX for domain.example. The MX records are like: domain.example mail is handled by 0 mx.domain.example. domain.example mail is handled by 10 myexim.otherdomain.example. Both hosts have both IPv4 and IPv6 addresses in DNS; the local resolver on myexim.otherdomain.example resolves its own host name to 127.0.1.1 by virtue of the normal Debian /etc/hosts file. [36/5023]mh@q:~ $ sudo exim -bt lists@domain.example R: domain_literal for lists@domain.example R: dnslookup_relay_to_domains for lists@domain.example lists@domain.example router = dnslookup_relay_to_domains, transport = remote_smtp host mx.domain.example [IPv6 address] MX=0 host mx.domain.example [IPv4 address] MX=0 host myexim.otherdomain.example [127.0.1.1] MX=10 [37/5024]mh@q:~ $ If mx.domain.example refuses mail, the local exim happily delivers to itself, causing a loop: 2021-08-18 08:06:15 1mGEiM-00089y-Vx <= linux-staging+bounces-5545-lists=domain.exam...@lists.linux.dev H=localhost (myexim.otherdomin.example) [127.0.0.1] P=esmtps X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no K S=14699 id= 2021-08-18 08:06:15 1mGEiK-00089g-NR => lists@domain.example R=dnslookup_relay_to_domains T=remote_smtp H=myexim.otherdomain.example [127.0.1.1] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes DN= K C="250- 7595 byte chunk, total 14687\\n250 OK id=1mGEiM-00089y-Vx" 2021-08-18 08:06:15 1mGEiK-00089g-NR Completed I have noticed that the dnslookup router in the upstream configure.defaut has a ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 option set, while our dnslookup_relay_to_domains router doesn't. I guess this was an omission made by myself back in 2003 when i added the dedicated handling of dnslookup for general e-mail and for domains that we have listed in dnslookup_relay_to_domains. I would like to suggest changing the dnslookup_relay_to_domains router to something like that: .ifndef ROUTER_DNSLOOKUP_RELAY_TO_DOMAINS_IGNORE_TARGET_HOSTS ROUTER_DNSLOOKUP_RELAY_TO_DOMAINS_IGNORE_TARGET_HOSTS = <; 0.0.0.0 ; 127.0.0.0/8 ; ::/128 ; ::1/128 .endif dnslookup_relay_to_domains: debug_print = "R: dnslookup_relay_to_domains for $local_part@$domain" driver = dnslookup domains = ! +local_domains : +relay_to_domains transport = remote_smtp same_domain_copy_routing = yes ignore_target_hosts = ROUTER_DNSLOOKUP_RELAY_TO_DOMAINS_IGNORE_TARGET_HOSTS no_more Or is exim supposed to never relay to itself automatically? If that is the case, more debugging is needed to find out why this happens here. Advice appreciated. Greetings Marc -- Package-specific info: Exim version 4.94.2 #2 built 04-May-2021 19:57:22 Copyright (c) University of Cambridge, 1995 - 2018 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018 Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PIPE_CONNECT PRDR PROXY SOCKS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated Configuration file is /var/lib/exim4/config.autogenerated -- System Information: Debian Release: 10.10 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.13.10-zgsrv20080 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages exim4-config depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 Versions of packages exim4-config recommends: ii ca-certificates 20200601~deb10u2 exim4-config suggests no packages. -- Configuration Files: /etc/exim4/conf.d/acl/20_exim4-config_local_deny_exceptions changed [not included] /etc/exim4/conf.d/router/600_exim4-config_userforward changed [not included] /etc/exim4/conf.d/router/700_exim4-config_procmail changed [not included] /etc/exim4/conf.d/router/800_exim4-config_maildrop changed [not included] /etc/exim4/conf.d/router/900_exim4-config_local_user changed [not included] /etc/exim4/passwd.client [Errno 13] Permission denied: '/etc/exim4/passwd.client' -- deb
Bug#992422: device files not created
Package: jailkit Version: 2.21-4 Running command to create jail with random and urandom devices produce following errors: Creating device /chroot/dev/random mknod: invalid major device number ‘1.03125’ Failed to create device /chroot/dev/random, this is a know problem with python 2.1 use "ls -l /dev/random" to find out the mode, major and minor for the device use "mknod /chroot/dev/random mode major minor" to create the device use chmod and chown to set the permissions as found by ls -l Creating device /chroot/dev/urandom mknod: invalid major device number ‘1.03515625’ Failed to create device /chroot/dev/urandom, this is a know problem with python 2.1 use "ls -l /dev/urandom" to find out the mode, major and minor for the device use "mknod /chroot/dev/urandom mode major minor" to create the device use chmod and chown to set the permissions as found by ls -l Peter
Bug#992336: RM: kdenlive [armel mips64el ppc64el s390x] -- ANAIS; Package requires qtwebengine5-dev, not available on every architecture
On Tue, Aug 17, 2021 at 03:23:48PM +0200, Patrick Matthäi wrote: >... > with kdenlive >= 21.04 qtwebengine5 is required, >... Are you sure? It is not obvious to me where it is used, and the package builds for me without. cu Adrian
Bug#992121: linux-image-5.10.0-8-amd64: kernel oops and subsequent hard crash in bluetooth bt_sock_poll, regression, upstream patch
On Thu, 12 Aug 2021, Salvatore Bonaccorso wrote: > > https://www.spinics.net/lists/linux-bluetooth/msg88356.html > > > > points to a patch that has supposedly already been applied to > > bluetooth-next, but is definitely not in linux-source-5.10 5.10.46-4 > > (testing). > > > > Current code still reads: > > > > /* cleanup runtime environment */ > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait); > > remove_wait_queue(sk_sleep(session->intr_sock->sk), &ctrl_wait); > > wake_up_interruptible(&session->report_queue); > > hidp_del_timer(session); > > > > Second remove_wait_queue should be: ctrl_sock->sk > > Would it be possible that you check if the upstream commit > https://git.kernel.org/linus/cca342d98bef68151a80b024f7bf5f388d1fbdea > fixes the issue? > > It was not yet queued for the 5.10.y series, but if yes, this should > go to stable@ so that we then can pick it up for either cherry-picking > for the next bullseye upload (or a rebase to the latest 5.10.y in a > point release). I've been running it for a few days now, and it seems good to me! -- Tim Connors
Bug#992424: awscli: Latest 1.x release
Package: awscli Version: 1.19.1-1 Severity: wishlist Dear Maintainer, I note there's some discussion in #966573 about packaging v2 and there's some complexity there. With the bullseye freeze over and the v2 plans uncertain, are you open to updating this package to the most recent release in the 1.x series? For my use case I'm particularly interested in the "ecs execute-command" subcommand, which seems like it was introduced in 1.19.28: https://github.com/aws/aws-cli/commit/ba4163d46969a8aba0e4712852aba9ad5a3f3667 -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages awscli depends on: ii groff 1.22.4-6 ii python3 3.9.2-3 ii python3-botocore1.20.0+repack-1 ii python3-colorama0.4.4-1 ii python3-docutils0.16+dfsg-4 ii python3-pyasn1 0.4.8-1 ii python3-rsa 4.0-4 ii python3-s3transfer 0.3.4-1 ii python3-yaml5.3.1-5 awscli recommends no packages. awscli suggests no packages. -- no debconf information
Bug#992425: ifupdown: run-parts path is hardcoded in several places
Package: ifupdown Version: 0.8.36 Severity: serious Dear Maintainer, In debianutils 5.0 run-parts has been moved from /bin to /usr/bin and thus the networking service is unable to start. Christian -- System Information: Debian Release: 11.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.60 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.13.0-2 ii libc6 2.31-15 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: pn isc-dhcp-client | dhcp-client Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information
Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0
On Tue, 01 Jun 2021 08:02:43 +0200 Tobias Frost wrote: > On Fri, 9 Apr 2021 00:41:35 +0530 Nilesh Patra wrote: > > Hi Ben, > (...) > > It has been a while, but do you still need sponsoring for this? If yes, > > I'm willing to do so. > > > > PS: aerc is out of testing for this release unfortunately :/ > > Nevertheless, lets target the next one > > Pinging Ben explictly… Maybe he missed that mail. > (Otherwise I'll mark the bugs moreinfo in a few weeks, as they are not > actionable without Ben's feedback; this includes the other golang RFS-bugs as > well…) Few weeks earlier, I saw a message from the other manitainer of aerc (Karthik in CC) in a common channel saying that both him and Ben do not have the time and enrgy to maintain this. Maybe someone really will have to take over the maintainance. I'll try reaching out meanwhile to ben but Ben does not seem active either. @Karthik, can you confirm that this is right? And if yes, can you please send in an email to the list if someone wants to take over the maintainance, if not, could you please file in a RFA bug? It still has RC bugs open, version lags behind, and folks are interested in the package as well, so this is kinda important. Hope that's fine Nilesh signature.asc Description: PGP signature
Bug#987572: FTCBFS: unsatisfiable python3-sphinx dependency
On Mon, 26 Apr 2021 02:29:45 +0530 Nilesh Patra wrote: > Package: biboumi > Version: 9.0-2 > Severity: normal > X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, > debian-cr...@lists.debian.org > Hi Vasudev, Hi Michel, gentle ping on this? Could you please apply this and upload a fix? Nilesh signature.asc Description: PGP signature
Bug#992426: debianutils: Removal of tempfile breaks X login
Package: debianutils Version: 5.0.1-1 Severity: important Dear Maintainer, The /etc/XSession script uses tempfile, so removal of that package breaks logging into X. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debianutils depends on: ii libc6 2.31-15 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information
Bug#992427: wims: binary-any FTBFS
Source: wims Version: 2:4.17b+svn13454~dfsg2-1 Severity: serious Tags: ftbfs Control: fixed -1 2:4.22~dfsg1-1 https://buildd.debian.org/status/package.php?p=wims&suite=sid ... dh_missing -a dh_missing: warning: usr/share/man/man1/flydraw.1.gz exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: flydraw (1), wims (24), wims-java-applets (0), wims-modules (1) * dh_installdocs: flydraw (0), wims (1), wims-java-applets (0), wims-modules (0) * dh_installman: flydraw (1), wims (0), wims-java-applets (0), wims-modules (0) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. make: *** [debian/rules:16: binary-arch] Error 25
Bug#971594: RFS: asciidoc/9.0.2-1 [ITA] -- Highly configurable text format for writing documentation
Hi tobi, Thanks for helping me adopting this package. First I'm sorry that I haven't answered before. For some reason I didn't receive any of your emails. Hopefully that is now fixed. On Wed, 09 Jun 2021 16:50:47 +0200 Tobias Frost wrote:> What I can see from the diff is that the only package dropped is vim-ascidoc. > This looks sane to me, and due to the fact that vim depends on vim-runtime > on any vim flavour != tiny, people possibly have already vim-runtime > installed. In the previous discussion I have stated that I also want to remove asciidoc-base. During the freeze period I've decided that I want to keep this binary package because it reduces the amount of dependencies for smaller use cases like generating man pages. Sorry if that caused some confusion. > However -- as popcon of the package is rather high -- I would put up some > NEWS.Debian file saying that this is dropped in favour of vim-runtime; > This is especially useful, if (I did not check if that is the case!) the > user needs to do someting to switch to the vim-runtime provided thingy. > What do you think? Sounds good. I have written something in the NEWS file in the newest upload. The user doesn't have to change their configuration. It should work out of the box. - Leon OpenPGP_signature Description: OpenPGP digital signature
Bug#648251: Please apply the patch
The problem still exists in os-prober 1.79, and I've confirmed that the patch still applies and solves the problem. Could this (or an equivalent) be applied for the next version? -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Bug#951374: RFP: gh -- the GitHub CLI
On 2021-08-18 05:33:30, Anthony Fok wrote: > Hi Antoine, > > On Tue, Aug 17, 2021 at 7:40 AM Antoine Beaupré wrote: >> >> On 2021-08-16 21:27:33, Anthony Fok wrote: >> >> [...] >> >> > So, in summary, it just means the following in debian/control: >> > >> > Source: github-cli >> > ... >> > XS-Go-Import-Path: github.com/github/cli >> > ... >> > Package: github-cli >> > ... >> > Conflicts: gitsome, gh >> > Provides: gh >> > Replaces: gh >> >> I do not see why you would Conflicts with `gh` here. It's not an actual >> package name, so it doesn't need that. I am not sure that Replaces is >> necessary either. Those would be required if we were renaming or >> replacing an existing package, which is not quite the case here. > > That is because "gh" _is_ an actual Debian package name > albeit not from official Debian sources. > That is how GitHub has named their .deb packages, as seen in their > latest release page here: > > https://github.com/cli/cli/releases/tag/v1.14.0 > > As a matter of fact, I already have their GoRelease-generated > gh_1.14.0_linux_arm64.deb installed because I couldn't wait. :-) > Needed it for a work task at > https://github.com/OpenDRR/opendrr-platform/issues/126 > > Anyhow, since GitHub has already named their deb package "gh", it may > be a good argument for us to name our official Debian package as "gh" > too. (haha!) > > But anyhow, if we do decide to name our package "github-cli", the > "Conflicts: gh" would allow me to smoothly upgrade from GitHub's "gh" > deb package to Debian's "github-cli" deb package. Oh, good point. This does seem like a good migration path then, although I can't help but think we should collaborate with upstream in this case, to make sure we converge over something instead of creating a confusing pair of package names. It would be better for our users to have a consistent naming with upstream... >> Some would argue that installing gitsome *and* gh *would* be desirable, >> however, which might make the Conflicts problematic. If that's the case, >> then there is a number of mechanisms that we could use, but I'd actually >> cross that bridge when we get there. > > Totally agreed. > I find diversions somewhat messy, so I'd rather not go there > unless someone actually starts complaining. :-) Right, I would totally avoid diversions in general. I was thinking more of "alternatives", and/or maybe splitting "gh" out of gitsome so that it wouldn't have to conflict anymore. a. -- Treating different things the same can generate as much inequality as treating the same things differently. - Kimberlé Crenshaw
Bug#992359: spdlog: Please package new upstream version (1.8.5)
Thank you for your report. Have you tested the packages that use libspdlog-dev with 1.8.5 ? They are bear cherrytree flameshot hinge intel-gmmlib kodi nheko osmid purify rapmap salmon sopt vast waybar On Tue, Aug 17, 2021 at 8:39 PM Boyuan Yang wrote: > Source: spdlog > Severity: normal > Version: 1:1.8.1+ds-2.1 > X-Debbugs-CC: cru...@debian.org > > Dear Debian spdlog package maintainers, > > Current version of spdlog in Debian is 1.8.1, and a new version of 1.8.5 is > now available. One of my packages (flameshot) needs spdlog/1.8.5 in the new > version. Could you please update spdlog to at least 1.8.5? > > I see that the git packaging repo in Salsa GitLab already has a 1.8.5 > version > prepared. It would be great if it can be packaged in near future. Please > let > me know if I can provide with any help (such as package sponsorship). > > Thanks, > Boyuan Yang >
Bug#975524: cmst/connman system-tray applet: please start automatically when installed
Package: lxqt Version: 30 Followup-For: Bug #975524 IMO cmst should have an desktop entry in /etc/xdg/autostart/ so that it is autostarted upon installation. Should we move this bug to cmst? signature.asc Description: PGP signature
Bug#991897: removal of the any/local-rtlddir-cross.diff patch broke cross builds
Hi,
On 2021-08-18 11:02, Matthias Klose wrote:
> On 8/6/21 10:44 AM, Aurelien Jarno wrote:
> > control: reassign -1 cross-toolchain-base-ports-46
> > control: tag -1 + patch
> > control: tag -1 - moreinfo
> > control: tag -1 - unreproducible
> >
> > On 2021-08-05 18:59, Aurelien Jarno wrote:
> >> control: tag -1 + moreinfo
> >> control: tag -1 + unreproducible
> >>
> >> On 2021-08-04 19:03, Matthias Klose wrote:
> >>> Package: src:glibc
> >>> Version: 2.31-13
> >>> Severity: serious
> >>> Tags: sid bullseye
> >>>
> >>> when cross-building glibc in the c-t-b packages, the libc.so linker file
> >>> for
> >>> some non-default multilib builds like the sparc build for sparc64 is
> >>> broken,
> >>> leading to build failures for at least all gcc-N cross multilib packages
> >>> at least.
> >>>
> >>> $ cat usr/lib32/libc.so
> >>> /* GNU ld script
> >>>Use the shared library, but some functions are only in
> >>>the static library, so try that secondarily. */
> >>> OUTPUT_FORMAT(elf32-sparc)
> >>> GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a AS_NEEDED (
> >>> /lib/ld-linux.so.2 ) )
> >>
> >> Can you point me where you got that file? It doesn't make sense from the
> >> path and the content point of view. Also it's not what I get in the
> >> libc6-sparc-sparc64-cross package generated by building
> >> cross-toolchain-base-ports in a bullseye chroot. I get instead:
> >>
> >> | cat /usr/sparc64-linux-gnu/lib32/libc.so
> >> | /* GNU ld script
> >> | Use the shared library, but some functions are only in
> >> |the static library, so try that secondarily. */
> >> | OUTPUT_FORMAT(elf32-sparc)
> >> | GROUP ( /usr/sparc64-linux-gnu/lib32/libc.so.6
> >> /usr/sparc64-linux-gnu/lib32/libc_nonshared.a AS_NEEDED (
> >> /usr/sparc64-linux-gnu/lib/ld-linux.so.2 ) )
> >>
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that the
> >>> maintainer is investigating, but apparently this never happened.
> >>
> >> I *did* investigate, and checked that the changes in the linker files
> >> are correct. I have just done that again for both cross-toolchain-base
> >> and cross-toolchain-base-ports. Here are the differences I observed on
> >> the linker scripts:
> >
> > I have ran a build of gcc-10-cross and gcc-10-cross-ports over the
> > night. gcc-10-cross just built fine, but gcc-10-cross-ports indeed
> > failed to build the sparc64 cross compiler as you reported.
> >
> > It appears that the embedded copy of dpkg-cross decided to map the
> > multiarch path to /usr/$triplet/lib, leaving lib32, lib64 or libx32 to
> > the other multilib builds. This causes an issue for the dynamic linker
> > symlink, which usually follows the upstream way of putting a 64-bit
> > library in /lib64. At the end, it means the 32-bit dynamic linker
> > ends-up in the /usr/triplet/lib directory containing the 64 bit
> > libraries. This is not a big deal for most architectures, except when
> > the 32- and 64-bit dynamic linkers have the same name like on sparc64.
> >
> > The problem seems to have been identified, as one of the two is just
> > removed in the debian/rules file, with this associated comment:
> >
> > # FIXME: don't remove these here, but find out why these are left in the
> > glibc build
> >
> > The problem is that the removed one is the most useful one, breaking the
> > assumption that /usr/$triplet/$rtld.so exists. The following patches
> > fixes the issue for sparc64:
> >
> >
> > diff -Nru cross-toolchain-base-ports-45/debian/rules
> > cross-toolchain-base-ports-46/debian/rules
> > --- cross-toolchain-base-ports-45/debian/rules 2021-03-03
> > 15:22:03.0 +0100
> > +++ cross-toolchain-base-ports-46/debian/rules 2021-08-06
> > 10:31:22.0 +0200
> > @@ -831,7 +831,7 @@
> > case "$$pkgname" in \
> > libc6-mips32-mips64-cross|libc6-mips32-mips64el-cross) \
> > rm -f $$tmp/usr/*/lib/ld.so.1;; \
> > - libc6-sparc-sparc64-cross) \
> > + libc6-sparc64-cross) \
> > rm -f $$tmp/usr/*/lib/ld-linux.so.2;; \
> > esac; \
> > if [ 'lib$(libgcc_base)1-dbg-$${cross_arch}-cross' = $$pkgname ]; then \
> >
> > I guess the same fix is needed for gcc-10-cross-mipsen, but I haven't
> > been able to build it yet.
>
> this fixes the gcc-N-cross-ports build, but leaves the libc.so with the wrong
> path of ld-linux.so.2.
What do you mean with the wrong path? gcc-N-cross-ports failed to build
because it was pointing to the wrong ld-linux.so.2. If it builds, I
believe it points to the correct one.
> Do you intend to fix that, or should that be worked
> around in the c-t-b package?
This is not something to fix in the glibc package. The packages
generated by cross-compiling glibc have the correct paths, the issue is
introduced by the path mangling done by the embedded dpkg-cross copy.
The issue should be fixed there, not by patching glibc with hacks that
have impacts on the non mangled packages.
Regards,
Aurelien
--
Aurelien Jarno
Bug#992428: link to syslog.service not changed
Package: syslog-ng Version: 3.28.1-2+b1 Link /etc/systemd/system/syslog.service still points to /lib/systemd/system/rsyslog.service which does not exist after installation syslog-ng. The link should be processed in the "install" section of /var/lib/dpkg/info/syslog-ng-core.preinst script too. Maybe it is the rsyslog package which should take care of. Peter
Bug#987572: FTCBFS: unsatisfiable python3-sphinx dependency
Quoting Nilesh Patra (2021-08-18 15:08:29) > On Mon, 26 Apr 2021 02:29:45 +0530 Nilesh Patra wrote: > > Package: biboumi > > Version: 9.0-2 > > Severity: normal > > X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, > > debian-cr...@lists.debian.org > > > > Hi Vasudev, Hi Michel, > > gentle ping on this? > Could you please apply this and upload a fix? I can have a look. Thanks for nudging! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#992430: schroot: user password does not match
Package: schroot Version: 1.6.10-12 Severity: important X-Debbugs-Cc: ser...@vlasov.me Dear Maintainer, When doing schroot into a buster chroot environment, sudo commands fail due to password not matching the current user password. There is no such problem for bullseye chroot environment. To reproduce: 0. make sure your current user belongs to sudo group 1. create buster chroot environment: $ sudo debootstrap buster /schroot-bug/buster 2. create schroot configuration file: $ cat << EOF | sudo tee /etc/schroot/chroot.d/buster [buster] type=directory directory=/schroot-bug/buster users=$USER profile=desktop personality=linux preserve-environment=false EOF 3. enter chroot: $ schroot -c buster 4. test sudo with your current password: $ sudo true [sudo] password for : Sorry, try again. [sudo] password for : Sorry, try again. [sudo] password for : sudo: 3 incorrect password attempts 5. repeat steps 1-4 but replace `buster` with `bullseye`. `sudo true` command accepts the current user password. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages schroot depends on: ii libboost-filesystem1.74.0 1.74.0-9 ii libboost-iostreams1.74.01.74.0-9 ii libboost-program-options1.74.0 1.74.0-9 ii libc6 2.31-13 ii libgcc-s1 10.2.1-6 ii libpam0g1.4.0-9 ii libstdc++6 10.2.1-6 ii libuuid12.36.1-8 ii lsb-base11.1.0 ii schroot-common 1.6.10-12 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-tools | unionfs-fuse pn btrfs-progs ii debootstrap1.0.123 ii lvm2 2.03.11-2.1 pn qemu-user-static pn zfsutils-linux -- no debconf information
Bug#992429: ITP: libapache-session-mongodb-perl -- Apache::Session implementation for MongoDB databases
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libapache-session-mongodb-perl Version : 0.21 Upstream Author : Xavier Guimard * URL : https://metacpan.org/release/Apache-Session-MongoDB * License : Artistic-1.0 or GPL-1+ Programming Lang: Perl Description : Apache::Session implementation for MongoDB databases Apache::Session::MongoDB module is an implementation of Apache::Session. It uses the MongoDB backing store and no locking. This module is one of the backends proposed by lemonldap-ng Web-SSO system. Cheers, Yadd
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
Link obviously works but i've noticed that 'tempfile' is gone in that version so lightdm cannot start xfce for example. root@vostro:~# apt-file list debianutils|head debianutils: /usr/bin/ischroot debianutils: /usr/bin/run-parts debianutils: /usr/bin/savelog debianutils: /usr/bin/which debianutils: /usr/sbin/add-shell debianutils: /usr/sbin/installkernel debianutils: /usr/sbin/remove-shell Can't find tempfile in other packages so only downgrade helps. On Wed, 18 Aug 2021 13:22:22 +0300 jim_p wrote: > Package: debianutils > Followup-For: Bug #992410 > X-Debbugs-Cc: pitsior...@outlook.com > > I second to that. It happened on my i686 pc that runs unstable. > As a workaround, one can symlink /usr/bin/run-parts to /bin/run-parts > > ln -s /usr/bin/run-parts /bin/run-parts > > and network.service comes up as usual. > > -- Regards, Rafał Olejnik OpenPGP_0x2CD45DA6B645A2AF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#992430: schroot: user password does not match
Hi, I'm not personally familiar with the changes in the latest Debian release, but please check that all the password, shadow password files etc. are all copied into the chroot and are self-consistent with one another. Are the host files using a hash type not supported by the chroot environment? Regards, Roger On 18/08/2021, 14:54, "Sergey Vlasov" wrote: Package: schroot Version: 1.6.10-12 Severity: important X-Debbugs-Cc: ser...@vlasov.me Dear Maintainer, When doing schroot into a buster chroot environment, sudo commands fail due to password not matching the current user password. There is no such problem for bullseye chroot environment.
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote: > I was expecting to be easy to collect the info in one or 2 files, but > I am wrong. I have 3 targets with multipath for 2 of them and I am > not certain what is active. I have multipath active, I am certain of > that, because of the device I am mouting: > /dev/mapper/mpath-X-part1 > > So I am expecting you need all files inside /etc/iscsi and some > run-time info? I am asking this information just for the sake of this task, to ascertain why it failed in the first 30 seconds. Since this worked for you, later, when you increased the timeout to 120 seconds; there's not much to do I suppose. But yes, from this bug report's sake, having that information clarified will be good. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#992401: debianutils: warning message: /usr/bin/which: this version of 'which' is deprecated and should not be used.
On Wed, 18 Aug 2021 09:34:17 +0200 Salman Mohammadi wrote: > > Package: debianutils > Version: 5.0.1-1 > Severity: normal > X-Debbugs-Cc: none, sal...@smoha.org, Salman Mohammadi > > Dear Maintainer(s), > > Running `which` in the commandline throws the following warning message: > > > /usr/bin/which: this version of 'which' is deprecated and should > not be used. > > > Could it be due to this commit? (which: punctuation fix) > > https://salsa.debian.org/debian/debianutils/-/commit/a92d15b24071cf2105c85daf4d27326dd6443732 > ... Rather to this one (Deprecate which): https://salsa.debian.org/debian/debianutils/-/commit/3a8dd10b4502f7bae8fc6973c13ce23fc9da7efb IMHO, it's a pity to deprecate it, and I am sure this change will break quite some scripts. E.g.: https://salsa.debian.org/dns-team/knot-dns/-/jobs/1828299#L625 Is it really mandatory to remove which? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#870395: hydrogen: Segmentation fault when creating or modifying drumkits
On Tue, Aug 17, 2021 at 05:44:47PM -0400, Nicholas D Steeves wrote: > So sorry for the unreasonably long wait for a reply! Don't worry, I'm so used to the workaround that I'll miss it when the bug is fixed ;) > We now have the option of 1.0.1-3 on Bullseye (Debian 11) :-) When you > have the time to upgrade to Bullseye, would you please update this bug > with your experience. Of course, I'll test it. I may need some time, though, until I find a good moment to upgrade computers... > I wonder if the reason you're able to trigger this issue > (I agree with your assessment and hypothesis, by the way) is because > your interface is taking slightly longer to process the packets/stream, > leading to a race->crash rather than a benign race? If so, you have a > great setup for audio bug hunting! :-D It's quite possible that my computer is taking a longer time, it's many years old and very slow compared to nowaday standards. > If you're comfortable installing individual packages from experimental, > and you're also able to reproduce the crash with 1.0.1-3 in Bullseye, > then would you please consider also testing 1.1.0~beta1-1~exp1 (from > experimental) to see if it's also affected? I can also do this, thank you for your suggestions.
Bug#992431: RFS: chromono/1.1.1-1 [ITP] -- A circular color puzzle game
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "chromono": * Package name: chromono Version : 1.1.1-1 Upstream Author : Thomas Perl * URL : https://thp.io/2013/chromono/ * License : CC-BY-3.0, GPL-2+, CC0 Section : games It builds those binary packages: chromono - A circular color puzzle game To access further information about this package, please visit the following URL: https://mentors.debian.net/package/chromono/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/chromono/chromono_1.1.1-1.dsc Changes for the initial release: chromono (1.1.1-1) unstable; urgency=medium . * Initial release (Closes: #992342) Regards, Thomas
Bug#991549: libpmix-dev: missing Breaks+Replaces: libpmix2 (<< 4.1)
Hello, this might do the trick:
http://launchpadlibrarian.net/554140305/pmix_4.1.0-2ubuntu1_4.1.0-2ubuntu2.diff.gz
We should also drop cython (gone in Debian too) and patch to use cython3
instead of failing the build.
diff -Nru pmix-4.1.0/debian/changelog pmix-4.1.0/debian/changelog
--- pmix-4.1.0/debian/changelog 2021-08-17 20:21:10.0 +
+++ pmix-4.1.0/debian/changelog 2021-08-18 07:57:28.0 +
@@ -1,3 +1,11 @@
+pmix (4.1.0-2.1) unstable; urgency=medium
+
+ * Update breaks/replaces to fix uninstallability (Closes: #991549)
+ * Drop cython b-d
+ * Move to cython3
+
+ -- Gianfranco Costamagna Wed, 18 Aug 2021
09:57:28 +0200
+
pmix (4.1.0-2ubuntu1) impish; urgency=low
* Merge from Debian unstable. Remaining changes:
diff -Nru pmix-4.1.0/debian/control pmix-4.1.0/debian/control
--- pmix-4.1.0/debian/control 2021-08-16 21:31:22.0 +
+++ pmix-4.1.0/debian/control 2021-08-18 07:57:28.0 +
@@ -7,7 +7,7 @@
chrpath,
flex,
python3-all-dev,
- cython3, cython,
+ cython3,
python3-distutils,
pandoc [!i386],
libpsm-infinipath1-dev [amd64 i386],
@@ -26,6 +26,8 @@
Package: libpmix-dev
Section: libdevel
Architecture: any
+Breaks: libpmix2 (<< 4.1.0~rc1-1)
+Replaces: libpmix2 (<< 4.1.0~rc1-1)
Multi-Arch: same
Depends: ${shlibs:Drepends}, ${misc:Depends}, libpmix2 (= ${binary:Version}),
libevent-dev, libhwloc-dev, zlib1g-dev
Description: Development files for the PMI Exascale library
diff -Nru pmix-4.1.0/debian/patches/pmix.patch
pmix-4.1.0/debian/patches/pmix.patch
--- pmix-4.1.0/debian/patches/pmix.patch1970-01-01 00:00:00.0
+
+++ pmix-4.1.0/debian/patches/pmix.patch2021-08-18 07:57:28.0
+
@@ -0,0 +1,26 @@
+Description: Force cython3
+Author: Gianfranco Costamagna
+Last-Update: 2021-08-18
+
+--- pmix-4.1.0.orig/config/pmix.m4
pmix-4.1.0/config/pmix.m4
+@@ -1276,16 +1276,16 @@ if test "$WANT_PYTHON_BINDINGS" = "1"; t
+ if test "$have_cython" = "0"; then
+ AC_MSG_RESULT([yes])
+ AC_MSG_CHECKING([Cython version])
+-cython_version=`python -c "from Cython.Compiler.Version import
version; print(version)"`
++cython_version=`python3 -c "from Cython.Compiler.Version import
version; print(version)"`
+ AC_MSG_RESULT([$cython_version])
+ PMIX_SUMMARY_ADD([[Bindings]],[[Cython]], [pmix_cython], [yes
($cython_version)])
+ else
+ AC_MSG_RESULT([no])
+ # Cython doesn't have any include or lib files - it is just a binary
+-AC_CHECK_PROG(pmix_cython_rpm, cython, [cython])
++AC_CHECK_PROG(pmix_cython_rpm, cython3, [cython])
+ if test "$pmix_cython_rpm" != ""; then
+ AC_MSG_CHECKING([Cython version])
+-cyvers=`cython --version 2>&1`
++cyvers=`cython3 --version 2>&1`
+ cython_version=${cyvers#"Cython version "}
+ AC_MSG_RESULT([$cython_version])
+ PMIX_SUMMARY_ADD([[Bindings]],[[Cython]], [pmix_cython], [yes
($cython_version)])
diff -Nru pmix-4.1.0/debian/patches/series pmix-4.1.0/debian/patches/series
--- pmix-4.1.0/debian/patches/series2021-08-16 21:31:22.0 +
+++ pmix-4.1.0/debian/patches/series2021-08-18 07:57:28.0 +
@@ -1 +1,2 @@
# hurd-fix.patch
+pmix.patch
On Tue, 27 Jul 2021 10:24:19 +0200 Andreas Beckmann wrote:
> Package: libpmix-dev
> Version: 4.1.0~rc1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
> It installed fine in 'sid', then the upgrade to 'experimental' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
>
> From the attached log (scroll to the bottom...):
>
> Preparing to unpack .../libpmix-dev_4.1.0~rc1-1_amd64.deb ...
> Unpacking libpmix-dev:amd64 (4.1.0~rc1-1) over (4.0.0-4) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libpmix-dev_4.1.0~rc1-1_amd64.deb (--unpack):
>trying to overwrite '/usr/lib/x86_64-linux-gnu/pmix2/lib/libpmix.so',
> which is also in package libpmix2:amd64 4.0.0-4
> Preparing to unpack .../libpmix2_4.1.0~rc1-1_amd64.deb ...
> Unpacking libpmix2:amd64 (4.1.0~rc1-1) over (4.0.0-4) ...
> Errors were encountered while processing:
>/var/cache/apt/archives/libpmix-dev_4.1.0~rc1-1_amd64.deb
>
>
> cheers,
>
> Andreas
Bug#992432: frobby: undefined symbol: _ZN9constants7versionE
Message-ID: <162929730510.557678.4828600179998098531.reportbug@mixtuppa> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: reportbug 7.10.3ubuntu1 Package: frobby Version: 0.9.5-1 Severity: important X-Debbugs-Cc: dtorra...@piedmont.edu /usr/bin/M2-binary: symbol lookup error: /usr/bin/M2-binary: undefined symbol: _ZN9constants7versionE >From a CI test run of Macaulay2 after the upload of frobby 0.9.5-1 [1]: This is due to the upstream change from constants::version to frobby_version [2]. Due to the change in interface, frobby should get a soname version bump. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/m/macaulay2/14665382/log.gz [2] https://github.com/Macaulay2/frobby/pull/5 Date: Wed, 18 Aug 2021 10:38:51 -0400
Bug#992433: RM: perl-cross-debian -- RoQA; Orphaned, Unused, Requested by maintainer
Package: ftp.debian.org X-Debbugs-Cc: by...@debian.org codeh...@debian.org Severity: normal Dear FTP Masters, As discussed in https://bugs.debian.org/c871961 , package perl-cross-debian has been orphaned since 2017, and its ex-maintainer (also upstream author, in cc list) indicates that it is not needed anymore and should be removed if not adopted after 2017. Now in 2021, I believe it's time to continue with the removal. * The package has no reverse dependencies. * The package has no reverse build-dependencies. * The package has a popcon of 35 (low). -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#992411: debianutils: please keep "which"
On Wed, Aug 18, 2021 at 09:44:28AM +0100, Andrej Shadura wrote: > The commit 3a8dd10, shipped in 5.0-1, deprecates "which", stating that > "type" and "command -v" are mandated by POSIX anyway. While it may be > true, that "which" can be replaced by something else in maintainer > scripts, it’s easier to remember due to its name, especially in > interactive sessions. > > Please "undeprecate" and keep it. If you or anyone else wants to package the FreeBSD version of which, or GNU which, or any other which, this comment may apply: https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_243156
Bug#992359: spdlog: Please package new upstream version (1.8.5)
Hi, 在 2021-08-18星期三的 15:39 +0200，Michael R. Crusoe写道： > Thank you for your report. > > Have you tested the packages that use libspdlog-dev with 1.8.5 ? > > They are bear > > cherrytree > flameshot > hinge > intel-gmmlib > kodi > nheko > osmid > purify > rapmap > salmon > sopt > vast > waybar I haven't tested it since spdlog/1.8.5 is not in Debian yet. Could you please upload the new version into experimental so that we can test it, or could I do a spdlog/1.8.5 NMU into experimental? Thanks, Boyuan Yang > On Tue, Aug 17, 2021 at 8:39 PM Boyuan Yang wrote: > > Source: spdlog > > Severity: normal > > Version: 1:1.8.1+ds-2.1 > > X-Debbugs-CC: cru...@debian.org > > > > Dear Debian spdlog package maintainers, > > > > Current version of spdlog in Debian is 1.8.1, and a new version of 1.8.5 > > is > > now available. One of my packages (flameshot) needs spdlog/1.8.5 in the > > new > > version. Could you please update spdlog to at least 1.8.5? > > > > I see that the git packaging repo in Salsa GitLab already has a 1.8.5 > > version > > prepared. It would be great if it can be packaged in near future. Please > > let > > me know if I can provide with any help (such as package sponsorship). > > > > Thanks, > > Boyuan Yang
Bug#992386: has a duplicated changelog
On Wed, Aug 18, 2021 at 06:27:50AM +0200, Marco d'Itri wrote: > Only one should be installed: > > 31bf287ed7a39cc395f6d91002ca8155 > /usr/share/doc/debianutils/changelog.Debian.gz > 31bf287ed7a39cc395f6d91002ca8155 /usr/share/doc/debianutils/changelog.gz This is true.
Bug#992434: RFS: extsmail/2.5-1 -- enables the robust sending of e-mail to external commands
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "extsmail" * Package name: extsmail Version : 2.5-1 Upstream Author : Laurence Tratt * URL : https://tratt.net/laurie/src/extsmail/ * License : BSD/MIT Section : mail It builds this binary package: extsmail - enables the robust sending of e-mail to external commands The package appears to be lintian-clean To access further information about this package, please visit the following URL: https://mentors.debian.net/package/extsmail Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.5-1.dsc Changes since the last upload: * New upstream release 2.5. * debian/control: Build-Depends: Update debhelper-compat (= 13). * debian/control: Build-Depends: Add libbsd-dev. * debian/control: Standards-Version: 4.6.0.0. * debian/patches/: Removed. Regards, -- Olivier
Bug#992418: surf: environment variable SURF_USERAGENT has no effect
Package: surf Version: 2.0+git20201107-2 Severity: minor Dear Maintainer, according to surf(1) the environment variable SURF_USERAGENT determines the user-agent header. But the variable has no effect. tested with nc -l 8080 surf http://localhost:8080 -- System Information: Debian Release: 11.0 Architecture: amd64 (x86_64) Versions of packages surf depends on: ii libc62.31-13 ii libgcr-base-3-1 3.38.1-2 ii libgcr-ui-3-13.38.1-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libjavascriptcoregtk-4.0-18 2.32.3-1 ii libwebkit2gtk-4.0-37 2.32.3-1 ii libx11-6 2:1.7.2-1 Versions of packages surf recommends: ii curl 7.74.0-1.3+b1 ii stterm [x-terminal-emulator] 0.8.4-1 ii suckless-tools46-1 ii x11-utils 7.7+5 ii xterm [x-terminal-emulator] 366-1 Versions of packages surf suggests: ii apparmor 2.13.6-10 -- no debconf information -- https://www.positivemoney.eu/about-us/ signature.asc Description: PGP signature
Bug#992383: debianutils: which is noisy and doesn't suggest a different option
On Wed, Aug 18, 2021 at 01:28:14PM +0900, Norbert Preining wrote: > it seems that /usr/bin/which from debianutils has been deprecated, which > is ok, but being noisy about it on any invocation, **without** providing > an alternative is a no go, since it might break scripts that parse > output including stderr. > > Please use NEWS, or whatever other channels, and above all, **provide > information on a replacement!** Alternatives include * type * command -v * whereis from util-linux * the which builtin in some interactive shells * the whence builtin in some interactive shells * the which() function included in keyboard-configuration.postinst I don't have a comprehensive list.
Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
On Wed, Aug 18, 2021 at 03:57:01PM +0900, Norbert Preining wrote: > /etc/X11/XSession relies on tempfile, which is not available anymore, > thus logging into an X session is broken. In our stable release, tempfile outputs this to stderr: WARNING: tempfile is deprecated; consider using mktemp instead. Apparently no one has cared.
Bug#992424: awscli: Latest 1.x release
On Wed, Aug 18, 2021 at 10:59:01PM +1000, James Healy wrote: > I note there's some discussion in #966573 about packaging v2 and there's > some complexity there. > > With the bullseye freeze over and the v2 plans uncertain, are you open > to updating this package to the most recent release in the 1.x series? > > For my use case I'm particularly interested in the "ecs execute-command" > subcommand, which seems like it was introduced in 1.19.28: > > https://github.com/aws/aws-cli/commit/ba4163d46969a8aba0e4712852aba9ad5a3f3667 Yes, awscli will be updated in sid in the near term. Newer versions may also make it into bullseye-backports and potentially be included in bullseye point releases if they contain important changes necessary for continued usefulness... noah
Bug#992430: schroot: user password does not match
Hi Roger, I compared `/etc/shadow` and `/etc/passwd` across my host and from inside the testable chroot environments, no difference, I also checked `/etc/pam.d/common-password` and it looks that bullseye uses `yescrypt` for hashing while buster uses `sha512`. It also says in `/etc/pam.d/common-password`: > if a shadow password hash will be shared between Debian 11 and older releases replace "yescrypt" with "sha512" for compatibility. My buster chroot already has "sha512" set. I tried to set "yescrypt" there but sudo still complains about the wrong password. Regards, Sergey On Wed, Aug 18, 2021 at 4:58 PM Roger Leigh wrote: > Hi, > > I'm not personally familiar with the changes in the latest Debian release, > but please check that all the password, shadow password files etc. are all > copied into the chroot and are self-consistent with one another. Are the > host files using a hash type not supported by the chroot environment? > > Regards, > Roger > > On 18/08/2021, 14:54, "Sergey Vlasov" wrote: > > Package: schroot > Version: 1.6.10-12 > Severity: important > X-Debbugs-Cc: ser...@vlasov.me > > Dear Maintainer, > > When doing schroot into a buster chroot environment, sudo > commands fail due to password not matching the current user password. > There is no such problem for bullseye chroot environment. > > > >
Bug#987572: FTCBFS: unsatisfiable python3-sphinx dependency
On Wed, 18 Aug, 2021, 7:15 pm Jonas Smedegaard, wrote: > Quoting Nilesh Patra (2021-08-18 15:08:29) > > On Mon, 26 Apr 2021 02:29:45 +0530 Nilesh Patra > wrote: > > > Package: biboumi > > > Version: 9.0-2 > > > Severity: normal > > > X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, > debian-cr...@lists.debian.org > > > > > > > Hi Vasudev, Hi Michel, > > > > gentle ping on this? > > Could you please apply this and upload a fix? > > I can have a look. Thanks for nudging! Thanks a lot for looking and uploading a quick fix! >
Bug#992399: debianutils: removes interface from essential package without proper transition
Adding a message to stderr telling people to use mktemp may be a reasonable step.
Bug#992433: RM: perl-cross-debian -- RoQA; Orphaned, Unused, Requested by maintainer
On Wed, 18 Aug 2021 10:44:41 -0400 Boyuan Yang wrote: > Package: ftp.debian.org > X-Debbugs-Cc: by...@debian.org codeh...@debian.org > Severity: normal > > Dear FTP Masters, > > As discussed in https://bugs.debian.org/c871961 , package > perl-cross-debian has been orphaned since 2017, and its ex-maintainer > (also upstream author, in cc list) indicates that it is not needed > anymore and should be removed if not adopted after 2017. Now in 2021, > I believe it's time to continue with the removal. Typo in the bug link: - it's 871961 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871961 > * The package has no reverse dependencies. > * The package has no reverse build-dependencies. > * The package has a popcon of 35 (low). More to the point, the upstream effort to support cross-building was never completed, so supporting each new version of Perl5 is a long process of porting the fixes & re-testing. Nobody else has offered to do this work and the supported versions (5.14.2, 5.16,2 and 5.17.7) no longer exist, even in oldoldstable which has 5.24.1. The removal is overdue (and became so as soon as whichever suite had 5.17.7 became oldoldstable). -- Neil Williams = https://linux.codehelp.co.uk/ pgp9jaKijpnJ6.pgp Description: OpenPGP digital signature
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 10:53:45AM -0400, Michael Stone wrote: > Adding a message to stderr telling people to use mktemp may be a reasonable > step. You mean the thing it does in our stable release?
Bug#992435: bullseye-pu: devscripts/2.21.3+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye Hi, attached an update to retarget `dch --bpo` (and `dch --stable`) from buster to bullseye. I kind of forgot to push it during the last days of the freeze. I already uploaded the package. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- diffstat for devscripts-2.21.3 devscripts-2.21.3+deb11u1 .gitlab-ci.yml | 16 ++-- debian/changelog |8 po4a/po/de.po |6 +++--- po4a/po/devscripts.pot |4 ++-- po4a/po/fr.po |6 +++--- po4a/po/pt.po |6 +++--- scripts/debchange.1|2 +- scripts/debchange.pl |6 +++--- test/test_debchange|6 +++--- 9 files changed, 28 insertions(+), 32 deletions(-) diff -Nru devscripts-2.21.3/debian/changelog devscripts-2.21.3+deb11u1/debian/changelog --- devscripts-2.21.3/debian/changelog 2021-06-30 15:11:06.0 +0200 +++ devscripts-2.21.3+deb11u1/debian/changelog 2021-08-18 17:02:14.0 +0200 @@ -1,3 +1,11 @@ +devscripts (2.21.3+deb11u1) bullseye; urgency=medium + + [ Mattia Rizzolo ] + * debchange: ++ Target bullseye-backports with --bpo. + + -- Mattia Rizzolo Wed, 18 Aug 2021 17:02:14 +0200 + devscripts (2.21.3) unstable; urgency=medium [ Johannes Schauer Marin Rodrigues ] diff -Nru devscripts-2.21.3/.gitlab-ci.yml devscripts-2.21.3+deb11u1/.gitlab-ci.yml --- devscripts-2.21.3/.gitlab-ci.yml 2021-03-16 14:16:39.0 +0100 +++ devscripts-2.21.3+deb11u1/.gitlab-ci.yml 2021-08-18 17:00:29.0 +0200 @@ -11,18 +11,6 @@ - make test - make destructive-test -unstable: +bullseye: <<: *test - image: debian:unstable - -testing: - <<: *test - image: debian:testing - -stable-bpo: - <<: *test - image: debian:stable-backports - -ubuntu-devel: - <<: *test - image: ubuntu:devel + image: debian:bullseye diff -Nru devscripts-2.21.3/po4a/po/de.po devscripts-2.21.3+deb11u1/po4a/po/de.po --- devscripts-2.21.3/po4a/po/de.po 2021-05-02 20:54:46.0 +0200 +++ devscripts-2.21.3+deb11u1/po4a/po/de.po 2021-08-18 17:01:41.0 +0200 @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: devscripts 2.18.9\n" "Report-Msgid-Bugs-To: devscri...@packages.debian.org\n" -"POT-Creation-Date: 2021-05-02 20:51+0200\n" +"POT-Creation-Date: 2021-08-18 17:00+0200\n" "PO-Revision-Date: 2020-04-25 23:04+0200\n" "Last-Translator: Chris Leick \n" "Language-Team: de \n" @@ -7222,10 +7222,10 @@ #. type: Plain text #: ../scripts/debchange.1:265 msgid "" -"Increment the Debian release number for an upload to buster-backports, and " +"Increment the Debian release number for an upload to bullseye-backports, and " "add a backport upload changelog comment." msgstr "" -"erhöht die Debian-Veröffentlichungsnummer für ein Hochladen nach buster-" +"erhöht die Debian-Veröffentlichungsnummer für ein Hochladen nach bullseye-" "backports und fügt einen Changelog-Kommentar »backport upload« hinzu." #. type: TP diff -Nru devscripts-2.21.3/po4a/po/devscripts.pot devscripts-2.21.3+deb11u1/po4a/po/devscripts.pot --- devscripts-2.21.3/po4a/po/devscripts.pot 2021-06-30 15:11:06.0 +0200 +++ devscripts-2.21.3+deb11u1/po4a/po/devscripts.pot 2021-08-18 17:02:14.0 +0200 @@ -7,7 +7,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2021-05-02 20:51+0200\n" +"POT-Creation-Date: 2021-08-18 17:00+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -5799,7 +5799,7 @@ #. type: Plain text #: ../scripts/debchange.1:265 msgid "" -"Increment the Debian release number for an upload to buster-backports, and " +"Increment the Debian release number for an upload to bullseye-backports, and " "add a backport upload changelog comment." msgstr "" diff -Nru devscripts-2.21.3/po4a/po/fr.po devscripts-2.21.3+deb11u1/po4a/po/fr.po --- devscripts-2.21.3/po4a/po/fr.po 2021-05-02 20:54:46.0 +0200 +++ devscripts-2.21.3+deb11u1/po4a/po/fr.po 2021-08-18 17:01:05.0 +0200 @@ -14,7 +14,7 @@ msgid "" msgstr "" "Project-Id-Version: devscripts\n" -"POT-Creation-Date: 2021-05-02 20:51+0200\n" +"POT-Creation-Date: 2021-08-18 17:00+0200\n" "PO-Revision-Date: 2021-05-02 20:52+0200\n" "Last-Translator: Xavier Guimard \n" "Language-Team: French \n" @@ -7230,10 +7230,10 @@ #. type: Plain text #: ../scripts/debchange.1:265 msgid "" -"Increment the Debian release number for an upload to buster-backports, and " +"Increment the Debian release number for an upload to bullseye-backports, and " "add a backport upload changelog comment." msgstr "" -"Incrémenter le numéro de publication de
Bug#992436: myproxy FTBFS on IPV6-only buildds
Source: myproxy Version: 6.2.8-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=myproxy&arch=amd64&ver=6.2.8-1&stamp=1629290865&raw=0 ... Bootstrapping MyProxy server root of trust. Creating directory /tmp/OvpeL_vrlB/.globus/certificates.test.8637.10196 Attempting to connect to ::1:45721 Attempting to connect to 127.0.0.1:45721 Successfully connected to localhost:45721 trust root bootstrap failed Unable to connect to ::1:45721 error:0200206F:system library:connect:Connection refused error:2008A067:BIO routines:BIO_connect:connect error error:0200206F:system library:connect:Connection refused hostname=localhost service=45721 error:20073067:BIO routines:conn_state:connect error error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Connection refused Unable to connect to ::1:45721 error:0200206F:system library:connect:Connection refused error:2008A067:BIO routines:BIO_connect:connect error error:0200206F:system library:connect:Connection refused hostname=localhost service=45721 error:20073067:BIO routines:conn_state:connect error error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Connection refused MyProxy Test 41 (retrieve trustroots w/o authentication): FAILED ...
Bug#992437: libgetdata8: Patch for CVE-2021-20204 breaks many regression tests
Package: libgetdata8 Version: 0.10.0-10 Severity: important Dear Maintainer, The current patch [1] for CVE-2021-20204 [2] breaks many (602 of 1638) regression tests (via "make check") and impacts basic library function. Downstream software is impacted (hence, Debian bug #992372 on KST.) For example: any dirfile with LINCOM fails to be recognized as a dirfile. Upstream has been notified of the CVE and will hopefully respond with their own patch. thanks, Graeme [1]: https://salsa.debian.org/science- team/libgetdata/-/commit/61275e4c051090ce11467207eb361a6d81c405d9 [2]: https://nvd.nist.gov/vuln/detail/CVE-2021-20204 -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgetdata8 depends on: ii libc6 2.31-11 ii libltdl7 2.4.6-15 libgetdata8 recommends no packages. libgetdata8 suggests no packages. -- no debconf information
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
On Wed, Aug 18, 2021 at 10:33:17AM +0200, fziel...@z-51.de wrote: > After todays updates and a reboot my network didn't come up anymore. > Problem is the move of /bin/run-parts to /usr/bin: > > systemd[1]: Starting Raise network interfaces... > ifup[1663]: /bin/sh: 1: /bin/run-parts: not found > ifup[1661]: ifup: pre-up script failed > systemd[1]: networking.service: Main process exited, code=exited, > status=1/FAILURE > systemd[1]: networking.service: Failed with result 'exit-code'. > systemd[1]: Failed to start Raise network interfaces. Also see #992425
Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
On Wed, 18 Aug 2021 23:19:17 +1200 Jean-Francois Pirus wrote: Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992385 No, not really. This removes a tool which is still in use. I get the desire to remove deprecated stuff, but the user friendly way is to communicate the removal of the usage to packages using said tool first, and only then removing the tool itself. Isn't that what transitions are used for? This change broke X for everyone on testing, that's not a very nice way forward. As a user I've never seen the deprecated output anywhere. It probably never for printed anywhere for Xsession?
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 03:06:07PM +, Clint Adams wrote: On Wed, Aug 18, 2021 at 10:53:45AM -0400, Michael Stone wrote: Adding a message to stderr telling people to use mktemp may be a reasonable step. You mean the thing it does in our stable release? apologies, box I checked was buster and not bullseye
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 11:22:53AM -0400, Michael Stone wrote: > apologies, box I checked was buster and not bullseye No problem, it seems evident that it did little good anyway.
Bug#985638: kdenlive: speed effect from right click does not change video speed
Hi Am 21.03.21 um 07:41 schrieb will: Package: kdenlive Version: 20.12.3-1 Severity: normal X-Debbugs-Cc: wiiliamchung...@gmail.com Dear Maintainer, Changing the video speed in the timeline via right click menu does not change the video speed, despite changing the corresponding time length. Playing back the "slowed" or "sped up" video will only display the default video speed, but cropped. This happens on both 20.12.2-1, and 20.12.3-1 Could you please retest this with version 21.04.3-3 from unstable and 21.08.0-1 from experimental and give a feedback? Thanks OpenPGP_0x12D9B04A90CBD8E4.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#992438: gmailieer FTBFS: help2man: can't get `--help' info from gmi
Source: gmailieer Version: 1.3-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=gmailieer&arch=all ... help2man --no-info --version-string=1.3-2 \ --name="Fast fetch and two-way tag synchronization between notmuch and GMail" \ --include=debian/gmi-man-include \ --output=debian/gmi.1 gmi help2man: can't get `--help' info from gmi Try `--no-discard-stderr' if option outputs to stderr make[1]: *** [debian/rules:11: debian/gmi.1] Error 127
Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
I guess more transitions are required, just by grep'ing in my local /usr I see these: /usr/bin/vimtutor:TUTORCOPY=`mktemp $tmp/tutorXX || tempfile -p tutor || echo none` /usr/bin/bzexe:tmpfile=`tempfile -p gztmp -d /tmp` || exit 1 /usr/bin/mupdf:tmp=$(tempfile -s .pdf) /usr/sbin/install-keymap:TMP=`tempfile` /usr/sbin/install-keymap:NEW=`tempfile --suffix .gz`
Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck
Package: libconfig-model-dpkg-perl Version: 2.143 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Licensecheck seemingly gets blocked from entering stable currently, due to libconfig-model-dpkg-perl 2.143 fialing its autopkgtest: not ok 14 - check scikit-learn copyright # Failed test 'check scikit-learn copyright' # at t/scanner/scan-copyright.t line 27. # --- t/scanner/examples/scikit-learn.out Mon Jan 25 17:34:01 2021 # +++ /tmp/9pPbiX1AYv Tue Aug 17 04:10:11 2021 # @@ -2,3 +2,7 @@ # Copyright: 2007-2019, The scikit-learn developers. # License: BSD-3-clause # # +Files: sklearn/* # +Copyright: no-info-found # +License: BSD-3-clause # + I don't understand exactly what that test does, but seems licensecheck identified the license for one of the files in the example directory: $ licensecheck --lines 0 --deb-fmt --recursive t/scanner/examples/scikit-learn.d t/scanner/examples/scikit-learn.d/COPYING: BSD-3-clause t/scanner/examples/scikit-learn.d/doc/README.md: *No copyright* UNKNOWN t/scanner/examples/scikit-learn.d/sklearn/base.py: *No copyright* UNKNOWN t/scanner/examples/scikit-learn.d/doc/images/inria-small.png: UNKNOWN t/scanner/examples/scikit-learn.d/sklearn/datasets/images/flower.jpg: UNKNOWN t/scanner/examples/scikit-learn.d/sklearn/datasets/images/scikit-learn-logo.bmp: UNKNOWN t/scanner/examples/scikit-learn.d/sklearn/datasets/images/sydney-primary.jpeg: UNKNOWN If this is believed to be a bug in licensecheck, then please provide a shell command to reproduce the issue, and reassign this bugreport to licensecheck. Kind regards, - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEdKgsACgkQLHwxRsGg ASFqtA//Wm1GrIACTRQvDNj6ZR0kSkF+9+hHg6l++VGqUWttP+A2bCQxAHCOTSJ8 h59KkCMATuz8BrbGBHB/Jv7M3zbAOGTIrGYt+AKPBw63kxbtSk/8P6yvpalvX2Zc TTw7tBZ7kNxdN8un4SXU6kzbSCx2E8bwDSqd3dYMm0VtBkdF+6hguND9Tu920mVh H2VMf70X0XVRn7uulBol4lFPpNLMSddFdohhIoH4cz4F4ZxX6aGGWC9AO38CDFAj k3RQDNcAkv/pPokk/5cHPqRKVWIwObC9fOhAA/1CCCSXQVmLcRLKNf2ZNIzikt++ 82kXJD6xZhCvRem5/zxh7FlnQiqvgk/7bNrayudxfybh9Q3qFQWXNx3kD/DG0/ti c3MKauBlTT+F04NmdpaN8bxaAI7mupl262jG1bBOMmpw2DwnvSivHfqPwBjK4SCC cuoksqtn8coo53wL4f9wmB3StEMs/r2P/J0u17xMPXnDCKCf1ZqUKoVHR88yxkc2 FPXRTrN3YpSsh8SGE/Yw6f6O8ln0VKIKGdrliLufG4W5lhlakwJkvfWsIJCf1ibk hCSZnfVYuKfB4VovbpnSVEpPhaG34NIGrRzJ4az3yMdutda/j59/jAAC7Kyj7wi7 XbVE8p2D9q3RBse+f93eaTCDcWShZ5tNkz74MZXlAvmynBy3Aic= =F+YP -END PGP SIGNATURE-
