Bug#1059757: firmware-sof: diff for NMU version 2023.12.1-1.1

[Chris Hofstaedtler]

Control: tags 1059757 + patch
Control: tags 1059757 + pending


Dear maintainer,

I've prepared an NMU for firmware-sof (versioned as 2023.12.1-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru firmware-sof-2023.12.1/debian/changelog firmware-sof-2023.12.1/debian/changelog
--- firmware-sof-2023.12.1/debian/changelog	2024-03-05 15:52:23.0 +0100
+++ firmware-sof-2023.12.1/debian/changelog	2024-05-30 01:19:39.0 +0200
@@ -1,3 +1,10 @@
+firmware-sof (2023.12.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr/lib instead of /lib. (Closes: #1059757)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 01:19:39 +0200
+
 firmware-sof (2023.12.1-1) unstable; urgency=medium
 
   * Update to upstream version 2023-12.1
diff -Nru firmware-sof-2023.12.1/debian/rules firmware-sof-2023.12.1/debian/rules
--- firmware-sof-2023.12.1/debian/rules	2024-03-05 15:52:23.0 +0100
+++ firmware-sof-2023.12.1/debian/rules	2024-05-30 01:19:39.0 +0200
@@ -4,7 +4,7 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
-export SOF_INSTALL_DIR=debian/firmware-sof-signed/lib/firmware/intel
+export SOF_INSTALL_DIR=debian/firmware-sof-signed/usr/lib/firmware/intel
 %:
 	dh $@
 

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Sudip Mukherjee]

On Wed, 29 May 2024 at 23:27, Luca Boccassi  wrote:
>
> On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings 
> wrote:
> > On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> > > And so, it will be great if kernel team will like to package and
> > > maintain it, if not, then I will be happy to do it. Please
> > > reject this bug report if you think bpftool should not be done
> > > separately and should live inside kernel source package.
> >
> > Since you are already maintaining libbpf I would be happy to hand
> over
> > bpftool to you.  I will try to discuss this at this evening's team
> > meeting.
>
> What about moving libbpf and bpftool to the kernel team area under
> Salsa? That way more people can help, and it can use salsa-ci too

bpftool is already with the kernel team and being built from kernel
source. And I anticipated that bpftool will move to github like
upstream libbpf did and also mentioned that at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041#83. So, its
upto the kernel team what they want to do with bpftool -
1. continue to build from kernel source and we can just close this bug
2. Split bpftool from kernel source and package it from github. The
kernel team can maintain if they want to maintain an userspace
package. If the kernel team does not want to maintain it, I can do
that.

About libbpf, I am confused with your message. What kind of help? Are
you seeing that libbpf is not maintained properly?


-- 
Regards
Sudip

Bug#1059414: open-ath9k-htc-firmware: diff for NMU version 1.4.0-108-gd856466+dfsg1-1.5

[Chris Hofstaedtler]

Control: tags 1059414 + pending


Dear maintainer,

I've prepared an NMU for open-ath9k-htc-firmware (versioned as 
1.4.0-108-gd856466+dfsg1-1.5) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog
--- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog	2023-07-26 21:09:48.0 +0200
+++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog	2024-05-30 01:01:56.0 +0200
@@ -1,3 +1,10 @@
+open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install all files below /usr. (Closes: #1059414)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 01:01:56 +0200
+
 open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install
--- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install	2023-07-26 21:09:18.0 +0200
+++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install	2024-05-30 01:01:52.0 +0200
@@ -1,2 +1,2 @@
-target_firmware/htc_*.fw lib/firmware/ath9k_htc/
+target_firmware/htc_*.fw usr/lib/firmware/ath9k_htc/
 debian/firmware-ath9k-htc.metainfo.xml usr/share/metainfo

Bug#1072185: farpd: Missing licenses

[Bastian Germann]

I am uploading a NMU to fix this and other issues.
The debdiff is attached.diff -Nru farpd-0.2/debian/changelog farpd-0.2/debian/changelog
--- farpd-0.2/debian/changelog  2023-09-05 20:05:19.0 +
+++ farpd-0.2/debian/changelog  2024-05-29 22:34:32.0 +
@@ -1,3 +1,15 @@
+farpd (0.2-11.4) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Send response to unicast instead of broadcast address (Closes: #698842)
+  * d/copyright: Convert to machine-readable format and add missing licenses
+(Closes: #1072185)
+  * d/control: Correct Standards-Version
+  * d/control: Add missing comma
+  * d/rules: Add missing dh_autoreconf_clean call
+
+ -- Bastian Germann   Wed, 29 May 2024 22:34:32 +
+
 farpd (0.2-11.3) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru farpd-0.2/debian/control farpd-0.2/debian/control
--- farpd-0.2/debian/control2023-08-17 22:18:37.0 +
+++ farpd-0.2/debian/control2024-05-29 22:34:32.0 +
@@ -3,11 +3,11 @@
 Priority: optional
 Maintainer: Javier Fernández-Sanguino Peña 
 Build-Depends: debhelper (>> 4.0.0), libdumbnet-dev, libpcap0.8-dev | 
libpcap-dev, libevent-dev, dh-autoreconf
-Standards-Version: 3.6.0.1
+Standards-Version: 3.6.0
 
 Package: farpd
 Architecture: any
-Depends: ${shlibs:Depends} ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Fake ARP user space daemon
  This ARP daemon replies to any ARP request for a set of IP addresses
  with the hardware MAC address of one of the interfaces of the
diff -Nru farpd-0.2/debian/copyright farpd-0.2/debian/copyright
--- farpd-0.2/debian/copyright  2023-08-17 22:18:27.0 +
+++ farpd-0.2/debian/copyright  2024-05-29 22:34:32.0 +
@@ -1,21 +1,23 @@
-This package was debianized by Javier Fernandez-Sanguino  on
-Thu, 27 Mar 2003 10:25:02 +0100.
-
-It was downloaded from http://www.citi.umich.edu/u/provos/honeyd/
-
-Upstream Authors: Dug Song and Niels Provos
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Javier Fernandez-Sanguino  
on
+ Thu, 27 Mar 2003 10:25:02 +0100.
+Source:
+ http://www.citi.umich.edu/u/provos/honeyd/
+Upstream-Contact:
+ Dug Song 
+ Niels Provos 
 
+Files: *
 Copyright:
-
-  
   Copyright (c) 2000, 2001, 2002 Dug Song 
   Copyright (c) 2002 Niels Provos 
   All rights reserved, all wrongs reversed.
-
+License: BSD-3-clause
   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:
-
+ .
   1. Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.
   2. Redistributions in binary form must reproduce the above copyright
@@ -24,7 +26,7 @@
   3. The names of the authors and copyright holders may not be used to
  endorse or promote products derived from this software without
  specific prior written permission.
-
+ .
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
   AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
@@ -36,3 +38,59 @@
   OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
   ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
+Files: tree.h
+Copyright:
+ Copyright 2002 Niels Provos 
+ All rights reserved.
+License: BSD-2-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ 1. Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Files:
+ daemon.c
+ err.h
+Copyright:
+ Copyright (c) 2000 Dug Song 
+ Copyright (c) 1990, 1993
+  The Regents of the University of California.  All rights reserved.
+License: BSD-4-clause-UC
+ Redistribution and use in source and binary forms, with or without
+ 

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 26/05/2024 at 22:29, Roland Clobus wrote:


Your patch series works fine, the firmware is correctly identified and 
loaded. Unfortunately for me, it still needs a reconnect cycle.

See the attached syslog for their effect. (I've used sid)


Thank you for testing my patches but I did not expect them to solve the 
reattachment issue, only to identify the right module.


After the r8712u module is first loaded without the firmware then 
unloaded and reloaded, what is the output of


ls -d /sys/bus/usb/drivers/r8712u/1-3*
ls -d /sys/bus/usb/devices/1-3/1-3*

assuming the wireless adapter is identified as 1-3 ?

Bug#1060333: atmel-firmware: diff for NMU version 1.3-7.1

[Chris Hofstaedtler]

Control: tags 1060333 + pending


Dear maintainer,

I've prepared an NMU for atmel-firmware (versioned as 1.3-7.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru atmel-firmware-1.3/debian/changelog atmel-firmware-1.3/debian/changelog
--- atmel-firmware-1.3/debian/changelog	2023-01-18 01:51:47.0 +0100
+++ atmel-firmware-1.3/debian/changelog	2024-05-30 01:05:26.0 +0200
@@ -1,3 +1,10 @@
+atmel-firmware (1.3-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr (DEP17 M2) (Closes: #1060333)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 01:05:26 +0200
+
 atmel-firmware (1.3-7) unstable; urgency=medium
 
   [ Cyril Brulebois ]
diff -Nru atmel-firmware-1.3/debian/rules atmel-firmware-1.3/debian/rules
--- atmel-firmware-1.3/debian/rules	2021-12-29 07:06:04.0 +0100
+++ atmel-firmware-1.3/debian/rules	2024-05-30 01:04:59.0 +0200
@@ -5,9 +5,9 @@
 
 override_dh_auto_install:
 	dh_auto_install
-	install -d -m 0755 debian/atmel-firmware/lib/firmware
-	install -m 0644 images/*.bin debian/atmel-firmware/lib/firmware
-	install -m 0644 images.usb/*.bin debian/atmel-firmware/lib/firmware
+	install -d -m 0755 debian/atmel-firmware/usr/lib/firmware
+	install -m 0644 images/*.bin debian/atmel-firmware/usr/lib/firmware
+	install -m 0644 images.usb/*.bin debian/atmel-firmware/usr/lib/firmware
 	install -D -m 0755 atmel_fwl.pl debian/atmel-firmware/usr/sbin/atmel_fwl
 	install -D -m 0644 atmel_fwl.8 debian/atmel-firmware/usr/share/man/man8/atmel_fwl.8
 	install -D -m 0644 atmel.conf debian/atmel-firmware/etc/pcmcia/atmel.conf

Bug#1072187: systemd: root fs read only if /tmp is in fstab

[David Burrows]

Package: systemd
Version: 256~rc3-5
Severity: important
X-Debbugs-Cc: burrows...@gmail.com

Dear Maintainer,

Installing this update led to my system booting with root (btrfs)
mounted as read only.

In my fstab I have the following:
tmpfs /tmp   tmpfs   
defaults,noatime,mode=1777 0 0

Commenting this out allowed the system to boot again with read/write.

In order to restore tmpfs I had to do the following (as root):
cp /usr/lib/systemd/system/tmp.mount /usr/share/systemd/tmp.mount

The is optional if you wish to have /tmp on root.

Prior to doing this it appears there is a broken symlink:
$ ls -l /etc/systemd/system/tmp.mount
lrwxrwxrwx 1 root root 28 Dec 30  2022 /etc/systemd/system/tmp.mount -> 
/usr/share/systemd/tmp.mount

I'm guessing that tmp in fstab is no longer default, but I didn't put it
there and it must be left over from an older install. This is consistent with
another 3 systems of mine.


-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.10-1-siduction-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.0.13-2
ii  libaudit1  1:3.1.2-2.1
ii  libblkid1  2.40.1-2
ii  libc6  2.38-11
ii  libcap21:2.66-5
ii  libcryptsetup122:2.7.2-2
ii  libfdisk1  2.40.1-2
ii  libmount1  2.40.1-2
ii  libpam0t64 [libpam0g]  1.5.3-4
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.1-3
ii  libsystemd-shared  256~rc3-5
ii  libsystemd0256~rc3-5
ii  mount  2.40.1-2

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  systemd-timesyncd [time-daemon]  256~rc3-5

Versions of packages systemd suggests:
ii  libgcrypt20 1.10.3-3
ii  libidn2-0   2.3.7-2
ii  liblz4-11.9.4-2
ii  liblzma55.6.1+really5.4.5-1
ii  libtss2-rc0t64  4.1.0-1
ii  libtss2-tcti-device0t64 [libtss2-tcti-device0]  4.1.0-1
ii  polkitd 124-2
pn  systemd-boot
ii  systemd-container   256~rc3-5
pn  systemd-homed   
ii  systemd-resolved256~rc3-5
pn  systemd-userdbd 

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 256~rc3-5
ii  libpam-systemd 256~rc3-5
ii  udev   256~rc3-5

-- no debconf information

Bug#1006655: [PATCH] Implement rm_conffile_if_unmodified

[Guillem Jover]

Control: forcemerge 330256 -1

Hi,

On Tue, 2024-05-28 at 14:28:49 -0700, Josh Triplett wrote:
> tags 1006655 + patch
> thanks
> 
> I've attached a patch implementing an rm_conffile_if_unmodifed command
> for dpkg-maintscript-helper, as well as a declarative version for
> debian/conffiles.
> 
> I've included documentation and tests for both.
> 
> Using this has the same effect as rm_conffile if the file is unmodified.
> However, if the file is modified, this leaves the file in place under
> the existing name (treating it as an obsolete conffile so that it still
> gets removed if purging the package).
> 
> Thus, unlike rm_conffile, this version is useful for packages that still
> support reading the configuration file if present, and thus don't want
> to move existing modified configuration aside with a .dpkg-bak suffix,
> because that'll prevent the modified configuration from being used.

As I mentioned in #822462, I think the default should be changed instead
to do this. I sat yesterday to see how much this would imply code wise
and ended up with a smallish patch, which then required adapting few test
cases. I also added a new --assert-unmodified-obsolete-conffile-removal
(although I'm not entirely happy with such a long name). I'd still need
to add a few more tests for downgrades, but otherwise it seems to work
fine.

Being this such a behavior change, although it seems pretty safe to
me, I think it would still deserve to be discussed in debian-dpkg and
debian-devel. The only problematic thing that comes to mind, is that
it will be harder to spot conffiles that need to be marked as
remove-on-upgrade, as test systems would automatically get rid of
unmodified conffiles.

Will try to add the missing tests and push this into a branch tomorrow,
and then try to start a thread on the mailing lists during the week or so.

Regards,
Guillem

Bug#1059378: dahdi-firmware: diff for NMU version 2.11.1.0.20170917-2.1

[Chris Hofstaedtler]

Control: tags 1059378 + pending


Dear maintainer,

I've prepared an NMU for dahdi-firmware (versioned as 2.11.1.0.20170917-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru dahdi-firmware-2.11.1.0.20170917/debian/changelog dahdi-firmware-2.11.1.0.20170917/debian/changelog
--- dahdi-firmware-2.11.1.0.20170917/debian/changelog	2023-01-28 02:07:36.0 +0100
+++ dahdi-firmware-2.11.1.0.20170917/debian/changelog	2024-05-30 00:58:10.0 +0200
@@ -1,3 +1,10 @@
+dahdi-firmware (2.11.1.0.20170917-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr instead of /. (Closes: #1059378)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 00:58:10 +0200
+
 dahdi-firmware (2.11.1.0.20170917-2) unstable; urgency=medium
 
   * Move source and binary from non-free/comm to non-free-firmware/comm
diff -Nru dahdi-firmware-2.11.1.0.20170917/debian/install dahdi-firmware-2.11.1.0.20170917/debian/install
--- dahdi-firmware-2.11.1.0.20170917/debian/install	2016-04-19 21:43:39.0 +0200
+++ dahdi-firmware-2.11.1.0.20170917/debian/install	2024-05-30 00:58:08.0 +0200
@@ -3,4 +3,4 @@
 debian/get-digium-firmware		usr/share/dahdi
 debian/OCT6104E-256D.ima		usr/share/dahdi
 build_tools/install_firmware		usr/share/dahdi
-drivers/dahdi/dahdi-fw-*.bin		lib/firmware/ 
+drivers/dahdi/dahdi-fw-*.bin		usr/lib/firmware/ 

Bug#1060358: rpcbind: diff for NMU version 1.2.6-8.1

[Chris Hofstaedtler]

Control: tags 1060358 + pending


Dear maintainer,

I've prepared an NMU for rpcbind (versioned as 1.2.6-8.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru rpcbind-1.2.6/debian/changelog rpcbind-1.2.6/debian/changelog
--- rpcbind-1.2.6/debian/changelog	2024-04-15 02:31:00.0 +0200
+++ rpcbind-1.2.6/debian/changelog	2024-05-30 00:53:15.0 +0200
@@ -1,3 +1,11 @@
+rpcbind (1.2.6-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install rpcbind into /usr/sbin (DEP17 M2). (Closes: #1060358)
+Update path in init script, systemd unit, et al.
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 00:53:15 +0200
+
 rpcbind (1.2.6-8) unstable; urgency=medium
 
   * Bump libtirpc-dev dependency to 1.3.4+ds-1.1. Closes: #1066880.
diff -Nru rpcbind-1.2.6/debian/init.d rpcbind-1.2.6/debian/init.d
--- rpcbind-1.2.6/debian/init.d	2024-04-15 02:31:00.0 +0200
+++ rpcbind-1.2.6/debian/init.d	2024-05-30 00:53:13.0 +0200
@@ -16,7 +16,7 @@
 #RPC include NFS and NIS.
 ### END INIT INFO
 
-test -f /sbin/rpcbind || exit 0
+test -f /usr/sbin/rpcbind || exit 0
 
 . /lib/lsb/init-functions
 
@@ -45,15 +45,15 @@
 exit 1
 fi
 [ -x /sbin/restorecon ] && /sbin/restorecon $STATEDIR
-pid=$( pidofproc /sbin/rpcbind )
+pid=$( pidofproc /usr/sbin/rpcbind )
 if [ -n "$pid" ]
 then
 log_action_msg "Already running: rpcbind"
 exit 0
 fi
 log_daemon_msg "Starting RPC port mapper daemon" "rpcbind"
-start-stop-daemon --start --quiet --oknodo --exec /sbin/rpcbind -- "$@"
-pid=$( pidofproc /sbin/rpcbind )
+start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/rpcbind -- "$@"
+pid=$( pidofproc /usr/sbin/rpcbind )
 echo -n "$pid" >"$PIDFILE"
 # /run/sendsigs.omit.d is created by /etc/init.d/mountkernfs.sh
 ln -sf "$PIDFILE" /run/sendsigs.omit.d/rpcbind
@@ -64,7 +64,7 @@
 stop ()
 {
 log_daemon_msg "Stopping RPC port mapper daemon" "rpcbind"
-start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --oknodo --exec /sbin/rpcbind
+start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --oknodo --exec /usr/sbin/rpcbind
 rm -f "$PIDFILE"
 log_end_msg $?
 }
@@ -90,7 +90,7 @@
 start $OPTIONS
 ;;
 status)
-status_of_proc /sbin/rpcbind rpcbind && exit 0 || exit $?
+status_of_proc /usr/sbin/rpcbind rpcbind && exit 0 || exit $?
 ;;
 *)
 log_success_msg "Usage: /etc/init.d/rpcbind {start|stop|force-reload|restart|status}"
diff -Nru rpcbind-1.2.6/debian/rpcbind.service rpcbind-1.2.6/debian/rpcbind.service
--- rpcbind-1.2.6/debian/rpcbind.service	2024-04-15 02:31:00.0 +0200
+++ rpcbind-1.2.6/debian/rpcbind.service	2024-05-30 00:53:13.0 +0200
@@ -13,7 +13,7 @@
 
 [Service]
 Environment="OPTIONS=-w"
-ExecStart=/sbin/rpcbind -f $OPTIONS
+ExecStart=/usr/sbin/rpcbind -f $OPTIONS
 EnvironmentFile=-/etc/rpcbind.conf
 EnvironmentFile=-/etc/default/rpcbind
 Type=notify
diff -Nru rpcbind-1.2.6/debian/rules rpcbind-1.2.6/debian/rules
--- rpcbind-1.2.6/debian/rules	2024-04-15 02:31:00.0 +0200
+++ rpcbind-1.2.6/debian/rules	2024-05-30 00:53:13.0 +0200
@@ -17,7 +17,7 @@
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --sbindir=/sbin --enable-warmstarts --enable-libwrap --with-statedir=/run/rpcbind --with-rpcuser=_rpc --enable-debug $(CONFIGURE_EXTRA_FLAGS)
+	dh_auto_configure -- --enable-warmstarts --enable-libwrap --with-statedir=/run/rpcbind --with-rpcuser=_rpc --enable-debug $(CONFIGURE_EXTRA_FLAGS)
 
 execute_after_dh_auto_install:
 	rm -Rf debian/rpcbind/unused
diff -Nru rpcbind-1.2.6/debian/tests/check-if-installed rpcbind-1.2.6/debian/tests/check-if-installed
--- rpcbind-1.2.6/debian/tests/check-if-installed	2024-04-15 02:31:00.0 +0200
+++ rpcbind-1.2.6/debian/tests/check-if-installed	2024-05-30 00:53:13.0 +0200
@@ -1,5 +1,5 @@
 #!/bin/bash
 
-if [ ! -f "/sbin/rpcbind" ]; then
+if [ ! -f "/usr/sbin/rpcbind" ]; then
 >&2 echo "rpcbind is not installed"
 fi

Bug#1072172: ltsp-server: ltsp-build-client fails

[Jim Mintha]

Hi Vagrant,

My apologies, I guess I still had it in my sources or something.  I will use
the new package and follow the ltsp.org docs.

You can close the bug.

Jim

- On May 29, 2024, at 11:50 AM, Vagrant Cascadian vagr...@debian.org wrote:

> On 2024-05-29, Jim Mintha wrote:
>> Package: ltsp-server
>> Version: 5.18.12-3
>> Severity: normal
>>
>> After installing the ltsp-server (and -standalone) packages I ran:
>> ltsp-build-client.
>> First time it failed with:
> 
> ltsp-server, ltsp-build-client, and all ltsp 5.x components were last
> present two stable releases ago and are no longer part of Debian.  While
> you *might* be able to get it to work by adding buster
> (a.k.a. oldoldstable) sources and various manual tweaks, I would not
> recommend it at this point... it receives no real attention or
> maintenance upstream or in any distro.
> 
> The current LTSP support is available in Debian as the "ltsp" package,
> see:
> 
>  https://ltsp.org/docs/
> 
> live well,
>   vagrant

-- 
Jim Mintha   Email: j...@popdata.bc.ca
Systems & Security ManagerWork: +1 604 827-3378
Population Data BCHome: +1 604 730-4648
University of British Columbia
_There are always Possibilities_  http://www.mintha.com

Bug#1060344: ecryptfs-utils: diff for NMU version 111-6.1

[Chris Hofstaedtler]

Control: tags 1060344 + patch
Control: tags 1060344 + pending


Dear maintainer,

I've prepared an NMU for ecryptfs-utils (versioned as 111-6.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ecryptfs-utils-111/debian/changelog ecryptfs-utils-111/debian/changelog
--- ecryptfs-utils-111/debian/changelog	2022-12-19 19:46:40.0 +0100
+++ ecryptfs-utils-111/debian/changelog	2024-05-30 00:48:02.0 +0200
@@ -1,3 +1,10 @@
+ecryptfs-utils (111-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install aliases files into /usr (DEP17 M2) (Closes: #1060344)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 00:48:02 +0200
+
 ecryptfs-utils (111-6) unstable; urgency=medium
 
   [ Andreas Metzler  ]
diff -Nru ecryptfs-utils-111/debian/ecryptfs-utils.install ecryptfs-utils-111/debian/ecryptfs-utils.install
--- ecryptfs-utils-111/debian/ecryptfs-utils.install	2013-02-09 08:05:28.0 +0100
+++ ecryptfs-utils-111/debian/ecryptfs-utils.install	2024-05-30 00:47:57.0 +0200
@@ -1,7 +1,7 @@
-lib/*/security
-sbin
+sbin/* usr/sbin/
 usr/bin
 usr/lib/*/ecryptfs
+usr/lib/*/security
 usr/share/doc
 usr/share/ecryptfs-utils
 usr/share/locale
diff -Nru ecryptfs-utils-111/debian/ecryptfs-utils.lintian-overrides ecryptfs-utils-111/debian/ecryptfs-utils.lintian-overrides
--- ecryptfs-utils-111/debian/ecryptfs-utils.lintian-overrides	2022-12-19 19:46:40.0 +0100
+++ ecryptfs-utils-111/debian/ecryptfs-utils.lintian-overrides	2024-05-30 00:47:57.0 +0200
@@ -1,3 +1,3 @@
 # false positives
-ecryptfs-utils: elevated-privileges 4755 root/root [sbin/mount.ecryptfs_private]
+ecryptfs-utils: elevated-privileges 4755 root/root [usr/sbin/mount.ecryptfs_private]
 ecryptfs-utils: executable-not-elf-or-script [usr/share/ecryptfs-utils/ecryptfs-record-passphrase]
diff -Nru ecryptfs-utils-111/debian/rules ecryptfs-utils-111/debian/rules
--- ecryptfs-utils-111/debian/rules	2020-06-16 21:31:59.0 +0200
+++ ecryptfs-utils-111/debian/rules	2024-05-30 00:47:57.0 +0200
@@ -21,7 +21,7 @@
 	dh_auto_configure -- \
 		--enable-gpg --enable-pam --enable-static --enable-tspi \
 		--disable-gui --disable-openssl --disable-pkcs11-helper \
-		--disable-pywrap \
+		--disable-pywrap --with-pamdir=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
 		CFLAGS="$(CFLAGS)"
 
 override_dh_auto_install:
@@ -30,7 +30,7 @@
 	install -D -m 0644 debian/local/ecryptfs-utils.pam-auth-update debian/ecryptfs-utils/usr/share/pam-configs/ecryptfs-utils
 
 	# Adding kmod integration
-	install -D -m 0644 debian/local/ecryptfs-utils.kmod debian/ecryptfs-utils/lib/modules-load.d/ecryptfs.conf
+	install -D -m 0644 debian/local/ecryptfs-utils.kmod debian/ecryptfs-utils/usr/lib/modules-load.d/ecryptfs.conf
 
 	# Removing useless files
 	rm -f debian/tmp/usr/lib/*/*.la
@@ -38,7 +38,7 @@
 override_dh_fixperms:
 	dh_fixperms
 
-	chmod 4755 debian/ecryptfs-utils/sbin/mount.ecryptfs_private
+	chmod 4755 debian/ecryptfs-utils/usr/sbin/mount.ecryptfs_private
 
 override_dh_install:
 	dh_install --fail-missing

Bug#1058821: x2gothinclient: diff for NMU version 1.5.0.1-10.1

[Chris Hofstaedtler]

Control: tags 1058821 + patch
Control: tags 1058821 + pending


Dear maintainer,

I've prepared an NMU for x2gothinclient (versioned as 1.5.0.1-10.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru x2gothinclient-1.5.0.1/debian/changelog x2gothinclient-1.5.0.1/debian/changelog
--- x2gothinclient-1.5.0.1/debian/changelog	2023-05-19 10:59:29.0 +0200
+++ x2gothinclient-1.5.0.1/debian/changelog	2024-05-30 00:43:28.0 +0200
@@ -1,3 +1,10 @@
+x2gothinclient (1.5.0.1-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udev.pc to place udev files. (Closes: #1058821)
+
+ -- Chris Hofstaedtler   Thu, 30 May 2024 00:43:28 +0200
+
 x2gothinclient (1.5.0.1-10) unstable; urgency=medium
 
   * debian/changelog:
diff -Nru x2gothinclient-1.5.0.1/debian/control x2gothinclient-1.5.0.1/debian/control
--- x2gothinclient-1.5.0.1/debian/control	2023-05-16 22:14:12.0 +0200
+++ x2gothinclient-1.5.0.1/debian/control	2024-05-30 00:43:25.0 +0200
@@ -8,7 +8,9 @@
 Build-Depends:
  debhelper-compat (= 13),
  qtbase5-dev,
+ pkgconf,
  po-debconf,
+ systemd-dev,
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://code.x2go.org/releases/source/x2gothinclient
diff -Nru x2gothinclient-1.5.0.1/debian/rules x2gothinclient-1.5.0.1/debian/rules
--- x2gothinclient-1.5.0.1/debian/rules	2022-10-03 11:48:15.0 +0200
+++ x2gothinclient-1.5.0.1/debian/rules	2024-05-30 00:43:25.0 +0200
@@ -4,6 +4,8 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
 export QT_SELECT=qt5
 
 DHFLAGS=--parallel
diff -Nru x2gothinclient-1.5.0.1/debian/x2gothinclient-smartcardrules.install x2gothinclient-1.5.0.1/debian/x2gothinclient-smartcardrules.install
--- x2gothinclient-1.5.0.1/debian/x2gothinclient-smartcardrules.install	2019-12-13 12:28:30.0 +0100
+++ x2gothinclient-1.5.0.1/debian/x2gothinclient-smartcardrules.install	2024-05-30 00:43:25.0 +0200
@@ -1,3 +1,3 @@
-smartcardrules/21-x2gognupgccid.ruleslib/udev/rules.d/
+smartcardrules/21-x2gognupgccid.rules${env:deb_udevdir}/rules.d/
 smartcardrules/x2gognupgccid usr/lib/x2go/tce/
 
diff -Nru x2gothinclient-1.5.0.1/debian/x2gothinclient-usbmount.install x2gothinclient-1.5.0.1/debian/x2gothinclient-usbmount.install
--- x2gothinclient-1.5.0.1/debian/x2gothinclient-usbmount.install	2019-12-13 12:28:29.0 +0100
+++ x2gothinclient-1.5.0.1/debian/x2gothinclient-usbmount.install	2024-05-30 00:43:25.0 +0200
@@ -1,3 +1,3 @@
-usbmount/61-x2gousbmount.ruleslib/udev/rules.d/
+usbmount/61-x2gousbmount.rules${env:deb_udevdir}/rules.d/
 usbmount/x2gousbmount usr/lib/x2go/tce/
 

Bug#1072186: ITP: veristat -- Tool to load, verify and debug BPF object files

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: veristat
  Version : 0.3.1
  Upstream Contact: many
* URL : https://github.com/libbpf/veristat
* License : GPL-2.0-only OR BSD-2-Clause
  Programming Lang: C
  Description : Tool to load, verify and debug BPF object files

veristat is the tool for loading, verifying, and debugging BPF object files.
It allows to work with BPF object files convenient and quickly, without having
to use or modify corresponding user-space parts of an application.


I can maintain this package.

-- 
Regards
Sudip

Bug#1072185: farpd: Missing licenses

[Bastian Germann]

Source: farpd
Version: 0.2-11
Severity: serious

The package includes more licenses than those that are listed in d/copyright.
A BSD-2-clause is in tree.h. BSD-4-clause-UC (copyright amendment allows
dropping the advertisement clause) is in daemon.c and err.h.

Bug#1065247: new lighttpd servers mangled file names

[gs-bugs . debian . org]

FYI, I submitted a patch to Debian on 19 March, over two months ago.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067126

It has taken Debian developers (volunteers) over 10 weeks (!!!)
to pick up a simple patch that I packaged for them and signed on
salsa.debian.org. :(

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Luca Boccassi]

On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings 
wrote:
> On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> > And so, it will be great if kernel team will like to package and
> > maintain it, if not, then I will be happy to do it. Please
> > reject this bug report if you think bpftool should not be done
> > separately and should live inside kernel source package.
> 
> Since you are already maintaining libbpf I would be happy to hand
over
> bpftool to you.  I will try to discuss this at this evening's team
> meeting.

What about moving libbpf and bpftool to the kernel team area under
Salsa? That way more people can help, and it can use salsa-ci too

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072184: openssh-server: Please stop writing /var/log/btmp

[Chris Hofstaedtler]

Package: openssh-server
Severity: normal

Hi Colin,

util-linux 2.40.1-3 will, as part of moving last to src:wtmpdb, also
stop installing lastb(1).
wtmpdb provides no replacement for lastb.

Please disable writing /var/log/btmp.

While openssh-server can continue writing that file, AFAIK nothing will
be left to read it.

I didn't understand this was part of the upstream changes until now,
sorry.

Thanks,
Chris

Bug#1072092: piuparts: switch default tmpdir to /var/tmp/

[Luca Boccassi]

Control: affects -1 - piuparts debos vmdb2
Control: reassign -1 piuparts

On Tue, 28 May 2024 13:14:00 +0200 Helmut Grohne 
wrote:
> Control: reassign -1 debootstrap
> Control: affects -1 + piuparts debos vmdb2
> 
> On Tue, May 28, 2024 at 12:08:37PM +0100, Luca Boccassi wrote:
> > When piuparts runs debootstrap, it is pointed to the default --
tmpdir,
> > which absent any configuration or env var is /tmp/, which is now
(since
> > systemd 256~rc3-3) a tmpfs, which as it is expected it is mounted
with
> > noudev for security reasons, but debootstrap doesn't like that as
it
> > wants to create fresh node files.
> 
> This is a problem in debootstrap. debootstrap should refrain from
> creating device nodes when doing so is not possible. Most consumers
of
> debootstrap bind mount /dev already. Reassigning.

Feel free to work on that if you like, but it is unrelated

> > Please make piuparts --tmpdir default to /var/tmp if nothing is
set, to
> > avoid this issue.
> 
> Please don't as that would make reduce piuparts performance to crap.

Currently /tmp is on the same filesystem as /var/tmp, so there are zero
performance differences. It's just a default, you can change it as you
see fit if you have some special local setup.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1066060: libpam-modules: pam_lastlog.so missing

[Chris Hofstaedtler]

Control: retitle -1 login: remove lastlog, remove pam_lastlog.so from PAM config
Control: severity -1 important

Dear shadow maintainers,

as originally requested, please drop pam_lastlog.so from the PAM
config.

Please also drop the lastlog binary, which isn't very useful when
the data it is reading is not updated anymore.

Chris

Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0

[Timo Röhling]

Source: fenics-dolfinx
Version: 1:0.8.0-6
Severity: serious
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

upgrading to nanobind 2.0 made your package FTBFS. I am sorry that I did not 
check this before uploading to unstable, that is on me. I have seen that 
Francesco has already fixed the issue upstream [1]. Depending on how far away 
the next upstream release is, maybe you can backport that fix?


Cheers
Timo

[1] 
https://github.com/FEniCS/dolfinx/commit/42c43485e81ada306f0b3f1dc735d95539174cbc


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZXnqYACgkQzIxr3RQD
9MoXDQ/8DwVCja0oy6uOKmPj6O4OO87042AQMVEzcFKWvn88I+ORD1eSdUFvesgE
88ocsjLmR2YiUNN7vgEzobe/BGuFYizuKvHITpTVAG3Iwmnoh5UBzh2AMhGXEubO
TpuX84DG2k6nQjp5qTJrxCIOCgmzjy8iHjyN70csoX6Mjj5lAN+HSmMmBVym8Tmn
EIbAFCRB1qJwmMyGXlAN9pCqQg5SmV6ikpyIfcB+T4XBdGS5F8LSF4T6qsWpHtyq
HrEgZoubY9DQxEHMUsS+UPzZBj509box1ldl7DuaPJ7JG0/PvEOuzpmuNhOmivPy
69SNnbWjVI/Y7xDH9vYaBNW2H78kybjB6oOKdEw9t/S+yN1gaLK+Jjj1Ifec1iI/
5XZ5vBo8yqF5ORpJ/dDd9LQrEukqiE+89xCa0/i6jcDSmMWwsymk11HsqDs9SxBv
+y1fINhM9C0LtvUXCJbkhFwnYoRF6q5g/GmZ7XNAJHJZTaSJfF3skLYY+5tWLv0o
h+XlcS/zyApl9dMR/uE6Az7DqpcQi0rJNseyd17j69svjChyJSSw9wAjaYYtrwrA
0aRzR58oIEfW1NVJObAlWwgmukOlGQJeZ2yRJgO8Utx1hKKbl5D3cCx4LyBEFGuH
k1ShEvxa0LPDPsrVtotY6UeGIrVKBMzfXSjXkxLbVWsPPHth8wY=
=+PF7
-END PGP SIGNATURE-

Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)

[Emanuele Rocca]

Hello Thorsten,

On 2024-05-27 02:31, Thorsten Leemhuis wrote:
> Would also help a lot to know if this is a 6.8.y only thing, or happens
> with 6.9 and mainline as well, as 6.8.y will likely be EOLed soon.

I could reproduce the issue with 6.9.2 too, will try mainline tomorrow.

FTR the procedure is quite simple. To build a sid qemu testbed:

 autopkgtest-build-qemu unstable /tmp/sid.img

Run the autopkgtest:

 autopkgtest -ddd -B dpdk -- autopkgtest-virt-qemu --debug --show-boot 
/tmp/sid.img

After a while the test hangs with:

 autopkgtest-virt-qemu: DBG: executing copydown /tmp/alog/tests-tree/ 
/tmp/autopkgtest.uG6tsJ/build.6QA/src/
 [...]
 autopkgtest-virt-qemu: DBG:  +>?

Then one can build a new kernel with:

 make oldconfig
 scripts/config --disable DEBUG_INFO
 scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
 make -j`nproc` bindeb-pkg

Boot the QCOW image:

 qemu-system-x86_64 -cpu host -machine accel=kvm -drive 
file=sid.img,format=qcow2 -m 4G -smp `nproc`

Upgrade the kernel, and run the autopkgtest again as above.

  Emanuele

Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4

[Bastian Germann]

I suggest fq renames the binary because it was introduced over 4 years later 
and has only been in one release so far.

Bug#1070322: marked as pending in kio

[Andreas B. Mundt]

Hi,

I started testing the patched kio. Unfortunatelly, it seems to not fix
all issues.  To ease testing, I export and mount from localhost and
run the following (note the link counter in ls -l):  

andi@kde:/media/samba$ ls -l test.tar.gz
ls: cannot access 'test.tar.gz': No such file or directory
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 1 andi andi 147 May 29 21:59 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 0 andi andi 147 May 29 21:59 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 1 andi andi 147 May 29 22:00 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 0 andi andi 147 May 29 22:00 test.tar.gz
   ^
andi@kde:/media/samba$ ls -l test.tar.gz
ls: cannot access 'test.tar.gz': No such file or directory

So if the archive exists, it is removed, if newly generated, it works.
No idea why the file shows up with link counter 0 if the file is
listed immediately after running ark.  It's gone if listed seperately.

Find below some more information about the setup, perhaps this gives
someone some ideas.  I'll continue tomorrow.

Best regards,

  Andi


andi@kdedaily:/media/samba$ grep -vE "^(#|;|$)" /etc/samba/smb.conf 
[global]
   workgroup = WORKGROUP
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* 
%n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[homes]
   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S
[printers]
   comment = All Printers
   browseable = no
   path = /var/tmp
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700
[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

mount:
//localhost/homes/ on /media/samba type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=andi,uid=1000,noforceuid,gid=1000,noforcegid,addr=:::::::0001,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=andi)

fstab:
//localhost/homes/ /media/samba cifs  user,nobrl,user=andi,password=123 0 0

apt list "libkf5kio*" "kio*" | grep install
kio-extras-data/stable,stable,now 4:22.12.3-1 all [installed,automatic]
kio-extras/stable,now 4:22.12.3-1 amd64 [installed,automatic]
kio-ldap/stable,now 22.12.3-1 amd64 [installed,automatic]
kio/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiocore5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiofilewidgets5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiogui5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiontlm5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiowidgets5/now 5.103.0-1+deb12u1 amd64 [installed,local]

Bug#1071501: [PATCH] NFS: add barriers when testing for NFS_FSDATA_BLOCKED

[NeilBrown]

On Wed, 29 May 2024, Trond Myklebust wrote:
> On Tue, 2024-05-28 at 11:19 +1000, NeilBrown wrote:
> > On Tue, 28 May 2024, Trond Myklebust wrote:
> > > On Mon, 2024-05-27 at 13:04 +1000, NeilBrown wrote:
> > > > 
> > > > dentry->d_fsdata is set to NFS_FSDATA_BLOCKED while unlinking or
> > > > renaming-over a file to ensure that no open succeeds while the
> > > > NFS
> > > > operation progressed on the server.
> > > > 
> > > > Setting dentry->d_fsdata to NFS_FSDATA_BLOCKED is done under -
> > > > >d_lock
> > > > after checking the refcount is not elevated.  Any attempt to open
> > > > the
> > > > file (through that name) will go through lookp_open() which will
> > > > take
> > > > ->d_lock while incrementing the refcount, we can be sure that
> > > > once
> > > > the
> > > > new value is set, __nfs_lookup_revalidate() *will* see the new
> > > > value
> > > > and
> > > > will block.
> > > > 
> > > > We don't have any locking guarantee that when we set ->d_fsdata
> > > > to
> > > > NULL,
> > > > the wait_var_event() in __nfs_lookup_revalidate() will notice.
> > > > wait/wake primitives do NOT provide barriers to guarantee order. 
> > > > We
> > > > must use smp_load_acquire() in wait_var_event() to ensure we look
> > > > at
> > > > an
> > > > up-to-date value, and must use smp_store_release() before
> > > > wake_up_var().
> > > > 
> > > > This patch adds those barrier functions and factors out
> > > > block_revalidate() and unblock_revalidate() far clarity.
> > > > 
> > > > There is also a hypothetical bug in that if memory allocation
> > > > fails
> > > > (which never happens in practice) we might leave ->d_fsdata
> > > > locked.
> > > > This patch adds the missing call to unblock_revalidate().
> > > > 
> > > > Reported-and-tested-by: Richard Kojedzinszky
> > > > 
> > > > Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
> > > > Fixes: 3c59366c207e ("NFS: don't unhash dentry during
> > > > unlink/rename")
> > > > Signed-off-by: NeilBrown 
> > > > ---
> > > >  fs/nfs/dir.c | 44 +---
> > > >  1 file changed, 29 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> > > > index ac505671efbd..c91dc36d41cc 100644
> > > > --- a/fs/nfs/dir.c
> > > > +++ b/fs/nfs/dir.c
> > > > @@ -1802,9 +1802,10 @@ __nfs_lookup_revalidate(struct dentry
> > > > *dentry,
> > > > unsigned int flags,
> > > >     if (parent != READ_ONCE(dentry->d_parent))
> > > >     return -ECHILD;
> > > >     } else {
> > > > -   /* Wait for unlink to complete */
> > > > +   /* Wait for unlink to complete - see
> > > > unblock_revalidate() */
> > > >     wait_var_event(>d_fsdata,
> > > > -      dentry->d_fsdata !=
> > > > NFS_FSDATA_BLOCKED);
> > > > +      smp_load_acquire(
> > > > >d_fsdata)
> > > > +      != NFS_FSDATA_BLOCKED);
> > > 
> > > Doesn't this end up being a reversed ACQUIRE+RELEASE as described
> > > in
> > > the "LOCK ACQUISITION FUNCTIONS" section of Documentation/memory-
> > > barriers.txt?
> > 
> > I don't think so.  That section is talking about STORE operations
> > which
> > can move backwards through ACQUIRE and forwards through RELEASE.
> > 
> > Above we have a LOAD operation which mustn't move backwards through
> > ACQUIRE.  Below there is a STORE operation which mustn't move
> > forwards
> > through a RELEASE.  Both of those are guaranteed.
> 
> It isn't necessary for the LOAD to move backwards through the ACQUIRE.
> As I understand it, the point is that the ACQUIRE can move through the
> RELEASE as per the following paragraph in that document:
> 
> Similarly, the reverse case of a RELEASE followed by an ACQUIRE 
> does
> not imply a full memory barrier.  Therefore, the CPU's execution 
> of the
> critical sections corresponding to the RELEASE and the ACQUIRE 
> can cross,
> so that:
> 
> *A = a;
> RELEASE M
> ACQUIRE N
> *B = b;
> 
> could occur as:
> 
> ACQUIRE N, STORE *B, STORE *A, RELEASE M

On the wakeup side we have:

  STORE ->d_fsdata
  RELEASE
  spin_lock
  LOAD: check is waitq is empty

and on the wait side we have

  STORE: add to waitq
  spin_unlock
  ACQUIRE
  LOAD ->d_fsdata

I believe that spin_lock is an ACQUIRE operation and spin_unlock is a
RELEASE operation.  So both of these have "ACQUIRE ; RELEASE" which
creates a full barrier.

> 
> This would presumably be why the function clear_and_wake_up_bit() needs
> a full memory barrier on most architectures, instead of being just an
> smp_wmb(). Is my understanding of this wrong?

clear_and_wake_up_bit() calls __wake_up_bit() which calls
waitqueue_active() without taking a lock.  So there is no ACQUIRE after
the RELEASE in 

Bug#1071432: /recent no longer working for debian-devel-changes

[Alexander Wirt]

On Thu, May 23, 2024 at 02:04:38PM +0200, di dit wrote:
> The original bug seems to me to be fixed but there is another issue
> which as far as I know affects only:
>   https://lists.debian.org/debian-devel-changes/recent
> The message is:
>  name 'cmp' is not defined
> 
> I didn't open a new bug report becauseit is related to "cmp" too but
> maybe it is unrelated.
> 
Oh man, fixed. Thanks

Alex


signature.asc
Description: PGP signature

Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11

[Niko Tyni]

On Wed, May 29, 2024 at 02:16:47PM +0800, Aron Xu wrote:
> On Wed, May 29, 2024 at 12:16 AM gregor herrmann  wrote:

> > Warning: program compiled against libxml 212 using older 209
> >
> > and this comes from libxml:
> >
> > https://sources.debian.org/src/libxml2/2.12.7+dfsg-2/parserInternals.c/?hl=79#L79
> >
> > if ((myversion / 100) < (version / 100)) {
> > xmlGenericError(xmlGenericErrorContext,
> > "Warning: program compiled against libxml %d using older 
> > %d\n",
> > (version / 100), (myversion / 100));
> > }
> >
> >
> > Not sure if this is should be fixed in libxml2 or if we should add an
> > artifical dependency on a newer libxml2 (to avoid testing against the
> > version in testing). The former sounds more logic to me.
> >
> 
> Although it looks trivial to remove the warning from libxml2, I'm
> reluctant since this piece of code existed for a very long time, a
> random check shows that version 2.2.3 (in 2000) has the logic:
> https://gitlab.gnome.org/GNOME/libxml2/-/blob/04698d9e1c56467007fcbb9472e5db67cf5938f5/parserInternals.c#L66

I'm a bit surprised that we haven't suffered from this before.  We've been
patching away similar things on the libxml-libxml-perl side.

But I see it only triggers with libxml2 "middle version" changes (2.x -> 2.y), 
and 
the last time that happened in Debian was in 2013. The autopkgtest checks were
not a thing back then, and I guess we've just tolerated the stderr warnings
or requested a rebuild of libxml-libxml-perl.

I suppose rebuilding on these "middle version" libxml2 changes is okay if
you want to keep the warning, even if the rebuild is strictly speaking
unnecessary. It's even conceivable that XML::LibXML might pick up new
features with the rebuild (for better or worse.)

But I think we should add dependency metadata so that the release team,
britney, debci etc. can see the need for a rebuild when we have a
"broken" combination, and then hint the "correct" versions for testing
migration together.  Updating libxml2 "middle version" would then mean
a mini-transition.

At the moment that would mean having libxml-libxml-perl
  Depends: libxml2 (>> 2.12), libxml2 (<< 2.13~)
or something like that, with the numbers automatically generated during
the build of course.

And libxml2 would need a one-time
  Breaks: libxml-libxml-perl (<<  2.0207+dfsg+really+2.0134-3)
or whichever version introduces the above dependencies.

Does that make sense or sound overkill?
-- 
Niko

Bug#1055619: Interested to be new maintainer

[Mwadime Makokha]

I am interested in being a new maintainer of the python-inotify package. I
would like your guidance.

-- 
*Mwadime Makokha*

Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

Control: tag -1 unreproducible moreinfo

Hi Bud,

Please understand that when I aksed you to carry out a specific test, I
had a good reason for doing exactly that.  The tests that you have
carried out so far, while useful, don't provide the same information.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



signature.asc
Description: This is a digitally signed message part

Bug#1071706: Acknowledgement (networkctl.1: some remarks and editorial changes for this man page)

[Bjarni Ingi Gislason]

  All generated man pages MUST have a comment telling:

what is generating them

its version

from what file is it done.

  This should be in the Debian policy!

Bug#1072172: ltsp-server: ltsp-build-client fails

[Vagrant Cascadian]

On 2024-05-29, Jim Mintha wrote:
> Package: ltsp-server
> Version: 5.18.12-3
> Severity: normal
>
> After installing the ltsp-server (and -standalone) packages I ran: 
> ltsp-build-client.  
> First time it failed with:

ltsp-server, ltsp-build-client, and all ltsp 5.x components were last
present two stable releases ago and are no longer part of Debian.  While
you *might* be able to get it to work by adding buster
(a.k.a. oldoldstable) sources and various manual tweaks, I would not
recommend it at this point... it receives no real attention or
maintenance upstream or in any distro.

The current LTSP support is available in Debian as the "ltsp" package,
see:

  https://ltsp.org/docs/

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1071629: Acknowledgement (loginctl.1: some remarks and editorial changes for this man page)

[Bjarni Ingi Gislason]

  All generated man pages MUST have a comment telling:

what is generating them

what is its version

from what file is it done.

  This should be in the Debian policy!

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Lyndon Brown]

On Wed, 2024-05-29 at 18:58 +0200, Andreas Metzler wrote:
> Hello,
> 
> That is false dichotomy. data-loss will occur when people use /tmp or
> /var/tmp for persistent data-storage because "This has (for a couple
> of
> years) worked on Debian systems" not because "This has (for a couple
> of
> years) worked on *this* *specific* Debian system.".
> 
> cu Andreas

I think you might be missing the point that this is the *DEFAULT*
behaviour. You're free to override it. If you personally have no
precious data in tmp storage to worry about then after upgrade you can
simply tweak the config to enable the new behaviour, as I have done.

I'm using Sid and after doing a little reading up on the topic
yesterday after the upgrade I believe all that needed doing was to
delete the /etc/tmpfiles.d/tmp.conf file, which as I understand it
contains a simple override of the new behaviour defined in
/usr/lib/tmpfiles.d/tmp.conf.

FWIW I think Luca made a perfectly sensible choice here.

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Ben Hutchings]

On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> Package: bpftool
> Severity: wishlist
> X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-ker...@lists.debian.org, 
> debian-de...@lists.debian.org
> 
> The official home for bpftool is now the github repo [1] but
> keeps the kernel as the authoritative source code of bpftool and
> is developed as part of the bpf-next Linux source tree.

I don't really understand the distinction they're trying to make
between "official" and "authoritative"...

> The Maintainers have said "Please use this Github repository for
> building and packaging bpftool" at [2] The announcement was at [3].
>
> imho, packaging it from the github instead of the kernel source
> will fix three issues:
> 1. bpftool will use libbpf available in Debian, whereas now it is
> building a libbpf.a from the development codes of libbpf in the
> kernel source and using that.

That's certainly a good reason.

> 2. The official releases of bpftool is done in the github repo
> when the bpf maintainers decides the code is ready for a release.
> But the Debian bpftool package is done from the kernel source and
> so follows the kernel releases. And as a result, when a new
> kernel is released which Debian kernel team will then pickup may
> not have a bpftool release worthy code. For example, bpftool v7.3
> was released on 23/11/2023,

So bpftool does not get stabilised in the kernel?  I don't really
understand why it's still in the kernel tree at all then!

> 3. bpftool package in Debian is from the kernel v6.5.13 and so
> looking at the source and git commits I can see the that the
> Debian package is missing 25 commits which is in the bpftool v7.3
> release.

Right.

> Do we package bpftool from their github repo independent of the
> kernel update? Then we will need to remove the bpftool building
> bits from the Debian kernel source and create a separate package
> for bpftool.
> 
> And so, it will be great if kernel team will like to package and
> maintain it, if not, then I will be happy to do it. Please
> reject this bug report if you think bpftool should not be done
> separately and should live inside kernel source package.

Since you are already maintaining libbpf I would be happy to hand over
bpftool to you.  I will try to discuss this at this evening's team
meeting.

Ben.

> 
> [1]. https://github.com/libbpf/bpftool
> [2]. https://github.com/libbpf/bpftool/blob/main/README.md?plain=1#L18
> [3]. 
> https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc...@isovalent.com/
> 

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



signature.asc
Description: This is a digitally signed message part

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Luca Boccassi]

Control: close -1

On Wed, 29 May 2024 20:15:36 +0200 Michael Biebl 
wrote:
> Control: reopen -1
> 
> On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi 
wrote:
> > Control: tags -1 wontfix
> > Control: close -1
> > 
> > On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl 
> > wrote:
> > > Package: systemd
> > > Version: 256~rc3-4
> > > Severity: normal
> > > 
> > > 
> > > Please do not not ship conflicting configuration for /run/lock
> > > 
> > > /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -  
-
> > > /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -
> > > 
> > > triggering unnecessary warnings.
> > 
> > This is needed to apply debian-specific changes, just ignore it,
it's
> > harmless
> 
> Besides the obvious warning message, shipping conflicting tmpfiles 
> configuration snippets also has the problem, that depending on which 
> file you override, one or the other becomes active.
> 
> Say you create a /etc/tmpfiles.d/debian.conf, then the configuration
in 
> legacy.conf becomes active and vise versa.
> This is highly confusing.

Yes, that is normal - if you change something, you need to check what's
there and what's not. This is not a new problem.

> tmpfiles entries are not easily overridable, as the mechanism is per 
> file and not per entry.
> 
> So, either legacy.conf gets split up so individual entries can be 
> overridden or your patch legacy.conf.
> 
> The current approach is not sufficient.

No. The current approach is just fine. If you don't like seeing the
harmless notice-level log, just add a local override in /etc/.

> Btw, please don't close bug reports without CCing the bug submitter. 
> That's rude.

Please stop playing ping pong with the BTS, this is staying as it is.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072177: systemd: some software crash at system start-up

[Luca Boccassi]

Control: tags -1 moreinfo

On Wed, 29 May 2024 19:08:02 +0200 Grzegorz  wrote:
> Package: systemd
> Version: 256~rc3-2
> Severity: minor
> X-Debbugs-Cc: grzeg...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
appropriate ***
> 
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

"some software crash at system start-up" is not an actionable bug
report. Please provide details - what, where, how, decoded backtraces,
etc.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Michael Biebl]

Control: reopen -1

On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  wrote:

Control: tags -1 wontfix
Control: close -1

On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl 
wrote:
> Package: systemd
> Version: 256~rc3-4
> Severity: normal
> 
> 
> Please do not not ship conflicting configuration for /run/lock
> 
> /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -   -

> /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -
> 
> triggering unnecessary warnings.


This is needed to apply debian-specific changes, just ignore it, it's
harmless


Besides the obvious warning message, shipping conflicting tmpfiles 
configuration snippets also has the problem, that depending on which 
file you override, one or the other becomes active.


Say you create a /etc/tmpfiles.d/debian.conf, then the configuration in 
legacy.conf becomes active and vise versa.

This is highly confusing.

tmpfiles entries are not easily overridable, as the mechanism is per 
file and not per entry.


So, either legacy.conf gets split up so individual entries can be 
overridden or your patch legacy.conf.


The current approach is not sufficient.


Btw, please don't close bug reports without CCing the bug submitter. 
That's rude.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071531: RFS: fvwm3/1.1.0+ds-1 -- F(?) Virtual Window Manager

[Phil Wyett]

Hi Jaimos,

Many thanks for taking the time to package this application.

Package builds perfect, the only issues I see is with 'debian/copyright'.
Running 'lrc' against the tree we get the below output.

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

GPL-2   | GPL-2+   bin/fvwm-convert-2.6.in
GPL-2   | GPL-2+   bin/fvwm-menu-directory.in
GPL-2   | GPL-2+   bin/fvwm-menu-xlock.in
GPL-2   | GPL-2+   bin/fvwm-perllib.in
GPL-2   | GPL-2+   bin/fvwm-root.c
GPL-2   | GPL  doc/fvwm3_manpage_source.adoc
GPL-2   | GPL-2+   fvwm/add_window.c
GPL-2   | GPL-2+   fvwm/bindings.c
GPL-2   | GPL-2+   fvwm/borders.c
GPL-2   | GPL-2+   fvwm/builtins.c
GPL-2   | GPL-2+   fvwm/cmdparser_old.c
GPL-2   | GPL-2+   fvwm/colormaps.c
GPL-2   | GPL-2+   fvwm/colormaps.h
GPL-2   | GPL-2+   fvwm/colorset.c
GPL-2   | GPL-2+   fvwm/conditional.c
GPL-2   | GPL-2+   fvwm/condrc.c
GPL-2   | GPL-2+   fvwm/cursor.c
GPL-2   | GPL-2+   fvwm/decorations.c
GPL-2   | GPL-2+   fvwm/events.c
GPL-2   | GPL-2+   fvwm/ewmh.c
GPL-2   | GPL-2+   fvwm/ewmh_conf.c
GPL-2   | GPL-2+   fvwm/ewmh_events.c
GPL-2   | GPL-2+   fvwm/ewmh_icons.c
GPL-2   | GPL-2+   fvwm/ewmh_names.c
GPL-2   | GPL-2+   fvwm/execcontext.c
GPL-2   | GPL-2+   fvwm/expand.c
GPL-2   | GPL-2+   fvwm/focus.c
GPL-2   | GPL-2+   fvwm/focus_policy.c
GPL-2   | GPL-2+   fvwm/frame.c
GPL-2   | GPL-2+   fvwm/functable.c
GPL-2   | GPL-2+   fvwm/functable_complex.c
GPL-2   | GPL-2+   fvwm/functions.c
GPL-2   | GPL-2+   fvwm/fvwm3.c
GPL-2   | GPL-2+   fvwm/geometry.c
GPL-2   | GPL-2+   fvwm/icccm2.c
GPL-2   | GPL-2+   fvwm/icons.c
GPL-2   | GPL-2+   fvwm/infostore.c
GPL-2   | GPL-2+   fvwm/menubindings.c
GPL-2   | GPL-2+   fvwm/menucmd.c
GPL-2   | GPL-2+   fvwm/menudim.c
GPL-2   | GPL-2+   fvwm/menugeometry.c
GPL-2   | GPL-2+   fvwm/menuitem.c
GPL-2   | GPL-2+   fvwm/menus.c
GPL-2   | GPL-2+   fvwm/menustyle.c
GPL-2   | GPL-2+   fvwm/misc.c
GPL-2   | GPL-2+   fvwm/modconf.c
GPL-2   | GPL-2+   fvwm/module_interface.c
GPL-2   | GPL-2+   fvwm/module_list.c
GPL-2   | GPL-2+   fvwm/move_resize.c
GPL-2   | GPL-2+   fvwm/placement.c
GPL-2   | GPL-2+   fvwm/read.c
GPL-2   | GPL-2+   fvwm/schedule.c
GPL-2   | NTP~disclaimer   fvwm/screen.h
GPL-2   | GPL-2+   fvwm/session.c
GPL-2   | GPL-2+   fvwm/stack.c
GPL-2   | GPL-2+   fvwm/style.c
GPL-2   | GPL-2+   fvwm/update.c
GPL-2   | GPL-2+   fvwm/virtual.c
GPL-2   | GPL-2+   fvwm/windowlist.c
GPL-2   | GPL-2+   fvwm/windowshade.c
GPL-2   | ISC  libs/asprintf.c
GPL-2   | GPL-2+   libs/BidiJoin.c
GPL-2   | GPL-2+   libs/Bindings.c
GPL-2   | GPL-2+   libs/charmap.c
GPL-2   | Expatlibs/cJSON.c
GPL-2   | Expatlibs/cJSON.h
GPL-2   | GPL-2+   libs/ClientMsg.c
GPL-2   | GPL-2+   libs/Colorset.c
GPL-2   | LGPL-2+  libs/ColorUtils.c
GPL-2   | GPL-2+   libs/CombineChars.c
GPL-2   | GPL-2+   libs/Cursor.c
GPL-2   | GPL-2+   libs/envvar.c
GPL-2   | GPL-2+   libs/Event.c
GPL-2   | GPL-2+   libs/FBidi.c
GPL-2   | GPL-2+   libs/FEvent.c
GPL-2   | GPL-2+   libs/Fft.c
GPL-2   | GPL-2+   libs/FGettext.c
GPL-2   | GPL-2+   libs/Ficonv.c
GPL-2   | GPL-2+   libs/FImage.c
GPL-2   | GPL-2+   libs/fio.c
GPL-2   | GPL-2+   libs/flist.c
GPL-2   | GPL-2+ and/or NTP libs/Flocale.c
GPL-2   | GPL-2+   libs/FlocaleCharset.c
GPL-2   | GPL-2+   libs/fqueue.c
GPL-2   | GPL-2+   libs/FRender.c
GPL-2   | GPL-2+   libs/FRenderInit.c
GPL-2   | GPL-2+   libs/FScreen.c
GPL-2   | GPL-2+   libs/FShape.c
GPL-2   | GPL-2+   libs/fsm.c
GPL-2   | GPL-2+   libs/FTips.c
GPL-2   | GPL-2+   libs/fvwmlib3.c
GPL-2 

Bug#1072182: delta: upstream location and 2020-06-22 release

[Matt Taggart]

Package: delta
Version: 2006.08.03-13

Maybe the upstream for delta is now

https://github.com/dsw/delta

There was a release on 2020-06-22 which is newer than what the package 
is using, although looking at the commits it's mostly just documentation 
changes.


popcon doesn't show many people using this, but if you care about it 
please adopt it!


--
Matt Taggart
m...@lackof.org

Bug#1072110: glslang breaks shaderc autopkgtest: undefined reference: ABI breakage?? -- not the case

[Philippe SWARTVAGHER]

Hello,

Well, this issue is "normal".

Currently, shaderc 2023.2-1 is in testing. This version suffers from an
"undefined symbol" bug
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070983). This bug is
fixed in version 2023.8-1 which is now in unstable. However, this
version never migrated to testing due to a blocking bug in glslang
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062799). This bug in
glslang is now fixed with the last upload.

I'm a beginner regarding this kind transition / blocking bug / CI, so I
don't know how this bug can be solved...

I don't know if it helps, but I have a RFS
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072181) for a new
version of shaderc (which changes nothing about this bug). You can see
on Salsa that autopkgtests pass with the version of glslang available in
unstable: https://salsa.debian.org/debian/shaderc/-/pipelines/683648.


Philippe.

Bug#1072181: RFS: shaderc/2024.1-1 -- Library API for accessing glslc functionality - shared libraries

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "shaderc":

 * Package name : shaderc
   Version  : 2024.1-1
   Upstream contact : David Neto 
 * URL  : https://github.com/google/shaderc/
 * License  : Apache-2.0, BSD-3-clause
 * Vcs  : https://salsa.debian.org/debian/shaderc
   Section  : libs

The source builds the following binary packages:

  glslc - Command line compiler for GLSL/HLSL to SPIR-V
  libshaderc-dev - Library API for accessing glslc functionality -
static libraries and headers
  libshaderc1 - Library API for accessing glslc functionality - shared
libraries

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/shaderc/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2024.1-1.dsc

Changes since the last upload:

 shaderc (2024.1-1) unstable; urgency=medium
 .
   * New upstream release
 - Refresh patch use-system-thirdparties.patch and drop patches applied
   upstream
   * Add "Forwarded: not-needed" to d/patches/rename-libshaderc.patch
   * Bump Standards-Version to 4.7.0: no change needed
   * Refresh d/copyright

Regards,
--
  Philippe

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Noah Meyerhans]

On Wed, May 29, 2024 at 06:58:32PM +0200, Andreas Metzler wrote:
> >> I think it is bad choice to deliberately have different behavior for
> >> freshly installed and upgraded systems. Offering upgrades has always
> >> been one of the major selling points of Debian, and imho this
> >> implicitely includes that you do not get a worse or second class Debian
> >> installation when you upgrade it than if you installed from scratch.
> 
> > I strongly disagree: it is a bad choice to change on upgrades a default 
> > which may cause data loss.
> 
> That is false dichotomy. data-loss will occur when people use /tmp or
> /var/tmp for persistent data-storage because "This has (for a couple of
> years) worked on Debian systems" not because "This has (for a couple of
> years) worked on *this* *specific* Debian system.".

Both perspectives are valid, and that is part of why this change is
concerning to me.  Transitioning the filesystem configuration of an
existing system is inherently dangerous and can lead to data loss, as
Marco points out.  But leaving a system to diverge from the default
Debian base configuration leads to configurtion drift that may trigger
obscure bugs, untested configuration, difficult upgrades, etc.  I'm not
convinced the change is worth the risk.

noah

Bug#1072180: golang-github-lucas-clemente-quic-go: CVE-2024-22189

[Moritz Mühlenhoff]

Source: golang-github-lucas-clemente-quic-go
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for 
golang-github-lucas-clemente-quic-go.

CVE-2024-22189[0]:
| quic-go is an implementation of the QUIC protocol in Go. Prior to
| version 0.42.0, an attacker can cause its peer to run out of memory
| sending a large number of `NEW_CONNECTION_ID` frames that retire old
| connection IDs. The receiver is supposed to respond to each
| retirement frame with a `RETIRE_CONNECTION_ID` frame. The attacker
| can prevent the receiver from sending out (the vast majority of)
| these `RETIRE_CONNECTION_ID` frames by collapsing the peers
| congestion window (by selectively acknowledging received packets)
| and by manipulating the peer's RTT estimate. Version 0.42.0 contains
| a patch for the issue. No known workarounds are available.

https://github.com/quic-go/quic-go/security/advisories/GHSA-c33x-xqrf-c478
https://github.com/quic-go/quic-go/commit/4a99b816ae3ab03ae5449d15aac45147c85ed47a
 (v0.42.0)
https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-management


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-22189
https://www.cve.org/CVERecord?id=CVE-2024-22189

Please adjust the affected versions in the BTS as needed.

Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server

[gs-bugs . debian . org]

Gianfranco, thank you for sponsoring this upload.

> Please some nitpicks for a future upload
> 1) wait for the sponsor upload before tagging,
>many of your entries were never uploaded

ack.

Still, this seems like unnecessary latency between humans once a Debian
developer volunteer picks up the sponsorship-request.  This
sponsorship-request bug was filed March 19 and as I write this, today is
May 29, over two months later.

> 2) don't create new entries if the previous ones are not yet in the archive

Should the now-incorrect tags in the repository be deleted and re-tagged?
I prefer not to move tags once the tag matches code on the master branch,
hence why I created new entries in the changelog and new tags.

Also, this sounds like a fragile limitation for which a bug should be
filed.  When uploading, it should be possible to programmatically query
the current version in the archive, find that changelog entry, and then
process the newer entries with versions between the current version in
the archive and the new version being submitted.

Cheers, Glenn

Bug#1072179: pypy3: CVE-2023-27043

[Moritz Mühlenhoff]

Source: pypy3
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for pypy3.

CVE-2023-27043[0]:
| The email module of Python through 3.11.3 incorrectly parses e-mail
| addresses that contain a special character. The wrong portion of an
| RFC2822 header is identified as the value of the addr-spec. In some
| applications, an attacker can bypass a protection mechanism in which
| application access is granted only after verifying receipt of e-mail
| to a specific domain (e.g., only @company.example.com addresses may
| be used for signup). This occurs in email/_parseaddr.py in recent
| versions of Python.

https://github.com/python/cpython/issues/102988


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27043
https://www.cve.org/CVERecord?id=CVE-2023-27043

Please adjust the affected versions in the BTS as needed.

Bug#1072178: libnetwork-ipv4addr-perl: CVE-2021-47155

[Moritz Mühlenhoff]

Source: libnetwork-ipv4addr-perl
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for libnetwork-ipv4addr-perl.

CVE-2021-47155[0]:
| The Net::IPV4Addr module 0.10 for Perl does not properly consider
| extraneous zero characters in an IP address string, which (in some
| situations) allows attackers to bypass access control that is based
| on IP addresses.

https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/#net-ipv4addrhttpsmetacpanorgreleasenet-ipv4addr


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-47155
https://www.cve.org/CVERecord?id=CVE-2021-47155

Please adjust the affected versions in the BTS as needed.

Bug#1066043: RFS: lem/2022-12-10+dfsg-1 [ITP] -- Tool merging math and logic for executable definitions (tool)

[Phil Wyett]

Hi Bo,

Bringing onto RFS now and for all reviews in the future as was requested on IRC.

Bo, As was discussed on the mentors webite. The package review has taken place
and I believe this package is now ready for entry into Debian. Many thanks for
creating this package for Debian.

Note: If any other mentors/developers would like to offer constructive criticism
on the package it would be gratefully received.

Regards

Phil

-- 

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


signature.asc
Description: This is a digitally signed message part

Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…

[Jean-Guilhem Cailton]

Le 26/05/2024 à 21:58, Sebastian Andrzej Siewior a écrit :

It seems to me that having both :i386 and :amd64 libraries increases the
risk of failure, because of the many "apt" steps that can take place between
the removal of old :amd64 (that may happen close to the treatment of the
:i386 version, like here for libssl3) and install of t64:amd64. On the
contrary, when only :amd64 is present, it seems that the replacement install
closely follows the removal.

how did you have two versions? I couldn't install :amd64 and :i386 of
that package. I tried several bookworm -> testing upgrade but in
bookworm I could install either :i386 or :amd64 version of postgres.
Installing the other version removed the former…
I performed a few upgrades and all succeeded. Anyway to reproduce what
you did?




I have only version :amd64 of postgresql.
(As a reminder, it was systemctl:amd64 that failed during upgrade of 
postgresql-16, because libssl3:amd64 had been removed "at the same time" 
than libssl3:i386, and only libssl3t64:i386 had been installed then — 
libssl3t64:amd64 was likely planned to get installed later.)


It was other packages, in the past, that have required :i386 libraries. 
I don’t remember which packages now.


For example, I have an old skype:i386 installed (version: 4.3.0.37-1), 
that depended on libssl1.0.0. Maybe that caused libssl3:i386 to become 
installed through some upgrade path. (Or maybe libssl3 was a dependency 
from another :i386 package.)


To reproduce, you would likely have to have some :i386 package 
installed, that depended on libssl3:i386. (Or maybe just libssl3:i386 
would be enough?)


Jean-Guilhem

Bug#1070343: closed by Debian FTP Masters (reply to Daniel Echeverri ) (Bug#1070343: fixed in openfortivpn 1.22.0-2)

[Francesco Poli]

On Thu, 16 May 2024 14:51:04 + Debian Bug Tracking System wrote:

[...]
>  openfortivpn (1.22.0-2) unstable; urgency=medium
>  .
>[ Bastian Germann ]
>* Disable legacy-pppd (Closes: #1070343)
[...]

Many thanks!   :-)
I can confirm that openfortivpn/1.22.0-2 works without any need to add
options to the pre-pppd-v2.5 configuration.

This is very appreciated.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp615DjVW0LR.pgp
Description: PGP signature

Bug#1072176: autogen.1: some remarks and editorial changes for this man page

[Andreas Metzler]

On 2024-05-29 Bjarni Ingi Gislason  wrote:
> Package: autogen
> Version: 1:5.18.16-5+b1
> Severity: minor
> Tags: patch

> [Copy is sent to autogen-us...@lists.sourceforge.net]

> Dear Maintainer,

>* What led up to the situation?

>   Checking for defects with

> [test-]groff -mandoc -t -K utf8 -ww -b -z 

>   [test-groff is a script in the repository for "groff"]

>* What was the outcome of this action?

> troff: backtrace: file '':30
> troff::30: warning: register 'Pp' not defined
> troff: backtrace: file '':319
> troff::319: warning: macro 'Ss' not defined

>* What outcome did you expect instead?

>   No output (warnings).

> -.-

>   Where are these undefined variables ment to be defined?

>   Where are these variables documented?

>   Notes and a patch are in the attachments.
[...]

Hello Bjarni,

autogen.1 is an autogenerated file there is litle use in trying to patch
it. Since autogen itself (which generates the manpage) is also EOL this
is very unlikely to be touched.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#911189: gpgme-json packaging

[Andreas Metzler]

On 2024-05-17 Detlef Eppers  wrote:
[...]
> So I'm throwing my hat in the ring for gpgme-json :)
[...]

Given that iirc Ubuntu has gone with gpgme-json we will probably go this
avenue, when we package it.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-29 Marco d'Itri  wrote:
> On May 28, Andreas Metzler  wrote:

>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.

> I strongly disagree: it is a bad choice to change on upgrades a default 
> which may cause data loss.

Hello,

That is false dichotomy. data-loss will occur when people use /tmp or
/var/tmp for persistent data-storage because "This has (for a couple of
years) worked on Debian systems" not because "This has (for a couple of
years) worked on *this* *specific* Debian system.".

cu Andreas

Bug#1072176: autogen.1: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: autogen
Version: 1:5.18.16-5+b1
Severity: minor
Tags: patch

[Copy is sent to autogen-us...@lists.sourceforge.net]

Dear Maintainer,

   * What led up to the situation?

  Checking for defects with

[test-]groff -mandoc -t -K utf8 -ww -b -z 

  [test-groff is a script in the repository for "groff"]

   * What was the outcome of this action?

troff: backtrace: file '':30
troff::30: warning: register 'Pp' not defined
troff: backtrace: file '':319
troff::319: warning: macro 'Ss' not defined

   * What outcome did you expect instead?

  No output (warnings).

-.-

  Where are these undefined variables ment to be defined?

  Where are these variables documented?

  Notes and a patch are in the attachments.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages autogen depends on:
ii  guile-3.0-libs  3.0.9-1+b2
ii  libc6   2.38-11
ii  libopts25   1:5.18.16-5+b1
ii  libopts25-dev   1:5.18.16-5+b1
ii  libxml2 2.9.14+dfsg-1.3+b3
ii  perl5.38.2-4

Versions of packages autogen recommends:
ii  autogen-doc  1:5.18.16-5

autogen suggests no packages.

-- no debconf information
  Any program (person), that produces man pages, should check its content for
defects by using

groff -mandoc -t -ww -b -z [ -K utf8 | k ] 

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any generator should check its products with the above mentioned
'groff' and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The generator may have to be corrected to get a better man page,
the source file may, and any additional file may.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint autogen.1": (possibly shortened list)

mandoc: autogen.1:209:93: STYLE: input text line longer than 80 bytes: This 
option takes a ...
mandoc: autogen.1:319:2: ERROR: skipping unknown macro: .Ss "These options can 
be used to control what gets processed
mandoc: autogen.1:371:2: WARNING: skipping paragraph macro: br before sp
mandoc: autogen.1:488:2: WARNING: skipping paragraph macro: PP empty
mandoc: autogen.1:567:2: WARNING: skipping paragraph macro: PP empty
mandoc: autogen.1:572:95: STYLE: input text line longer than 80 bytes: This 
program is rele...

-.-.

Change '-' (\-) to '\(en' (en-dash) for a numeric range.
GNU gnulib has recently (2023-06-18) updated its
"build_aux/update-copyright" to recognize "\(en" in man pages.

autogen.1:571:Copyright (C) 1992-2018 Bruce Korb all rights reserved.

-.-.

Change two HYPHEN-MINUSES (code 0x2D) to an em-dash (\(em),
if one is intended.  An en-dash is usually surrounded by a space,
while an em-dash is used without spaces.
"man" (1 byte characters in input) transforms an en-dash (\(en) to one
HYPHEN-MINUS,
and an em-dash to two HYPHEN-MINUSES without considering the space
around it.
If "--" are two single "-" (end of options) then use "\-\-".

autogen.1:84:Specify, \fB--no-definitions\fP when you wish to process
autogen.1:284:in.  For example, \fB--traceout='| less'\fP will run the trace 
output
autogen.1:334:specify \fB--skip-suffix=c\fP on the command line.

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


262:(i.e. the text outside of macro quotes).  Additionally, if you rebuild

-.-.

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

84:Specify, \fB--no-definitions\fP when you wish to process
284:in.  For example, \fB--traceout='| less'\fP will run the trace output
334:specify \fB--skip-suffix=c\fP on the command line.

-.-.

Use the correct macro for the font change of a single argument or

Bug#1070256: closed by Debian FTP Masters (reply to Alec Leamas ) (Bug#1070256: fixed in libcxx-serial 1.2.1-6)

[Adrian Bunk]

On Wed, May 29, 2024 at 05:15:45PM +0200, Alec Leamas wrote:
>...
> I can see the build log, but have problems reproducing the problem. In
> short, I do
> 
> $ export DEB_BUILD_OPTIONS=nobench nocheck parallel=2
> $ dpkg-buildpackage --sanitize-env -us -uc -B -rfakeroot
> 
> which configures and builds successfully.
> 
> Attaching the build log. Have you any hint about what's going on?

$ export DEB_BUILD_OPTIONS=nobench nocheck parallel=2
$ echo $DEB_BUILD_OPTIONS
nobench
$ export DEB_BUILD_OPTIONS="nobench nocheck parallel=2"
$ echo $DEB_BUILD_OPTIONS
nobench nocheck parallel=2
$

> Cheers!
> --alec

cu
Adrian

Bug#1026898: [External] Re: Bug#1026898: deprecate QUOTAUSER post-bookworm

[Merlin Hansen]

Hi Marc,

Unfortunately I have no experience in creating test cases for a package build. 
However, point me in a direction where I can learn and I'm willing to look into 
the feasibility of contributing.

Cheers,
Merlin.

--
Merlin Hansen
Computer Science Technician,
IT Endpoint Systems Administrator,
Vancouver Island University
900 Fifth Street
Nanaimo BC  V9R 5S5
250-753-3245 x 2321
merlin.han...@viu.ca

From: Marc Haber 
Sent: May 28, 2024 10:45 PM
To: Merlin Hansen ; 1026...@bugs.debian.org 
<1026...@bugs.debian.org>
Subject: [External] Re: Bug#1026898: deprecate QUOTAUSER post-bookworm

[You don't often get email from mh+debian-b...@zugschlus.de. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

External Email: This email was sent from outside VIU, treat links and 
attachments with extra caution.

On Tue, May 28, 2024 at 10:48:54PM +, Merlin Hansen wrote:
> Just ran across the notification of deprecation when upgrading Proxmox v2 to 
> v3. We also use QUOTAUSER in multi-user systems in a post-secondary 
> environment. While we can modify our account creation process to manually set 
> the quota using "edquota -p foo bar", having the QUOTAUSER option configured 
> ensures no accounts get created without a quota set (as another submitter 
> mentioned).

Would you be willing to submit test cases so that we can have QUOTAUSER
tested during package build? We would also appreciate code that has
adduser error out more nicely (preferably before doing any changes to
the system) of edquota isnt installed.

My main concern about QUOTAUSER is that we currently dont have tests and
know that it leaves half-setup users if edquota isnt there.

Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1072175: texlive-lang-japanese: missing Breaks+Replaces: texlive-binaries (<< 2024)

[Andreas Beckmann]

Package: texlive-lang-japanese
Version: 2024.20240401-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict
Control: affects -1 + texlive-full

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Unpacking texlive-lang-japanese (2024.20240401-2) over (2022.20230122-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-RX4bNT/12-texlive-lang-japanese_2024.20240401-2_all.deb 
(--unpack):
   trying to overwrite '/usr/share/man/man1/pbibtex.1.gz', which is also in 
package texlive-binaries 2022.20220321.62855-5.1+deb12u1


According to snapshot.d.o, texlive-binaries 2024.20240313.70630+ds-1
was the first version no longer shipping (u)pbibtex.1.gz


cheers,

Andreas


texlive-full_2024.20240401-2.log.gz
Description: application/gzip

Bug#1058839: opencpn: diff for NMU version 5.8.4+dfsg-1.1

[Chris Hofstaedtler]

Control: tags 1058839 + patch
Control: tags 1058839 + pending


Dear maintainer,

I've prepared an NMU for opencpn (versioned as 5.8.4+dfsg-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru opencpn-5.8.4+dfsg/debian/changelog opencpn-5.8.4+dfsg/debian/changelog
--- opencpn-5.8.4+dfsg/debian/changelog	2023-06-15 20:26:20.0 +0200
+++ opencpn-5.8.4+dfsg/debian/changelog	2024-05-29 17:45:16.0 +0200
@@ -1,3 +1,10 @@
+opencpn (5.8.4+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udev.pc to place udev files. (Closes: #1058839)
+
+ -- Chris Hofstaedtler   Wed, 29 May 2024 17:45:16 +0200
+
 opencpn (5.8.4+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru opencpn-5.8.4+dfsg/debian/control opencpn-5.8.4+dfsg/debian/control
--- opencpn-5.8.4+dfsg/debian/control	2023-05-17 10:09:06.0 +0200
+++ opencpn-5.8.4+dfsg/debian/control	2024-05-29 17:45:15.0 +0200
@@ -30,8 +30,10 @@
  libwxgtk3.2-dev | libwxgtk3.0-gtk3-dev,
  libwxgtk-webview3.2-dev | libwxgtk-webview3.0-gtk3-dev,
  lsb-release,
+ pkgconf,
  portaudio19-dev,
- rapidjson-dev
+ rapidjson-dev,
+ systemd-dev
 Standards-Version: 4.6.2
 Vcs-Browser: https://gitlab.com/leamas/opencpn
 Vcs-Git: https://gitlab.com/leamas/opencpn.git -b debian/sid
diff -Nru opencpn-5.8.4+dfsg/debian/opencpn.install opencpn-5.8.4+dfsg/debian/opencpn.install
--- opencpn-5.8.4+dfsg/debian/opencpn.install	2023-05-07 09:06:59.0 +0200
+++ opencpn-5.8.4+dfsg/debian/opencpn.install	2024-05-29 17:45:15.0 +0200
@@ -1,4 +1,4 @@
-lib/udev/rules.d/98-sglock-ocpn.rules
+lib/udev/rules.d/98-sglock-ocpn.rules ${env:deb_udevdir}/rules.d/
 usr/bin/opencpn
 usr/bin/opencpn-cmd
 usr/lib/opencpn/*.so
diff -Nru opencpn-5.8.4+dfsg/debian/rules opencpn-5.8.4+dfsg/debian/rules
--- opencpn-5.8.4+dfsg/debian/rules	2023-05-07 09:06:59.0 +0200
+++ opencpn-5.8.4+dfsg/debian/rules	2024-05-29 17:45:15.0 +0200
@@ -1,4 +1,5 @@
 #!/usr/bin/make -f
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
 
 include  /usr/share/dpkg/architecture.mk
 

Bug#1072174: dracut 060+5-8 plus systemd 256~rc3-2 still hang on boot

[Farblos]

Package: dracut
Version: 060+5-8
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

Recent update to dracut 060+5-8 and systemd 256~rc3-2.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Regenerated initrd, rebooted on a system with unencrypted boot and
encrypted root device.  The system uses systemd-cryptsetup and has
a FIDO2 device set up in one of the LUKS slots.

   * What was the outcome of this action?

Getting errors related to /usr not being writable while initrd
operates.  The systemd-cryptsetup prompt for the FIDO2 device show up,
but after that the boot hangs waiting for the root device to occur.

Will try to send a screenshot of the errors in a separate mail.

   * What outcome did you expect instead?

Clean boot.

   * Other information

I'm aware of Debian bugs #1071278, #1056108, and related.  But even
though these (and related) should be fixed on my system it hangs
during boot.

This issue should be related to the "ProtectSystem" parameter: If I
set that to false and the regenerate the initrd, then the system
comes up as expected.

So probably there are still more problems that need to be fixed in
dracut to not write to /usr ...

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut depends on:
ii  dracut-core  060+5-8

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1072173: riseup-vpn: obfs4 connection fails with socks5 proxy connection refused socks-error

[hgj]

Package: riseup-vpn
Version: 0.24.5+ds1-2~bpo12+1
Severity: normal
X-Debbugs-Cc: h...@riseup.net

Dear Maintainer,

I have just upgraded riseup-vpn to the backport version on Debian stable, but it
fails to connect with socks-error, I saw the line  

start socks5 proxy 127.0.0.1:8080

in both the verbose log and riseup-vpn
connection parameters. The following error message repeats itself and
riseup vpn fails to connect.
```
2024/05/29 23:36:12 New connection into the management
2024/05/29 23:36:12 cannot dial: dial tcp 204.13.164.252:443: connect:
connection refused
2024/05/29 23:36:12 Event: INFO: OpenVPN Management Interface Version 5
-- type 'help' for more info
2024/05/29 23:36:13 Event: TCP_CONNECT
```
Here on the machine there is a tor instance running at 127.0.0.1:9050, I
am not sure if this causes any conflict between riseup-vpn and tor. I
start riseup-vpn from terminal commandline and there is no proxy related
environment variables loaded. 

Thanks.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12+bpo-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, 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 riseup-vpn depends on:
ii  ca-certificates 20230311
ii  iproute26.1.0-3
ii  iptables1.8.9-2
ii  libc6   2.36-9+deb12u7
ii  libgcc-s1   12.2.0-14
ii  libqt6core6 6.4.2+dfsg-10
ii  libqt6gui6  6.4.2+dfsg-10
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6svg6  6.4.2-2
ii  libqt6widgets6  6.4.2+dfsg-10
ii  libstdc++6  12.2.0-14
ii  lxpolkit [polkit-1-auth-agent]  0.5.5-2+b1
ii  openvpn 2.6.3-1+deb12u2
ii  pkexec  122-3
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1+b1
ii  qml6-module-qt-labs-platform6.4.2+dfsg-1
ii  qml6-module-qt-labs-settings6.4.2+dfsg-1
ii  qml6-module-qt5compat-graphicaleffects  6.4.2-1
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg-1
ii  qml6-module-qtquick 6.4.2+dfsg-1
ii  qml6-module-qtquick-controls6.4.2+dfsg-1
ii  qml6-module-qtquick-dialogs 6.4.2+dfsg-1
ii  qml6-module-qtquick-layouts 6.4.2+dfsg-1
ii  qml6-module-qtquick-templates   6.4.2+dfsg-1
ii  qml6-module-qtquick-window  6.4.2+dfsg-1

Versions of packages riseup-vpn recommends:
ii  qt6-wayland  6.4.2-1

riseup-vpn suggests no packages.

-- no debconf information

Bug#1069909: dcraw: diff for NMU version 9.28-5.1

[Eriberto Mota]

> Dear Eriberto,
> 
>   thank you for preparing of the upload. I think it
> is completelly ready to be published thanks to you.
> 
> Best regards,
> FH
> --
> PS. Sorry I am late, the end semester is hectic.

Hi Filip,

Thanks for your reply. I just uploaded the NMU revision.

I wish you a good end of the semester.

Regards,

Eriberto

Bug#1054086: lsm: let dh_installsystemd choose the location of units

[Lucas Castro]

Em 25/05/2024 17:42, Lucas Castro escreveu:


Em 25/05/2024 17:23, Chris Hofstaedtler escreveu:

Dear Maintainer,

On Mon, Oct 16, 2023 at 08:11:55PM +0200, Helmut Grohne wrote:

Source: lsm
Version: 1.0.4-2

I've prepared an NMU and uploaded to DELAYED/7. It is time to get
this done.

Feel free to fix this bug yourself before this time.


Chris, the bug was fixed.

There's a RFS, if I'm waiting for someone to sponsor it, if you don't 
mind, feel free to sponsorship it.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064297


I would like the NMU be canceled.







Best,
Chris



OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040696: kbd: setfont doesn't set a default font

[Sven Grewe]

Control: block 741874 by -1


> Given the $ and the error message, I assume this is a permission problem
> on your side. Does it not work if you run it as a user that has access
> to modify the console (eg. root)?

I tried it again and can confirm that it doesn't say anything with root.

However, attempting this in a tty with and without root gave me the 
following error message:

setfont: ERROR setfont.c:406 kfont_load_font: Cannot find default font

Kind regards,
Sven Grewe

Bug#1059516: chasquid: diff for NMU version 1.13-1.1

[Chris Hofstaedtler]

Control: tags 1059516 + patch
Control: tags 1059516 + pending


Dear maintainer,

I've prepared an NMU for chasquid (versioned as 1.13-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru chasquid-1.13/debian/changelog chasquid-1.13/debian/changelog
--- chasquid-1.13/debian/changelog	2023-12-26 15:22:37.0 +0100
+++ chasquid-1.13/debian/changelog	2024-05-29 17:40:23.0 +0200
@@ -1,3 +1,11 @@
+chasquid (1.13-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units into /usr instead of /. (Closes: #1059516)
+Build-Depend on newer debhelper supporting that path.
+
+ -- Chris Hofstaedtler   Wed, 29 May 2024 17:40:23 +0200
+
 chasquid (1.13-1) unstable; urgency=medium
 
   * New upstream release (1.13)
diff -Nru chasquid-1.13/debian/control chasquid-1.13/debian/control
--- chasquid-1.13/debian/control	2023-12-26 15:22:37.0 +0100
+++ chasquid-1.13/debian/control	2024-05-29 17:40:15.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Debian Go Packaging Team 
 Uploaders: Martina Ferrari ,
Alberto Bertogli 
-Build-Depends: debhelper (>= 13~),
+Build-Depends: debhelper (>= 13.11.6~),
debhelper-compat (= 13),
dh-golang (>= 1.18~),
golang-any,
diff -Nru chasquid-1.13/debian/install chasquid-1.13/debian/install
--- chasquid-1.13/debian/install	2023-12-26 15:22:37.0 +0100
+++ chasquid-1.13/debian/install	2024-05-29 17:40:15.0 +0200
@@ -9,5 +9,5 @@
 # Override the service and sockets, as we make small Debian-specific
 # changes to it, and retain the 1.10 structure (it was changed in 1.11 and we
 # have not yet updated the Debian package to it).
-debian/systemd/*.service	lib/systemd/system/
-debian/systemd/*.socket		lib/systemd/system/
+debian/systemd/*.service	usr/lib/systemd/system/
+debian/systemd/*.socket		usr/lib/systemd/system/

Bug#1072172: ltsp-server: ltsp-build-client fails

[Jim Mintha]

Package: ltsp-server
Version: 5.18.12-3
Severity: normal

After installing the ltsp-server (and -standalone) packages I ran: 
ltsp-build-client.  
First time it failed with:

> E: The repository 'http://security.debian.org bookworm/updates Release' does 
> not have a Release file.
> N: Updating from such a repository can't be done securely, and is therefore 
> disabled by default.
> N: See apt-secure(8) manpage for repository creation and user configuration 
> details.
> error: LTSP client installation ended abnormally

I reran with: ltsp-build-client --copy-sourceslist
this went further but failed with:

> ...
> I: Configuring locales...
> I: Base system installed successfully.
> Generating locales (this might take a while)...
>   en_US.UTF-8... done
> Generation complete.
> Adding 'diversion of /sbin/start-stop-daemon to /sbin/start-stop-daemon.real 
> by ltsp-client'
> dpkg-divert: warning: diverting file '/sbin/start-stop-daemon' from an 
> Essential package with rename is dangerous, use --no-rename
> update-alternatives: using /usr/sbin/policy-rc.d.ltsp to provide 
> /usr/sbin/policy-rc.d (policy-rc.d) in auto mode
> Adding 'diversion of /etc/mtab to /etc/mtab.real by ltsp-client'
> renamed '/opt/ltsp/amd64/etc/apt/sources.list' -> 
> '/opt/ltsp/amd64/etc/apt/sources.list.old'
> Hit:1 http://deb.debian.org/debian bookworm InRelease
> Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
> Get:3 http://deb.debian.org/debian bookworm/main Translation-en [6109 kB]
> Ign:4 http://security.debian.org bookworm/updates InRelease
> Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [13.8 
> kB]
> Get:6 http://deb.debian.org/debian bookworm-updates/main Translation-en [16.0 
> kB]  
> Err:7 http://security.debian.org bookworm/updates Release 
>
>   404  Not Found [IP: 151.101.194.132 80]
> Reading package lists... Done
> E: The repository 'http://security.debian.org bookworm/updates Release' does 
> not have a Release file.
> N: Updating from such a repository can't be done securely, and is therefore 
> disabled by default.
> N: See apt-secure(8) manpage for repository creation and user configuration 
> details.
> error: LTSP client installation ended abnormally


There is no ltsp-client package in debian.  When I changed:
/usr/share/ltsp/plugins/ltsp-build-client/Debian/000-basic-configuration
and removed the line:
EARLY_PACKAGES=${EARLY_PACKAGES:-"ltsp-client"}

then it ran to completion.


-- Package-specific info:
packages in chroot: /opt/ltsp/amd64

found: /opt/ltsp/amd64/etc/lts.conf
# This is the default lts.conf file for ltsp 5.  For more information about
# valid options please see lts.conf(5) man page, available in the ltsp-docs
# package.
#
# Note that things like sound and local device support are auto-enabled if the
# corresponding packages are installed, there is no need to manually set these
# options anymore.

[default] 
LTSP_CONFIG=True
#SOUND=False
#LOCALDEV=False
#CONFIGURE_X=False

found image: /opt/ltsp/images/amd64.img
/opt/ltsp/images/amd64.img: Squashfs filesystem, little endian, version 4.0, 
zlib compressed, 206811945 bytes, 13124 inodes, blocksize: 131072 bytes, 
created: Wed May 29 05:32:47 2024


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ltsp-server depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  debconf-utils  1.5.82
ii  debootstrap1.0.128+nmu2+deb12u1
ii  gettext-base   0.21-12
ii  iproute2   6.1.0-3
ii  lsb-release12.0-1
ii  openssh-client 1:9.2p1-2+deb12u2
ii  tcpd   7.6.q-32

Versions of packages ltsp-server recommends:
ii  dnsmasq   2.89-1
ii  gnupg 2.2.40-1.1
ii  nbd-server1:3.24-1.1
ii  openbsd-inetd [inet-superserver]  0.20221205-2~deb12u1
ii  openssh-server1:9.2p1-2+deb12u2
ii  squashfs-tools1:4.5.1-1

Versions of packages ltsp-server suggests:
pn  audiooss  
ii  dnsmasq   2.89-1
ii  ldm-server2:2.18.06-1+deb10u1
ii  libasound2-plugins1.2.7.1-1
ii  ltspfs1.5-2
ii  marco [x-window-manager]  1.26.1-3+deb12u2
ii  mate-desktop-environment  1.26.0+1
ii  mate-session-manager [x-session-manager]  1.26.0-1+deb12u1
ii  pulseaudio16.1+dfsg1-2+b1
pn  qemu-user-static   

Bug#1070256: closed by Debian FTP Masters (reply to Alec Leamas ) (Bug#1070256: fixed in libcxx-serial 1.2.1-6)

[Alec Leamas]

On Thu, 23 May 2024 21:19:14 +0300 Adrian Bunk  wrote:

Control: reopen -1

On Sun, May 12, 2024 at 07:09:07PM +, Debian Bug Tracking System wrote:
>...
> Changes:
>  libcxx-serial (1.2.1-6) trixie; urgency=medium
>  .
>* Avoid crash when running with nocheck profile. Closes: #1070256
>...

1.2.1-7 does still FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial=sh4=1.2.1-7=1715548569=0

ifeq (,$(findstring nocheck,$(DEB_BUILD_PROFILES)))
ENABLE_TESTS := ON
else
ENABLE_TESTS := OFF
endif


This should be DEB_BUILD_OPTIONS, not DEB_BUILD_PROFILES.



I can see the build log, but have problems reproducing the problem. In 
short, I do


$ export DEB_BUILD_OPTIONS=nobench nocheck parallel=2
$ dpkg-buildpackage --sanitize-env -us -uc -B -rfakeroot

which configures and builds successfully.

Attaching the build log. Have you any hint about what's going on?

Cheers!
--alec

dpkg-buildpackage: info: source package libcxx-serial
dpkg-buildpackage: info: source version 1.2.1-7
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Alec Leamas 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-build-Fix-packaging-issues.patch
dpkg-source: info: applying 0002-Avoid-using-v8stdint.h-if-not-required.patch
dpkg-source: info: applying 0003-on-Linux-use-CLOCK_MONOTONIC-for-clock_gettime.patch
dpkg-source: info: applying 0004-resource-leak-if-exception-in-SerialImpl-constructor.patch
dpkg-source: info: applying 0005-Support-500kbps-serial-ports.-167.patch
dpkg-source: info: applying 0006-Fix-memory-leak-when-exception-is-thrown-by-impl-cla.patch
dpkg-source: info: applying 0007-tests-CMakeLists-avoid-crash-w-disabled-tests.patch
dpkg-source: info: applying 0008-Make-sure-package.xml-is-installed.patch
 debian/rules clean
echo foobar
foobar
echo DEB_BUILD_PROFILES: 
DEB_BUILD_PROFILES:
echo ENABLE_TESTS: ON
ENABLE_TESTS: ON
dh clean  --buildsystem=cmake
   dh_auto_clean -O--buildsystem=cmake
   dh_autoreconf_clean -O--buildsystem=cmake
   dh_clean -O--buildsystem=cmake
 debian/rules binary-arch
echo foobar
foobar
echo DEB_BUILD_PROFILES: 
DEB_BUILD_PROFILES:
echo ENABLE_TESTS: ON
ENABLE_TESTS: ON
dh binary-arch  --buildsystem=cmake
   dh_update_autotools_config -a -O--buildsystem=cmake
   dh_autoreconf -a -O--buildsystem=cmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/mk/cxx-serial/cxx-serial'
dh_auto_configure -- \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCATKIN_ENABLE_TESTING=ON
	cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_VERBOSE_MAKEFILE=ON -DCATKIN_ENABLE_TESTING=ON ..
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /home/mk/cxx-serial/cxx-serial/obj-x86_64-linux-gnu/devel
-- Using CMAKE_PREFIX_PATH: 
CMake Warning (dev) at /usr/share/catkin/cmake/python.cmake:7 (find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:164 (include)
  /usr/share/catkin/cmake/catkinConfig.cmake:20 (include)
  tests/CMakeLists.txt:9 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.11.6", minimum required is "3")
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/mk/cxx-serial/cxx-serial/obj-x86_64-linux-gnu/test_results
-- GTest is available
-- GMock is available
-- Using Python nosetests: /usr/bin/nosetests
-- Found Threads: TRUE
-- catkin 0.8.10
-- BUILD_SHARED_LIBS is on
-- Found Doxygen: /usr/bin/doxygen (found version "1.9.8") found components: 

Bug#1072171: gdm3: cannot access gdm login screen after logout via remote session (gnome-remote-desktop)

[clues_4me]

Package: gdm3
Version: 43.0-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

   * What led up to the situation?
    when logout on gnome-remote-desktop, cannot access login screen
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
    enable gnome-remote-desktop session on root user
    trying access via x11vnc
   * What was the outcome of this action?
    nothing
   * What outcome did you expect instead?
    at least give me login screen

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
Locale: LANG=id_ID.UTF-8, LC_CTYPE=id_ID.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 gdm3 depends on:
ii  accountsservice  22.08.8-6
ii  adduser  3.134
ii  dbus [default-dbus-system-bus]   1.14.10-1~deb12u1
ii  dbus-bin 1.14.10-1~deb12u1
ii  dbus-daemon  1.14.10-1~deb12u1
ii  dconf-cli    0.40.0-4
ii  dconf-gsettings-backend  0.40.0-4
ii  debconf [debconf-2.0]    1.5.82
ii  gir1.2-gdm-1.0   43.0-3
ii  gnome-session [x-session-manager]    43.0-1+deb12u1
ii  gnome-session-bin    43.0-1+deb12u1
ii  gnome-session-common 43.0-1+deb12u1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  gnome-settings-daemon    43.0-4
ii  gnome-shell  43.9-0+deb12u2
ii  gnome-terminal [x-terminal-emulator] 3.46.8-1
ii  gsettings-desktop-schemas    43.0-1
ii  libaccountsservice0  22.08.8-6
ii  libaudit1    1:3.0.9-1
ii  libc6    2.36-9+deb12u7
ii  libcanberra-gtk3-0   0.30-10
ii  libcanberra0 0.30-10
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgdm1  43.0-3
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libglib2.0-bin   2.74.6-2+deb12u2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgudev-1.0-0   237-2
ii  libkeyutils1 1.6.3-2
ii  libpam-modules   1.5.2-6+deb12u1
ii  libpam-runtime   1.5.2-6+deb12u1
ii  libpam-systemd [logind]  252.22-1~deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  librsvg2-common  2.54.7+dfsg-1~deb12u1
ii  libselinux1  3.4-1+b6
ii  libsystemd0  252.22-1~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxau6  1:1.0.9-1
ii  libxcb1  1.15-1
ii  libxdmcp6    1:1.1.2-3
ii  metacity [x-window-manager]  1:3.46.1-1
ii  mutter [x-window-manager]    43.8-0+deb12u1
ii  polkitd  122-3
ii  procps   2:4.0.2-3
ii  systemd-sysv 252.22-1~deb12u1
ii  ucf  3.0043+nmu1
ii  x11-common   1:7.7+23
ii  x11-xserver-utils    7.7+9+b1
ii  xfce4-session [x-session-manager]    4.18.1-1
ii  xfce4-terminal [x-terminal-emulator] 1.0.4-1
ii  xfwm4 [x-window-manager] 4.18.0-1

Versions of packages gdm3 recommends:
ii  at-spi2-core 2.46.0-5
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  gnome-session [x-session-manager]    43.0-1+deb12u1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  x11-xkb-utils    7.7+7
ii  xfce4-session [x-session-manager]    4.18.1-1
ii  xserver-xephyr   2:21.1.7-3+deb12u7
ii  xserver-xorg 1:7.7+23
ii  zenity   3.44.0-1

Versions of packages gdm3 suggests:
ii  libpam-fprintd    1.94.2-2
ii  libpam-gnome-keyring  42.1-1+b2
pn  libpam-pkcs11 
pn  libpam-sss    
ii  orca

Bug#1072170: gdm3: cannot access gdm login screen after logout via remote session (gnome-remote-desktop)

[clues_4me]

Package: gdm3
Version: 43.0-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

   * What led up to the situation?
    when logout on gnome-remote-desktop, cannot access login screen
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
    enable gnome-remote-desktop session on root user
    trying access via x11vnc
   * What was the outcome of this action?
    nothing
   * What outcome did you expect instead?
    at least give me login screen

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
Locale: LANG=id_ID.UTF-8, LC_CTYPE=id_ID.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 gdm3 depends on:
ii  accountsservice  22.08.8-6
ii  adduser  3.134
ii  dbus [default-dbus-system-bus]   1.14.10-1~deb12u1
ii  dbus-bin 1.14.10-1~deb12u1
ii  dbus-daemon  1.14.10-1~deb12u1
ii  dconf-cli    0.40.0-4
ii  dconf-gsettings-backend  0.40.0-4
ii  debconf [debconf-2.0]    1.5.82
ii  gir1.2-gdm-1.0   43.0-3
ii  gnome-session [x-session-manager]    43.0-1+deb12u1
ii  gnome-session-bin    43.0-1+deb12u1
ii  gnome-session-common 43.0-1+deb12u1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  gnome-settings-daemon    43.0-4
ii  gnome-shell  43.9-0+deb12u2
ii  gnome-terminal [x-terminal-emulator] 3.46.8-1
ii  gsettings-desktop-schemas    43.0-1
ii  libaccountsservice0  22.08.8-6
ii  libaudit1    1:3.0.9-1
ii  libc6    2.36-9+deb12u7
ii  libcanberra-gtk3-0   0.30-10
ii  libcanberra0 0.30-10
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgdm1  43.0-3
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libglib2.0-bin   2.74.6-2+deb12u2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgudev-1.0-0   237-2
ii  libkeyutils1 1.6.3-2
ii  libpam-modules   1.5.2-6+deb12u1
ii  libpam-runtime   1.5.2-6+deb12u1
ii  libpam-systemd [logind]  252.22-1~deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  librsvg2-common  2.54.7+dfsg-1~deb12u1
ii  libselinux1  3.4-1+b6
ii  libsystemd0  252.22-1~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxau6  1:1.0.9-1
ii  libxcb1  1.15-1
ii  libxdmcp6    1:1.1.2-3
ii  metacity [x-window-manager]  1:3.46.1-1
ii  mutter [x-window-manager]    43.8-0+deb12u1
ii  polkitd  122-3
ii  procps   2:4.0.2-3
ii  systemd-sysv 252.22-1~deb12u1
ii  ucf  3.0043+nmu1
ii  x11-common   1:7.7+23
ii  x11-xserver-utils    7.7+9+b1
ii  xfce4-session [x-session-manager]    4.18.1-1
ii  xfce4-terminal [x-terminal-emulator] 1.0.4-1
ii  xfwm4 [x-window-manager] 4.18.0-1

Versions of packages gdm3 recommends:
ii  at-spi2-core 2.46.0-5
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  gnome-session [x-session-manager]    43.0-1+deb12u1
ii  gnome-session-flashback [x-session-manager]  3.46.0-1
ii  x11-xkb-utils    7.7+7
ii  xfce4-session [x-session-manager]    4.18.1-1
ii  xserver-xephyr   2:21.1.7-3+deb12u7
ii  xserver-xorg 1:7.7+23
ii  zenity   3.44.0-1

Versions of packages gdm3 suggests:
ii  libpam-fprintd    1.94.2-2
ii  libpam-gnome-keyring  42.1-1+b2
pn  libpam-pkcs11 
pn  libpam-sss    
ii  orca

Bug#1055749: RFA: freetype-py -- Freetype Python bindings for Python 3

[Georges Khaznadar]

Hello Bastian,
I shall adopt this package, as it is a direct dependency for
python3-reportlab which I maintain.

Best regards,   Georges.

Bastian Germann a écrit :
> Package: wnpp
> 
> As I am no longer interested in the package, I request a new maintainer for 
> freetype-py.
> 
> Description: Freetype Python bindings for Python 3
>  Freetype Python provides bindings for the FreeType library.
>  Only the high-level API is bound.
> 
>  All the font access is done through the FreeType2 library,
>  which supports many formats.  It can render images of characters with
>  high-quality hinting and antialiasing, extract metrics information, and
>  extract the outlines of characters in scalable formats like TrueType.
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1072169: php-pecl-http: the http module requires the raphf module, which is not pulled in

[Gerardo Esteban Malazdrewicz]

Source: php-pecl-http
Severity: normal
X-Debbugs-Cc: gera...@malazdrewicz.com.ar

Dear Maintainer,

I get this after installing php-http:

PHP Warning:  Cannot load module "http" because required module "raphf" is not 
loaded in Unknown on line 0

While the system when reporting this is trixie based, I observed same behavior 
in bookworm.
Perhaps php-http should have php-raphf as a dependency.

Thanks,
   Gerardo

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1072168: freeipa-client: Conflicting conflict with systemd-timesyncd

[Adrian]

Package: freeipa-client
Version: 4.11.1-2
Severity: important
X-Debbugs-Cc: deb...@p3lim.net

Dear Maintainer,

As we're upgrading our Ubuntu Server 22.04 machines to 24.04 we
immediately stumbled upon this problem - the freeipa-client package is now
conflicting with systemd-timesyncd, which is installed by default on
Ubuntu Server, and is our NTP client of choice.

We use timesyncd specifically because it properly supports DHCP Option 42,
something chrony does not support, but we also feel like its utility
provides a much better user experience.

We're using freeipa-client without NTP (as in we're using the "-N" flag
upon installation with the ipa-client-install tool). This has worked for
us for years, but as of freeipa-client 4.9.11-1 (or earlier) a conflicts
flag was added to the package.

This does not make sense for several reasons:

- freeipa-client package does not depend on any NTP client package, it
  only _recommends_ chrony.
- ipa-client-install does not require an NTP client to run, and as a
  user you can be explicit about this (set the "-N" flag).
- if the user installs freeipa-client without recommendations they are
  left without an NTP client on their system, even though one is
  provided by the system (e.g. Ubuntu Server comes with
  systemd-timesyncd by default).
- the chrony package has a conflicts field with "time-daemon", which
  systemd-timesyncd is a part of, thus making this conflicts field
  unneccesary in the first place.

Please consider reverting this change.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble'), 
(100, 'noble-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-31-generic (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freeipa-client depends on:
ii  bind9-dnsutils [dnsutils]1:9.18.24-0ubuntu5
pn  bind9-utils  
pn  certmonger   
ii  curl 8.5.0-2ubuntu10.1
pn  freeipa-common   
pn  krb5-user
ii  libc62.39-0ubuntu8.1
ii  libcom-err2  1.47.0-2.4~exp1ubuntu4
ii  libcurl4t64  8.5.0-2ubuntu10.1
pn  libini-config5t64
ii  libjansson4  2.14-2build2
ii  libk5crypto3 1.20.1-6ubuntu2
ii  libkrb5-31.20.1-6ubuntu2
ii  libldap2 2.6.7+dfsg-1~exp1ubuntu8
pn  libnss-sss   
pn  libnss3-tools
pn  libpam-sss   
ii  libpopt0 1.19+dfsg-1build1
pn  libsasl2-modules-gssapi-mit  
ii  libssl3t64   3.0.13-0ubuntu3.1
pn  libsss-sudo  
pn  oddjob-mkhomedir 
ii  python3  3.12.3-0ubuntu1
pn  python3-dnspython
pn  python3-gssapi   
pn  python3-ipaclient
pn  python3-ldap 
pn  python3-sss  
pn  sssd 

Versions of packages freeipa-client recommends:
pn  chrony
pn  sssd-passkey  

Versions of packages freeipa-client suggests:
pn  libpam-krb5  

Bug#1072167: grub-pc-dbg: newly-added symbol file "..." does not provide any symbols

[lucas]

Package: grub-pc-dbg
Version: 2.12-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,


I am following the recommended procedure to debug GRUB from the GRUB Developers 
Manual, ch. 7 Debugging, section i386. [1]

gdb refuses to start, because it cannot load the symbols from the *.image files
for some reason.


$  gdb -x gdb_grub
GNU gdb (Debian 13.2-1+b1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "boot.image"
warning: newly-added symbol file "boot.image" does not provide any symbols
add symbol table from file "diskboot.image"
warning: newly-added symbol file "diskboot.image" does not provide any symbols
add symbol table from file "lzma_decompress.image"
warning: newly-added symbol file "lzma_decompress.image" does not provide any 
symbols
gdb_grub:137: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.


[1] https://www.gnu.org/software/grub/manual/grub-dev/html_node/i386_002dpc.html

Bug#1072166: python-zombie-imp: Missing build dependency

[Antoine Le Gonidec]

Source: python-zombie-imp
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The python-zombie-imp source requires the "setuptools" Python module,
but python3-setuptools is not included in its build dependencies.

This has been noticed when trying to build a local backport of
python3-zombie-imp for Bookworm, I have not checked yet if the same
problem happens when building on top of Trixie or Sid.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1072165: ftpmasters: please decide on sunrpc in dietlibc

[Thorsten Glaser]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: christ...@iwakd.de, t...@mirbsd.de, bastian.germ...@gmx.de
Control: blocks -1 1067946 1069365

Dear ftpmasters,

in #1067946 it was reported that some consider the sunrpc code as
included in dietlibc nōn-free.

Given that the actual wording is…

> […] Users
> * may copy or modify Sun RPC without charge, but are not authorized
> * to license or distribute it to anyone else except as part of a product or
> * program developed by the user.

… and that we receive dietlibc as “a product or program developed by”
Fefe (upstream author) under GPL, I think differently, and this *has*
passed review in the past.

Ultimately, *our* options are closing this as not a problem, removing
dietlibc (not very favourable), and excising the code in question
hoping not to break any downstream users. The reporter has also sent
this to upstream, which is the correct place where to apply the fix
suggested (replace with a different implementation), but there hasn’t
yet been any response or decision either way.

Now I don’t just want to close it or play bug pingpong, so I’d prefer
there to be an official decision either way, so that we can decide
what to do. (And then, I can invest some time to look at the other RC
reported and try to reproduce it on a porterbox etc. but I prefer to
do this when there’s not a sword of possible removal hanging over us.)

Thanks in advance!

Bug#1072089: debos: autopkgtest calls debootstrap in /tmp/, fails if it's a nodev tmpfs

[Luca Boccassi]

On Wed, 29 May 2024 11:16:22 +0100 Luca Boccassi 
wrote:
> On Tue, 28 May 2024 10:59:58 +0100 Luca Boccassi 
> wrote:
> > Source: debos
> > Version: 1.1.1-2.1
> > Severity: important
> > Tags: patch
> > 
> > Hi,
> > 
> > debos calls debootstrap in /tmp/. Since systemd 256~rc3-3 /tmp/ is
a
> > tmpfs, mounted nodev, so debootstrap doesn't like it:
> > 
> > 76s 2024/05/28 08:39:27 Debootstrap | E: Cannot install into target
> '/tmp/autopkgtest.YDXle7/build.twd/src/.debos-1362844167/root'
mounted
> with noexec or nodev"
> > 
> > https://ci.debian.net/packages/d/debos/testing/amd64/47065797/
> > 
> > Please use /var/tmp/ instead. MR is provided at:
> > 
> > https://salsa.debian.org/go-team/packages/debos/-/merge_requests/7
> > 
> > I tested this with autopkgtest + virt-qemu and it fixes the issue.
> I'd
> > appreciate a quick upload, as it blocks systemd's migration.
> > I'd also be happy to NMU this if you are busy.
> > 
> > Thanks!
> 
> If there are no objections, given the fix only touches autopkgtest
and
> it blocks systemd's migration, I am going to upload to DELAYED/1
later
> today, to unblock it. Thanks.

Uploaded to DELAYED/1. Let me know if you want me to cancel it. debdiff
attached, and MR updated with changelog commit.

-- 
Kind regards,
Luca Boccassi
diff -Nru debos-1.1.4/debian/changelog debos-1.1.4/debian/changelog
--- debos-1.1.4/debian/changelog	2024-05-15 15:55:37.0 +0100
+++ debos-1.1.4/debian/changelog	2024-05-29 14:42:19.0 +0100
@@ -1,3 +1,11 @@
+debos (1.1.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Autopkgtest: use /var/tmp/ instead of /tmp/ for debootstrap (Closes:
+#1072089)
+
+ -- Luca Boccassi   Wed, 29 May 2024 14:42:19 +0100
+
 debos (1.1.4-1) unstable; urgency=medium
 
   [ Christopher Obbard ]
diff -Nru debos-1.1.4/debian/tests/build-chroot debos-1.1.4/debian/tests/build-chroot
--- debos-1.1.4/debian/tests/build-chroot	2023-02-08 10:09:05.0 +
+++ debos-1.1.4/debian/tests/build-chroot	2024-05-28 10:52:24.0 +0100
@@ -1,5 +1,13 @@
 #!/bin/sh
 
+set -e
+
 : ${testdir:=$PWD/debian/tests}
 
+workdir="$(mktemp --directory --tmpdir=/var/tmp/ debos.XX)"
+trap "rm -rf '$workdir'" EXIT
+cd "$workdir"
+
 debos --disable-fakemachine $testdir/example.yaml
+
+cd "$testdir/../../"


signature.asc
Description: This is a digitally signed message part

Bug#1072124: gnome-shell: CVE-2024-36472

[Jeremy Bícha]

On Tue, May 28, 2024 at 5:37 PM Moritz Muehlenhoff  wrote:
>
> On Tue, May 28, 2024 at 05:33:32PM -0400, Jeremy Bícha wrote:
> > Control: forwarded -1 
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7688
> >
> > On Tue, May 28, 2024 at 5:24 PM Moritz Mühlenhoff  wrote:
> > > CVE-2024-36472[0]:
> > > | In GNOME Shell through 45.7, a portal helper can be launched
> > > | automatically (without user confirmation) based on network responses
> > > | provided by an adversary (e.g., an adversary who controls the local
> > > | Wi-Fi network), and subsequently loads untrusted JavaScript code,
> > > | which may lead to resource consumption or other impacts depending on
> > > | the JavaScript code's behavior.
> >
> > The initial GNOME issue was closed already (the CVE was requested by
> > someone who is not a GNOME developer). But GNOME Shell may change the
> > workflow for the captive portal helper so we can leave this bug open,
> > pointing to the new issue that was opened upstream.
>
> Yeah, the never filed a bug for the botched CVE assignment, this is the
> bug reference explocitly for the followup actionable filed by Michael 
> Catanzaro

Oh, the bug reporter actually requested 2 CVEs. CVE-2024-36472 which
you already filed the Debian bug for, is
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7688 and is
recognized as valid by GNOME.

The other CVE, CVE-2023-50977, was closed already in NIST.

Thank you,
Jeremy Bícha

Bug#1072164: grub-pc-dbg: missing gdb_helper.py script from the upstream source code

[lucas]

Package: grub-pc-dbg
Version: 2.12-2
Severity: important

Dear Maintainer,

I am following the recommended procedure to debug GRUB from the GRUB Developers
Manual, ch. 7 Debugging, section i386. [1]

When using a pre-built GRUB, the distribution may have a package which
installs this GDB script along with debug symbol binaries, such as Debian’s
‘grub-pc-dbg’ package. The GDB script is intended to be used like so,
assuming that ‘/path/to/script’ is the path to the directory containing the
gdb_grub script and debug symbol files:

cd $(dirname /path/to/script/gdb_grub)
gdb -x gdb_grub

The gdb_grub script (/usr/lib/grub/i386-pc/gdb_grub) gives error while sourcing
gdb_helper.py, which is not installed. gdb gives warning: No such file or
directory.

gdb_helper.py is in the upstream GRUB2 source tree and should be included in 
the package.

[1] https://www.gnu.org/software/grub/manual/grub-dev/html_node/i386_002dpc.html

Bug#1072163: libxmlrpc-core-c3-dev: Missing dependency on libxmlrpc-util-dev

[Guillem Jover]

Package: libxmlrpc-core-c3-dev
Version: 1.59.03-2
Severity: serious

Hi!

After the recent package split, the .pc file does not work anymore, as
there's a missing dependency on the libxmlrpc-util-dev package, which
the .pc file depends on. On a pristine system after installing only
the libxmlrpc-core-c3-dev package and running pkgconf to get its flags
one gets this:

  ,---
  $ pkgconf --libs xmlrpc
  Package xmlrpc_util was not found in the pkg-config search path.
  Perhaps you should add the directory containing `xmlrpc_util.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'xmlrpc_util', required by 'xmlrpc', not found
  Package 'xmlrpc_util', required by 'xmlrpc_expat', not found
  `---

After installing the missing dependency:

  ,---
  $ pkgconf --libs xmlrpc
  -lxmlrpc -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util
  `---

Setting to serious, because the intra-dependencies are an
implementation detail that packages depending on the core package or
using its .pc file should not need to be aware of, and this would
cause FTBFS issues now.

Thanks,
Guillem

Bug#1072162: gimp: Segnmentation fault after running batch process.

[xndr]

Package: gimp
Version: 2.10.34-1+deb12u2
Severity: important
X-Debbugs-Cc: xa...@gmx.co.uk

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?




```
GNU Image Manipulation Program version 2.10.34
git-describe: GIMP_2_10_34
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-
languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-
major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-
verify --enable-plugin --enable-default-pie --with-system-zlib --enable-
libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-
abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-
none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-
amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-
defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-
gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

# Libraries #
using babl version 0.1.98 (compiled against version 0.1.98)
using GEGL version 0.4.42 (compiled against version 0.4.42)
using GLib version 2.74.6 (compiled against version 2.74.6)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.12 (compiled against version 1.50.12)
using Fontconfig version 2.14.1 (compiled against version 2.14.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 422732 - Thread 422732 #

[New LWP 422734]
[New LWP 422735]
[New LWP 422736]
[New LWP 422740]
[New LWP 422741]
[New LWP 422745]
[New LWP 422792]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffc764769b0, fd=21) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target IdFrame
* 1Thread 0x7fb0402c2300 (LWP 422732) "gimp-2.10"   __GI___libc_read
(nbytes=256, buf=0x7ffc764769b0, fd=21) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7fb03f7ff6c0 (LWP 422734) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7fb03effe6c0 (LWP 422735) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7fb037fff6c0 (LWP 422736) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7fb035bfd6c0 (LWP 422740) "gmain"   0x7fb040d4a15f in
__GI___poll (fds=0x557f7c9194c0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  6Thread 0x7fb0363fe6c0 (LWP 422741) "gdbus"   0x7fb040d4a15f in
__GI___poll (fds=0x557f7c941ca0, nfds=3, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7fb01d9fe6c0 (LWP 422745) "async"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7fb01c9fc6c0 (LWP 422792) "swap writer" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 8 (Thread 0x7fb01c9fc6c0 (LWP 422792) "swap writer"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7fb040fb73cf in g_cond_wait () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x7fb04153fa29 in  () at /lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3  0x7fb040f8ccfd in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fb040cd7134 in start_thread (arg=) at
./nptl/pthread_create.c:442
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140394371204800,
-7840294754635220572, -1152, 11, 140722292872160, 140394362814464,
7805182677851306404, 7805069034385963428}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call 

Bug#1072148: epics-base: please add support for loong64

[Andrius Merkys]

On 2024-05-29 11:32, wuruilong wrote:
Modify the valgrind header file because valgrind's code has gone too 
long without loongarch support.


Does the valgrind Debian package support loong64? If so, the embedded 
valgrind/valgrind.h can be replaced with the header from Debian package.


Andrius

Bug#1072161: RM: rust-isahc/experimental -- RoQA; NVIU; librust-isahc-dev is now arch:all

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the rust-isahc cruft from experimental, librust-isahc-dev
is now an arch:all package

librust-isahc-dev | 1.7.2+ds-3| experimental | amd64, arm64, armel, armhf, 
i386, mips64el, ppc64el, s390x
librust-isahc-dev | 1.7.2+ds-20   | stable   | all
librust-isahc-dev | 1.7.2+ds-25   | unstable | all
rust-isahc| 1.7.2+ds-3| experimental | source
rust-isahc| 1.7.2+ds-20   | stable   | source
rust-isahc| 1.7.2+ds-25   | unstable | source
rust-isahc| 1.7.2+ds-26   | unstable | source


Andreas

Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable

[Harlan Lieberman-Berg]

On Wed, 22 May 2024 20:07:21 +0200 Evgeni Golov  wrote:
> I've opened an MR against the dracut package [2] and uploaded built
> packages at [3] if anyone wants to try :)

Can confirm, your test packages fix the issue.  Thanks, Evgeni, Benjamin!

Also, for extra salt-in-wound, apparently this bug also breaks custom
keyboard layouts -- though that is also fixed by the patch.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Helmut Grohne]

Hi release team,

On Wed, Mar 13, 2024 at 10:55:09AM +0100, Helmut Grohne wrote:
> I propose April 11th on the condition that all relevant packages
> (including cryptsetup and e2fsprogs) have migrated. I'll also check with
> Aurelien on feasibility after Easter.

Stuff wasn't ready back then and we kept bumping the /usr-move back. I
think we need to fix dates soon. During the past months, I reserved time
for the essential fallout and I cannot promise that in second-half-June,
July and first-half-August. Meanwhile all the relevant stuff has
migrated including the glibc upstream release. So we basically have the
following options:

 * Pick a date before June 7th and go ahead soon.
 * Go for later and I'll handle the fallout best-effort. (i.e. similar
   t64 fallout)
 * Pick a date August 12th or later.

Since noble includes these changes and I'd get this done sooner rather
than later, how about moving forward with June 5th after 22:30 UTC (such
that all buildds have regenerated their chroots before the upload)?

There also is little to be done from the release team's side beyond
installing a block for base-files, bash, dash, glibc, util-linux and
then lifting the block once all of them are ready turn that block into a
force hint such that they really migrate together. (There is no
dependency relation between them ensuring concurrent migration as that
would make upgrades more difficult.)

Other than the bootstrap matter, we're down to 350 affected packages and
dumat is finding one to five issues per week most of which are
undeclared file conflicts. As a result of the dumat work, I haven't seen
an actual end user report about a /usr-move problem in quite a while. A
list of affected packages is at
https://subdivi.de/~helmut/usrmove.ddlist (not entirely current). I'll
propose a MBF for the remaining no-change sourceful uploads as well as
the remaining "Build-Depends: dh-sequence-movetousr" uploads. All other
moves already have bugs. I also plan to bump the severity of these bugs
to important soon. Do you also agree with bumping these bugs to serious
severity once their number goes below 200? Keep in mind that they are
all actionable in the sense that one of the following applies:
 * No-change sourceful upload fixes
 * An upload adding "Build-Depends: dh-sequence-movetousr" fixes
 * The attached patch fixes
 * Rarely maintainer feedback has been requested

Chris has already performed a number of NMUs and we'll need to do some
more to eventually get us down to 0 aliased packages. A while ago I
removed 10 affected source packages that were FTBFSing for two stable
releases already.

Helmut

Bug#1072160: libmirage FTCBFS: fails running gtk-doc-scan

[Helmut Grohne]

Source: libmirage
Version: 3.2.7-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libmirage fails to cross build from source, because it fails running the
gtk-doc scanner. This is a common problem for cross builds. Fortunately,
libmirage has its documentation split out to libmirage-doc, so there
isn't actually any need to run the scanner in an arch-only build. Simply
skipping it there makes the cross build succeed while not affecting the
binary artifacts (according to diffoscope) and it also slightly speeds
up the native arch-only build (e.g. on buildds). I'm attaching a patch
for your convenience.

Helmut
diff --minimal -Nru libmirage-3.2.7/debian/changelog 
libmirage-3.2.7/debian/changelog
--- libmirage-3.2.7/debian/changelog2024-05-25 12:55:24.0 +0200
+++ libmirage-3.2.7/debian/changelog2024-05-29 09:41:43.0 +0200
@@ -1,3 +1,10 @@
+libmirage (3.2.7-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable gtk-doc on arch-only build. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 29 May 2024 09:41:43 +0200
+
 libmirage (3.2.7-4) unstable; urgency=medium
 
   * debian/appstream/net.sf.cdemu.libmirage.metainfo.xml:
diff --minimal -Nru libmirage-3.2.7/debian/rules libmirage-3.2.7/debian/rules
--- libmirage-3.2.7/debian/rules2024-02-20 15:57:49.0 +0100
+++ libmirage-3.2.7/debian/rules2024-05-29 09:41:41.0 +0200
@@ -7,7 +7,9 @@
 
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DPOST_INSTALL_HOOKS:BOOL=OFF
+   dh_auto_configure -- \
+   -DPOST_INSTALL_HOOKS:BOOL=OFF \
+   -DGTKDOC_ENABLED=$(if $(filter libmirage-doc,$(shell 
dh_listpackages)),ON,OFF)
 
 override_dh_makeshlibs:
dh_makeshlibs --exclude="libmirage-3.2"

Bug#1072159: rust-pango-sys FTBFS with nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory

[Helmut Grohne]

Source: rust-pango-sys
Version: 0.19.5-2
Severity: serious
Tags: ftbfs trixie sid

rust-pango-sys fails to build from source when enabling the nocheck
build profile. A build ends with:

|dh_auto_configure -O--buildsystem=cargo
| debian cargo wrapper: options, profiles, parallel, lto: ['nocheck', 
'parallel=8'] ['nocheck'] ['-j8'] 0
| debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
| debian cargo wrapper: linking /usr/share/cargo/registry/* into 
/<>/debian/cargo_registry/
|debian/rules execute_before_dh_auto_build
| make[1]: Entering directory '/<>'
| cp /usr/share/gir-1.0/GLib-2.0.gir /<>
| cp /usr/share/gir-1.0/GModule-2.0.gir /<>
| cp /usr/share/gir-1.0/GObject-2.0.gir /<>
| cp /usr/share/gir-1.0/Pango-1.0.gir /<>
| cp: cannot stat '/usr/share/gir-1.0/Pango-1.0.gir': No such file or directory
| make[1]: *** [debian/rules:12: execute_before_dh_auto_build] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:4: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Please review the  annotations in your package. Since trixie,
a nocheck build failure is considered release-critical.

Helmut

Bug#1072158: manpages-dev: missing Breaks+Replaces: glibc-doc (<< 2.37-16)

[Andreas Beckmann]

Package: manpages-dev
Version: 6.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../manpages-dev_6.8-1_all.deb ...
  Unpacking manpages-dev (6.8-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_6.8-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man3/pthread_atfork.3.gz', which is also 
in package glibc-doc 2.36-9+deb12u4
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-dev_6.8-1_all.deb

The corresponding change in src:glibc was:

glibc (2.37-16) unstable; urgency=medium

...
  * debian/debhelper.in/glibc-doc.{links,manpages},
debian/local/manpages/pthread_*: drop the man pages for libpthread
functions, as they are now included in manpages-dev.  Closes: #1068188.
  * debian/control.in/main: update glibc-doc description following the removal
of the pthread manpages.
...

 -- Aurelien Jarno   Wed, 10 Apr 2024 00:15:44 +0200


cheers,

Andreas


glibc-doc=2.36-9+deb12u4_manpages-dev=6.8-1.log.gz
Description: application/gzip

Bug#1071717: gnome-settings-daemon: gsd-media-keys fires D-Bus MPris PlayPause message randomly

[Andres Gomez Garcia]

Hi Simon,

Thanks for the thorough explanation.

I was already considering this and it may be as you say, but I wonder
why the headphone would be sending "false" key presses randomly and,
more often, when I'm far from the dongle receiver.

I'll check on a way to log the key presses when using the headphones so
I can conclude that this is the case or not.

Thanks again!

-- 
Br,

Andres

Bug#1072073: python3-proto-plus has an undeclared file conflict on /usr/lib/python3/dist-packages/proto/__init__.py

[Andreas Beckmann]

Followup-For: Bug #1072073

This looks like some kind of namespace violation in nanopb.

nanopb ships

/usr/lib/python3/dist-packages/nanopb/*
/usr/lib/python3/dist-packages/proto
/usr/lib/python3/dist-packages/proto/__init__.py
/usr/lib/python3/dist-packages/proto/_utils.py
/usr/lib/python3/dist-packages/proto/google
/usr/lib/python3/dist-packages/proto/google/protobuf
/usr/lib/python3/dist-packages/proto/google/protobuf/descriptor.proto
/usr/lib/python3/dist-packages/proto/nanopb.proto
/usr/lib/python3/dist-packages/proto/nanopb_pb2.py

and that proto module looks like something very specific to nanopb.


Andreas

Bug#1072157: gnome-shell: Log spam: g_closure_unref: assertion 'closure->ref_count > 0' failed

[Jo Drexl]

Package: gnome-shell
Version: 43.9-0+deb12u2
Severity: important

Dear Maintainer,

when switching to the overview (pressing super key or using the active
top left corner), a message is written to the syslog containing

g_closure_unref: assertion 'closure->ref_count > 0' failed

For every extension that is enabled this message seems to be logged too,
but even without an extension it is logged at least once, so with 4
enabled extensions it's 5 messages with every switch to the overview.
When being awakened from sleep/hibernation, this problem is worsening,
with more and more such messages appearing, also leading to severe lag
(multiple seconds). Re-login resets the problem, but it quickly
accumulates again. 

There is an Ubuntu bug (2045632) without solution, pointing to enabled
extensions, but my systems shows at least one message even with all of
them disabled.

I currently have no idea how to give you further information about this,
if you have any clue, I'm happy to assist hunting that bugger down.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.38-2~deb12u1
ii  gir1.2-gtk-4.0   4.8.3+ds-2+deb12u1
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.8-0+deb12u1
ii  gir1.2-nm-1.01.42.4-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-1~deb12u1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.44.2-1~deb12u1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.9-0+deb12u2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3+deb12u1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u7
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-2
ii  libedataserver-1.2-273.46.4-2
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1+deb12u1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libglib2.0-bin   2.74.6-2+deb12u2
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.8-0+deb12u1
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0 

Bug#1072156: libkf6purpose-bin: missing Breaks+Replaces: libkf5purpose-bin (<< 6)

[Andreas Beckmann]

Package: libkf6purpose-bin
Version: 6.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

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.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

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 .../libkf6purpose-bin_6.0.0-1_amd64.deb ...
  Unpacking libkf6purpose-bin:amd64 (6.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkf6purpose-bin_6.0.0-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/share/accounts/services/kde/google-youtube.service', which is also in 
package libkf5purpose-bin:amd64 5.115.0-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libkf6purpose-bin_6.0.0-1_amd64.deb

The following files are in both packages:

usr/share/accounts/services/kde/google-youtube.service
usr/share/accounts/services/kde/nextcloud-upload.service


cheers,

Andreas


libkf5purpose-bin=5.115.0-2_libkf6purpose-bin=6.0.0-1.log.gz
Description: application/gzip

Bug#1072155: Wrong NEWS.Debian item

[Dan Jacobson]

Package: systemd
Version: 256~rc3-5
File: /usr/share/doc/systemd/NEWS.Debian.gz

>  - On new installations, tmpfiles.d will now cleanup by default /tmp/ every
>10 days, and /var/tmp/ every 30 days.

That note needs to be changed to

>  - On new installations, tmpfiles.d will now cleanup by default files
>that have not been changed on /tmp/ for 10 days, and /var/tmp/ for 30 days.

Big difference.

Bug#1072146: libexplain: kill(pid = 42 "sh", sig = SIGTERM) failed, Operation not permitted (EPERM)

[Santiago Vila]

owner 1072146 !
thanks

El 29/5/24 a las 8:35, Jochen Sprickerhof escribió:

libexplain fails to build in sbuild+unshare now used on some of the
buildd:

PATH=`pwd`/bin:$PATH /bin/sh test/04/t0462a.sh
1c1
< kill(pid = 42, sig = SIGTERM) failed, Operation not permitted (EPERM)
---

kill(pid = 42 "sh", sig = SIGTERM) failed, Operation not permitted (EPERM)

FAILED test of kill EPERM
make[2]: *** [Makefile:42004: t0462a] Error 1

I assume this is due to the test is skipped in the schroot backend.
Tagging patch as it is easy to fix from the diff above.


The diff above is what happens when you try this:

dpkg-buildpackage -uc -us -b

If, instead, you try this:

sbuild -d sid-unshare --chroot-mode=unshare libexplain_1.4.D001-13.dsc

then you get a diff like this:

< kill(pid = 42, sig = SIGTERM) failed, Operation not permitted (EPERM)
< because the process does not have permission to send the signal to any
< of the target processes, and the process is not privileged
---

kill(pid = 42 "perl", sig = SIGTERM) failed, Operation not permitted
(EPERM) because the process does not have permission to send the signal
to any of the target processes, and the process is not privileged


Since we want the package to be buildable in all allowed ways, I'm
going to make sure that the test is always skipped (not just when using
root or fakeroot), as there is no diff which will work for everybody.

Thanks.

Bug#1067303: trash-cli in Debian: test problems again

[Jonathan Dowland]

Hi Boyuan (and Andrea)

On Tue May 28, 2024 at 8:08 PM BST, Boyuan Yang wrote:
> On Sun, 26 May 2024 14:04:40 +0200 Andrea Francia  
> wrote:
> > Hi Jonathan and Lucas,
> >   I solved the problem in the new release (0.24.5.26).

That's great news! I' dli

> Can you take a look and prepare a new release into Sid recently? If not,
> would you mind a NMU into DELAYED/15 with the fix included?

I'll take a look Today. I'm otherwise happy for NMUs, I'm on the Low
Threshold NMU list.


Best wishes,

-- 

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE

[Diederik de Haas]

On Wednesday, 29 May 2024 03:22:50 CEST Mark Pearson wrote:
> >> X-Debbugs-Cc: mpearson-len...@squebb.ca
> > ...
> > The MR for it (1062) has just been merged into master.
> 
> Awesome - thanks! I did scan the bugs before submitting but missed that one.
> Apologies. Should I close this issue then as it's a duplicate?

I *assumed* the "X-Debbugs-Cc" meant that bug would've landed directly in your 
inbox, but I can be wrong. Sorry about that.

No need to do anything. They're merged which means that when the kernel with 
that commit gets uploaded to the Debian archives, both will automatically be 
closed together.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#1072154: (no subject)

[Lorenzo Bertini]

Package: gnome-builder
Version: 46.2-1
Severity: important
X-Debbugs-Cc: lorenzobertin...@gmail.com

Dear Maintainer,
installing builder does not require gir1.2-json-1.0 as a dependency. However,
without it it reports

> ide-shortcut-bundle[ 3169]: CRITICAL: Failed to eval keybindings.gsl: Typelib
> file for namespace 'Json', version '1.0' not found

and keybindings such as CTRL-S to save or CTRL-N to open a new file do not work.

Installing gir1.2-json-1.0 fixes the message and keybindings work again. I see
that one of the dependencies is gir1.2-jsonrpc-1.0. I don't know what is their
relation.

Cheers,
Lorenzo

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-builder depends on:
ii  clang1:16.0-58.1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  exuberant-ctags  1:5.9~svn20110310-19
ii  gir1.2-adw-1 1.5.0-1
ii  gir1.2-dex-1 0.6.0-1
ii  gir1.2-glib-2.0 [gir1.2-gio-2.0] 2.80.2-2
ii  gir1.2-gtk-4.0   4.14.4+ds-1
ii  gir1.2-gtksource-5   5.12.0-1
ii  gir1.2-jsonrpc-1.0   3.44.0-2+b2
ii  gir1.2-panel-1   1.6.0-1
ii  gir1.2-peas-22.0.2-1
ii  gir1.2-template-1.0  3.36.2-1
ii  gir1.2-vte-3.91  0.76.1-1
ii  gir1.2-webkit-6.02.45.2-1
ii  libadwaita-1-0   1.5.0-1
ii  libc62.38-11
ii  libcairo21.18.0-3+b1
ii  libclang1-16t64  1:16.0.6-27
ii  libcmark0.30.2   0.30.2-6+b1
ii  libdex-1-1   0.6.0-1
ii  libdspy-1-1  1.10.0-1
ii  libeditorconfig0 0.12.7-0.1
ii  libenchant-2-2   2.3.3-2+b2
ii  libflatpak0  1.15.8-1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libgirepository-1.0-11.80.1-3
ii  libgit2-1.7  1.7.2+ds-1+b2
ii  libgit2-glib-1.0-0   1.2.0-1+b2
ii  libglib2.0-0t64  2.80.2-2
ii  libgtk-4-1   4.14.4+ds-1
ii  libgtksourceview-5-0 5.12.0-1
ii  libicu72 72.1-4+b1
ii  libjson-glib-1.0-0   1.8.0-2+b1
ii  libjsonrpc-glib-1.0-13.44.0-2+b2
ii  libpanel-1-1 1.6.0-1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libpeas-2-0  2.0.2-1
ii  libportal-gtk4-1 0.7.1-5+b1
ii  libportal1   0.7.1-5+b1
ii  libsoup-3.0-03.4.4-5+b1
ii  libtemplate-glib-1.0-0   3.36.2-1
ii  libvala-0.56-dev [libvala-dev]   0.56.17-1
ii  libvte-2.91-gtk4-0   0.76.1-1
ii  libwebkitgtk-6.0-4   2.45.2-1
ii  libxml2  2.12.7+dfsg-2
ii  python3  3.11.8-1
ii  python3-gi   3.48.2-1

Versions of packages gnome-builder recommends:
ii  build-essential12.10
pn  flatpak-builder
pn  gettext
ii  meson  1.4.0-2
ii  pkgconf1.8.1-1+b2
pn  python3-lxml   
pn  valgrind-if-available  

Versions of packages gnome-builder suggests:
pn  rubocop  

-- no debconf information

Bug#1071703: gammapy: test fail with scipy 1.12

[Drew Parsons]

tags 1071703 + fixed-upstream patch
thanks

Fixed upstream PR#4997
https://github.com/gammapy/gammapy/pull/4997

Bug#1070361: python-blosch vs c-blosc

[Alexandre Detiste]

They look like two active & different things

https://github.com/Blosc/c-blosc - 1.21.5
https://github.com/Blosc/python-blosc - 1.11.0

I don't know enough on the matter

Bug#1072153: python3-tornado: unable to instantiate an empty AsyncTestCase

[Timo Röhling]

Package: python3-tornado
Version: 6.4.0-1
Severity: serious
Tags: patch
User: debian-pyt...@lists.debian.org
Usertags: pytest-8
Control: affects -1 src:python-tenacity src:terminado

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

unittest.TestCase has a feature where it allows instantiating MyTestClass() 
with the default method name runTest even if a runTest method doesn't actually 
exist. This is documented in TestCase's docs under "Changed in version 3.2" 
[0].

Since version 8.2, pytest relies on this, and started breaking on Tornado's 
AsyncTestCase [1].

Find attached a patch (submitted to upstream [2]) that resolves the issue.


Cheers
Timo

[0] https://docs.python.org/3/library/unittest.html#unittest.TestCase
[1] https://github.com/pytest-dev/pytest/issues/12263
[2] https://github.com/tornadoweb/tornado/pull/3374



-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZXBNUACgkQzIxr3RQD
9MpHCxAAhX5aHeyUNaO6Zn1Beex96vffhC8r72FQnu0IUw1Ty9tLW8erwX6sdoxm
EYft79iBL03nQdyucRgr4cglB1jly/0KOuns9VwqBk8nEwjBvCg9TO0CgryH8eip
N8A9Yf0j6A4tW95dbS0Ovs1XfQR4NJ66grDj08vmlTcseBIN9EgrFVEVaOv5QuPm
q8Z78jIqmHDc2YBpHEegxOQD4UtkJZofsQwzjGZhwvz9Zlnuv69PBp4r4XxLQEmm
iErjajRU9mjBMVEosL89xkl1Fb5AQp/IFvTXNsPhbFfKfwcE0hs5EmUO0WhQOJWr
HjiYm8te9QEGhKB1oLad+mg30B9FAMXrdq1qsw/yaZeUaVM9Dpq2LJ2zEGlQKTSX
yauPcxxFeAtVmsq94JdBHT7ag/v8fsJ4MO+hAVZikPh21oT4yA/fixFd4dORJIFy
LFISGojbAjxFnCDnls5JLK0I+QGGnyVQxYu/wEAG6KkA2+1lDFtU2IiTGy1+EOro
FfXde94WF386DlOr0806/4ts4u0qYFcXpwh3SAvJH7Y6ikyt3kgyR+YLkglWeoKM
bEcpsPVn/a2jzyXI5o0TRuIOwLyjxJSbKZYm4QECNQneGez38vmiNjaZZXitlkCR
fTytpm1DIxAN39ah8yt/NG12yKBidQK824595JmOx/gFV5DRQ5w=
=v71Z
-END PGP SIGNATURE-
commit c851aa8a949524b35f72c82b45a52353aa3c0558
Author: Ran Benita 
Date:   Sun Apr 28 14:17:54 2024 +0300

testing: allow to instantiate an empty AsyncTestCase

`unittest.TestCase` has a feature where it allows instantiating
`MyTestClass()` with the default method name `runTest` even if a
`runTest` method doesn't actually exist. This is documented in
`TestCase`'s docs under "Changed in version 3.2"[0].

Since version 8.2, pytest relies on this, and started breaking on
Tornado's `AsyncTestCase`[1].

Change `AsyncTestCase` to allow empty instatiation, by matching the
upstream code.

[0] https://docs.python.org/3/library/unittest.html#unittest.TestCase
[1] https://github.com/pytest-dev/pytest/issues/12263

diff --git a/tornado/test/testing_test.py b/tornado/test/testing_test.py
index 0429feee..8e2b8db4 100644
--- a/tornado/test/testing_test.py
+++ b/tornado/test/testing_test.py
@@ -61,6 +61,15 @@ class AsyncTestCaseTest(AsyncTestCase):
 self.io_loop.add_timeout(self.io_loop.time() + 0.2, self.stop)
 self.wait(timeout=0.4)
 
+def test_empty_instantation_is_allowed(self):
+"""
+Test that empty instatiation of an AsyncTestCase is allowed.
+
+unittest.TestCase docs guarantee this working, and pytest's unittest
+support relies on it.
+"""
+AsyncTestCaseTest()
+
 
 class LeakTest(AsyncTestCase):
 def tearDown(self):
diff --git a/tornado/testing.py b/tornado/testing.py
index bdbff87b..9455411a 100644
--- a/tornado/testing.py
+++ b/tornado/testing.py
@@ -177,7 +177,17 @@ class AsyncTestCase(unittest.TestCase):
 # the test will silently be ignored because nothing will consume
 # the generator.  Replace the test method with a wrapper that will
 # make sure it's not an undecorated generator.
-setattr(self, methodName, _TestMethodWrapper(getattr(self, 
methodName)))
+try:
+test_method = getattr(self, methodName)
+except AttributeError:
+if methodName != "runTest":
+# We allow instantiation with no explicit method name
+# but not an *incorrect* or missing method name.
+raise ValueError(
+"no such test method in %s: %s" % (self.__class__, 
methodName)
+)
+else:
+setattr(self, methodName, _TestMethodWrapper(test_method))
 
 # Not used in this class itself, but used by @gen_test
 self._test_generator = None  # type: Optional[Union[Generator, 
Coroutine]]

Bug#1069127: python-idna: CVE-2024-3651

[Moritz Mühlenhoff]

Hi Guilhem,

> > CVE-2024-3651[0]:
> > | potential DoS via resource consumption via specially crafted inputs to
> > | idna.encode()
> 
> I'm preparing an update for this issue for Buster LTS, would you like me
> to propose debdiffs for (o)s-pu and sid too?

Please do so!

Cheers,
Moritz

Bug#1072152: libreoffice-base: Copy/Paste calc>base fails on external postgres when used to specific schema on database

[wim]

Package: libreoffice-base
Version: 4:7.4.7-1+deb12u2
Severity: normal
X-Debbugs-Cc: wim.bert...@ucll.be

Hello,

this bug has been present for quiet a while in my experience.

An example on how to reproduce:
1. create a small simple table in calc, eg a 2c by 4r table with a header (eg 
id, value with some rows)
2. connect to a postgres database with multiple schemas as a regular user userx 
(non superuser) (eg the schema schema1, schema2, schema3 exist) (using the 
built in external options
3. copy the small table from calc
4. paste it into a non default schema, like schema1
5. go through the popup menu and make the table
6. an exception will be thrown that the schema userx does not exist, even 
though you pasting to schema1

Designing a table does not have this issue.

I know this is not the latest version, but this is a bug that has existed for 
some years now, i don't think it fixed in more recent versions.

hth,
Wim


-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/base.xcdlibreoffice-baseYes No
All deployed bundled extensions:

Identifier: com.sun.wiki-publisher
  Version: 1.2.0
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: De Wiki Publisher stelt u in staat om Wiki-artikelen te maken op 
MediaWiki-server zonder de syntaxis van de MediaWiki markup language te kennen. 
Publiceer uw nieuwe en bestaande documenten duidelijk met Writer naar een 
Wiki-pagina.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcs
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-schema
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiEditor/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/ProtocolHandler.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/OptionsDialog.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Filter.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Types.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Paths.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: com.sun.star.comp.Calc.NLPSolver
  Version: 0.9
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Deze extensie wordt ge\xefntegreerd in Calc en biedt nieuwe 
oplossingsmethoden die gebruikt kunnen worden voor het optimaliseren van 
niet-lineaire programmeermodellen.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  }

Identifier: org.openoffice.da.writer2latex.oxt
  Version: 1.4
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Writer2LaTeX voorziet in exportfilters voor LaTeX en BibTeX
  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/writer2latex.rdb
  is registered: yes
  Media-Type: 

Bug#1072089: debos: autopkgtest calls debootstrap in /tmp/, fails if it's a nodev tmpfs

[Luca Boccassi]

On Tue, 28 May 2024 10:59:58 +0100 Luca Boccassi 
wrote:
> Source: debos
> Version: 1.1.1-2.1
> Severity: important
> Tags: patch
> 
> Hi,
> 
> debos calls debootstrap in /tmp/. Since systemd 256~rc3-3 /tmp/ is a
> tmpfs, mounted nodev, so debootstrap doesn't like it:
> 
> 76s 2024/05/28 08:39:27 Debootstrap | E: Cannot install into target
'/tmp/autopkgtest.YDXle7/build.twd/src/.debos-1362844167/root' mounted
with noexec or nodev"
> 
> https://ci.debian.net/packages/d/debos/testing/amd64/47065797/
> 
> Please use /var/tmp/ instead. MR is provided at:
> 
> https://salsa.debian.org/go-team/packages/debos/-/merge_requests/7
> 
> I tested this with autopkgtest + virt-qemu and it fixes the issue.
I'd
> appreciate a quick upload, as it blocks systemd's migration.
> I'd also be happy to NMU this if you are busy.
> 
> Thanks!

If there are no objections, given the fix only touches autopkgtest and
it blocks systemd's migration, I am going to upload to DELAYED/1 later
today, to unblock it. Thanks.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part