Bug#1023730: libicu-dev: Installing libicu-dev auto deconfigure

[Tianyu Chen]

Package: libicu-dev
Version: 72.1-2
Severity: important
X-Debbugs-Cc: billchenchina2...@gmail.com

Error: considering deconfiguration of libicu-dev:amd64, which would be broken
by installation of icu-devtools ...

Error: yes, will deconfigure libicu-dev:amd64 (broken by icu-devtools)


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/12 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 libicu-dev depends on:
ii  icu-devtools  72.1-2
ii  libc6-dev [libc-dev]  2.36-4
ii  libicu72  72.1-2

libicu-dev recommends no packages.

Versions of packages libicu-dev suggests:
pn  icu-doc  

-- no debconf information

Bug#1022900: grub-install, efibootmgr etc. not working with new kernel

[Stephan Verbücheln]

Update for completeness:

The EFI patches have not made it into 6.0.7. As expected, 6.0.7 from
Debian still has the problem.

New EFI patches have been merged into master on November 4. I hope to
find them in 6.0.8 or 6.1. Then I will test again.

Regards

Bug#1023669: osmo-msc: FTBFS in sid (libsmpp34 failure)

[Gianfranco Costamagna]

severity 1023669 serious
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019423: libreoffice: Need to maximize window manually before libreoffice window opens on plasma-desktop

[Rene Engelhard]

Hi,


reading https://bugs.documentfoundation.org/show_bug.cgi?id=150236 ...

Am 09.11.22 um 07:34 schrieb Rene Engelhard:

$ cat libreoffice-core.NEWS
libreoffice (1:7.4.2~rc1-1) unstable; urgency=low

  * LibreOffice 7.4.1 contained a bug about wrongly remembering the


Make that 7.4.0/7.4..1

Regards,


Rene

Bug#1019423: libreoffice: Need to maximize window manually before libreoffice window opens on plasma-desktop

[Rene Engelhard]

Hi,

Am 09.11.22 um 07:05 schrieb Rene Engelhard:
The question is where? libreoffice-core would be the correct place but 
then people not using KDE will also get it. -kf5/-qt5 might do it as 
they seem somehow to be the only affected but then it might be shown 
twice and is on the package which doesn't have the actual fix/file 
affected...



What about


$ cat libreoffice-core.NEWS
libreoffice (1:7.4.2~rc1-1) unstable; urgency=low

  * LibreOffice 7.4.1 contained a bug about wrongly remembering the
    size of the LibreOffice windows. (Most prominently showing inside KDE).
    .
    This has been fixed in 7.4.2 but you experience this problem even after
    a second start of the new LibreOffice you might either need to 
reset your

    user profile or remove the affecting keys from it manuallly
    (ooSetupFactoryWindowAttributes in
    ~/.config/libreofficei/4/user/registrymodifications.xcu)

 -- Rene Engelhard   Wed, 09 Nov 2022 07:31:23 +0200

which then also shows for GNOME/XFCE/.. users, too, but oh, well...

[...]

Worth a  try at least. Would also be a senseful information for .NEWS.


Assuming ooSetupFactoryWindowAttributes removal would suffice.


Regards,


Rene

Bug#1019423: libreoffice: Need to maximize window manually before libreoffice window opens on plasma-desktop

[Rene Engelhard]

Hi,

Am 08.11.22 um 21:32 schrieb Rainer Dorsch:
So far I confirmed that it does not happen in safe mode. I assume that 
at least

some Debian users upgrading to bookworm will run into this issue.
Well, people either use stable and has 7.0.4 and skip the broken 7.4.1 
when upgrading since bookworm will contain 7.4.2+ (the sign that it does 
is that it appeared in bullseye-backports now) nad already had 7.4.1 
installed in bullseye/bullseye-backports and are already affected.

I think the users should be notified during the upgrade.


Maybe, yes.

The question is where? libreoffice-core would be the correct place but 
then people not using KDE will also get it. -kf5/-qt5 might do it as 
they seem somehow to be the only affected but then it might be shown 
twice and is on the package which doesn't have the actual fix/file 
affected...



If anybody is interested in defining some experiments to narrow down the issue
and try to avoid the complete user profile resetting requirement after the
upgrade to bookworm, please let me know. Otherwise I would just reset my user
profile and assume that this will work fine for me.


Well, if the bug report title is right you probably can  just remove the 
affected key?


rene@frodo:~/.config/libreoffice$ grep -r ooSetupFactoryWindowAttributes *
4/user/registrymodifications.xcu:oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.drawing.DrawingDocument']">oor:name="ooSetupFactoryWindowAttributes" 
oor:op="fuse">0,71,5,5;5;0,71,1921,1010;
4/user/registrymodifications.xcu:oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.frame.StartModule']">oor:name="ooSetupFactoryWindowAttributes" 
oor:op="fuse">0,71,37,33;5;0,71,1600,788;
4/user/registrymodifications.xcu:oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.presentation.PresentationDocument']">oor:name="ooSetupFactoryWindowAttributes" 
oor:op="fuse">0,0,208,2;5;0,0,1920,1009;
4/user/registrymodifications.xcu:oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']">oor:name="ooSetupFactoryWindowAttributes" 
oor:op="fuse">0,71,3,3;5;0,71,1921,1010;
4/user/registrymodifications.xcu:oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.text.TextDocument']">oor:name="ooSetupFactoryWindowAttributes" 
oor:op="fuse">0,71,1921,1010;5;0,71,1920,1009;


Worth a  try at least. Would also be a senseful information for .NEWS.


Regards,


Rene

Bug#1023728: dhcpcd5: Prefix delegation updates failing after link loss and recovery on WAN

[Wilfried Teiken]

Package: dhcpcd5
Version: 7.1.0-2
Severity: normal
Tags: ipv6 patch

Dear Maintainer,

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

   * What led up to the situation?
Set up multiple LANs with prefix delegation from WAN using ia_pd with an 
explicit list of interaces to delegate to.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Initial dhcp startup works fine, prefixes get delegated as expected.
When the WAN link is lost the delegated addresses are removed as expected.
After the link recovers the delegation does not work properly.
   * What was the outcome of this action?
Right after link restoration the first LAN interface gets an address from the 
prefix assigned. With each renew another interface get an address assigned.
   * What outcome did you expect instead?
All interfaces should get a delegated address assigned immediately.


Root cause: In dhcp6_delegate_prefix is a loop over all interfaces in the 
context. As the delegated prefixes are assigned the interface order is changing 
(e.g., due to DAD being executed for the newly assigned prefix which changes 
interface priority). This causes the loop to skip other LAN interfaces.

Solution that worked for me: Replace the loop with a "_SAFE" variant. This will 
likely process interfaces twice but this has no negative side effects.

The binary is modified on the system as I have the patched binary running 
successfully.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.153-clearfog (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dhcpcd5 depends on:
ii  libc6 2.31-13+deb11u5
ii  lsb-base  11.1.0

Versions of packages dhcpcd5 recommends:
ii  openresolv [resolvconf]  3.12.0-1

Versions of packages dhcpcd5 suggests:
pn  dhcpcd-gtk  

-- Configuration Files:
/etc/dhcpcd.conf changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/sbin/dhcpcd (from dhcpcd5 package)
--- dhcp6.c.orig2022-11-08 22:14:22.153113692 -0500
+++ dhcp6.c 2022-11-08 23:37:03.903831263 -0500
@@ -2751,7 +2751,7 @@
size_t i, j, k;
struct if_ia *ia;
struct if_sla *sla;
-   struct interface *ifd;
+   struct interface *ifd, *ifdn;
bool carrier_warned;
 
ifo = ifp->options;
@@ -2762,7 +2762,7 @@
ap->flags &= ~IPV6_AF_DELEGATEDLOG;
}
 
-   TAILQ_FOREACH(ifd, ifp->ctx->ifaces, next) {
+   TAILQ_FOREACH_SAFE(ifd, ifp->ctx->ifaces, next, ifdn) {
if (!ifd->active)
continue;
k = 0;

Bug#1023486: Please add loong64 support to dpkg

[WANG Xuerui]

On Sat, Nov 05, 2022 at 06:08:03PM +0800, 张丹丹 wrote:

Package: dpkg
Version: 1.21.10
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64


Do we want to insist on "loongarch64" while the Debian arch name is "loong64" 
instead?
As people are going to refer to this port as something like "Debian loong64" in 
the
coming days, I guess bug reports would come in with "loong64" tags and I'm not 
sure an
additional "loongarch64" tag would help.

Bug#1023727: ITP: r-cran-timechange -- Efficient Manipulation of Date-Times

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

Subject: ITP: r-cran-timechange -- Efficient Manipulation of Date-Times
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: r-cran-timechange
  Version : 0.1.1
  Upstream Author : Vitalie Spinu,
* URL : https://cran.r-project.org/package=timechange
* License : GPL-3
  Programming Lang: GNU R
  Description : Efficient Manipulation of Date-Times
 Efficient routines for manipulation of date-time objects while
 accounting for time-zones and daylight saving times. The package includes
 utilities for updating of date-time components (year, month, day etc.),
 modification of time-zones, rounding of date-times, period addition and
 subtraction etc. Parts of the 'CCTZ' source code, released under the Apache
 2.0 License, are included in this package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-timechange

Bug#1023725: rasdaemon: kernel null pointer dereference oops with rasdaemon

[Michael Stone]

Package: rasdaemon
Version: 0.6.7-1+b1
Severity: important
Tags: upstream

With linux-image-6.0.0-2-amd64 rasdaemon causes a kernel oops with a signature 
similar to this:
 BUG: kernel NULL pointer dereference, address: 01c8
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 0 P4D 0 
 Oops: 0002 [#1] PREEMPT SMP NOPTI
 CPU: 11 PID: 1227 Comm: rasdaemon Tainted: P   OE  6.0.0-2-amd64 
#1  Debian 6.0.6-2
 RIP: 0010:ring_buffer_wake_waiters+0x1c/0xa0

See
https://lore.kernel.org/lkml/CAM6Wdxft33zLeeXHhmNX5jyJtfGTLiwkQSApc=10fqf+rqh...@mail.gmail.com/T/
for a discussion of the bug (easiest to start from the bottom). It seems that
on systems which allow more cpus than are initialized[1], rasdaemon will attempt
to poll non-existent cpus which causes a kernel oops. The fix for this
reportedly causes rasdaemon to segfault which will likely require a fix there
as well.

A workaround for systems experiencing the oops with linux-image-6.0.0-2 is to
disable rasdaemon.

[1] On my system, dmesg reports
smpboot: Allowing 32 CPUs, 16 hotplug CPUs
for a system with 8 cores/16 threads

Bug#1023724: mirror submission for mirrors.eze.sysarmy.com

[Sysarmy]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.eze.sysarmy.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Sysarmy 
Country: AR Argentina
Sponsor: Sysarmy https://sysarmy.com/




Trace Url: http://mirrors.eze.sysarmy.com/debian/project/trace/
Trace Url: 
http://mirrors.eze.sysarmy.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirrors.eze.sysarmy.com/debian/project/trace/mirrors.eze.sysarmy.com

Bug#1023723: mirror submission for mirrors.eze.sysarmy.com

[Sysarmy]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.eze.sysarmy.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Sysarmy 
Country: AR Argentina
Sponsor: Sysarmy https://sysarmy.com/




Trace Url: http://mirrors.eze.sysarmy.com/debian/project/trace/
Trace Url: 
http://mirrors.eze.sysarmy.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirrors.eze.sysarmy.com/debian/project/trace/mirrors.eze.sysarmy.com

Bug#1023722: qrenderdoc crashes immediately

[Zeb Figura]

Package: qrenderdoc
Version: 1.22+dfsg-1
Severity: important

Dear Maintainer,

qrenderdoc crashes immmediately when run:

whatsit@camazotz:~$ qrenderdoc
Segmentation fault (core dumped)

A gdb backtrace suggests it's crashing trying to call the host glGetString,
which is NULL for some reason. I don't know why this would be. This is 64-bit
qrenderdoc; 64-bit glxgears works fine. Using `renderdoccmd capture` and
`renderdoccmd replay` also works fine.

This does not happen with the upstream renderdoc 1.22 package available at
.

gdb backtrace pasted below:

(gdb) bt
#0  0x in ?? ()
#1  0x7622cfd7 in glGetString_renderdoc_hooked (name=eGL_VERSION) at
./renderdoc/driver/gl/gl_hooks.cpp:158
#2  glGetString (name=eGL_VERSION) at ./renderdoc/driver/gl/gl_hooks.cpp:158
#3  0x73622359 in getGlString (param=7938) at
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:144
#4  updateFormatFromContext (format=...) at
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:174
#5  0x73623b7e in QGLXContext::init (this=0x5663ad30,
screen=, share=) at
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:416
#6  0x736211b7 in QXcbGlxIntegration::createPlatformOpenGLContext
(this=, context=0x7fffd0f0) at
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qxcbglxintegration.cpp:197
#7  0x74f827bd in QOpenGLContext::create (this=0x7fffd0f0) at
kernel/qopenglcontext.cpp:612
#8  0x701bd03c in ?? () from /usr/lib/x86_64-linux-
gnu/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
#9  0x748b7aaf in QCoreApplicationPrivate::init() () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x74f37b8c in QGuiApplicationPrivate::init (this=0x5652c620) at
kernel/qguiapplication.cpp:1530
#11 0x757684c9 in QApplicationPrivate::init() () from
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x55820884 in main ()


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 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 qrenderdoc depends on:
ii  libc6 2.36-4
ii  libgcc-s1 12.2.0-9
ii  libgl11.5.0-1
ii  libpython3.10 3.10.8-3
ii  libqt5core5a  5.15.6+dfsg-2
ii  libqt5gui55.15.6+dfsg-2
ii  libqt5network55.15.6+dfsg-2
ii  libqt5svg55.15.6-2
ii  libqt5widgets55.15.6+dfsg-2
ii  libqt5x11extras5  5.15.6-2
ii  librenderdoc  1.22+dfsg-1
ii  libstdc++612.2.0-9

qrenderdoc recommends no packages.

qrenderdoc suggests no packages.

-- no debconf information

Bug#993048: mosquitto init script broken with bullseye update

[Ethan Trevor]

Dear maintainers,

can you please apply the following patch to the mosquitto init script?

I fixed the problem with the PID file and made the code formatting more 
consistent.


The PID file cannot be created directly in /run as sergio suggested 
because mosquitto has no root privileges.


Thank you very much in advance!

Best regards,
Ethan


Index: mosquitto-2.0.11/debian/mosquitto.init
===
--- mosquitto-2.0.11.orig/debian/mosquitto.init	2021-06-09 
14:54:33.0 +0200
+++ mosquitto-2.0.11/debian/mosquitto.init	2022-11-08 23:38:28.973747203 
+0100

@@ -1,16 +1,16 @@
-#! /bin/sh
+#!/bin/sh

 ### BEGIN INIT INFO
-# Provides:mosquitto
-# Required-Start:  $remote_fs $syslog
-# Required-Stop:   $remote_fs $syslog
-# Default-Start:   2 3 4 5
-# Default-Stop:0 1 6
-# Short-Description:   mosquitto MQTT v3.1 message broker
-# Description:
+# Provides:   mosquitto
+# Required-Start: $remote_fs $syslog
+# Required-Stop:  $remote_fs $syslog
+# Default-Start:  2 3 4 5
+# Default-Stop:   0 1 6
+# Short-Description: mosquitto MQTT v3.1 message broker
+# Description:
 #  This is a message broker that supports version 3.1 of the MQ Telemetry
 #  Transport (MQTT) protocol.
-#
+#
 #  MQTT provides a method of carrying out messaging using a 
publish/subscribe

 #  model. It is lightweight, both in terms of bandwidth usage and ease of
 #  implementation. This makes it particularly useful at the edge of 
the network

@@ -20,12 +20,17 @@

 set -e

-PIDFILE=/run/mosquitto/mosquitto.pid
+NAME=mosquitto
+USER=mosquitto
 DAEMON=/usr/sbin/mosquitto
+PIDDIR=/run/mosquitto
+PIDFILE="${PIDDIR}/mosquitto.pid"
+LOGDIR=/var/log/mosquitto
+CONFFILE=/etc/mosquitto/mosquitto.conf

 # /etc/init.d/mosquitto: start and stop the mosquitto MQTT message broker

-test -x ${DAEMON} || exit 0
+test -x "$DAEMON" || exit 0

 umask 022

@@ -38,101 +43,110 @@

 export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"

+create_dirs() {
+mkdir -p "$PIDDIR"
+chown "$USER" "$PIDDIR"
+mkdir -p "$LOGDIR"
+chown "$USER" "$LOGDIR"
+}
+
 case "$1" in
-  start)
-   if init_is_upstart; then
-   exit 1
-   fi
-   log_daemon_msg "Starting network daemon:" "mosquitto"
-	if start-stop-daemon --start --quiet --oknodo --background 
--make-pidfile --pidfile ${PIDFILE} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then

-   log_end_msg 0
-   else
-   log_end_msg 1
-   fi
-   ;;
-  stop)
-   if init_is_upstart; then
-   exit 0
-   fi
-   log_daemon_msg "Stopping network daemon:" "mosquitto"
-   if start-stop-daemon --stop --quiet --oknodo --pidfile ${PIDFILE}; then
-   log_end_msg 0
-   rm -f ${PIDFILE}
-   else
-   log_end_msg 1
-   fi
-   ;;
-
-
-  reload|force-reload)
-   if init_is_upstart; then
-   exit 1
-   fi
-   log_daemon_msg "Reloading network daemon configuration:" "mosquitto"
-if start-stop-daemon --stop --signal HUP --quiet --oknodo 
--pidfile $PIDFILE; then

+start)
+if init_is_upstart; then
+exit 1
+fi
+create_dirs
+log_daemon_msg "Starting network daemon" "$NAME"
+if start-stop-daemon --user "$USER" --chuid "$USER" --start 
--quiet --oknodo --background --pidfile "$PIDFILE" --exec "$DAEMON" -- 
-c "$CONFFILE" ; then

+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+
+stop)
+if init_is_upstart; then
+exit 0
+fi
+log_daemon_msg "Stopping network daemon" "$NAME"
+if start-stop-daemon --user "$USER" --chuid "$USER" --stop 
--quiet --oknodo --pidfile "$PIDFILE"; then

+log_end_msg 0
+rm -f "$PIDFILE"
+else
+log_end_msg 1
+fi
+;;
+
+reload|force-reload)
+if init_is_upstart; then
+exit 1
+fi
+log_daemon_msg "Reloading network daemon configuration" "$NAME"
+if start-stop-daemon --user "$USER" --stop --signal HUP --quiet 
--oknodo --pidfile "$PIDFILE"; then

+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+
+restart)
+if init_is_upstart; then
+exit 1
+fi
+log_daemon_msg "Restarting network daemon" "$NAME"
+if start-stop-daemon --user "$USER" --stop --quiet --oknodo 
--retry 30 --pidfile "$PIDFILE"; then

+rm -f "$PIDFILE"
+fi
+create_dirs
+if start-stop-daemon --user "$USER" --chuid "$USER" --start 
--quiet --oknodo --background --pidfile "$PIDFILE" --exec "$DAEMON" -- 
-c "$CONFFILE" ; then

 log_end_msg 0
 else
 log_end_msg 1
-fi 
-   ;;
+fi
+;;

-  restart)
-   if init_is_upstart; then
-   exit 1
-   fi
-   log_daemon_msg "Restarting network 

Bug#1023721: libx86emu: enable upstream tests at build time

[Paul Wise]

Source: libx86emu
Version: 3.5-1
Severity: wishlist

The libx86emu upstream tests work when adding nasm to the build-deps
and dropping override_dh_auto_test from debian/rules. The tests also do
not take very long, so there isn't any reason to keep them disabled as
far as I can tell. Please enable the upstream tests.

Since nasm is only needed for the tests, please annotate the build-dep
of nasm with the nocheck build profile like this:

   Build-Depends: nasm 

https://wiki.debian.org/BuildProfileSpec

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1023720: linux: Couldn't find DTB rk3328-rock64.dtb in /usr/lib/linux-image-6.1.0-0-arm64

[Diederik de Haas]

Source: linux
Version: 6.1~rc3-1~exp1
Severity: important

I just used d-i from 20221108 to install a fresh Debian Bookworm system
on my Rock64. After reboot I added (Sid and) Experimental sources as my
goal is/was to install/run kernel version 6.1~rc3-1~exp1.

That did not succeed:

==

root@rock64-bookworm-test:~# uname -a
Linux rock64-bookworm-test 6.0.0-2-arm64 #1 SMP Debian 6.0.5-1 (2022-10-28) 
aarch64 GNU/Linux
root@rock64-bookworm-test:~# aptitude versions linux-image-arm64
i   6.0.5-1 
   testing,unstable 
   990
p   6.1~rc3-1~exp1  
   experimental 
   101
root@rock64-bookworm-test:~# aptitude safe-upgrade linux-image-arm64 -t 
experimental
Resolving dependencies...
The following NEW packages will be installed:
  linux-image-6.1.0-0-arm64{a}
The following packages will be upgraded:
  linux-image-arm64
1 packages upgraded, 1 newly installed, 0 to remove and 40 not upgraded.
Need to get 59.5 MB of archives. After unpacking 398 MB will be used.
Do you want to continue? [Y/n/?]
Get: 1 http://deb.debian.org/debian experimental/main arm64 
linux-image-6.1.0-0-arm64 arm64 6.1~rc3-1~exp1 [59.5 MB]
Get: 2 http://deb.debian.org/debian experimental/main arm64 linux-image-arm64 
arm64 6.1~rc3-1~exp1 [1,444 B]
Fetched 59.5 MB in 6s (9,300 kB/s)
Reading changelogs... Done
Selecting previously unselected package linux-image-6.1.0-0-arm64.
(Reading database ... 29422 files and directories currently installed.)
Preparing to unpack .../linux-image-6.1.0-0-arm64_6.1~rc3-1~exp1_arm64.deb ...
Unpacking linux-image-6.1.0-0-arm64 (6.1~rc3-1~exp1) ...
Preparing to unpack .../linux-image-arm64_6.1~rc3-1~exp1_arm64.deb ...
Unpacking linux-image-arm64 (6.1~rc3-1~exp1) over (6.0.5-1) ...
Setting up linux-image-6.1.0-0-arm64 (6.1~rc3-1~exp1) ...
I: /boot/vmlinuz is now a symlink to vmlinuz-6.1.0-0-arm64
I: /boot/initrd.img is now a symlink to initrd.img-6.1.0-0-arm64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-0-arm64
W: Possible missing firmware /lib/firmware/rockchip/dptx.bin for module 
rockchipdrm
Using DTB: rockchip/rk3328-rock64.dtb
Couldn't find DTB rk3328-rock64.dtb in /usr/lib/linux-image-6.1.0-0-arm64 or 
/etc/flash-kernel/dtbs
Installing  into /boot/dtbs/6.1.0-0-arm64/rockchip/rk3328-rock64.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-0-arm64 (--configure):
 installed linux-image-6.1.0-0-arm64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-arm64:
 linux-image-arm64 depends on linux-image-6.1.0-0-arm64 (= 6.1~rc3-1~exp1); 
however:
  Package linux-image-6.1.0-0-arm64 is not configured yet.

dpkg: error processing package linux-image-arm64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-0-arm64
 linux-image-arm64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up linux-image-6.1.0-0-arm64 (6.1~rc3-1~exp1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-0-arm64
W: Possible missing firmware /lib/firmware/rockchip/dptx.bin for module 
rockchipdrm
Using DTB: rockchip/rk3328-rock64.dtb
Couldn't find DTB rk3328-rock64.dtb in /usr/lib/linux-image-6.1.0-0-arm64 or 
/etc/flash-kernel/dtbs
Installing  into /boot/dtbs/6.1.0-0-arm64/rockchip/rk3328-rock64.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-6.1.0-0-arm64 (--configure):
 installed linux-image-6.1.0-0-arm64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-arm64:
 linux-image-arm64 depends on linux-image-6.1.0-0-arm64 (= 6.1~rc3-1~exp1); 
however:
  Package linux-image-6.1.0-0-arm64 is not configured yet.

dpkg: error processing package linux-image-arm64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-0-arm64
 linux-image-arm64

Current status: 40 (-1) upgradable.
root@rock64-bookworm-test:~# ls -lhd /usr/lib/linux*
drwxr-xr-x 16 root root 4.0K Nov  8 23:08 /usr/lib/linux-image-6.0.0-2-arm64
==

The /usr/lib/linux-image-6.1.0-0-arm64 does indeed not exist

Bug#1021918: debian-installer: Kernel module blacklisting inconsistent

[Pascal Hambourg]

On 08/11/2022 at 12:35, Olaf Meeuwissen wrote:


Pascal Hambourg  writes:


I could not reproduce this after tricking the installer into unloading
and reloading the mt7921e module. The module unloads and reloads
cleanly. But I do not have any hardware matching this module.


The freeze probably only occurs when an attempt to loadh the firmware
file is made.


I don't think so. I think it happens when unloading the module.


Anyway, this issue is not with this particular kernel module but with
the installer's inconsistent module blacklisting behaviour.


The freeze is related with this kernel module, not the installer.


It looks like a kernel bug when unloading this module. Can you trigger
the bug in an installed system ? If yes it means that it not specific
to the installer.


Checked this morning.  With the firmware file loaded, rmmod succeeds
without problems.  With the firmware file not loaded, trying to rmmod it
echoes "Killed" on the command-line and created a longish call trace in
/var/log/kern.log.  Not sure if it was the same, though.


As expected.


You may want to double check how the kernel command parse results
are used then.


I did, and .blacklist works as expected with NIC modules
matching my hardware (iwlwifi and e1000e).


I meant double check by reading the source code


I did.


not by trying with some rather commonly used modules.


The blacklist handling is not related to a specific module, so any 
module matching present hardware will do.



You mentioned above that's a minor bug and easily fixed.  If so, then
please fix it.


I am not a Debian developer. The best I can do is submit a patch.


By all means, please do.  Thanks in advance.


Already done in another mail with attached patches sent to the bug.


The netinst one, according to the syslog I attached earlier.  Looking at
that log, I don't see any proof of the firmware loading error fly by
before the installer starts.


Indeed, the log clearly shows that the module is loaded at the 
"detecting networking hardware" step as expected.



I cannot reproduce the firmware file load failures before the installer
starts.

Consistent with the previous log.

Bug#1023303: jhead 1:3.06.0.1-3 deletes EXIF data

[Stefan Pietsch]

On 04.11.22 09:36, Joachim Reichel wrote:

Hi Stefan,

it would have been helpful if you had attached an image that shows this behavior. I have an idea what the problem might be, but having 
access to your test case for verification would be good. Feel free to send it directly to my email address if you prefer.


Best regards,
   Joachim



Hi Joachim,

I have uploaded the test picture here: 
https://salsa.debian.org/IPv4v6/debian-bug-1023303/-/blob/master/IMG_20221102_000230.jpg


Best regards,
Stefan

Bug#1023719: field3d FTBFS: OpenEXR/ImathBox.h: No such file or directory

[Adrian Bunk]

Source: field3d
Version: 1.7.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=field3d=amd64=1.7.2-1%2Bb11=1667935694=0

...
/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK 
-DBOOST_THREAD_DYN_LINK -DField3D_EXPORTS -DREQUIRE_IOSTREAM 
-I/<>/. -I/<>/src -I/<>/export 
-I/<>/include -I/usr/include/hdf5/serial -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   
-fPIC -Wno-invalid-offsetof -MD -MT 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o -MF 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o.d -o 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o -c 
/<>/src/ClassFactory.cpp
In file included from /<>/export/Types.h:56,
 from /<>/export/Traits.h:54,
 from /<>/export/Field.h:55,
 from /<>/export/ClassFactory.h:50,
 from /<>/src/ClassFactory.cpp:44:
/<>/export/StdMathLib.h:41:10: fatal error: OpenEXR/ImathBox.h: No 
such file or directory
   41 | #include 
  |  ^~~~
compilation terminated.
make[3]: *** [CMakeFiles/Field3D.dir/build.make:79: 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o] Error 1

Bug#1018828: innoextract: NMU 1.9-0.1

[Bastian Germann]

I am sponsoring NMU 1.9-0.1. debdiff attached.diff -Nru innoextract-1.8/CHANGELOG innoextract-1.9/CHANGELOG
--- innoextract-1.8/CHANGELOG   2020-01-15 16:29:27.0 +0100
+++ innoextract-1.9/CHANGELOG   2020-08-09 20:48:04.0 +0200
@@ -1,4 +1,14 @@
 
+innoextract 1.9 (2020-08-09)
+ - Added preliminary support for Inno Setup 6.1.0
+ - Added support for a modified Inno Setup 5.4.2 variant
+ - Fixed output directory being created for unsupported installers
+ - Fixed some safe non-ASCII characters being stripped from filenames
+ - Fixed handling of path separators in Japanese and Korean installers
+ - Fixed build with newer Boost versions
+ - Windows: Fixed heap corruption
+ - Windows: Fixed garbled output
+
 innoextract 1.8 (2019-09-15)
  - Added support for Inno Setup 6.0.0 installers
  - Added support for pre-release Inno Setup 5.6.2 installers used by GOG
diff -Nru innoextract-1.8/cmake/CompileCheck.cmake 
innoextract-1.9/cmake/CompileCheck.cmake
--- innoextract-1.8/cmake/CompileCheck.cmake2020-01-15 16:29:27.0 
+0100
+++ innoextract-1.9/cmake/CompileCheck.cmake2020-08-09 20:48:04.0 
+0200
@@ -1,5 +1,5 @@
 
-# Copyright (C) 2011-2019 Daniel Scharrer
+# Copyright (C) 2011-2020 Daniel Scharrer
 #
 # This software is provided 'as-is', without any express or implied
 # warranty.  In no event will the author(s) be held liable for any damages
@@ -131,7 +131,7 @@
 endfunction(check_flag)
 
 macro(strip_warning_flags VAR)
-   string(REGEX REPLACE "(^| )\\-(W[^ ]*|pedantic)" "" ${VAR} "${${VAR}}")
+   string(REGEX REPLACE "(^| )\\-(W[^ l][^ ]*|Wl[^,][^ ]*|pedantic)" "" 
${VAR} "${${VAR}}")
 endmacro()
 
 function(check_builtin RESULT EXPR)
@@ -191,96 +191,3 @@
endif()

 endfunction(add_ldflag)
-
-function(try_link_library LIBRARY_NAME LIBRARY_FILE ERROR_VAR)
-   # See if we can link a simple program with the library using the 
configured c++ compiler
-   set(link_test_file "${CMAKE_CURRENT_BINARY_DIR}/link_test.cpp")
-   file(WRITE ${link_test_file} "int main(){}\n")
-   if(CMAKE_THREAD_LIBS_INIT)
-   list(APPEND LIBRARY_FILE "${CMAKE_THREAD_LIBS_INIT}")
-   endif()
-   try_compile(
-   CHECK_${LIBRARY_NAME}_LINK "${PROJECT_BINARY_DIR}" 
"${link_test_file}"
-   CMAKE_FLAGS "-DLINK_LIBRARIES=${LIBRARY_FILE}"
-   "-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}"
-   "-DCMAKE_EXE_LINKER_FLAGS=${CMAKE_EXE_LINKER_FLAGS}"
-   
"-DCMAKE_SHARED_LINKER_FLAGS=${CMAKE_SHARED_LINKER_FLAGS}"
-   
"-DCMAKE_MODULE_LINKER_FLAGS=${CMAKE_MODULE_LINKER_FLAGS}"
-   OUTPUT_VARIABLE ERRORLOG
-   )
-   set(${ERROR_VAR} "${ERRORLOG}" PARENT_SCOPE)
-endfunction(try_link_library)
-
-##
-# Check that a a library actually works for the current configuration
-# This is neede because CMake prefers /usr/lib over /usr/lib32 for -m32 builds
-# See https://public.kitware.com/Bug/view.php?id=11260
-function(check_link_library LIBRARY_NAME LIBRARY_VARIABLE)
-   
-   if(MSVC)
-   # The main point of this is to work around CMakes ignorance of 
lib32.
-   # This doesn't really apply for systems that don't use a 
unix-like library dir layout.
-   return()
-   endif()
-   
-   set(lib_current "${${LIBRARY_VARIABLE}}")
-   set(found_var "ARX_CLL_${LIBRARY_NAME}_FOUND")
-   set(working_var "ARX_CLL_${LIBRARY_NAME}_WORKING")
-   
-   if(CHECK_${LIBRARY_NAME}_LINK)
-   set(lib_found "${${found_var}}")
-   set(lib_working "${${working_var}}")
-   if((lib_current STREQUAL lib_found) OR (lib_current STREQUAL 
lib_working))
-   set("${LIBRARY_VARIABLE}" "${lib_working}" PARENT_SCOPE)
-   return()
-   endif()
-   endif()
-   
-   set("${found_var}" "${lib_current}" CACHE INTERNAL "...")
-   
-   if(NOT lib_current STREQUAL "")
-   message(STATUS "Checking ${LIBRARY_NAME}: ${lib_current}")
-   endif()
-   
-   # Check if we can link to the full path found by find_package
-   try_link_library(${LIBRARY_NAME} "${lib_current}" ERRORLOG1)
-   
-   if(CHECK_${LIBRARY_NAME}_LINK)
-   set("${working_var}" "${lib_current}" CACHE INTERNAL "...")
-   return()
-   endif()
-   
-   # Check if the linker is smarter than cmake and try to link with only 
the library name
-   string(REGEX REPLACE "(^|;)[^;]*/lib([^;/]*)\\.so" "\\1-l\\2"
-  LIBRARY_FILE "${lib_current}")
-   
-   if(NOT LIBRARY_FILE STREQUAL lib_current)
-   
-   try_link_library(${LIBRARY_NAME} "${LIBRARY_FILE}" ERRORLOG2)
-   
-   if(CHECK_${LIBRARY_NAME}_LINK)
-   

Bug#1019806: marked as pending in sooperlooper

[Olly Betts]

On Tue, Sep 20, 2022 at 09:18:52PM +, Dennis Braun wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #1019806 in sooperlooper reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/multimedia-team/sooperlooper/-/commit/f8994f33f1dbfae2d7f4820f7c35af60b14501db
> 
> 
> Transition to wxWidgets 3.2 (Closes: #1019806)
> 

This was tagged "pending" 7 weeks ago, but hasn't been uploaded yet.

Could one of the maintainers please make an upload soon?

I see recent uploads were sponsored - if lack of a sponsor is the blocker
I can sponsor.

Cheers,
Olly

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Sudip Mukherjee]

On Tue, Nov 8, 2022 at 6:06 PM Pavel Odintsov  wrote:
>
> Hello!
>
> I think I have one more question.
>
> For most of the platforms we support libbpf 1.0.1 works fine but I noticed 
> issues with Debian 11 and Ubuntu 20 about enum declarations:

Can you please give me the steps to reproduce this enum error. libbpf
1.0.1 is not available in Debian-11, so I built a backport package for
libbpf/1.0.1 and then tried building fastnetmon with the backported
libbpf in a Bullseye chroot. I did not see the enum issue, but I got a
different error:

/<>/src/fastnetmon.cpp: In function ‘int main(int, char**)’:
/<>/src/fastnetmon.cpp:1540:14: error: ‘std::filesystem’
has not been declared
 1540 | if (std::filesystem::exists(backtrace_path)) {
  |  ^~
/<>/src/fastnetmon.cpp:1550:14: error: ‘std::filesystem’
has not been declared
 1550 | std::filesystem::remove(backtrace_path);
  |  ^~
make[3]: *** [CMakeFiles/fastnetmon.dir/build.make:85:
CMakeFiles/fastnetmon.dir/fastnetmon.cpp.o] Error 1

Note: I saw that you have commented on the upstream issue about the
enum problem and noticed you are using "latest C++ compiler (not from
Linux distro) and C++ 2022."

-- 
Regards
Sudip

Bug#1023718: ffmpeg: Please enable oneVPL support

[Michael Fladischer]

Source: ffmpeg
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

now that oneVPL has made its way into the archive, it would be nice to have
- --enable-libvpl added.
albeit there is one caveat: --enable-libvpl connot be used together with
- --enable-libmfx.

Regards,
Michael

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmNq11ERHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrwtAgAgiKA1RBySIynuOyTDO6cf3jcYRXvAh9w
LJxCQkuEdSg0/XCu4Gm+cn6Xdvy4fFDs2aq8lhDX23sj79K5nsDJUVg4GmvI8xOf
qWZpEOjHp3h45auN9MPR4pPRlyk/kU6BkZvqLVjJcwjWJCwFL3pYWN5Xso+r6rP/
HbAFjGZs+ZUuSsxHYeyK6OGbrIttt6jZVgSXXj7Uyk4xYnC7K6cycpnHSBQCodQd
DpEUx1V6jN7LkIeI4rZKCpS/1ip6jFEK/APsMIrccJWXaTjDrGYUXg2DTza6MrGI
on/I6wzurWGKf2RS1VTt8qoT3KO5wc+O+Ds4r4NEIxcrAcetd7oX/w==
=P5d8
-END PGP SIGNATURE-

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Sudip Mukherjee]

On Tue, Nov 8, 2022 at 4:55 PM Pavel Odintsov  wrote:
>
> Hello!
>
> Added copy to all.
>
> I think I fixed it with these commits: 
> https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4
>  and 
> https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c

Thanks.

>
> I've used 
> https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/ and 
> https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c as 
> examples as this code was my reference during implementation.
>
> Would be great if you could review it a second time.

lgtm.


-- 
Regards
Sudip

Bug#1023717: libbpf: CVE-2022-3533 CVE-2022-3534 CVE-2022-3606

[Salvatore Bonaccorso]

Source: libbpf
Version: 1.0.1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for libbpf.

CVE-2022-3533[0]:
| A vulnerability was found in Linux Kernel. It has been rated as
| problematic. This issue affects the function parse_usdt_arg of the
| file tools/lib/bpf/usdt.c of the component BPF. The manipulation of
| the argument reg_name leads to memory leak. It is recommended to apply
| a patch to fix this issue. The associated identifier of this
| vulnerability is VDB-211031.


CVE-2022-3534[1]:
| A vulnerability classified as critical has been found in Linux Kernel.
| Affected is the function btf_dump_name_dups of the file
| tools/lib/bpf/btf_dump.c of the component libbpf. The manipulation
| leads to use after free. It is recommended to apply a patch to fix
| this issue. The identifier of this vulnerability is VDB-211032.


CVE-2022-3606[2]:
| A vulnerability was found in Linux Kernel. It has been classified as
| problematic. This affects the function find_prog_by_sec_insn of the
| file tools/lib/bpf/libbpf.c of the component BPF. The manipulation
| leads to null pointer dereference. It is recommended to apply a patch
| to fix this issue. The identifier VDB-211749 was assigned to this
| vulnerability.


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

For further information see:

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

https://github.com/libbpf/libbpf/commit/881a10980b7ded995da5d9cc1919992c36c9d2be
[1] https://security-tracker.debian.org/tracker/CVE-2022-3534
https://www.cve.org/CVERecord?id=CVE-2022-3534

https://github.com/libbpf/libbpf/commit/54caf920db0e489de90f341e2a51ddbcd084
[2] https://security-tracker.debian.org/tracker/CVE-2022-3606
https://www.cve.org/CVERecord?id=CVE-2022-3606

https://github.com/libbpf/libbpf/commit/3a3ef0c1d09e1894740db71cdcb7be0bfd713671

Regards,
Salvatore

Bug#1023651: 2.9.0~pre0+git20221105.ffb6bda926-1.2 NMU: Fix build failure on arm and hppa

[Petter Reinholdtsen]

I updated the NMU to handle an extra HPPA CPU string found on a build
daemon.  This is the updated patch.

--- linuxcnc-2.9.0~pre0+git20221105.ffb6bda926/debian/changelog 2022-11-06 
03:48:00.0 +0100
+++ linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/debian/changelog 
2022-11-08 22:39:48.431085361 +0100
@@ -1,3 +1,19 @@
+linuxcnc (2.9.0~pre0+git20221105.ffb6bda926-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Updated 0010-arm-hppa.patch from upstream to handle hppa1.1 cpu and to
+exit build earlier if libboost-python is not found.
+
+ -- Petter Reinholdtsen   Tue, 08 Nov 2022 22:38:32 +0100
+
+linuxcnc (2.9.0~pre0+git20221105.ffb6bda926-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Added 0010-arm-hppa.patch from upstream to fix build failures on armv8l
+and hppa64 CPU build daemons.
+
+ -- Petter Reinholdtsen   Tue, 08 Nov 2022 09:55:13 +0100
+
 linuxcnc (2.9.0~pre0+git20221105.ffb6bda926-1) unstable; urgency=medium
 
   * New upstream version 2.9.0~pre0+git20221105.ffb6bda926
--- /dev/null   2022-11-05 21:32:50.228001479 +0100
+++ linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/debian/patches/series
2022-11-08 10:23:10.981029985 +0100
@@ -0,0 +1 @@
+0010-arm-hppa.patch
--- /dev/null   2022-11-05 21:32:50.228001479 +0100
+++ 
linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/debian/patches/0010-arm-hppa.patch
   2022-11-08 22:38:05.358652658 +0100
@@ -0,0 +1,85 @@
+commit 37cc349c296e04fe274574210dbafcc3ad755c18
+Author: Petter Reinholdtsen 
+Date:   Mon Nov 7 14:53:44 2022 +0100
+
+Fix boost python detection on arm and hppa in ax_boost_base.m4.
+
+This should fix the failing build on Debian.
+
+Also reintroduce a typo fix in the file header that was lost in a recent
+upgrade of the file version.
+
+The change has been emailed Thomas Porschberg to get it upstream.  Not sure
+if it is going to work, as a comment on
+http://randspringer.de/boost/index.html > make it sound like he want
+to no longer maintain the file.
+
+Index: linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/src/m4/ax_boost_base.m4
+===
+--- 
linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu.orig/src/m4/ax_boost_base.m4 
   2022-11-08 22:36:16.390194781 +0100
 linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/src/m4/ax_boost_base.m4 
2022-11-08 22:37:58.154622401 +0100
+@@ -10,7 +10,7 @@
+ #
+ #   Test for the Boost C++ libraries of a particular version (or newer)
+ #
+-#   If no path to the installed boost library is given the macro searchs
++#   If no path to the installed boost library is given the macro searches
+ #   under /usr, /usr/local, /opt, /opt/local and /opt/homebrew and evaluates
+ #   the $BOOST_ROOT environment variable. Further documentation is available
+ #   at .
+@@ -123,7 +123,8 @@
+ dnl are almost assuredly the ones desired.
+ AS_CASE([${host_cpu}],
+   [i?86],[multiarch_libsubdir="lib/i386-${host_os}"],
+-  [armv7l],[multiarch_libsubdir="lib/arm-${host_os}"],
++  [armv?l],[multiarch_libsubdir="lib/arm-${host_os}"],
++  [hppa1.1|hppa64],[multiarch_libsubdir="lib/hppa-${host_os}"],
+   [multiarch_libsubdir="lib/${host_cpu}-${host_os}"]
+ )
+ 
+Index: linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/src/configure.ac
+===
+--- linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu.orig/src/configure.ac   
2022-10-23 18:28:59.0 +0200
 linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/src/configure.ac
2022-11-08 22:37:58.154622401 +0100
+@@ -112,6 +112,7 @@
+   ])
+ ])
+ 
++DEPFOUND=true
+ 
+ ##
+ # Section 2  #
+@@ -1001,7 +1002,11 @@
+ AX_PYTHON
+ AC_PATH_PROG(PYTHON,[$PYTHON_BIN])
+ AX_PYTHON_DEVEL(,,AC_MSG_ERROR([python-dev not found]))
+-AX_BOOST_PYTHON(,,AC_MSG_ERROR([libboost-python not found]))
++AX_BOOST_PYTHON()
++if test "x" = "x$BOOST_PYTHON_LIB"; then
++AC_MSG_NOTICE([error: libboost-python not found])
++DEPFOUND=false
++fi
+ 
+ AC_MSG_CHECKING([whether to build documentation])
+ AC_ARG_ENABLE(build-documentation,
+@@ -1744,8 +1749,12 @@
+ echo "#   GPL.  Check out http://www.linuxcnc.org/ for more details.   #"
+ echo "##"
+ echo "##"
+-echo "#   It seems that ./configure completed successfully.#"
+-echo "#   This means that RT is properly installed #"
++if $DEPFOUND ; then
++  echo "#   It seems that ./configure completed successfully.
#"
++  echo "#   This means that RT is properly installed 
#"
++else
++  echo "#   It seems that 

Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm

[Hauke Mehrtens]

Package: cryptsetup
Version: 2:2.5.0-6
Severity: important

Dear Maintainer,

Unlocking and mounting of the root partitions does not work any more
from the initramfs. When I call cryptroot-unlock and provide the disk
password I see some error messages about mdadm, but the bootup process
does not continue. If needed I can provide the detailed messages, they
are not in a log file, but only printed on screen. Normally I unlock the
system over the network from the initramfs, then I do not get any error
message, but the system continues to stay in initramfs.

It looks like this when unlocking the system unsuccessfully from the
initramfs over ssh:
--
$ ssh root@192.168.10.15
To unlock root partition, and maybe others like swap, run 
`cryptroot-unlock`.



BusyBox v1.35.0 (Debian 1:1.35.0-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # vi /scripts/local-top/cryptroot
~ # cryptroot-unlock
Please unlock disk sda3_crypt:
cryptsetup: sda3_crypt set up successfully
~ #
--

The system was installed using Debian bookworm in July 2022 and
unlocking worked fine at that time.
Then this change was introduced which broke the unlocking:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6
When I revert this change and generate a new initramfs it works again.

Hauke


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.0.0-2-amd64 root=/dev/mapper/system-root ro 
rd.luks.options=discard


-- /etc/crypttab
sda3_crypt UUID=aabe34b0-d2e8-4e3f-9243-655acdc286bc none luks,discard
data1_crypt UUID=d835f05f-a68d-445a-b7b0-75092049d23b /etc/cryptkeyfile luks
data2_crypt UUID=e2cf01d0-2982-48b0-837f-d83cf1445185 /etc/cryptkeyfile luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#
/dev/mapper/system-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/sda2 during installation
UUID=1a2f9f2a-4d12-49bf-a170-bb6536cf2a97 /boot   ext4 
defaults0   2

# /boot/efi was on /dev/sda1 during installation
UUID=25FC-83BA  /boot/efi   vfatumask=0077  0   1
/dev/mapper/system-swap noneswapsw  0   0

-- lsmod
Module  Size  Used by
vhost_net  36864  2
vhost  57344  1 vhost_net
vhost_iotlb16384  1 vhost
tap28672  1 vhost_net
tun61440  5 vhost_net
ctr16384  2
ccm20480  6
dm_cache_smq   28672  1
dm_cache   73728  2 dm_cache_smq
dm_persistent_data106496  1 dm_cache
dm_bio_prison  20480  1 dm_cache
dm_bufio   40960  1 dm_persistent_data
qrtr   49152  4
dm_raid45056  3
bridge311296  0
stp16384  1 bridge
llc16384  2 bridge,stp
binfmt_misc24576  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   24576  1
intel_rapl_msr 20480  0
fat90112  1 vfat
intel_rapl_common  28672  1 intel_rapl_msr
amdgpu   9347072  0
iwlmvm376832  0
btusb  65536  0
btrtl  28672  1 btusb
btbcm  24576  1 btusb
btintel45056  1 btusb
btmtk  16384  1 btusb
mac80211 1159168  1 iwlmvm
bluetooth 954368  6 btrtl,btmtk,btintel,btbcm,btusb
snd_hda_codec_hdmi 81920  1
libarc416384  1 mac80211
snd_hda_intel  57344  0
edac_mce_amd   40960  0
snd_intel_dspcfg   36864  1 snd_hda_intel
jitterentropy_rng  16384  1
iwlwifi   356352  1 iwlmvm
snd_intel_sdw_acpi 20480  1 snd_intel_dspcfg
snd_hda_codec 184320  2 snd_hda_codec_hdmi,snd_hda_intel
gpu_sched  53248  1 amdgpu
sha512_ssse3   49152  1
kvm_amd   155648  4
sha512_generic 16384  1 sha512_ssse3
drm_buddy  20480  1 amdgpu
eeepc_wmi  16384  0
drm_display_helper184320  1 amdgpu
evdev  28672  2
snd_hda_core  122880  3 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec

drbg   45056  1
kvm  1122304  1 kvm_amd
asus_wmi   61440  1 eeepc_wmi
cec61440  1 drm_display_helper
cfg80211 1118208  3 iwlmvm,iwlwifi,mac80211
rc_core69632  1 cec
snd_hwdep  16384  1 snd_hda_codec
drm_ttm_helper 16384  1 amdgpu
ansi_cprng 16384  0
platform_profile

Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1

[Olly Betts]

Control: tags 1019790 + patch

Dear maintainer,

I've managed to build eviacam using wxwidgets3.2 with a couple of minor
changes (patch attached).

However I can't test my patched build because eviacam doesn't start
(I'm guessing it doesn't like my webcam for some reason) - starting it I
get:

$ eviacam
[ERROR:0@0.016] global ./modules/core/src/persistence.cpp (505) open Can't open 
file: '/usr/share/eviacam/haarcascade_frontalface_default.xml' in read mode
[ERROR:0@0.017] global ./modules/core/src/persistence.cpp (505) open Can't open 
file: '/usr/share/opencv/haarcascades/haarcascade_frontalface_default.xml' in 
read mode
[ERROR:0@0.017] global ./modules/core/src/persistence.cpp (505) open Can't open 
file: '/usr/share/OpenCV/haarcascades/haarcascade_frontalface_default.xml' in 
read mode
[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, name = 
'User Controls', type = 6
[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x00980001, name = 'User Controls'
[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x009A0001, name = 
'Camera Controls', type = 6
[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x009A0001, name = 'Camera Controls'

(eviacam:184091): Gtk-CRITICAL **: 10:24:53.628: gtk_box_gadget_distribute: 
assertion 'size >= 0' failed in GtkScrollbar
[ WARN:0@3.768] global ./modules/videoio/src/videoio_c.cpp (15) 
cvCreateCameraCapture cvCreateCameraCapture doesn't support legacy API anymore.
$

I also get the same error for the version already in unstable.

Please can you test with my patch, and upload if it works.

Cheers,
Olly
diff -Nru eviacam-2.1.4/debian/changelog eviacam-2.1.4/debian/changelog
--- eviacam-2.1.4/debian/changelog	2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/changelog	2022-11-09 10:14:08.0 +1300
@@ -1,3 +1,11 @@
+eviacam (2.1.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Update to build with wxwidgets-3.2 (new patch
+wx3.2-compat.patch) (Closes: #1019790)
+
+ -- Olly Betts   Wed, 09 Nov 2022 10:14:08 +1300
+
 eviacam (2.1.4-2) unstable; urgency=medium
 
   * Team upload
diff -Nru eviacam-2.1.4/debian/control eviacam-2.1.4/debian/control
--- eviacam-2.1.4/debian/control	2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/control	2022-11-09 10:05:50.0 +1300
@@ -7,7 +7,7 @@
libopencv-dev (>= 2.0),
libpng-dev,
libv4l-dev,
-   libwxgtk3.0-gtk3-dev,
+   libwxgtk3.2-dev,
libgtk-3-dev,
libxext-dev,
libxtst-dev,
diff -Nru eviacam-2.1.4/debian/patches/series eviacam-2.1.4/debian/patches/series
--- eviacam-2.1.4/debian/patches/series	2020-02-12 02:09:11.0 +1300
+++ eviacam-2.1.4/debian/patches/series	2022-11-09 10:14:08.0 +1300
@@ -1 +1,2 @@
 new-opencv.patch
+wx3.2-compat.patch
diff -Nru eviacam-2.1.4/debian/patches/wx3.2-compat.patch eviacam-2.1.4/debian/patches/wx3.2-compat.patch
--- eviacam-2.1.4/debian/patches/wx3.2-compat.patch	1970-01-01 12:00:00.0 +1200
+++ eviacam-2.1.4/debian/patches/wx3.2-compat.patch	2022-11-09 10:14:08.0 +1300
@@ -0,0 +1,29 @@
+Description: Fixes for compatibility with wxWidgets 3.2
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/1019790
+Forwarded: no
+Last-Update: 2022-11-08
+
+--- a/src/wviacam.cpp
 b/src/wviacam.cpp
+@@ -598,7 +598,8 @@
+ 		case (wxLANGUAGE_SPANISH_GUATEMALA):
+ 		case (wxLANGUAGE_SPANISH_HONDURAS):
+ 		case (wxLANGUAGE_SPANISH_MEXICAN):
+-		case (wxLANGUAGE_SPANISH_MODERN):
++		// Same value as wxLANGUAGE_SPANISH in wx3.2:
++		// case (wxLANGUAGE_SPANISH_MODERN):
+ 		case (wxLANGUAGE_SPANISH_NICARAGUA):
+ 		case (wxLANGUAGE_SPANISH_PANAMA):
+ 		case (wxLANGUAGE_SPANISH_PARAGUAY):
+--- a/src/viacamcontroller.cpp
 b/src/viacamcontroller.cpp
+@@ -230,7 +230,7 @@
+ 
+ 			wxSingleChoiceDialog choiceDlg(
+ NULL, _("Choose the camera to use"), _T("Enable Viacam"), strArray, 
+-(char**)NULL, wxDEFAULT_DIALOG_STYLE | wxOK | wxCANCEL | wxCENTRE);
++(void**)NULL, wxDEFAULT_DIALOG_STYLE | wxOK | wxCANCEL | wxCENTRE);
+ 
+ 			if (choiceDlg.ShowModal ()!= wxID_OK) return NULL;
+ 

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> wolfssl has no active maintainer, plenty of open security issues and we 
> already
> have too many TLS libraries in our releases. Keep it out of testing. I'm going
> to file bugs against the handful of reverse deps.

Sorry, I have been out ill, but please do what you think is right.

Kind regards
Felix

Bug#1023715: python-libtmux: autopkgtest failure on armel, armhf and s390x

[Paul Gevers]

Source: python-libtmux
Version: 0.15.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package python-libtmux, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report. The name of 
the test hints that the test may be too sensitive to slower test 
environments. If the test passes on retries, a test is flaky, which we 
consider RC too.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-libtmux

https://ci.debian.net/data/autopkgtest/testing/armel/p/python-libtmux/27460261/log.gz

=== FAILURES 
===
___ test_function_times_out_no_rise 



def test_function_times_out_no_rise() -> None:
ini = time()
def never_true() -> bool:
return False
retry_until(never_true, 1, raises=False)
end = time()
>   assert abs((end - ini) - 1.0) < 0.01
E   assert 0.01221323013305664 < 0.01
E+  where 0.01221323013305664 = abs(((1666538658.7831485 - 
1666538657.7709353) - 1.0))


tests/test_test.py:54: AssertionError
=== short test summary info 

FAILED tests/test_test.py::test_function_times_out_no_rise - assert 
0.0122132...
= 1 failed, 92 passed, 1 deselected in 18.51s 
==

autopkgtest [10:24:29]: test pytest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023714: Should bison++ be removed?

[Adrian Bunk]

Package: bison++
Version: 1.21.11-5
Severity: important
Control: block -1 by 1023713

bison++ is a fork of a 1990s version of bison, addressing limitations
GNU bison had at that time. Except for vice (see the bug blocking
this bug) it is not used anymore in Debian, and users should use
the bison package (or other Yacc implementations) instead of this old fork.

If you as maintainer agree that bison++ is a candidate for removal
from bookworm, please raise the severity of this bug to release critical.

Bug#1023713: vice: Please use bison or byacc instead of bison++

[Adrian Bunk]

Source: vice
Version: 3.6.1+dfsg-3
Severity: important

vice is the only package in the archive building with bison++.

Please change the build dependency to bison or byacc (or make bison
the first alternative so that it gets installed on the buildds).

Standard bison can regenerate src/monitor/mon_parse.{c,h} and
the resulting build is successful.

Right now bison++ is not even used during the build
(except in the configure.ac check) because the generated
files src/monitor/mon_parse.{c,h} are shipped and not
rebuilt during the package build.

The generated src/monitor/mon_parse.{c,h} shipped in the
upstream tarball were generated with byacc.

Bug#1023712: why3 breaks frama-c (autopkgtest): missing versioned Breaks?

[Paul Gevers]

Source: why3
Control: found -1 why3/1.5.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks

Dear maintainer(s),

With a recent upload of why3 the autopkgtest of frama-c fails in testing 
when that autopkgtest is run with the binary packages of why3 from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
why3   from testing1.5.1-1
frama-cfrom testing20220511-manganese-1.3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The message 
seems serious enough (to my eyes) that you'd want to prevent this on 
partial upgrades and during dist-upgrades. Does why3 (version in 
unstable) really break the version of frama-c in testing? Then adding a 
*versioned* Breaks might be a good idea. Maybe the failure isn't as bad 
as it looks, then please just close this bug report (but be warned, why3 
might migrate then, while the fixed frama-c seems stuck).


Currently this regression is blocking the migration of why3 to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=why3

https://ci.debian.net/data/autopkgtest/testing/amd64/f/frama-c/28047266/log.gz

[kernel] User Error: cannot load plug-in 'frama-c-wp': cannot load module
  Details: implementation mismatch on Why3
[kernel] User Error: Deferred error message was emitted during 
execution. See above messages for more information.

[kernel] Frama-C aborted: invalid user input.
autopkgtest [20:18:19]: test eva



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019423: libreoffice: Need to maximize window manually before libreoffice window opens on plasma-desktop

[Rainer Dorsch]

Am Samstag, 8. Oktober 2022, 01:09:27 CET schrieben Sie:
> Version: 1:7.4.2~rc1-1
> Control: tag 1019423 + upstream
> Control: tag 1019423 + fixed-upstream
> Control: forwarded 1019423
> https://bugs.documentfoundation.org/show_bug.cgi?id=150856
> 
> Hi,
> 
>  Am 8. Oktober 2022 00:24:47 MESZ schrieb Rainer Dorsch :
> >Am Freitag, 7. Oktober 2022, 21:17:34 CEST schrieb Rene Engelhard:
> >> Hi,
> >> 
> >> Am 07.10.22 um 21:00 schrieb Gunter Königsmann:
> >> > Ubuntu 22.10 had the same problem until a few weeks ago.
> >> 
> >> Until which version? This suggests this is fixed in 7.4.2 then?
> >
> >The upstream bug report referenced in https://bugs.debian.org/cgi-bin/
> >bugreport.cgi?bug=1019423
> 
> Ah, missed that mail apparently.
> Thanks for pointing that out.
> 
> >claims that it is fixed in 7.4.2
> >
> >https://bugs.documentfoundation.org/show_bug.cgi?id=150856#c16
> 
> Marking as such then. (In the exact version, the version Tracking will know
> sud is affected untul 7.4.2 final gets uploaded to sid)
> 
> Backports will then get it after 7.4.2 final is in testing as the bpo rules.
> 

I installed the version 7,4,2 from backports today, but unfortunately the 
issue is still present. 

I continued to read in the upstream bugreport and found in

https://bugs.documentfoundation.org/show_bug.cgi?id=151054

that resetting the user profile resolves the issue (at least for some 
Libreoffice 
users).

So far I confirmed that it does not happen in safe mode. I assume that at least 
some Debian users upgrading to bookworm will run into this issue.

I think the users should be notified during the upgrade.

If anybody is interested in defining some experiments to narrow down the issue 
and try to avoid the complete user profile resetting requirement after the 
upgrade to bookworm, please let me know. Otherwise I would just reset my user 
profile and assume that this will work fine for me.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Bernhard Schmidt]

Control: reopen -1 =
Control: fixed -1 1:9.19.6-2

Reopening because we don't have that fix in unstable yet (needs to be 
backported)

Bug#1023711: Missing python_socks

[Yuri D'Elia]

Package: python3-aiohttp-socks
Version: 0.7.1-1
Severity: grave

aiohttp-socks 0.7.1 fails to import:

>>> import aiohttp_socks
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/aiohttp_socks/__init__.py", line 4, in 

from python_socks import (
ModuleNotFoundError: No module named 'python_socks'

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 python3-aiohttp-socks depends on:
ii  python3  3.10.6-1
ii  python3-aiohttp  3.8.3-1
ii  python3-attr 22.1.0-1

python3-aiohttp-socks recommends no packages.

python3-aiohttp-socks suggests no packages.

Bug#1023710: jbigkit: autopkgtest failure: unittests-Makefile: No such file or directory

[Paul Gevers]

Source: jbigkit
Version: 2.1-6
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package jbigkit, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=jbigkit

https://ci.debian.net/data/autopkgtest/testing/amd64/j/jbigkit/27243460/log.gz

make: unittests-Makefile: No such file or directory
make: *** No rule to make target 'unittests-Makefile'.  Stop.
autopkgtest [15:21:30]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023709: pkwalify: autopkgtest regression: t/pkwalify.t Failed: 22

[Paul Gevers]

Source: pkwalify
Version: 1.23-2
Severity: serious
X-Debbugs-CC: jel...@debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pkwalify the autopkgtest of pkwalify fails in 
testing when that autopkgtest is run with the binary packages of 
pkwalify from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
pkwalify   from testing1.23-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=pkwalify

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pkwalify/27088725/log.gz

t/Kwalify.t .. 1..100
ok 1 - use Kwalify;
ok 2 - use Schema::Kwalify;
ok 3 - sequence of str
ok 4 - sequence with default type (str)
ok 5 - Non valid data, int in sequence of str
ok 6
ok 7 - mapping
ok 8 - invalid mapping
ok 9
ok 10
ok 11
ok 12 - sequence of mapping
ok 13
ok 14
ok 15
ok 16
ok 17 - mapping of sequence
ok 18
ok 19
ok 20
ok 21 - Many rules
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33 - unique
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39 - valid data against schema with recursive rules (no endless loop)
ok 40 - valid recursive data against schema with recursive rules (no 
endless loop)

ok 41 - valid data against perl schema
ok 42 - invalid data against perl schema
ok 43 - min-ex length pass
ok 44 - min-ex length fail
ok 45 - max-ex length pass
ok 46 - max-ex length fail
ok 47 - min-ex range pass
ok 48 - min-ex range fail
ok 49 - max-ex range pass
ok 50 - max-ex range fail
ok 51 - max length pass
ok 52 - max length fail
ok 53 - max range pass
ok 54 - max range fail
ok 55 - Passing name/classname/desc
ok 56 - Passing name/class/desc
ok 57 - a ref is not a text
ok 58 - undef is not a text
ok 59 - a str is not a text
ok 60 - undef is not a str
ok 61 - a number is not a str
ok 62 - a non-float
ok 63 - a non-number
ok 64 - a non-bool
ok 65 - validate '0' as bool
ok 66 - validate '1' as bool
ok 67 - validate 'yes' as bool
ok 68 - validate 'no' as bool
ok 69 - validate 'true' as bool
ok 70 - validate 'false' as bool
ok 71 - validate float
ok 72 - validate number
ok 73 - validate time
ok 74 - schema must be hash
ok 75 - unknown type
ok 76 - invalid length spec
ok 77 - invalid enum spec
ok 78 - invalid range spec
ok 79 - unknown key in type
ok 80 - unknown key in range
ok 81 - unknown key in length
ok 82 - expected hash in data
ok 83 - wrong seq in schema
ok 84 - wrong seq in schema
ok 85 - wrong seq in schema
ok 86 - wrong data, no sequence
ok 87 - wrong map in schema
ok 88 - wrong map in schema
ok 89 - wrong data, undefined
ok 90 - wrong data, no mapping
ok 91 - An object of class 'Schema::Kwalify' isa 'Schema::Kwalify'
ok 92 - Simple Schema::Kwalify validation
ok 93 - Simple Schema::Kwalify failure
ok 94 - type any with additional check, successful
ok 95 - type any with additional check, failure
ok 96 - enum with defined value
ok 97 - enum with undefined value
ok 98 - legally undefined pattern
ok 99 - legally undefined pattern
ok 100 - No warnings expected
ok
t/compat.t ... 1..2
# Running under perl version 5.034000 for linux
# Current time local: Fri Oct 14 22:02:12 2022
# Current time GMT:   Fri Oct 14 22:02:12 2022
# Using Test.pm version 1.31
ok 1
ok 2
ok
t/pkwalify.t . 1..31
not ok 1 - There are warnings in -f 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/schema05.yaml 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/document05a.yaml


#   Failed test 'There are warnings in -f 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/schema05.yaml 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/document05a.yaml'

#   at t/pkwalify.t line 119.
#  got: ''
# expected: anything else
not ok 2 - Nothing in STDERR

#   Failed test 'Nothing in STDERR'
#   at t/pkwalify.t line 119.
#  got: 'Can't open perl script 
"/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/../blib/script/pkwalify": 
No such file or directory

# '
# expected: ''
not ok 3 - -f 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/schema05.yaml 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/document05a.yaml


#   Failed test '-f 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/schema05.yaml 
/tmp/autopkgtest-lxc.ns43i5rp/downtmp/autopkgtest_tmp/smokex78hlS/t/testdata/document05a.yaml'

#   at t/pkwalify.t line 119.
#  got: '0'
# expected: '1'
# -f 

Bug#1023708: ITP: ruby-rackup -- A general server command for Rack applications

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro
X-Debbugs-Cc:debian-r...@lists.debian.org

* Package name: ruby-rackup
  Version : 0.2.2
  Upstream Author :Leah Neukirchen    
,
Samuel G. D. Williams    

* URL :https://github.com/rack/rackup/
* License : Expat
  Programming Lang: Ruby
  Description :A general server command for Rack applications

|rackup|  provides a command line interface for running a Rack-compatible 
application.

The rackup command was extracted from ruby-rack in the latest upstream release, 
a.k.a. 3.0.0, and now it is provided as a separated gem.

This package will be maintained under the Ruby team's umbrella.

--
Lucas Kanashiro

Bug#1023707: src:cross-toolchain-base: unsatisfied build dependency in testing: linux-source-5.19

[Paul Gevers]

Source: cross-toolchain-base
Version: 61
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023706: src:cross-toolchain-base-mipsen: unsatisfied build dependency in testing: linux-source-5.19

[Paul Gevers]

Source: cross-toolchain-base-mipsen
Version: 21
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023705: src:metview: fails to migrate to testing for too long: FTBFS on mips64el and s390x

[Paul Gevers]

Source: metview
Version: 5.16.0-2
Severity: serious
Control: close -1 5.17.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1022978

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:metview has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on mips64el and s390x where it built successfully in the past. 
Your package is also stuck behind atlas-ecmwf, which I reported in bug 
#1022978.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=metview



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023704: jackd: Accept pipewire-jack as alternative dependency (also in backports, please)

[Marcel Partap]

Package: jackd
Version: 5+nmu1
Severity: wishlist
X-Debbugs-Cc: mpar...@gmx.net

Hi,
currently, sonic-pi can not be used with pipewire easily because the former
depends on the jackd meta package and successlessly tries to invoke the jack
daemon, when actually pipewire-jack should provide the same interface..


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (510, 'unstable'), (509, 'experimental'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 jackd depends on:
ii  jackd2  1.9.21~dfsg-1

jackd recommends no packages.

jackd suggests no packages.

-- no debconf information

Bug#1023703: qemu build depends on gcc-11-alpha-linux-gnu that should not be in bookworm

[Michael Tokarev]

08.11.2022 23:07, Adrian Bunk пишет:

Source: qemu
Version: 1:7.1+dfsg-2
Severity: important
Control: block 1023690 by -1

qemu build depends on gcc-11-alpha-linux-gnu that should
not be in bookworm.


https://salsa.debian.org/qemu-team/qemu/-/commit/591846e1e5e434c4c9c4c09ae41fa36a40d481a2
https://salsa.debian.org/qemu-team/qemu/-/commit/9fbc91b88a5551abe8494c76cafcfbb36779dc83

/mjt

Bug#1010648: marked as pending in golang-github-pierrec-lz4.v4

[Nicholas D Steeves]

Hi Eric,

Sorry for the delay, I had thought I had sent this draft, but I just saw
that I hadn't.

Eric Evans  writes:

> Do you have a link to this discussion?
>

Hm, it seems the Go team uses a @tracker.d.o email, and I can't find a
team+pkg...@tracker.debian.org archive.  I didn't know there wasn't an
archive for this...my mistake, I had assumed all teams dh-make-lang
helper specified a devel mailing list that was archived...  Since it
turns out that the thread was not actually public, I had to ask for
permission to forward the emails, received permission, and I will PM
them to you since I finally found some free time today.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1023703: qemu build depends on gcc-11-alpha-linux-gnu that should not be in bookworm

[Adrian Bunk]

Source: qemu
Version: 1:7.1+dfsg-2
Severity: important
Control: block 1023690 by -1

qemu build depends on gcc-11-alpha-linux-gnu that should
not be in bookworm.

Bug#1023702: openjfx build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: openjfx
Version: 11.0.11+1-1.1
Severity: important
Control: found -1 11.0.11+0-1.1
Control: block 1023690 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023701: nodejs build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: nodejs
Version: 18.7.0+dfsg-3
Severity: important
Control: block 1023690 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023700: cryptsetup: Option fido2-device unknown

[Peter Wienemann]

Package: cryptsetup
Version: 2:2.5.0-6
Severity: normal

Dear maintainer,

inspired by [0] I am trying to unlock a LUKS volume using a FIDO2 token
on a system running bookworm/testing using systemd 252-2.

The relevant line in /etc/crypttab looks like this:


rootfs  /dev/nvme0n1p3  noneluks,discard,fido2-device=auto


After running

systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p3

and adding the "fido2-device=auto" option in /etc/crypttab, I obtain the
following warning during updating the initramfs image:


cryptsetup: WARNING: rootfs: ignoring unknown option 'fido2-device'


As a result, it comes as no surprise that unlocking the volume using the
FIDO2 token does not work as desired.

Best regards,

Peter

[0] 
https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html

Bug#1023699: build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: gcl
Version: 2.6.12-124
Severity: important
Control: block 1023690 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023698: gcc-xtensa-lx106 build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: gcc-xtensa-lx106
Version: 11
Severity: important
Control: block 1023690 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?

[karogyoker999]

Actually, firefox-esr doesn't even work on real x86_32 CPUs (except
Pentium 4) since years.
It requires SSE2 without the sse2-support package, so basically it is
committing a baseline violation on i386.
Currently, due to some random GCC behavior, it doesn't crash instantly
when I try to open any page. But this can change in any upcoming
versions.

There is a fix, but it is not merged since months:
https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/7

If it was merged, it would close the following bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923785
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961663
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009808
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002600
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019246

Alternatively, epiphany-browser could be used instead of firefox-esr
on i386, because that works without SSE or even without MMX.

Bug#1023697: Keep out of testing

[Moritz Muehlenhoff]

Source: wolfssl
Version: 5.2.0-2
Severity: serious

wolfssl has no active maintainer, plenty of open security issues and we already
have too many TLS libraries in our releases. Keep it out of testing. I'm going
to file bugs against the handful of reverse deps.

Cheers,
Moritz

Bug#782699: debian-boot: IPv6 prefix notation in the installer

[Marc Haber]

On Tue, Nov 08, 2022 at 06:31:54PM +0100, Marc Haber wrote:
> On Thu, Apr 16, 2015 at 02:44:57PM +0200, Jens Link wrote:
> > When using IPv6 addresses in the installer the prefix (netmask) has do be 
> > entered in 
> > hex (e.g. :::::). I think this is highly unusual and I have 
> > never seen
> > this notation before. 
> 
> I agree with that. How high are the chances that this prominent
> installer issue will be looked at or even addressed seven years after it
> was originally filed?

After digging a bit in codesearch, I think that this actually belongs to
the netcfg package. The error message encountered by Jens is still in
debian/netcfg-static.templates, in netcfg/bad_ipaddress, which is
invoked in various places inside static.c.

The line
debconf_set(client, "netcfg/get_netmask", ":::::");
in netcfg_get_netmask strongly suggests that the original author
seriously thinks that this is a correct way to notate an IPv6 prefix
length.

Greetings
Marc

Bug#1023696: libfreeimage-dev: libfreeimage-dev should be Multi-arch:same

[Dima Kogan]

Package: libfreeimage-dev
Version: 3.18.0+ds2-8
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This package can be marked Multi-arch:same since all the files
either are straight copies from the upstream repo (FreeImage.h) or live
in arch-specific directories:

  $ dpkg -L libfreeimage-dev

  /.
  /usr
  /usr/include
  /usr/include/FreeImage.h
  /usr/lib
  /usr/lib/x86_64-linux-gnu
  /usr/lib/x86_64-linux-gnu/libfreeimage.a
  /usr/lib/x86_64-linux-gnu/libfreeimageplus.a
  /usr/share
  /usr/share/doc
  /usr/share/doc/libfreeimage-dev
  /usr/share/doc/libfreeimage-dev/changelog.Debian.gz
  /usr/share/doc/libfreeimage-dev/changelog.gz
  /usr/share/doc/libfreeimage-dev/copyright
  /usr/lib/x86_64-linux-gnu/libfreeimage.so

Adding Multi-arch:same to that package will make it more convenient to
use.

Thanks!

Bug#1023695: gcc-12 build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: gcc-12
Version: 12.2.0-9
Severity: important
Control: block 1023690 by -1

gcc-12 build depends on gcc-11 that should not be in bookworm.

Bug#1023694: cross-toolchain-base-mipsen build depends on gcc-11 that should not be in bookworm

[Adrian Bunk]

Source: cross-toolchain-base-mipsen
Version: 21
Severity: important
Control: block 1023690 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023680: ITP: django-jsonstore -- Expose JSONField data as a virtual django model fields

[Edward Betts]

I'm retracting this ITP.

Edward Betts  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: django-jsonstore
>   Version : 0.5.0
>   Upstream Author : UPSTREAM
> * URL : https://github.com/viewflow/jsonstore
> * License : GPL-3
>   Programming Lang: Python
>   Description : Expose JSONField data as a virtual django model fields
> 
>   Use ModelForm and ModelAdmin as usual. Perform simple queries. Migrate to
>   real table columns when needed without code change.
>   .
>   Suitable to store dumb business data, quick prototypes without DB
>   migrations, and to replace multi-table inheritance joins.
>  
> I plan to maintain this package as part of the Python team.
> 
> This is a dependancy of AlekSIS [1]
> 
>1: https://edugit.org/AlekSIS/official/AlekSIS-Core
> 
> 

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Sean Whitton]

Hello Vincent,

Are you able to test the patch?  Let me know if you need help getting an
installable .deb.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023693: libstb: CVE-2021-37789

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for libstb.

CVE-2021-37789[0]:
| stb_image.h 2.27 has a heap-based buffer over in stbi__jpeg_load,
| leading to Information Disclosure or Denial of Service.

https://github.com/nothings/stb/issues/1178

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-37789
https://www.cve.org/CVERecord?id=CVE-2021-37789

Please adjust the affected versions in the BTS as needed.

Bug#1023691: pycuda: autopkgtest failure

[Andreas Beckmann]

Control: tag -1 wontfix

On 08/11/2022 20.19, Sebastian Ramacher wrote:

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pycuda/28053345/log.gz


pycuda 2022.1~dfsg-5 needs to migrate together with
nvidia-cuda-toolkit 11.6.2-2 - that combination should have working tests


Andreas

Bug#1023654: liburing 2.3 breaks binary compatibility

[Michael Tokarev]

08.11.2022 17:50, Michael Tokarev wrote:

08.11.2022 17:11, Guillem Jover wrote:
[..]

If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.


Well. I already deleted my test chroot. I can't say for 100% now that it
breaks the other way around. I'll have to double-check.  It took me quite
quite some time especially due to other urgent things I'm doing today.
I can check if 2.2-compiled samba works with 2.3-uring but a bit later
today.  Even if it works, it is not exactly conclusive, since samba only
uses certain code paths.  But ofc if it doesn't work, it *is* conclusive :)


Ok, I double-verified this: samba compiled against older liburing works
with liburing 2.3 after upgrading liburing2 package.  So it must be just
me being too tired when debugging all this.  So it appears to be backwards-
compatible (non-conclusive! ;)), just needs new lib for newly compiled
programs.

It's a rare case really, because of the rather heavy usage of inline
functions for access, - so parts of the library are actually compiled
into the program, and now you've more pieces to keep in sync.

It's an interesting case really.

Thank you!

/mjt

Bug#1023692: gcc-arm-linux-gnueabihf: Compiling anything with fails: error: '_Float128' is not supported on this target

[Dima Kogan]

Package: gcc-arm-linux-gnueabihf
Version: 4:12.2.0-1
Severity: important
X-Debbugs-Cc: none, Dima Kogan 

Hi. I have a "tst.c" which has just one line:

  #include 

Cross-compiling it doesn't work:

  $ arm-linux-gnueabihf-gcc-12 -c -o tst.o tst.c

  In file included from tst.c:1:
  /usr/include/bits/mathcalls-helper-functions.h:20:40: error: '_Float128' is 
not supported on this target
 20 | __MATHDECL_ALIAS (int, __fpclassify,, (_Mdouble_ __value), fpclassify)
|^
  /usr/include/bits/mathcalls-helper-functions.h:24:37: error: '_Float128' is 
not supported on this target
 24 | __MATHDECL_ALIAS (int, __signbit,, (_Mdouble_ __value), signbit)
| ^
  /usr/include/bits/mathcalls-helper-functions.h:29:35: error: '_Float128' is 
not supported on this target
 29 | __MATHDECL_ALIAS (int, __isinf,, (_Mdouble_ __value), isinf)
|   ^
  /usr/include/bits/mathcalls-helper-functions.h:33:36: error: '_Float128' is 
not supported on this target
 33 | __MATHDECL_ALIAS (int, __finite,, (_Mdouble_ __value), finite)
|^
  /usr/include/bits/mathcalls-helper-functions.h:37:35: error: '_Float128' is 
not supported on this target
 37 | __MATHDECL_ALIAS (int, __isnan,, (_Mdouble_ __value), isnan)
|   ^
  /usr/include/bits/mathcalls-helper-functions.h:41:37: error: '_Float128' is 
not supported on this target
 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), 
iseqsig);
| ^
  /usr/include/bits/mathcalls-helper-functions.h:41:52: error: '_Float128' is 
not supported on this target
 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), 
iseqsig);
|^
  /usr/include/bits/mathcalls-helper-functions.h:44:41: error: '_Float128' is 
not supported on this target
 44 | __MATHDECL_ALIAS (int, __issignaling,, (_Mdouble_ __value), 
issignaling)
| ^

This should work.

Thanks


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-arm-linux-gnueabihf depends on:
ii  cpp-arm-linux-gnueabihf 4:12.2.0-1
ii  gcc-12-arm-linux-gnueabihf  12.2.0-3cross2

Versions of packages gcc-arm-linux-gnueabihf recommends:
pn  libc6-dev-armhf-cross | libc-dev-armhf-cross  

Versions of packages gcc-arm-linux-gnueabihf suggests:
ii  autoconf 2.71-2
ii  automake 1:1.16.5-1.3
ii  bison2:3.8.2+dfsg-1
ii  flex 2.6.4-8
ii  gcc-doc  5:12.1.0-1
pn  gdb-arm-linux-gnueabihf  
ii  libtool  2.4.7-4
ii  make 4.3-4.1
ii  manpages-dev 5.13-1

-- no debconf information

Bug#1023691: pycuda: autopkgtest failure

[Sebastian Ramacher]

Source: pycuda
Version: 2022.1~dfsg-5
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pycuda/28053345/log.gz

emoving autopkgtest-satdep (0) ...
autopkgtest [05:23:44]: test compile-stl-headers_g++-11: 
debian/tests/compile-stl-headers g++-11
autopkgtest [05:23:44]: test compile-stl-headers_g++-11: 
[---
algorithm
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not 
expanded with ‘...’:
  435 | function(_Functor&& __f)
  | 
^ 
/usr/include/c++/11/bits/std_function.h:435:145: note: ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not 
expanded with ‘...’:
  530 | operator=(_Functor&& __f)
  | 
 ^ 
/usr/include/c++/11/bits/std_function.h:530:146: note: ‘_ArgTypes’
FAIL: algorithm
any
array
atomic
barrier
bit
bitset
cassert
ccomplex
cctype
cerrno
cfenv
cfloat
charconv
chrono
cinttypes
ciso646
climits
clocale
cmath
codecvt
compare
complex
complex.h
concepts
condition_variable
coroutine (may fail)
/usr/include/c++/11/coroutine:294:23: error: default member initializer for 
‘std::__n4861::coroutine_handle::__frame::__r’
 required before the end of its enclosing class
  294 |   static __frame _S_fr;
  |   ^
/usr/include/c++/11/coroutine:289:26: note: defined here
  289 | void (*__r)() = __dummy_resume_destroy;
  |  ^~   
/usr/include/c++/11/coroutine:294:23: error: default member initializer for 
‘std::__n4861::coroutine_handle::__frame::__d’
 required before the end of its enclosing class
  294 |   static __frame _S_fr;
  |   ^
/usr/include/c++/11/coroutine:290:26: note: defined here
  290 | void (*__d)() = __dummy_resume_destroy;
  |  ^~   
/usr/include/c++/11/coroutine:304:60: error: redefinition of 
‘std::__n4861::coroutine_handle::__frame 
std::__n4861::coroutine_handle::_S_fr’
  304 |   noop_coroutine_handle::_S_fr{};
  |^

/usr/include/c++/11/coroutine:294:23: note: 
‘std::__n4861::coroutine_handle::__frame 
std::__n4861::coroutine_handle::_S_fr’ 
previously declared here
  294 |   static __frame _S_fr;
  |   ^
Ignored failure: coroutine
csetjmp
csignal
cstdalign
cstdarg
cstdbool
cstddef
cstdint
cstdio
cstdlib
cstring
ctgmath
ctime
cuchar
cwchar
cwctype
cxxabi.h
deque
exception
execution
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not 
expanded with ‘...’:
  435 | function(_Functor&& __f)
  | 
^ 
/usr/include/c++/11/bits/std_function.h:435:145: note: ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not 
expanded with ‘...’:
  530 | operator=(_Functor&& __f)
  | 
 ^ 
/usr/include/c++/11/bits/std_function.h:530:146: note: ‘_ArgTypes’
FAIL: execution
fenv.h
filesystem
forward_list
fstream
functional
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not 
expanded with ‘...’:
  435 | function(_Functor&& __f)
  | 
^ 
/usr/include/c++/11/bits/std_function.h:435:145: note: ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not 
expanded with ‘...’:
  530 | operator=(_Functor&& __f)
  | 
 ^ 
/usr/include/c++/11/bits/std_function.h:530:146: note: ‘_ArgTypes’
FAIL: functional
future
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not 
expanded with ‘...’:
  435 | function(_Functor&& __f)
  | 
^ 
/usr/include/c++/11/bits/std_function.h:435:145: note: ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not 
expanded with ‘...’:
  530 | operator=(_Functor&& __f)
  |   

Bug#1023690: gcc-11 should not be shipped in bookworm

[Adrian Bunk]

Package: gcc-11
Version: 11.3.0-8
Severity: important

gcc-11 should not be shipped in bookworm.

Bug#1023689: minilla: FTBFS: test failures with git 1:2.38.1-1 : transport 'file' not allowed

[Niko Tyni]

Source: minilla
Version: 3.1.18-1
Severity: serious
Tags: ftbfs

This package fails to build from source on current sid.

   Test Summary Report
   ---
   t/filegatherer.t   (Wstat: 65280 (exited 255) Tests: 
2 Failed: 1)
 Failed test:  2
 Non-zero exit status: 255
 Parse errors: No plan found in TAP output
   t/filegatherer/submodules-recursive.t  (Wstat: 65280 (exited 255) Tests: 
2 Failed: 1)
 Failed test:  2
 Non-zero exit status: 255
 Parse errors: No plan found in TAP output
   t/project/in_submodule.t   (Wstat: 65280 (exited 255) Tests: 
1 Failed: 1)
 Failed test:  1
 Non-zero exit status: 255
 Parse errors: No plan found in TAP output
   Files=62, Tests=170, 105 wallclock secs ( 0.42 usr  0.08 sys + 44.82 cusr 
11.18 csys = 56.50 CPU)
   Result: FAIL
 
The build log is rather hard to read as there are intentional test
failures sprayed all over, but I think the main thing that is new is
messages like this:

  Cloning into '/tmp/uGVjCBrSr3/libfoo'...
  fatal: transport 'file' not allowed
  fatal: clone of 'file:///tmp/hhqN4NFWJc' into submodule path 
'/tmp/uGVjCBrSr3/libfoo' failed

I've tested that building in bookworm succeeds, but injecting
git_1%3a2.38.1-1_amd64.deb (and git-man_1%3a2.38.1-1_all.deb) makes it
fail. I assume this is about

  https://security-tracker.debian.org/tracker/CVE-2022-39253

which was fixed in git 1:2.38.1-1.
-- 
Niko Tyni   nt...@debian.org

Bug#1023688: improper permissions on fcgiwrap systemd socket lead to privilege escalation to www-data under default config

[Anton Luka Šijanec]

Package: fcgiwrap
Version: 1.1.0-12
Severity: critical
Tags: patch, security

On a default installation of Debian 11 (bullseye) with other releases probably 
also affected, systemd socket file /lib/systemd/system/fcgiwrap.socket from 
package fcgiwrap contains no Mode= configuration parameter, making systemd pick 
the default 0666. The socket is therefore world accessible and any user on the 
system may, when package fcgiwrap is installed, elevate privileges and execute 
code as www-data user by communicating with the socket via fastcgi protocol. 
www-data is specified as User= and Group= in 
/lib/systemd/system/fcgiwrap.service, also supplied by package fcgiwrap.

Proof of concept terminal recording: http://upload.sijanec.eu/f.mp4

Solution: add SocketMode=0660, SocketUser=www-data, Group=www-data to 
/lib/systemd/system/fcgiwrap.socket --- this would, however, break existing 
configurations that rely on /run/fcgiwrap.socket being world connectable.

Is this intended behaviour? Doesn't it break user's expectations, as suddenly 
everyone can influence httpd (nginx slaves also run under www-data, for 
example)?

- BEGIN PATCH -
Author: Anton Luka Šijanec 
Description: Modify default user/group and listening mode of socket
Forwarded: no

--- a/systemd/fcgiwrap.socket
+++ b/systemd/fcgiwrap.socketfixed
@@ -3,6 +3,9 @@ Description=fcgiwrap Socket

 [Socket]
 ListenStream=/run/fcgiwrap.sock
+Mode=0660
+SocketUser=www-data
+SockerGroup=www-data

 [Install]
 WantedBy=sockets.target
- END PATCH -

Attachments:
root@host:~# ls -lah /run/fcgiwrap.socket
srw-rw-rw- 1 root root 0 Nov  8 19:42 /run/fcgiwrap.socket

=> /lib/systemd/system/fcgiwrap.socket
[Unit]
Description=fcgiwrap Socket

[Socket]
ListenStream=/run/fcgiwrap.socket

[Install]
WantedBy=sockets.target



=> /lib/systemd/system/fcgiwrap.service
[Unit]
Description=Simple CGI Server
After=nss-user-lookup.target
Requires=fcgiwrap.socket

[Service]
Environment=DAEMON_OPTS=-f
EnvironmentFile=-/etc/default/fcgiwrap
ExecStart=/usr/sbin/fcgiwrap ${DAEMON_OPTS}
User=www-data
Group=www-data

[Install]
Also=fcgiwrap.socket

-- 
Anton Luka Šijanec 
F4C3E3A4DFB7254397A9F993E76135F49802CD14
http://splet.sijanec.eu/pgp-key.txt

Bug#1023680: ITP: django-jsonstore -- Expose JSONField data as a virtual django model fields

[Dominik George]

Hi,

> * License : GPL-3

Please mind that this library is licensed under AGPL.

Therefore, we deem it unfit for release in a free software product, and will 
replace it in AlekSIS.

-nik

Bug#1023687: simde build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: simde
Version: 0.7.2-6
Severity: serious
Control: block 1023666 by -1
Control: close -1 0.7.3~0git20210929204341.90523a2-1

This is already fixed in experimental.

Bug#1023686: readline: Inaccurate copyright file

[Bastian Germann]

Source: readline
Version: 8.2-1.1
Severity: serious
Tags: patch

The debian/copyright file is missing some information (copyright statements and 
at least one license).
I have put together and attached machine-readable versions of the two copyright 
files with added info.

You should repack to get rid of the embedded rlwrap copy and the non-source doc 
files (#1023683),
which would simplify maintaining the copyright files.

The licenses of the embedded fonts are not included in the attached copyright 
file.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment:
This is Debian GNU/Linux's prepackaged version of the FSF's GNU
Readline library.
 .
This package was put together by Matthias Klose ,
derived from the bash package by Guy Maor .
Upstream-Name: Readline
Upstream-Contact: 
Chet Ramey 
Jeff Solomon  (examples/excallback.c)
Harold Levy  (examples/rl-fgets.c)
Source: http://ftp.gnu.org/gnu/readline/

Files: *
Copyright:
Copyright (C) 1987-2022 Free Software Foundation, Inc.
License: GPL-3+
Readline is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 .
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
 .
You should have received a copy of the GNU General Public License
along with Readline.  If not, see .
Comment:
 On Debian systems, the complete text of the GNU General Public License
 version 3 can be found in `/usr/share/common-licenses/GPL-3'.

Files: examples/readlinebuf.h
   examples/rl-fgets.c
   examples/rlfe/*
   examples/rlwrap-*.tar.gz
Copyright:
Copyright (C) 1987-2022 Free Software Foundation, Inc.
Copyright (c) 2001 by Dimitris Vyzovitis [v...@media.mit.edu]
Copyright (C) 1999 Jeff Solomon (examples/excallback.c)
Copyright (C) 2003-2004 Harold Levy (examples/rl-fgets.c)
Copyright (c) 1993-2002 Juergen Weigert 
(jnwei...@immd4.informatik.uni-erlangen.de)
Copyright (c) 1993-2002 Michael Schroeder 
(mlsch...@immd4.informatik.uni-erlangen.de)
Copyright (C) 1987 Oliver Laumann (examples/rlfe)
Copyright (C) 2004, 1999 Per Bothner
Copyright (C) 2000-2007 Hans Lub
Copyright (C) 1999-2001 Geoff Wing
Copyright (C) Damian Ivereigh 2000
License: GPL-2+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
 .
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
 .
You should have received a copy of the GNU General Public License
along with this program (see the file COPYING); if not, write to the
Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
Comment:
 On Debian systems, the complete text of the GNU General Public License
 version 2 can be found in `/usr/share/common-licenses/GPL-2'.
 .
 The rlwrap example is also available in its own Debian package.
 The code copyrighted by Damian Ivereigh is licensed under LGPL-2.1+.

Files: doc/*.texi doc/*.info doc/*.html doc/*.[03] doc/*.dvi doc/*.pdf doc/*.ps
Copyright:
Copyright (C) 1988-2015 Free Software Foundation, Inc.
License: GFDL-NIV-1.3+
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and
no Back-Cover Texts.  A copy of the license is included in the
section entitled "GNU Free Documentation License".
Comment:
 On Debian systems, the complete text of the GNU Free Documentation
 License can be found in `/usr/share/common-licenses/GFDL'.

Files: support/wcwidth.c
Copyright: Markus Kuhn
License: ISC-no-attribution
 Permission to use, copy, modify, and distribute this software
 for any purpose and without fee is hereby granted. The author
 disclaims all warranties with regard to this software.

Files: debian/*
Copyright:
Copyright (C) 1999-2009 Matthias Klose 
License: GPL-3
 The Debian packaging is licensed under the GPL version 3, 
 see `/usr/share/common-licenses/GPL-3'.
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment:
This is Debian GNU/Linux's prepackaged version of the rlfe program.
This package was put together 

Bug#1023659: gscan2pdf: can't use unpaper as it gives errors

[Jeff]

reassign 1023659 unpaper 7.0.0-0.1
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023685: libdancer-perl: FTBFS: 10_error_dumper_without_clone.t failure

[Niko Tyni]

Source: libdancer-perl
Version: 1.3513+dfsg-1
Severity: serious
Tags: ftbfs sid bookworm
Control: affects -1 libhttp-message-perl

This package fails to build from source on current sid.

   t/12_response/10_error_dumper.t . 
   1..5
   ok 1 - An object of class 'Dancer::Error' isa 'Dancer::Error'
   ok 2 - Data was censored in the output
   ok 3 - Original data was not overwritten
   ok 4 - Censoring of complex data structures works fine
   ok 5 - recursive censored hash
   ok
   Devel::Hide hides Clone.pm
   Can't locate Clone.pm in @INC (hidden)
   BEGIN failed--compilation aborted at /usr/share/perl5/HTTP/Headers.pm line 8.
   Compilation failed in require at 
/<>/blib/lib/Dancer/Response.pm line 14.
   BEGIN failed--compilation aborted at 
/<>/blib/lib/Dancer/Response.pm line 14.
   Compilation failed in require at 
/<>/blib/lib/Dancer/SharedData.pm line 8.
   BEGIN failed--compilation aborted at 
/<>/blib/lib/Dancer/SharedData.pm line 8.
   Compilation failed in require at /<>/blib/lib/Dancer/Request.pm 
line 13.
   BEGIN failed--compilation aborted at 
/<>/blib/lib/Dancer/Request.pm line 13.
   Compilation failed in require at /<>/blib/lib/Dancer/Route.pm 
line 13.
   BEGIN failed--compilation aborted at 
/<>/blib/lib/Dancer/Route.pm line 13.
   Compilation failed in require at 
/<>/blib/lib/Dancer/Route/Registry.pm line 8.
   BEGIN failed--compilation aborted at 
/<>/blib/lib/Dancer/Route/Registry.pm line 8.
   Compilation failed in require at /<>/blib/lib/Dancer/App.pm 
line 12.
   BEGIN failed--compilation aborted at /<>/blib/lib/Dancer/App.pm 
line 12.
   Compilation failed in require at /<>/blib/lib/Dancer.pm line 10.
   BEGIN failed--compilation aborted at /<>/blib/lib/Dancer.pm 
line 10.
   Compilation failed in require at 
t/12_response/10_error_dumper_without_clone.t line 17.
   BEGIN failed--compilation aborted at 
t/12_response/10_error_dumper_without_clone.t line 17.
   t/12_response/10_error_dumper_without_clone.t ... 
   Dubious, test returned 255 (wstat 65280, 0xff00)
   No subtests run 
 
I assume this broke with libhttp-message-perl 6.44-1, which is currently
blocked from migrating to testing due to a similar autopkgtest regression.

>From the upstream HTTP-Message changelog:

  Changes for version 6.44 - 2022-10-26
  
  - Made the Clone module a hard requirement, so we don't have to provide
a fallback function for HTTP::Headers::clone(). We require at least
Clone 0.46, as that release now supports Perl back to 5.8.1, just like
us. (GH#184) (Neil Bowers)
  - Import clone from Clone rather than inheriting (GH#189) (Graham Knop)

Looking at the above, my guess is that the Dancer test which "hides
Clone.pm" needs to be updated, as it uses HTTP::Headers which now
requires Clone.
-- 
Niko Tyni   nt...@debian.org

Bug#1023684: odb build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: odb
Version: 2.4.0-15
Severity: serious
Control: block 1023666 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023682: gringo build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: gringo
Version: 5.4.1-3
Severity: serious
Tags: bookworm sid
Control: block 1023666 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023683: readline: Non-source doc files with embedded fonts

[Bastian Germann]

Source: readline
Version: 8.2-1.1
Severity: important

The doc directory has several files which are non-source.
Some of them (dvi, ps, pdf) have embedded fonts whose licenses are not 
documented in d/copyright.

Please exclude the non-source documentation files, at least those with embedded 
fonts.

Bug#1023681: ghdl build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: ghdl
Version: 1.0.0+dfsg-8
Severity: serious
Control: block 1023666 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023680: ITP: django-jsonstore -- Expose JSONField data as a virtual django model fields

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: django-jsonstore
  Version : 0.5.0
  Upstream Author : UPSTREAM
* URL : https://github.com/viewflow/jsonstore
* License : GPL-3
  Programming Lang: Python
  Description : Expose JSONField data as a virtual django model fields

  Use ModelForm and ModelAdmin as usual. Perform simple queries. Migrate to
  real table columns when needed without code change.
  .
  Suitable to store dumb business data, quick prototypes without DB
  migrations, and to replace multi-table inheritance joins.
 
I plan to maintain this package as part of the Python team.

This is a dependancy of AlekSIS [1]

   1: https://edugit.org/AlekSIS/official/AlekSIS-Core

Bug#967010: apache2: Did not reporoduce

[Shai Berger]

Hi,

On Tue, 08 Nov 2022 18:05:23 +0100
"Yadd"  wrote:

> 
> Hi, it's a Buster-only bug, not a Bullseye's one
> 

It was flagged by apt-listbugs on my bookworm/sid system.

Bug#1023679: gcc-mingw-w64 build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: gcc-mingw-w64
Version: 24.4
Severity: serious
Control: block 1023666 by -1

Please switch to gcc-12 that is default in bookworm.

Bug#1023678: clasp build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: clasp
Version: 3.3.5-4.1
Severity: serious
Control: block 1023666 by -1

Please use the default gcc if possible,
or switch to gcc-12 that is default in bookworm.

Bug#1023677: bart-cuda build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: bart-cuda
Version: 0.8.00-1
Severity: serious
Control: block 1023666 by -1

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016625#65
gcc-11 might be a temporary workaround (but it might be only gcc-12 that
will be in bookworm).

Bug#1023676: readline: Drop inaccurate README.source

[Bastian Germann]

Source: readline
Version: 8.2-1.1
Severity: minor

Please drop the outdated README.source which still mentions dpatch.

Bug#1023674: astra-toolbox build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Source: astra-toolbox
Version: 2.1.0-1
Severity: serious
Control: block 1023666 by -1

#1003037 might contain some background information on how to fix this.

Bug#1023675: astra-toolbox: debian/rules does export NVCCFLAGS="-ccbin clang-9"

[Adrian Bunk]

Source: astra-toolbox
Version: 2.1.0-1
Severity: important

https://sources.debian.org/src/astra-toolbox/2.1.0-1/debian/rules/#L26

Whatever this was supposed to do, astra-toolbox does not longer
build depend on clang-9.

Bug#1023659: gscan2pdf: can't use unpaper as it gives errors

[Jeff]

On 08/11/2022 15:06, Francesco Potortì wrote:

If I enable the "Postprocessing / Clean up images" option with default values, 
I get errors from unpaper.  Here they are:

[image2 @ 0x564ee7da3540] Encoder did not produce proper pts, making some up.
[image2 @ 0x564ee7da3540] The specified filename 
'/tmp/gscan2pdf-EBri/SGOfFcr2Nn.pnm' does not contain an image sequence pattern 
or a pattern is invalid.
[image2 @ 0x564ee7da3540] Use a pattern such as %03d for an image sequence or 
use the -update option (with -frames:v 1 if needed) to write a single image.

The file mentioned in the second of the three error messages does not exist.


I think that these are warnings, not errors, as I get output from 
unpaper despite them.


Because of errors/warnings like this, the message window that displays 
them gives you the possibility to hide them in the future. This works 
for the first and third messages, but not the second (because the 
filename changes every time).


I could take a look at the logic that parses the messages and see if I 
improve it.


However, I'm not sure there is any point, as I see this bug report:

https://github.com/unpaper/unpaper/issues/113

which is fixed by this commit:

https://github.com/unpaper/unpaper/commit/a2a88fe837fd6770ac94f08b2eb841f0dc9d2430

So I am tempted to reassign this to unpaper.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Pavel Odintsov]

Hello!

I think I have one more question.

For most of the platforms we support libbpf 1.0.1 works fine but I noticed
issues with Debian 11 and Ubuntu 20 about enum declarations:

In file included from
/tmp/fastnetmon.build.dir.i2Ak87Hs7Y/fastnetmon/src/xdp_plugin/xdp_collector.cpp:14:
/opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/bpf.h:396:6:
error: use of enum 'bpf_stats_type' without previous declaration
  396 | enum bpf_stats_type; /* defined in up-to-date linux/bpf.h */
  |  ^~
/opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/bpf.h:397:38:
error: use of enum 'bpf_stats_type' without previous declaration
  397 | LIBBPF_API int bpf_enable_stats(enum bpf_stats_type type);
  |  ^~
In file included from
/tmp/fastnetmon.build.dir.i2Ak87Hs7Y/fastnetmon/src/xdp_plugin/xdp_collector.cpp:15:
/opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/libbpf.h:70:54:
error: use of enum 'bpf_link_type' without previous declaration
   70 | LIBBPF_API const char *libbpf_bpf_link_type_str(enum bpf_link_type
t);
  |  ^~~~

Did you experience similar errors previously by any chance?

Thank you!


On Tue, 8 Nov 2022 at 16:55, Pavel Odintsov 
wrote:

> Hello!
>
> Added copy to all.
>
> I think I fixed it with these commits:
> https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4
> and
> https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c
>
> I've used
> https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/
> and
> https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c
> as examples as this code was my reference during implementation.
>
> Would be great if you could review it a second time.
>
> Thank you!
>
> On Mon, 7 Nov 2022 at 11:59, Sudip Mukherjee 
> wrote:
>
>> Hi Pavel,
>>
>> On Mon, Nov 7, 2022 at 11:53 AM Pavel Odintsov 
>> wrote:
>> >
>> > Hello!
>> >
>> > Thank you for reaching me.
>> >
>> > Sure, I'll be happy to check.
>> >
>> > May I kindly ask what exactly changed to trigger these errors? I
>> believe it was successfully built previously.
>>
>> Its the update of libbpf to v1.0.1 which removed some of the deprecated
>> API.
>>
>>
>> --
>> Regards
>> Sudip
>>
>
>
> --
> Sincerely yours, Pavel Odintsov
>


-- 
Sincerely yours, Pavel Odintsov

Bug#1023590: RFS: monitoring-plugins-check-logfiles/4.1.0.1-1 [ITP] -- Nagios plugin check_logfiles

[Hilmar Preuße]

Am 08.11.2022 um 11:05 teilte Alexander Reichle-Schmehl mit:

Hi,


We are using that plugin at the company, so thanks for packaging!

I'm willing to sponsor and will try to take a closer look at it in the
evening.


Good. Thanks!


But just a first question:  Mentors service says, that you didn't added
a watch file to it.  Is there a specific reason for it?


I just wasn't aware that it is quite easy to implement. File has been
added, new package is on mentors.

Hilmar
--
sigfault

Bug#782699: debian-boot: IPv6 prefix notation in the installer

[Marc Haber]

On Thu, Apr 16, 2015 at 02:44:57PM +0200, Jens Link wrote:
> When using IPv6 addresses in the installer the prefix (netmask) has do be 
> entered in 
> hex (e.g. :::::). I think this is highly unusual and I have 
> never seen
> this notation before. 

I agree with that. How high are the chances that this prominent
installer issue will be looked at or even addressed seven years after it
was originally filed?

Greetings
Marc

Bug#1023673: erlang-base: erlang runtime crashes on armel (segmentation fault)

[Igor Rudchenko]

Package: erlang-base
Version: 1:23.2.6+dfsg-1
Severity: important

Dear Maintainer,

After upgrading Debian from 10 to 11 on armel hardware (Qnap TS-410 and
TS-421) I found that erlang runtime no longer works.

First I tried to found the last working debian version from snapshots -
it turned out to be 1:23.0.3+dfsg-1. Erlang runtime started crashing
from 1:23.0.4+dfsg-1 version and looks like all binary builds after this
one is broken on armel.

Debian switched from gcc-9 to gcc-10 for 1:23.0.4+dfsg-1 build.

Attempts to build from source with gcc-10 or gcc-12 failed for all
versions that I tried - 23.0.3, 23.0.4, 25.1.2, but all builds were
successful with gcc-9. Also the builds were successful with newer
versions of GCC and -O1 level of optimization.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 5.10.0-19-marvell
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 erlang-base depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u5
ii  libsystemd0  247.3-7+deb11u1
ii  libtinfo66.2+20201114-2
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages erlang-base recommends:
pn  erlang-crypto
pn  erlang-syntax-tools  
pn  libsctp1 

Versions of packages erlang-base suggests:
pn  erlang   
pn  erlang-doc   
pn  erlang-manpages  
pn  erlang-tools 

-- debconf-show failed

Bug#1023672: Please switch to Sailfish's presage

[Guido Günther]

Package: presage
Version: 0.9.1-2.3
Severity: wishlist

The upstream repo at sourceforge didn't see any changes recently however
the SailifshOS folks made some changes and maintain it at:

   https://github.com/sailfish-keyboard/presage

Hence I'd propse to switch to that as new upstream.
Cheers,
 -- Guido


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

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

Versions of packages presage depends on:
ii  libc6  2.35-3
ii  libgcc-s1  12.2.0-3
ii  libncurses66.3+20220423-2
ii  libpresage1v5  0.9.1-2.4
ii  libsqlite3-0   3.39.4-1
ii  libstdc++6 12.2.0-3
ii  libtinfo6  6.3+20220423-2

presage recommends no packages.

presage suggests no packages.

-- no debconf information

Bug#1023386: pacman-package-manager: Please backport to bullseye-backports

[Dylan Aïssi]

Hello Ben,

Le jeu. 3 nov. 2022 à 18:54, Ben Westover  a écrit :
>
> Thanks for the link. I have uploaded my backport to Mentors [1] for your
> sponsorship, and it's also available in the debian/bullseye branch of my
> package repo [2]. Can you provide DM access after it passes NEW?
>

Thanks for preparing the package. I tried to build it with gbp buildpackage
in a clean bullseye environment but it failed. It seems some build-deps are
missing from the control file. At least python3-distutils needs to be added but
then it fails to build with another error. Can you take a look?

Thanks,
Dylan

Bug#1023671: afl++ silently drops gcc_plugin support when gcc-X-plugin-dev build dependency not on the default gcc

[Adrian Bunk]

Package: afl++
Version: 4.02c-1
Severity: serious
Control: block 1023666 by -1

https://buildd.debian.org/status/fetch.php?pkg=aflplusplus=amd64=4.02c-1=1662644587=0

...
[*] Checking for gcc plugin development header files...
[-] Oops, can't find gcc header files. Be sure to install 'gcc-X-plugin-dev'.
make[3]: *** [GNUmakefile.gcc_plugin:125: test_deps] Error 1
...


This should be an error, which would then result in someone updating
the build dependency when the default gcc changes.

Bug#967010: apache2: Did not reporoduce

[Yadd]

Le Mardi, Novembre 08, 2022 16:01 CET, Shai Berger  a écrit:
> Package: apache2
> Followup-For: Bug #967010
>
> Dear Maintainer,
>
> I just installed Apache2 and did not encounter the problem
> as reported in this bug.
>
> It is an old bug, and for some reason full of spam.
>
> Please close and/or delete it.
>
> Thanks.

Hi, it's a Buster-only bug, not a Bullseye's one

Bug#1023670: O: jamulus -- real-time collaborative music session client and server

[Thorsten Glaser]

Package: wnpp
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de, d...@debian.org
Control: affects -1 src:jamulus

I intend to orphan the jamulus package. I am reducing my involvement
in post-bullseye Debian.

The package description is:
 Jamulus, a low-latency audio client and server, enables musicians to
 perform real-time “jam” sessions over the internet. It is available
 across multiple platforms, so participants of any field can communicate
 without specialist setup requirements. This is not restricted to music,
 of course; other use (perhaps conferencing?) is also possible.
 .
 One participant starts Jamulus in server mode, ideally on a dedicated
 server (virtual) machine; all participants start the (graphical) client
 which transmits audio to the server, receiving back a mixed stream. Use
 of a metronome is recommended.

Bug#1023669: osmo-msc: FTBFS in sid (libsmpp34 failure)

[Gianfranco Costamagna]

Source: libsmpp34
Version: 1.14.1-2

affects: osmo-msc

Hello, as can be seen in tests.reproducible-builds.org, the build is now 
failing in sid

I'm attaching the build log, and a link to the r-b one 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/osmo-msc_1.9.0+dfsg1-2.rbuild.log.gz



The change in libsmpp34 in 
https://salsa.debian.org/debian-mobcom-team/libsmpp34/-/commit/b8d786585d00e9c980fff98a71fc76e8571ecb5f
broke the build, due to Version field not being defined anymore

checking pkg-config is at least version 0.20... yes
checking for sqlite3... yes
checking for libosmocore >= 1.7.0... yes
checking for libosmovty >= 1.7.0... yes
checking for libosmoctrl >= 1.7.0... yes
checking for libosmogsm >= 1.7.0... yes
checking for libosmoabis >= 1.3.0... yes
checking for libosmo-netif >= 1.2.0... yes
checking for libosmo-sigtran >= 1.6.0... yes
checking for libosmo-sccp >= 1.6.0... yes
checking for libosmo-mgcp-client >= 1.10.0... yes
checking for libosmo-gsup-client >= 1.5.0... yes
checking for timegm... yes
checking for library containing sctp_send... -lsctp
checking for libsmpp34 >= 1.14.0... no
configure: error: Package requirements (libsmpp34 >= 1.14.0) were not met:

Requested 'libsmpp34 >= 1.14.0' but version of libsmpp34 is

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBSMPP34_CFLAGS
and LIBSMPP34_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
tail -v -n \+0 config.log
==> config.log <==
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

The reason behind this failure has to be found in smpp34 moving from 1.14.0-2 
to 1.14.1-2

and missing include of /usr/share/dpkg/pkg-info.mk
made the build fail.
Also, DEB_VERSION variable should probably be DEB_VERSION_UPSTREAM


--- libsmpp34-1.14.1/debian/changelog   2022-10-26 22:03:24.0 +0200
+++ libsmpp34-1.14.1/debian/changelog   2022-11-08 17:54:03.0 +0100
@@ -1,3 +1,9 @@
+libsmpp34 (1.14.1-2.1) unstable; urgency=medium
+
+  * Fix build of osmo-msc, Closes: #-1.
+
+ -- Gianfranco Costamagna   Tue, 08 Nov 2022 
17:54:03 +0100
+
 libsmpp34 (1.14.1-2) unstable; urgency=medium
 
   * upload to unstable

diff -Nru libsmpp34-1.14.1/debian/rules libsmpp34-1.14.1/debian/rules
--- libsmpp34-1.14.1/debian/rules   2022-10-26 22:03:24.0 +0200
+++ libsmpp34-1.14.1/debian/rules   2022-11-08 17:54:01.0 +0100
@@ -2,6 +2,7 @@
 
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/pkg-info.mk

 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

@@ -13,7 +14,7 @@
 #PKG  = $(word 2,$(shell dpkg-parsechangelog -l$(PKD)/changelog | grep 
^Source))
 PKG  = $(DEB_SOURCE)
 #VER ?= $(shell dpkg-parsechangelog -l$(PKD)/changelog | perl -ne 'print $$1 
if m{^Version:\s+(?:\d+:)?(\d.*)(?:\-\d+.*)};')
-VER ?= $(DEB_VERSION)
+VER ?= $(DEB_VERSION_UPSTREAM)
 
 
 %:


G.
D: cmdline: build --distribution sid --buildresult 
/home/locutus/pbuilder/sid_result --basetgz /home/locutus/pbuilder/sid-base.tgz 
--logfile /home/locutus/pbuilder/sid_result/osmo-msc_1.9.0+dfsg1-2_amd64.build 
--mirror http://deb.debian.org/debian --debootstrapopts 
--keyring=/usr/share/keyrings/debian-archive-keyring.gpg --aptcache 
/home/locutus/pbuilder/aptcache/debian --components main contrib non-free 
../osmo-msc_1.9.0+dfsg1-2.dsc
W: cgroups are not available on the host, not using them.
I: pbuilder: network access will be disabled during build
I: Current time: Tue Nov  8 17:30:39 CET 2022
I: pbuilder-time-stamp: 1667925039
I: Building the build Environment
I: extracting base tarball [/home/locutus/pbuilder/sid-base.tgz]
I: copying local configuration
W: No local /etc/mailname to copy, relying on 
/tmp/build/778058/etc/mailname to be correct
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [../osmo-msc_1.9.0+dfsg1-2.dsc]
I: copying [../osmo-msc_1.9.0+dfsg1.orig.tar.xz]
I: copying [../osmo-msc_1.9.0+dfsg1-2.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.eYn2IOTG/trustedkeys.kbx': 
General error
gpgv: Signature made Thu Oct 13 22:41:18 2022 UTC
gpgv:using RSA key 6201FBFFDBBDE07822EABB9696FCAC0D387B5847
gpgv:issuer "deb...@alteholz.de"
gpgv: Can't check 

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Pavel Odintsov]

Hello!

Added copy to all.

I think I fixed it with these commits:
https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4
and
https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c

I've used
https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/ and
https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c
as examples as this code was my reference during implementation.

Would be great if you could review it a second time.

Thank you!

On Mon, 7 Nov 2022 at 11:59, Sudip Mukherjee 
wrote:

> Hi Pavel,
>
> On Mon, Nov 7, 2022 at 11:53 AM Pavel Odintsov 
> wrote:
> >
> > Hello!
> >
> > Thank you for reaching me.
> >
> > Sure, I'll be happy to check.
> >
> > May I kindly ask what exactly changed to trigger these errors? I believe
> it was successfully built previously.
>
> Its the update of libbpf to v1.0.1 which removed some of the deprecated
> API.
>
>
> --
> Regards
> Sudip
>


-- 
Sincerely yours, Pavel Odintsov

Bug#1023668: O: antimicro -- GUI for mapping keyboard keys and mouse controls to a gamepad

[Thorsten Glaser]

Package: wnpp
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Control: affects -1 src:antimicro

I intend to orphan the antimicro package. I am reducing my involvement
in post-bullseye Debian.

The package description is:
 AntiMicroX is a graphical program used to map keyboard keys and mouse
 controls to a gamepad. This program is useful for playing PC games
 using a gamepad that do not have any form of built-in gamepad support.
 However, you can use this program to control any desktop application
 (while running an X11 environment) with a gamepad.
 .
 https://github.com/AntiMicroX/antimicrox-profiles is a repository for
 pre-made AntiMicroX profiles, providing convenience controller layouts
 suitable for playing a game without having to map everything yourself.
 .
 Use evtest, or perhaps jstest from the joystick package, if you
 encounter problems detecting a controller, axes or buttons.

Bug#1023204: (no subject)

[Andre Naujoks]

Just FYI. This is "fixed" in the current samba-libs version.

Am 5. November 2022 19:05:19 MEZ schrieb Andre Naujoks :
>I am also affected by this. I worked around this by installing the samba-libs 
>package from testing and pinning the version to 2:4.16*
>
>This workaround will go away though, when 2:4.17 migrates to testing as well.
>
>-- 
>To unsubscribe, send mail to 1023204-unsubscr...@bugs.debian.org.

Bug#1023667: xen-tools: xt-guess-suite-and-mirror cannot handle deb http://ports.ubuntu.com/ubuntu-ports

[Nick Rosbrook]

Source: xen-tools
Version: 4.9.1-1
Severity: normal

Dear Maintainer,

The xt-guess-suite-and-mirror tools is not able to handle sources.list
entries like this:

  deb http://ports.ubuntu.com/ubuntu-ports kinetic main restricted

This comes from a default installation of Ubuntu Kinetic on arm64
(raspberry pi). Specifically, the tool is not able to handle the
ubuntu-ports portion of the entry.

This is what the tool reports:

  pi@ubuntu:~$ xt-guess-suite-and-mirror --mirror
  Couldn't find a useful entry in the sources.list files of the Dom0. Tried:
/etc/apt/sources.list
  pi@ubuntu:~$ xt-guess-suite-and-mirror --suite
  Couldn't find a useful entry in the sources.list files of the Dom0. Tried:
/etc/apt/sources.list

I would expect it to correctly report 'http://ports.ubuntu.com/ubuntu-ports'
and 'kinetic' instead. 

Thanks,
Nick

Bug#1023666: gcc-10 should not be shipped in bookworm

[Adrian Bunk]

Package: gcc-10
Version: 10.4.0-5
Severity: serious

gcc-10 should not be shipped in bookworm.