Bug#1061728: fio: add build support for loongarch64

[zhangdandan]

Source: fio
Version: 3.36-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Maybe we need to add build support for loongarch64.
I hope to give you feedback in advance.
Please consider the patch I have attached.

I would like to remind you that the compilation dependency of fio is not 
yet satisfied. Depends on the librbd-dev and libnbd-dev packages when 
compiling fio.
About the dependencies packages, such as librbd-dev and libnbd-dev, we 
have also submitted bug separately to BTS to add loongarch64 support.
The fio source package was compiled successfully on my local loong64 
rootfs environment, for example:


```
make[1]: Leaving directory '/home/fio/fio-3.36'
   dh_auto_test
   make -j32 test "TESTSUITEFLAGS=-j32 --verbose" VERBOSE=1
make[1]: Entering directory '/home/fio/fio-3.36'
./fio --minimal --thread --exitall_on_error --runtime=1s --name=nulltest 
--ioengine=null --rw=randrw --iodepth=2 --norandommap 
--random_generator=tausworthe64 --size=16T --name=verifyfstest 
--filename=fiotestfile.tmp --unlink=1 --rw=write --verify=crc32c 
--verify_state_save=0 --size=16K

3;fio-3.36;nulltest;0;0;2045220;2045220;511305;1000;0;83;0.104989;0.11;0;49;0.541493;0.089076;1.00%=0;5.00%=0;10.00%=0;20.00%=0;30.00%=0;40.00%=0;50.00%=0;60.00%=0;70.00%=0;80.00%=0;90.00%=0;95.00%=0;99.00%=0;99.50%=0;99.90%=0;99.95%=0;99.99%=2;0%=0;0%=0;0%=0;0;84;0.646483;0.150796;2046475;2046475;100.00%;2046475.00;0.00;2042196;2042196;510549;1000;0;3;0.107921;0.010351;0;14;0.542254;0.044376;1.00%=0;5.00%=0;10.00%=0;20.00%=0;30.00%=0;40.00%=0;50.00%=0;60.00%=0;70.00%=0;80.00%=0;90.00%=0;95.00%=0;99.00%=0;99.50%=0;99.90%=0;99.95%=0;99.99%=2;0%=0;0%=0;0%=0;0;14;0.650175;0.045519;2043635;2043635;100.00%;2043635.00;0.00;99.70%;0.00%;2;0;0;100.0%;0.0%;0.0%;0.0%;0.0%;0.0%;0.0%;99.99%;0.01%;0.01%;0.01%;0.01%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%
..
dpkg-deb: building package 'fio-dbgsym' in 
'../fio-dbgsym_3.36-1_loong64.deb'.
dpkg-deb: building package 'fio-examples' in 
'../fio-examples_3.36-1_all.deb'.

dpkg-deb: building package 'fio' in '../fio_3.36-1_loong64.deb'.
```

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru fio-3.36/debian/control fio-3.36/debian/control
--- fio-3.36/debian/control 2023-10-23 09:47:12.0 +
+++ fio-3.36/debian/control 2023-10-23 09:47:12.0 +
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Martin Steigerwald 
-Build-Depends: debhelper-compat (= 13), libaio-dev [linux-any], zlib1g-dev, 
librdmacm-dev [linux-any], libibverbs-dev [linux-any], librbd-dev [linux-amd64 
linux-arm64 linux-ppc64el linux-ppc64 linux-riscv64 linux-mips64el linux-s390x 
linux-ia64 linux-sparc64], libcairo2-dev, libnuma-dev [linux-any], flex, bison, 
sphinx, python3-sphinx, libglusterfs-dev [amd64 arm64 ppc64el ppc64 riscv64 
mips64el s390x ia64 sparc64], libpmem-dev [amd64 arm64 ppc64el], libnbd-dev
+Build-Depends: debhelper-compat (= 13), libaio-dev [linux-any], zlib1g-dev, 
librdmacm-dev [linux-any], libibverbs-dev [linux-any], librbd-dev [linux-amd64 
linux-arm64 linux-loong64 linux-ppc64el linux-ppc64 linux-riscv64 
linux-mips64el linux-s390x linux-ia64 linux-sparc64], libcairo2-dev, 
libnuma-dev [linux-any], flex, bison, sphinx, python3-sphinx, libglusterfs-dev 
[amd64 arm64 loong64 ppc64el ppc64 riscv64 mips64el s390x ia64 sparc64], 
libpmem-dev [amd64 arm64 ppc64el], libnbd-dev
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://github.com/axboe/fio

Bug#1061564: [INTL:sv] Swedish strings for postfix debconf

[Martin Bagge / brother]

On 2024-01-27 16:48, Scott Kitterman wrote:

On Friday, January 26, 2024 10:29:55 AM EST Anders Jonsson wrote:

Hi Martin,
did some small grammar fixes in this one.

E.g "det korrekta värde" -> "det korrekta värdet"; "den här inställning"
-> "den här inställningen"


Martin,

Would you please reply to the bug if you agree with this or not?  I would
prefer not to apply anything until there is agreement.


Sure!

This makes it more correct indeed. Also the spacing further down in the 
file is correct.


--
brother

Bug#1061725: libvirt-daemon: Deleting external snapshot for non-running system VM fails with Permission Denied

[Martin Pitt]

Control: retitle -1 libvirt-daemon: Deleting external snapshot for non-running 
system VM fails with AppArmor

when stracing libvirt, this is what happens:

6557  openat(AT_FDCWD, "/var/lib/libvirt/images/test2.qcow2", O_RDWR|O_CLOEXEC) 
= -1 EACCES (Permission denied)
6557  sendmsg(13, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="{\"id\": 
\"libvirt-443\", \"error\": {\"class\": \"GenericError\", \"desc\
": \"Could not open '/var/lib/libvirt/images/test2.qcow2': Permission 
denied\"}}\r\n", iov_len=142}], msg_iovlen=1, msg_controllen=0, msg_flags
=0}, 0 

and the most recent geteuid() call responded with "0". So it actually *does*
smell like an AppArmor issue, even though it's weird that it would work for a
running VM then. Running `aa-teardown` before the creation of the VM doesn't
work, nor does "aa-complain libvirtd". But after `dpkg -P apparmor; reboot` it
does work.

So AppArmor breaks this without even logging about it, i.e. some "deny" rule. I
don't know how to make AA log deny rules -- the profile has tons of them
(albeit to /proc, /dev/, etc.), and it's further complicated by the dynamic
profile creation through virt-aa-helper.

As this works in current Ubuntu, it's perhaps worth looking at
https://patches.ubuntu.com/libv/libvirt/libvirt_9.6.0-1ubuntu2.patch
The most plausible one may be 
debian/patches/ubuntu-aa/0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch
but that requires rebuilding libvirt. But also, that patch is from 2017, and
it's still broken in Ubuntu 22.04.

Bug#1034600: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

[Per Lundberg]

Thanks for incorporating this fix into openjdk-11, appreciated Matthias. AFAIK, 
this should be applicable to openjdk-17-jdk as-is as well. I looked in the 
changelog at https://packages.debian.org/sid/openjdk-17-jdk and couldn't see it 
mentioned there (searched for JDK-8307977 and 1034600).

Do you want me to create a new bug for this or just reopen+reassign this bug to 
src:openjdk-17? (feel free to just reassign it yourself if you want to)

Best regards,
Per


From: Debian Bug Tracking System 
Sent: Friday, January 26, 2024 22:45
To: Per Lundberg 
Subject: Bug#1034600 closed by Debian FTP Masters 
 (reply to Matthias Klose ) 
(Bug#1034600: fixed in openjdk-11 11.0.22+7-2)

This is an automatic notification regarding your Bug report
which was filed against the src:openjdk-11 package:

#1034600: tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or 
greater

It has been closed by Debian FTP Masters  
(reply to Matthias Klose ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Matthias Klose ) by
replying to this email.


--
1034600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034600
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1061729: libclips: identified for time_t transition but no ABI in shlibs

[Steve Langasek]

Package: libclips
Version: 6.30-4.1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Javier,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
libclips as an affected package, on the basis that the headers could not be
compiled and analyzed out of the box using abi-compliance-checker[2], so we
have to assume it's affected.

However, libclips's shlibs file declares a dependency on a library package
name that contains no ABI information:

$ cat DEBIAN/shlibs
libclips 6 libclips (>=6.21-1)
$

It is therefore not obvious that we should rename the package to
'libclipst64' as part of this transition.

Looking at the archive, there is a package that depend on this library,
clips.  Despite being built from the same source package, it does not have a
strict versioned dependency on libclips but instead uses the shlibs.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading libclips without also upgrading
clips) will result in ABI skew and may result in broken behavior.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/libclips-dev/base/log.txt


signature.asc
Description: PGP signature

Bug#1060795: Bug #1060795

[Brian Tarricone]

Can confirm that the patch in the comment at 
https://github.com/bluez/bluez/issues/686#issuecomment-1858902231 fixes the 
issue for me.

Bug#1061725: Info received (Bug#1061725: libvirt-daemon: Deleting external snapshot for non-running system VM fails with Permission Denied)

[Martin Pitt]

I can't make head or tail of this. aa-complain still enforces deny
rules, there is no (discoverable) way to log deny rules, and

  grep -r deny /etc/apparmor.d | grep virt | grep -v /sys | grep -v /dev

doesn't show anything which would apply to /var/lib/libvirt/.

`aa-disable 
/etc/apparmor.d/libvirt/libvirt-a5aa3a67-6967-43a5-9d61-b0b380bd14e6` also
doesn't work because it references a non-existing
libvirt/libvirt-a5aa3a67-6967-43a5-9d61-b0b380bd14e6.files.

The only thing that works is

  aa-disable libvirtd
  systemctl restart libvirtd

(That requires apparmor-utils)

After that, the snapshot-delete command works.

I don't know what else I could try here to debug this properly, so a hint from
someone AppArmor-savvy would be much appreciated.

Bug#1061728: fio: add build support for loongarch64

[Martin Steigerwald]

Hi Dandan.

Thanks for your in-advance notice.

Am Montag, dem 29.01.2024 um 15:57 +0800 schrieb zhangdandan:
> Maybe we need to add build support for loongarch64.
> I hope to give you feedback in advance.
> Please consider the patch I have attached.
>
> I would like to remind you that the compilation dependency of fio is
> not yet satisfied. Depends on the librbd-dev and libnbd-dev packages
> when compiling fio.

So about timing: Does it make sense to include your patch in the next
upload already or do you prefer me to wait until further notice?

I intend to wait for next fio release until uploading again.

Ciao,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Jonas Hasselberg
 •
Chris Hudson
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Johannes Schauer Marin Rodrigues]

Hi,

On 2024-01-29 00:07, Francesco Poli wrote:

I was under the impression that the qcow2 format was the recommended
one for QEMU/KVM virtual machine images. At least, qemu-img(1)
describes it as "the most versatile format"...

Anyway, if you think that the raw format is a better choice for
autopkgtest and sbuild VM images, I take your word for it.


as I said in my other mail, I'm not the expert on the topic, so I asked 
some experts. :)


In the other mail I already paraphrased what f_g said. I now also got 
feedback from mjt (Michael Tokarev) our QEMU maintainer in Debian:


09:10 < mjt> for me, snapshots in qcow2 isn't of much use (I usually do 
it the other way, by stacking another qcow2 on

 top of the main image)
09:12 < jochensp> mjt: afair stacking only works if the base image is 
already qcow2, or?
09:12 < mjt> speaking of qcow2 vs raw, both has their own good and bad 
sides, mostly minor, and the preference is more
 about taste than actual technical differences.  People tend 
to forget about sparseness of a raw image,
 becoming surprizing the drivee usage increases dramatically 
after a copy

09:13 < mjt> jochensp: no, stacking works on top of any image format
09:14 < mjt> ..on the other hand, trim support is more difficult on 
qcow2
09:14 < mjt> myself, I choose raw for regular work and qcow2 when I have 
to transfer the image somewhere
09:15 < mjt> it's quite easy to mount a qcow2 image on the host too, but 
this needs extra layer (I usually use

 qemu-nbd for this)
09:17 < mjt> for direct manipulation, when you have libext2fs and the 
tools, raw is the only way to go


With that said, I think mmdebstrap-autopkgtest-build-qemu should keep 
using raw images.


Thanks!

cheers, josch

Bug#1061730: openjfx: add loongarch64 support

[Zhang Na]

Source: openjfx
Version: 11.0.11+1-3.1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
  I have a patch and a suggestion!
  Firstly, I submitted a loongarch64's patch for openjfx-11, but it does not 
support webkit as the minimum version of LoongArch's g++ is 13;
  Secondly, I suggest upgrading to the latest version of openjfx, which already 
supports LoongArch and also supports g++13, looking forward to your reply. Of 
course, I also saw the same question(#1023702 and #1041527), but there was no 
response, but I still look forward to it.
  
  Thanks!



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From fc418a426205deb8e198f51a374bcfc125f96111 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 29 Jan 2024 08:37:58 +
Subject: [PATCH] Add LoongArch support

---
 debian/control | 2 +-
 debian/gradle.properties.loong64   | 4 
 debian/rules   | 4 
 .../gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h | 2 +-
 modules/javafx.web/src/main/native/CMakeLists.txt  | 2 ++
 .../src/main/native/Source/JavaScriptCore/CMakeLists.txt   | 7 +++
 .../ThirdParty/icu/source/i18n/double-conversion-utils.h   | 2 +-
 .../javafx.web/src/main/native/Source/WTF/wtf/PageBlock.h  | 2 +-
 .../src/main/native/Source/WTF/wtf/PlatformCPU.h   | 6 ++
 .../javafx.web/src/main/native/Source/WTF/wtf/dtoa/utils.h | 2 +-
 10 files changed, 28 insertions(+), 5 deletions(-)
 create mode 100644 debian/gradle.properties.loong64

diff --git a/debian/control b/debian/control
index d6bff1a3..aff82e6a 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: antlr4,
default-jdk,
default-jdk-doc,
flex,
-   g++-11,
+   g++-11 [!loong64],
gperf,
gradle (>= 4.4),
gradle-debian-helper (>= 2.0),
diff --git a/debian/gradle.properties.loong64 b/debian/gradle.properties.loong64
new file mode 100644
index ..47cc7b48
--- /dev/null
+++ b/debian/gradle.properties.loong64
@@ -0,0 +1,4 @@
+COMPILE_WEBKIT = false
+COMPILE_MEDIA = true
+GRADLE_VERSION_CHECK = false
+CONF = Release
diff --git a/debian/rules b/debian/rules
index 63f7f36a..4e4aafc0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,11 @@ export NUMBER_OF_PROCESSORS ?= $(shell nproc)
dh $@ --buildsystem=gradle --no-parallel --with maven-repo-helper
 
 override_dh_auto_configure-arch:
+ifneq (,$(filter $(DEB_HOST_ARCH), loong64))
+   cp debian/gradle.properties.loong64 gradle.properties
+else
cp debian/gradle.properties .
+endif
 
 override_dh_auto_configure-indep:
echo "GRADLE_VERSION_CHECK = false" >> gradle.properties
diff --git 
a/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
 
b/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
index c889459e..dbc9bcda 100644
--- 
a/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
+++ 
b/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstconfig.h
@@ -107,7 +107,7 @@
  */
 #if defined(__alpha__) || defined(__arc__) || defined(__arm__) || 
defined(__aarch64__) || defined(__bfin) || defined(__hppa__) || 
defined(__nios2__) || defined(__MICROBLAZE__) || defined(__mips__) || 
defined(__or1k__) || defined(__sh__) || defined(__SH4__) || defined(__sparc__) 
|| defined(__sparc) || defined(__ia64__) || defined(_M_ALPHA) || 
defined(_M_ARM) || defined(_M_IA64) || defined(__xtensa__) || defined(__e2k__)
 #  define GST_HAVE_UNALIGNED_ACCESS 0
-#elif defined(__i386__) || defined(__i386) || defined(__amd64__) || 
defined(__amd64) || defined(__x86_64__) || defined(__ppc__) || 
defined(__ppc64__) || defined(__powerpc__) || defined(__powerpc64__) || 
defined(__m68k__) || defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) 
|| defined(__s390__) || defined(__s390x__) || defined(__zarch__)
+#elif defined(__i386__) || defined(__i386) || defined(__amd64__) || 
defined(__amd64) || defined(__x86_64__) || defined(__ppc__) || 
defined(__ppc64__) || defined(__powerpc__) || defined(__powerpc64__) || 
defined(__m68k__) || defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) 
|| defined(__s390__) || defined(__s390x__) || defined(__zarch__) || 
defined(__loongarch__)
 #  define GST_HAVE_UNALIGNED_ACCESS 1
 #else
 #  error "Could not detect architecture; don't know whether it supports 
unaligned access! Please file a bug."
d

Bug#1061728: fio: add build support for loongarch64

[zhangdandan]

Hi,
    I'm very happy to receive your timely reply. Nice to meet you.
在 2024/1/29 下午5:08, Martin Steigerwald 写道:

Hi Dandan.

Thanks for your in-advance notice.
Am Montag, dem 29.01.2024 um 15:57 +0800 schrieb zhangdandan:
> I would like to remind you that the compilation dependency of fio is
> not yet satisfied. Depends on the librbd-dev and libnbd-dev packages
> when compiling fio.

So about timing: Does it make sense to include your patch in the next
upload already or do you prefer me to wait until further notice?
I will also actively pay attention to whether fio's dependency packages 
are satisfied.

About timing, I believe your solution will be more appropriate.

I intend to wait for next fio release until uploading again.


I agree with your plan, thank you.

Regards,
Dandan

Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”

[Laurent Bigonville]

Package: fwupd
Version: 1.9.12-1
Severity: serious

Hello,

It seems that fwupd is not starting anymore on my machine.

In the logs I can see:

jan 29 10:40:28 eriador systemd[1]: Starting fwupd.service - Firmware 
update daemon...
jan 29 10:40:28 eriador fwupd[13042]: Failed to load daemon: failed to 
load engine: Failed to load config: Key file does not have group “redfish”
jan 29 10:40:28 eriador systemd[1]: fwupd.service: Main process exited, 
code=exited, status=1/FAILURE
jan 29 10:40:28 eriador systemd[1]: fwupd.service: Failed with result 
'exit-code'.
jan 29 10:40:28 eriador systemd[1]: Failed to start fwupd.service - 
Firmware update daemon.


Kind regards,

Laurent Bigonville

Bug#1060988: marked as done (mathcomp-analysis: FTBFS: make[3]: *** [Makefile.coq:838: classical/mathcomp_extra.vo] Error 1)

[julien . puydt]

Hi,

Le lundi 29 janvier 2024 à 09:39 +, Debian Bug Tracking System a
écrit :
> Your message dated Mon, 29 Jan 2024 09:35:04 +
> with message-id 
> and subject line Bug#1060988: fixed in mathcomp-analysis 1.0.0-1
> has caused the Debian Bug report #1060988,
> regarding mathcomp-analysis: FTBFS: make[3]: *** [Makefile.coq:838:
> classical/mathcomp_extra.vo] Error 1
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)

I had a transition planned, and as the new mathcomp-analysis wasn't out
yet when I requested it, it wasn't part of its ben script... I'll
upload manually a -2 when time will come.

Cheers,

J.Puydt

Bug#1061732: aspcud: depends on RC buggy gringo

[Graham Inggs]

Source: aspcud
Version: 1:1.9.6-2
Severity: serious
Tags: sid trixie

Hi Maintainer

aspcud has a dependency on gringo which has been RC buggy [1] since
October 2023.

I'm filing this bug because aspcud is considered a "key package" [2]
due to a dependency in apt-cudf, and as such, does not receive
notifications of RC bugs in its dependencies.

Regards
Graham


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054688
[2] https://release.debian.org/key-packages.html

Bug#1061733: RFS: dds-ktx/0.0~git20230626,c3ca8fe-1 -- Header-only library for parsing KTX textures

[David James]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: davidjamescastor...@proton.me

From: David James 
To: sub...@bugs.debian.org
Subject: RFS: dds-ktx/0.0~git20230626.c3ca8fe-1 [ITP] -- Header-only library 
for parsing KTX textures

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dds-ktx":

 * Package name : dds-ktx
   Version  : 0.0~git20230626.c3ca8fe-1
   Upstream contact : sep...@pm.me
 * URL  : https://github.com/septag/dds-ktx
 * License  : BSD-2-clause
 * Vcs  : https://salsa.debian.org/Castor216/dds-ktx
   Section  : libs

The source builds the following binary packages:

  dds-ktx-header - Header-only library for parsing KTX textures

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

  https://mentors.debian.net/package/dds-ktx/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dds-ktx/dds-ktx_0.0~git20230626.c3ca8fe-1.dsc

Changes for the initial release:

 dds-ktx (0.0~git20230626.c3ca8fe-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1060208)

Notes:
This is one of the two remaining depedencies for the Citra Nintendo 3DS
emulator.

Regards,
-- 
  David James

Bug#1061734: aptitude: in TUI, incorrect "will be automatically removed because of dependency errors" message

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-5+b1
Severity: normal

When I choose to upgrade swig from the TUI, I get the incorrect message


swig4.0 (remove, 4.1.0-0.3) will be automatically removed because of dependency
errors:


with nothing else.

With more details:

I currently have

i   swig   4.1.0-0.34.2.0-1

Over this line, I type '+', so that I get:

aptitude 0.8.13 @ cventinDisk: -184 kB   DL: 1429 kB
[...]
iu  swig +5509 kB  4.1.0-0.34.2.0-1

Now, I type 'g', and I get:

--\ Packages to be upgraded (1) 
iu  swig +5509 kB  4.1.0-0.34.2.0-1 
--\ Packages being deleted due to unsatisfied dependencies (1)
idA swig4.0  -5693 kB  4.1.0-0.34.1.0-0.3   
--\ Packages being held back (15)
[...]

Over the swig line, I get:


swig (upgrade, 4.1.0-0.3 -> 4.2.0-1) will be upgraded from version 4.1.0-0.3 to
version 4.2.0-1.


Over the swig4.0 line, I get:


swig4.0 (remove, 4.1.0-0.3) will be automatically removed because of dependency
errors:


with nothing else. Without any error message, this doesn't make sense.

Then, when I type ':' over the swig4.0 line, this message changes to:


swig4.0 (remove, 4.1.0-0.3) was installed automatically; it is being removed
because all of the packages which depend upon it are being removed:

  * swig (upgrade, 4.1.0-0.3 -> 4.2.0-1) depends on swig4.0 (>= 4.1.0-0.3)
(provided by swig4.0:i386 4.1.0-0.3)


Now this is almost correct. I don't understand the ":i386". This is
a configured foreign architecture on this machine, but this package
is not installed:

cventin:~> dpkg -l | grep swig
ii  swig   4.1.0-0.3
all  Generate scripting interfaces to C/C++ code
ii  swig4.04.1.0-0.3
amd64Generate scripting interfaces to C/C++ code

Note that with the currently installed swig package:

Package: swig
Version: 4.1.0-0.3
[...]
Architecture: all
Replaces: swig2.0
Depends: swig4.0 (>= 4.1.0-0.3)
Suggests: swig-doc, swig-examples
Conflicts: swig2.0

and with the new version:

Package: swig
Version: 4.2.0-1
[...]
Architecture: amd64
Replaces: swig4.0
Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libpcre2-8-0 (>= 10.22), 
libstdc++6 (>= 13.1)
Suggests: swig-doc, swig-examples
Conflicts: swig4.0

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.4
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20240113
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffeeaddb000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7fa687a8f000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fa68720)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fa687a55000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fa6875cb000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fa687a4c000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fa6874c9000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa68708a000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7fa6874af000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fa686e0)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa686a0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa686d21000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa687482000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa68681e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa687a43000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fa68747d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa68745e000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fa68744b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7

Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[Simon McVittie]

Control: reassign -1 libpixman-1-0 0.42.2-1
Control: affects -1 + librsvg
Control: tags -1 + upstream
Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/78

On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> After a lot of debugging, by upgrading librsvg and its dependency packages one
> after another like libcairo, libpixman and libpango, we found out that while
> upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> version 0.42.2-1, the test suites failed in the librsvg.
> 
> I built these packages ( i.e. cairo, pixman & pango) manually from their
> respective sources by resolving all the version dependencies and ran the
> librsvg tests to make sure that the test suites failed while upgrading pixman
> package from 0.40.0-1 to version 0.42.2-1..
> 
> By doing git-bisect on pixman package commits, I figured out the below
> mentioned commit which has changes w.r.t. big-endian architectures, introduced
> the regression.. But I checked the main line repo of pixman and I see that the
> test suites are passing. I will check further on this and post my updates...!
> 
> commit b4a105d77232a87304b7b621e2f99e699a8eebd3
> Author: Jocelyn Falempe <[1]jfale...@redhat.com>
> Date:   Wed Jun 29 10:55:43 2022 +0200
> 
> Fix inverted colors on big endian system
> 
> bits_image_fetch_separable_convolution_affine() didn't take care
> of big endian system
> 
> Signed-off-by: Jocelyn Falempe <[2]jfale...@redhat.com>
> 
>  There is one open issues in pixman regarding to this commit changes which
> effecting the big-endian systems.
> 
> [3]https://gitlab.freedesktop.org/pixman/pixman/-/issues/78
> 
> [4]https://gitlab.freedesktop.org/pixman/pixman/-/issues/72

Thanks, reassigning the Debian bug from librsvg to pixman.

smcv

Bug#1060273: [Pkg-pascal-devel] Bug#1060273: Bug#1060273: lazarus-3.0: Lazarus fails to compile itself

[Abou Al Montacir]

I've check more deeply this issue and could find that the IDE build make file
mixes old and newly compiled units which leads to a compiler deadlock in finding
the right ppu for dialogs unit.

I was able to patch ide/Makefile to resolve this locally, but I'm not this is
the right way to do, so I need more time to investigate this issue and confirm
with upstream that this is the right fix.

diff --git a/ide/Makefile.fpc b/ide/Makefile.fpc
index 9275b2b2..af53d875 100644
--- a/ide/Makefile.fpc
+++ b/ide/Makefile.fpc
@@ -179,21 +179,21 @@ idepackages:
 #-
 # compile IDE without extra packages
 ide: $(COMPILER_UNITTARGETDIR) revisioninc
-$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) 
OPT='$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT)'
+$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(if $(patsubst 
@%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT))'
 
 #-
 # compile IDE with some extra packages
 bigide: $(COMPILER_UNITTARGETDIR) revisioninc
 -$(DEL) $(COMPILER_UNITTARGETDIR)/pkgmanager$(PPUEXT)
-$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(OPT) 
$(BIG_IDE_OPTIONS)'
+$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(if $(patsubst 
@%,@,${OPT}),${OPT},$(OPT) $(BIG_IDE_OPTIONS))'
 
 #-
 starter: $(COMPILER_UNITTARGETDIR)
-$(MAKE) --assume-new=startlazarus.lpr startlazarus$(EXEEXT) 
OPT='$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT)'
+$(MAKE) --assume-new=startlazarus.lpr startlazarus$(EXEEXT) OPT='$(if 
$(patsubst @%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT))'
 
 #-
 lazbuilder: $(COMPILER_UNITTARGETDIR)
-$(MAKE) --assume-new=lazbuild.lpr lazbuild$(EXEEXT) 
OPT='$(DEFAULT_IDE_OPTIONS) $(OPT)'
+$(MAKE) --assume-new=lazbuild.lpr lazbuild$(EXEEXT) OPT='$(if 
$(patsubst @%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(OPT))'
 
 #-
 all: ide starter lazbuilder

-- 
Cheers,
Abou Al Montacir

-- 
Cheers,
Abou Al Montacir


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

Bug#1061735: bdepstrap ftbfs with Python 3.12 as the default

[Matthias Klose]

Package: src:bdebstrap
Version: 0.6.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
Test: Run pylint on Python source code. ... Running following command:
/usr/bin/python3.12 -m pylint 
--rcfile=/<>/tests/pylint.conf -- 
/<>/bdebstrap tests /<>/setup.py

FAIL
test_flake8 (tests.test_shellcheck.ShellcheckTestCase.test_flake8)
Test: Run shellcheck on Shell source code. ... Running following command:
shellcheck /<>/hooks/disable-units 
/<>/hooks/enable-units

ok

==
FAIL: test_pylint (tests.test_pylint.PylintTestCase.test_pylint)
Test: Run pylint on Python source code.
--
Traceback (most recent call last):
  File "/<>/tests/test_pylint.py", line 74, in test_pylint
self.fail("\n".join(msgs))
AssertionError: pylint found issues:
* Module setup
/<>/setup.py:26:0: E0401: Unable to import 'distutils.log' 
(import-error)
/<>/setup.py:27:0: E0401: Unable to import 
'distutils.command.build' (import-error)
/<>/setup.py:28:0: E0401: Unable to import 
'distutils.command.clean' (import-error)
/<>/setup.py:57:4: C0116: Missing function or method 
docstring (missing-function-docstring)
/<>/setup.py:54:0: R0903: Too few public methods (1/2) 
(too-few-public-methods)
/<>/setup.py:65:4: C0116: Missing function or method 
docstring (missing-function-docstring)
/<>/setup.py:62:0: R0903: Too few public methods (1/2) 
(too-few-public-methods)


--
Ran 61 tests in 5.767s

FAILED (failures=1)
E: pybuild pybuild:391: test: plugin distutils failed with: exit code=1: 
cd /<>/.pybuild/cpython3_3.12/build; python3.12 -m unittest 
discover -v -s /<>
dh_auto_test: error: pybuild --test -i python{version} -p 3.12 returned 
exit code 13

Bug#1061736: aubio ftbfs with Python 3.12 as the default

[Matthias Klose]

Package: src:aubio
Version: 0.4.9-4.3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
python3 ./waf configure --verbose --destdir=debian/tmp --prefix=/usr 
--enable-fftw3f --libdir=/usr/lib/x86_64-linux-gnu
/<>/waflib/Utils.py:443: SyntaxWarning: invalid escape 
sequence '\d'

  return re.split('\d+$',s)[0]
/<>/waflib/ConfigSet.py:7: SyntaxWarning: invalid escape 
sequence '\ '

  re_imp=re.compile('^(#)*?([^#=]*?)\ =\ (.*?)$',re.M)
/<>/waflib/ansiterm.py:178: SyntaxWarning: invalid escape 
sequence '\['

  ansi_tokens=re.compile('(?:\x1b\[([0-9?;]*)([a-zA-Z])|([^\x1b]+))')
Traceback (most recent call last):
  File "/<>/./waf", line 164, in 
from waflib import Scripting
  File "/<>/waflib/Scripting.py", line 7, in 
from waflib import 
Utils,Configure,Logs,Options,ConfigSet,Context,Errors,Build,Node

  File "/<>/waflib/Configure.py", line 6, in 
from waflib import ConfigSet,Utils,Options,Logs,Context,Build,Errors
  File "/<>/waflib/Options.py", line 6, in 
from waflib import Logs,Utils,Context,Errors
  File "/<>/waflib/Context.py", line 5, in 
import os,re,imp,sys
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:45: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary] Error 2

Bug#1061737: bookletimposer ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:bookletimposer
Version: 0.3.1-3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:305: python3.11 setup.py clean
Traceback (most recent call last):
  File "/<>/setup.py", line 73, in 
class clean_man(distutils.command.clean.clean):
^^^
AttributeError: module 'distutils.command' has no attribute 'clean'
E: pybuild pybuild:391: clean: plugin distutils failed with: exit 
code=1: python3.11 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.11 3.12" 
returned exit code 13

make: *** [debian/rules:6: clean] Error 25

Bug#1061738: cmdtest ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:cmdtest
Version: 0.32.14.gcdfe14e-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
dh clean --with=python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:305: python3.11 setup.py clean
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.11' does not exist -- can't clean it
I: pybuild base:305: python3.12 setup.py clean
Traceback (most recent call last):
  File "/<>/setup.py", line 28, in 
import yarnlib
  File "/<>/yarnlib/__init__.py", line 22, in 
from .block_parser import BlockParser, BlockError
  File "/<>/yarnlib/block_parser.py", line 19, in 
import cliapp
  File "/usr/lib/python3/dist-packages/cliapp/__init__.py", line 45, in 


from .pluginmgr import PluginManager
  File "/usr/lib/python3/dist-packages/cliapp/pluginmgr.py", line 29, 
in 

import imp
ModuleNotFoundError: No module named 'imp'
E: pybuild pybuild:391: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.11 3.12" 
returned exit code 13

make: *** [debian/rules:4: clean] Error 25

Bug#1061739: datalad-next ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:datalad-next
Version: 1.1.0-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

not exactly sure what is failing. It looks like there are already 
failures with Python 3.11.


Please see
https://launchpadlibrarian.net/711662090/buildlog_ubuntu-noble-amd64.datalad-next_1.1.0-5_BUILDING.txt.gz

Bug#1061740: django-rich ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:django-rich
Version: 1.8.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

Please note that the build was don in Ubuntu noble for now,
complete build log at
https://launchpadlibrarian.net/711661762/buildlog_ubuntu-noble-amd64.django-rich_1.8.0-1_BUILDING.txt.gz

[...]

dh_auto_test -- --system=custom --test-args="{interpreter} -m coverage 
run -m pytest tests"

I: pybuild base:305: python3.11 -m coverage run -m pytest tests
= test session starts 
==

platform linux -- Python 3.11.7, pytest-7.4.4, pluggy-1.4.0
django: settings: tests.settings (from option)
rootdir: /<>
configfile: pyproject.toml
plugins: django-4.5.2
collected 48 items

tests/test_test.py s 
[ 27%]
tests/test_management.py  
[ 43%]
tests/test_test.py ...F... 
[100%]


=== FAILURES 
===
__ TestRunnerTests.test_skip_verbose 
___


self = 

def test_skip_verbose(self):
result = self.run_test("-v", "2", 
f"{__name__}.ExampleTests.test_skip")

assert result.returncode == 0
lines = result.stderr.splitlines()
if sys.version_info >= (3, 11):
>   assert lines[1:4] == [
(
"test_skip (tests.test_test.ExampleTests.test_skip) 
... "

+ "skipped 'some reason'"
),
"",
"-" * 70,
]
E   assert ["skipped 'so...'] == ["test_skip 
(...']
E At index 0 diff: "skipped 'some reason'" != "test_skip 
(tests.test_test.ExampleTests.test_skip) ... skipped 'some reason'"

E Use -v to get more diff

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

FAILED tests/test_test.py::TestRunnerTests::test_skip_verbose - assert 
["skip...
== 1 failed, 34 passed, 13 skipped in 33.52s 
===
E: pybuild pybuild:391: test: plugin custom failed with: exit code=1: 
python3.11 -m coverage run -m pytest tests

I: pybuild base:305: python3.12 -m coverage run -m pytest tests
= test session starts 
==

platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0
django: settings: tests.settings (from option)
rootdir: /<>
configfile: pyproject.toml
plugins: django-4.5.2
collected 48 items

tests/test_test.py s 
[ 27%]
tests/test_management.py  
[ 43%]
tests/test_test.py ...F... 
[100%]


=== FAILURES 
===
__ TestRunnerTests.test_skip_verbose 
___


self = 

def test_skip_verbose(self):
result = self.run_test("-v", "2", 
f"{__name__}.ExampleTests.test_skip")

assert result.returncode == 0
lines = result.stderr.splitlines()
if sys.version_info >= (3, 11):
>   assert lines[1:4] == [
(
"test_skip (tests.test_test.ExampleTests.test_skip) 
... "

+ "skipped 'some reason'"
),
"",
"-" * 70,
]
E   assert ["skipped 'so...'] == ["test_skip 
(...']
E At index 0 diff: "skipped 'some reason'" != "test_skip 
(tests.test_test.ExampleTests.test_skip) ... skipped 'some reason'"

E Use -v to get more diff

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

FAILED tests/test_test.py::TestRunnerTests::test_skip_verbose - assert 
["skip...
== 1 failed, 34 passed, 13 skipped in 33.71s 
===
E: pybuild pybuild:391: test: plugin custom failed with: exit code=1: 
python3.12 -m coverage run -m pytest tests
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 
"3.11 3.12" --system=custom "--test-args={interpreter} -m coverage run 
-m pytest tests" returned exit code 13

make[1]: *** [debian/rules:19: override_dh_auto_test] Error 25

Bug#1061741: faiss ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:faiss
Version: 1.7.4-3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx: 
In function ‘PyObject* swig_ptr(PyObject*)’:
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:4939:41: 
error: ‘SWIGTYPE_p_unsigned_long_long’ was not declared in this scope; 
did you mean ‘SWIGTYPE_p_unsigned_long’?
 4939 | return SWIG_NewPointerObj(data, 
SWIGTYPE_p_unsigned_long_long, 0);
  | 
^
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:1136:94: 
note: in definition of macro ‘SWIG_NewPointerObj’
 1136 | #define SWIG_NewPointerObj(ptr, type, flags) 
SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
  | 
 ^~~~
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:4946:41: 
error: ‘SWIGTYPE_p_long_long’ was not declared in this scope; did you 
mean ‘SWIGTYPE_p_long’?

 4946 | return SWIG_NewPointerObj(data, SWIGTYPE_p_long_long, 0);
  | ^~~~
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:1136:94: 
note: in definition of macro ‘SWIG_NewPointerObj’
 1136 | #define SWIG_NewPointerObj(ptr, type, flags) 
SWIG_Python_NewPointerObj(NULL, ptr, type, flags)

  |

Bug#1061734: aptitude: in TUI, incorrect "will be automatically removed because of dependency errors" message

[Vincent Lefevre]

Note that there was a similar bug in the past (2005, fixed in 2016):

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

with title:

  aptitude: "X will be automatically removed because of dependency errors:"
  then no errors shown

On 2024-01-29 11:20:45 +0100, Vincent Lefevre wrote:
> When I choose to upgrade swig from the TUI, I get the incorrect message
> 
> 
> swig4.0 (remove, 4.1.0-0.3) will be automatically removed because of
> dependency errors:
> 
> 
> with nothing else.

I cannot reproduce this issue on another machine, which doesn't have
a foreign architecture. I get just after 'g' and putting the cursor
over the swig4.0 line:


swig4.0 (remove, 4.1.0-0.3) will be automatically removed because of dependency
errors:

  * swig (upgrade, 4.1.0-0.3 -> 4.2.0-1) conflicts with swig4.0


However, AFAIK, it will be automatically removed not because of the
conflict, but because the new swig package no longer depends on it
(on both machines, swig4.0 is marked as automatically installed).

This is a different message from

> Then, when I type ':' over the swig4.0 line, this message changes to:
> 
> 
> swig4.0 (remove, 4.1.0-0.3) was installed automatically; it is being removed
> because all of the packages which depend upon it are being removed:
> 
>   * swig (upgrade, 4.1.0-0.3 -> 4.2.0-1) depends on swig4.0 (>= 4.1.0-0.3)
> (provided by swig4.0:i386 4.1.0-0.3)
> 

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1061742: git-remote-hg ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:git-remote-hg
Version: 1.0.4~ds-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
drwxr-xr-x 3 buildd buildd 4096 Jan 29 10:36 clone
drwxr-xr-x 4 buildd buildd 4096 Jan 29 10:36 refs
/<>/test/trash directory.main-push/bin/git-remote-hg:154: 
SyntaxWarning: invalid escape sequence '\w'

  RAW_AUTHOR_RE = re.compile(b'^(\w+) (?:(.+)? )?<(.*)> (\d+) ([+-]\d+)')
/<>/test/trash directory.main-push/bin/git-remote-hg:392: 
SyntaxWarning: invalid escape sequence '\('

  m = re.match(b'^(.+?) ext:\((.+)\)$', name)
/<>/test/trash directory.main-push/bin/git-remote-hg:57: 
DeprecationWarning: 'locale.getdefaultlocale' is deprecated and slated 
for removal in Python 3.15. Use setlocale(), getencoding() and 
getlocale() instead.

  or locale.getdefaultlocale()[1]
WARNING: seeded marks of origin with shared; performing gc
/<>/test/trash directory.main-push/bin/git-hg-helper:44: 
DeprecationWarning: 'locale.getdefaultlocale' is deprecated and slated 
for removal in Python 3.15. Use setlocale(), getencoding() and 
getlocale() instead.

  or locale.getdefaultlocale()[1]
Traceback (most recent call last):
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 1031, in 

sys.exit(main(sys.argv))
 ^^
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 1024, in main

c.execute(argv)
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 365, in execute

self.do(self.options, [compat.decode_sysarg(a) for a in self.args])
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 484, in do

remotehg = import_sibling('remotehg', 'git-remote-hg')
   ^^^
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 101, in import_sibling

import imp
ModuleNotFoundError: No module named 'imp'
WARNING: gc for origin failed
WARNING: seeded marks of second with shared; performing gc
/<>/test/trash directory.main-push/bin/git-hg-helper:44: 
DeprecationWarning: 'locale.getdefaultlocale' is deprecated and slated 
for removal in Python 3.15. Use setlocale(), getencoding() and 
getlocale() instead.

  or locale.getdefaultlocale()[1]
Traceback (most recent call last):
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 1031, in 

sys.exit(main(sys.argv))
 ^^
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 1024, in main

c.execute(argv)
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 365, in execute

self.do(self.options, [compat.decode_sysarg(a) for a in self.args])
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 484, in do

remotehg = import_sibling('remotehg', 'git-remote-hg')
   ^^^
  File "/<>/test/trash 
directory.main-push/bin/git-hg-helper", line 101, in import_sibling

import imp
ModuleNotFoundError: No module named 'imp'
WARNING: gc for second failed
no changes found
total 20

Bug#1061743: gramps ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:gramps
Version: 5.1.6+dfsg-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
FAIL: test2_exec_CLI (gramps.cli.test.cli_test.Test.test2_exec_CLI)
--
Traceback (most recent call last):
  File "/<>/gramps/cli/test/cli_test.py", line 88, in 
test2_exec_CLI

self.assertEqual(process.returncode, 0,
AssertionError: 1 != 0 : executed CLI command ['/usr/bin/python3', 
'Gramps.py', '-i', '/<>/gramps/cli/test/min1r.ged', '-e', 
'/<>/gramps/cli/test/test_out.ged']


==
FAIL: test3_files_in_import_dir 
(gramps.cli.test.cli_test.Test.test3_files_in_import_dir)

--
Traceback (most recent call last):
  File "/<>/gramps/cli/test/cli_test.py", line 120, in 
test3_files_in_import_dir

self.assertEqual(process.returncode, 0,
AssertionError: 1 != 0 : executed CLI command ['/usr/bin/python3', 
'Gramps.py', '-i', '/<>/gramps/cli/test/min1r.ged', '-e', 
'/<>/gramps/cli/test/test_out.ged']


==
FAIL: test_number_of_ancestors 
(gramps.plugins.test.reports_test.TestDynamic.test_number_of_ancestors)

--
Traceback (most recent call last):
  File "/<>/gramps/plugins/test/reports_test.py", line 91, 
in test_method

self.assertTrue(test_function(out, err, report_name, **options))
AssertionError: False is not true

--
Ran 21830 tests in 277.329s

FAILED (failures=3, skipped=57)
ERROR: Unit test failure.
make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1

Bug#1061744: ipyparallel ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:ipyparallel
Version: 7.1.0-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
=== FAILURES 
===
_ test_disambiguate_ip 
_


warn_mock = 

@mock.patch('warnings.warn')
def test_disambiguate_ip(warn_mock):
# garbage in, garbage out
assert util.disambiguate_ip_address('garbage') == 'garbage'
assert util.disambiguate_ip_address('0.0.0.0', 
socket.gethostname()) == localhost()

wontresolve = 'this.wontresolve.dns'
assert util.disambiguate_ip_address('0.0.0.0', wontresolve) == 
wontresolve

assert warn_mock.called_once_with(
'IPython could not determine IPs for {}: '
'[Errno -2] Name or service not known'.format(wontresolve),
RuntimeWarning,
>   )

ipyparallel/tests/test_util.py:21:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


self = , name = 
'called_once_with'


def __getattr__(self, name):
if name in {'_mock_methods', '_mock_unsafe'}:
raise AttributeError(name)
elif self._mock_methods is not None:
if name not in self._mock_methods or name in _all_magics:
raise AttributeError("Mock object has no attribute %r" 
% name)

elif _is_magic(name):
raise AttributeError(name)
if not self._mock_unsafe and (not self._mock_methods or name 
not in self._mock_methods):
if name.startswith(('assert', 'assret', 'asert', 'aseert', 
'assrt')) or name in _ATTRIB_DENY_LIST:

>   raise AttributeError(
f"{name!r} is not a valid assertion. Use a spec "
f"for the mock if {name!r} is meant to be an 
attribute.")
E   AttributeError: 'called_once_with' is not a valid 
assertion. Use a spec for the mock if 'called_once_with' is meant to be 
an attribute.. Did you mean: 'assert_called_once_with'?


/usr/lib/python3.12/unittest/mock.py:663: AttributeError

Bug#1061745: j2cli ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:j2cli
Version: 0.3.12b-4
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
python3 -m nose2 -v tests
test_render (nose2.loader.ModuleImportFailure.test_render) ... ERROR

==
ERROR: test_render (nose2.loader.ModuleImportFailure.test_render)
--
ImportError: Failed to import test module: test_render
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/nose2/plugins/loader/discovery.py", line 
196, in _find_tests_in_file

module = util.module_from_name(module_name)
 ^^
  File "/usr/lib/python3/dist-packages/nose2/util.py", line 73, in 
module_from_name

__import__(name)
  File "/<>/tests/test_render.py", line 11, in 
from j2cli.cli import render_command
  File "/<>/j2cli/__init__.py", line 10, in 
from j2cli.cli import main
  File "/<>/j2cli/cli.py", line 8, in 
import imp, inspect
ModuleNotFoundError: No module named 'imp'


--
Ran 1 test in 0.000s

FAILED (errors=1)

Bug#1061747: liac-arff ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:liac-arff
Version: 2.5.0-4
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: test_encode_too_many_attributes_coo 
(tests.test_data.TestCOOData.test_encode_too_many_attributes_coo)

--
Traceback (most recent call last):
  File "/<>/tests/test_data.py", line 206, in 
test_encode_too_many_attributes_coo

with self.assertRaisesRegexp(arff.BadObject,
 ^^^
AttributeError: 'TestCOOData' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_encode_too_many_attributes_dense 
(tests.test_data.TestData.test_encode_too_many_attributes_dense)

--
Traceback (most recent call last):
  File "/<>/tests/test_data.py", line 99, in 
test_encode_too_many_attributes_dense

with self.assertRaisesRegexp(arff.BadObject,
 ^^^
AttributeError: 'TestData' object has no attribute 'assertRaisesRegexp'. 
Did you mean: 'assertRaisesRegex'?


==
ERROR: test_encode_too_many_attributes_lod 
(tests.test_data.TestLODData.test_encode_too_many_attributes_lod)

--
Traceback (most recent call last):
  File "/<>/tests/test_data.py", line 300, in 
test_encode_too_many_attributes_lod

with self.assertRaisesRegexp(arff.BadObject,
 ^^^
AttributeError: 'TestLODData' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_encode_duplicate_attribute_name 
(tests.test_encode.TestEncodeComment.test_encode_duplicate_attribute_name)

--
Traceback (most recent call last):
  File "/<>/tests/test_encode.py", line 169, in 
test_encode_duplicate_attribute_name

with self.assertRaisesRegexp(arff.BadObject,
 ^^^
AttributeError: 'TestEncodeComment' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_decode 
(tests.test_decode.TestDuplicateAttributeName.test_decode)

--
Traceback (most recent call last):
  File "/<>/tests/test_decode.py", line 359, in test_decode
with self.assertRaisesRegexp(arff.BadAttributeName,
 ^^^
AttributeError: 'TestDuplicateAttributeName' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_dense (tests.test_decode.TestInvalidValues.test_dense)
--
Traceback (most recent call last):
  File "/<>/tests/test_decode.py", line 382, in test_dense
with self.assertRaisesRegexp(arff.ArffException,
 ^^^
AttributeError: 'TestInvalidValues' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_sparse (tests.test_decode.TestInvalidValues.test_sparse)
--
Traceback (most recent call last):
  File "/<>/tests/test_decode.py", line 399, in test_sparse
with self.assertRaisesRegexp(arff.ArffException,
 ^^^
AttributeError: 'TestInvalidValues' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_coo (tests.test_decode.TestTooManyAttributes.test_coo)
--
Traceback (most recent call last):
  File "/<>/tests/test_decode.py", line 333, in test_coo
with self.assertRaisesRegexp(arff.BadDataFormat,
 ^^^
AttributeError: 'TestTooManyAttributes' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


==
ERROR: test_dense (tests.test_decode.TestTooManyAttributes.test_dense)
--
Traceback (most recent call last):
  File "/<>/tests/test_decode.py", line 326, in test_dense
with self.assertRaisesRegexp(arff.BadDataFormat,
 ^^^
AttributeError: 'TestTooManyAttr

Bug#1061746: jupyter-notebook ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:jupyter-notebook
Version: 6.4.12-2.2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

complete build log at
https://launchpadlibrarian.net/711662548/buildlog_ubuntu-noble-amd64.jupyter-notebook_6.4.12-2.2_BUILDING.txt.gz

[...]
=== short test summary info 

FAILED 
notebook/services/contents/tests/test_manager.py::TestContentsManager::test_get
FAILED 
notebook/services/contents/tests/test_manager.py::TestContentsManagerNoAtomic::test_get
FAILED 
notebook/services/kernels/tests/test_kernels_api.py::KernelAPITest::test_connections
ERROR 
notebook/tests/test_notebookapp.py::NotebookUnixSocketTests::test_list_running_sock_servers

ERROR notebook/tests/test_notebookapp.py::NotebookUnixSocketTests::test_run
= 3 failed, 306 passed, 14 skipped, 5 deselected, 2091 warnings, 2 
errors in 83.79s (0:01:23) =

Bug#1061748: ontospy ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:ontospy
Version: 2.1.1~dfsg2-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
python3 -m ontospy.tests.test_load_local
Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 112, in _get_module_details
  File "/<>/ontospy/__init__.py", line 7, in 
from .core.ontospy import Ontospy
  File "/<>/ontospy/core/__init__.py", line 9, in 
from configparser import SafeConfigParser
ImportError: cannot import name 'SafeConfigParser' from 'configparser' 
(/usr/lib/python3.12/configparser.py). Did you mean: 'RawConfigParser'?

make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:46: binary] Error 2

Bug#1059782: mesa-vdpau-drivers: Upgrade to 23.3.* breaks video rendering in tkinter

[jim_p]

Package: mesa-vdpau-drivers
Followup-For: Bug #1059782
X-Debbugs-Cc: pitsior...@outlook.com

@Vasyl Gello

Shouldn't this be opened under mesa-VA-drivers as a new bug report with the
same or greater severity?
I am on a 6450, I am using radeon and I have lost vaapi on all my players since
23.3.x moved to testing. There isn't a single bug report for this and all I
have found is a thread on debian forums. I commented on it, but there are no
further replies, not even if 23.3.4 fixes it, which reached unstable a couple
of days ago. So right now I am waiting for it to reach testing by the end of
the week before posting again.

The only patch that may fix it is this one I found on arch
https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/commit/15e037dba159f893360d642e4efa13e09682b080


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

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

Versions of packages mesa-vdpau-drivers depends on:
ii  libc62.37-14
ii  libdrm-amdgpu1   2.4.120-1
ii  libdrm-nouveau2  2.4.120-1
ii  libdrm-radeon1   2.4.120-1
ii  libdrm2  2.4.120-1
ii  libelf1  0.190-1+b1
ii  libexpat12.5.0-2+b2
ii  libgcc-s113.2.0-10
ii  libllvm171:17.0.6-5
ii  libstdc++6   13.2.0-10
ii  libvdpau11.5-2
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-dri2-01.15-1
ii  libxcb-dri3-01.15-1
ii  libxcb-present0  1.15-1
ii  libxcb-sync1 1.15-1
ii  libxcb-xfixes0   1.15-1
ii  libxcb1  1.15-1
ii  libxshmfence11.3-1
ii  libzstd1 1.5.5+dfsg2-2
ii  zlib1g   1:1.3.dfsg-3+b1

mesa-vdpau-drivers recommends no packages.

mesa-vdpau-drivers suggests no packages.

Bug#1061749: piuparts ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:piuparts
Version: 1.3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: testAlternatives 
(test_dependencyparser.DependencyParserTests.testAlternatives)

--
Traceback (most recent call last):
  File "/<>/tests/test_dependencyparser.py", line 34, in 
testAlternatives

self.failUnlessEqual(names, [["foo"], ["bar", "foobar"]])

AttributeError: 'DependencyParserTests' object has no attribute 
'failUnlessEqual'


==
ERROR: testEmpty (test_dependencyparser.DependencyParserTests.testEmpty)
--
Traceback (most recent call last):
  File "/<>/tests/test_dependencyparser.py", line 22, in 
testEmpty

self.failUnlessEqual(deps, [])

AttributeError: 'DependencyParserTests' object has no attribute 
'failUnlessEqual'


==
ERROR: testSingle (test_dependencyparser.DependencyParserTests.testSingle)
--
Traceback (most recent call last):
  File "/<>/tests/test_dependencyparser.py", line 26, in 
testSingle

self.failUnlessEqual(names, [["foo"]])

AttributeError: 'DependencyParserTests' object has no attribute 
'failUnlessEqual'


==
ERROR: testTwo (test_dependencyparser.DependencyParserTests.testTwo)
--
Traceback (most recent call last):
  File "/<>/tests/test_dependencyparser.py", line 30, in 
testTwo

self.failUnlessEqual(names, [["foo"], ["bar"]])

AttributeError: 'DependencyParserTests' object has no attribute 
'failUnlessEqual'


==
ERROR: testAbsoluteBroken 
(test_piuparts.IsBrokenSymlinkTests.testAbsoluteBroken)

--
Traceback (most recent call last):
  File "/<>/tests/test_piuparts.py", line 110, in 
testAbsoluteBroken
self.failUnless(is_broken_symlink(self.testdir, self.testdir, 
"absolute-broken"))

^^^
AttributeError: 'IsBrokenSymlinkTests' object has no attribute 'failUnless'

==
ERROR: testAbsoluteBrokenToSymlink 
(test_piuparts.IsBrokenSymlinkTests.testAbsoluteBrokenToSymlink)

--
Traceback (most recent call last):
  File "/<>/tests/test_piuparts.py", line 113, in 
testAbsoluteBrokenToSymlink
self.failUnless(is_broken_symlink(self.testdir, self.testdir, 
"absolute-broken-to-symlink"))

^^^
AttributeError: 'IsBrokenSymlinkTests' object has no attribute 'failUnless'

==
ERROR: testAbsoluteSelfLoopBroken 
(test_piuparts.IsBrokenSymlinkTests.testAbsoluteSelfLoopBroken)

--
Traceback (most recent call last):
  File "/<>/tests/test_piuparts.py", line 125, in 
testAbsoluteSelfLoopBroken
self.failUnless(is_broken_symlink(self.testdir, self.testdir, 
"absolute-selfloop"))

^^^
AttributeError: 'IsBrokenSymlinkTests' object has no attribute 'failUnless'

==
ERROR: testAbsoluteWorks 
(test_piuparts.IsBrokenSymlinkTests.testAbsoluteWorks)

--
Traceback (most recent call last):
  File "/<>/tests/test_piuparts.py", line 142, in 
testAbsoluteWorks
self.failIf(is_broken_symlink(self.testdir, self.testdir, 
"absolute-works"))

^^^
AttributeError: 'IsBrokenSymlinkTests' object has no attribute 'failIf'. 
Did you mean: 'fail'?


==
ERROR: testAbsoluteWorksToSymlink 
(test_piuparts.IsBrokenSymlinkTests.testAbsoluteWorksToSymlink)

--
Traceback (most recent call last):
  File "/<>/tests/test_piuparts.py", line 145, in 
testAbsoluteWorksToSymlink
self.failIf(is_broken_symlink(self.testdir, self.testdir, 
"absolute-works-to-symlink"))

^^^
AttributeError: 'IsBrokenSymlinkTests' object has no attribute 'failIf'. 
Did you mean: 'fail'?


==
ERROR: testExpandingSelfLoopBroken 
(test_piuparts.IsBrokenSymlinkTests.testExpandingSel

Bug#1061750: python-cliapp ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-cliapp
Version: 1.20180812.1-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: test_exports_all_config_sections_via_as_cp 
(cliapp.settings_tests.SettingsTests.test_exports_all_config_sections_via_as_cp)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 596, in 
test_exports_all_config_sections_via_as_cp

self.settings.load_configs(open_file=mock_open)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


==
ERROR: test_handles_defaults_with_ini_files 
(cliapp.settings_tests.SettingsTests.test_handles_defaults_with_ini_files)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 357, in 
test_handles_defaults_with_ini_files

self.settings.load_configs(open_file=mock_open)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


==
ERROR: test_handles_overridden_defaults_with_ini_files 
(cliapp.settings_tests.SettingsTests.test_handles_overridden_defaults_with_ini_files)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 387, in 
test_handles_overridden_defaults_with_ini_files

self.settings.load_configs(open_file=mock_open)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


==
ERROR: test_handles_values_from_ini_files_overridden_on_command_line 
(cliapp.settings_tests.SettingsTests.test_handles_values_from_ini_files_overridden_on_command_line)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 419, in 
test_handles_values_from_ini_files_overridden_on_command_line

self.settings.load_configs(open_file=mock_open)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


==
ERROR: test_load_configs_raises_error_for_unknown_variable_in_ini 
(cliapp.settings_tests.SettingsTests.test_load_configs_raises_error_for_unknown_variable_in_ini)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 451, in 
test_load_configs_raises_error_for_unknown_variable_in_ini

self.assertRaises(
  File "/usr/lib/python3.12/unittest/case.py", line 780, in assertRaises
return context.handle('assertRaises', args, kwargs)
   
  File "/usr/lib/python3.12/unittest/case.py", line 238, in handle
callable_obj(*args, **kwargs)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


==
ERROR: test_load_configs_remembers_extra_sections_in_ini 
(cliapp.settings_tests.SettingsTests.test_load_configs_remembers_extra_sections_in_ini)

--
Traceback (most recent call last):
  File "/<>/cliapp/settings_tests.py", line 480, in 
test_load_configs_remembers_extra_sections_in_ini

self.settings.load_configs(open_file=mock_open)
  File "/<>/cliapp/settings.py", line 829, in load_configs
self._read_ini(pathname, f)
  File "/<>/cliapp/settings.py", line 838, in _read_ini
cp.readfp(f)
^
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?


=

Bug#1061751: python-django-debug-toolbar ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-django-debug-toolbar
Version: 1:4.2-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
FAIL: test_listcomp_escaped 
(tests.panels.test_profiling.ProfilingPanelTestCase.test_listcomp_escaped)

--
Traceback (most recent call last):
  File "/<>/tests/panels/test_profiling.py", line 59, in 
test_listcomp_escaped
self.assertIn('', 
content)
AssertionError: '' not 
found in '\n\n  \n\n  Call\n 
CumTime\n  Per\n  TotTime\n 
Per\n  Count\n\n  \n  \n 
 \n  id="profilingMain_0">\n\n  data-djdt-styles="paddingLeft:0px">\n\n  type="button" class="djProfileToggleDetails djToggleSwitch" 
data-toggle-name="profilingMain" data-toggle-id="0">-\n 
   \nclass="djdt-path">/<>/debug_toolbar/panels/class="djdt-file">__init__.py in class="djdt-func">process_request(class="djdt-lineno">195)\n  \n 
\n0.003\n0.003\n 
0.000\n0.000\n1\n 
\n\n  \n\n  data-djdt-styles="paddingLeft:16px">\n\n 
data-toggle-name="profilingMain" data-toggle-id="0_1">-\n 
 \nclass="djdt-path">/<>/tests/class="djdt-file">base.py in class="djdt-func">get_response(class="djdt-lineno">55)\n  \n\n 
   0.003\n0.003\n0.000\n 
   0.000\n1\n  \n\n  class="djdt-profile-row djdt-highlighted   djToggleDetails_0 
djToggleDetails_0_1" id="profilingMain_0_1_1">\n\n 
\n\n 
data-toggle-name="profilingMain" data-toggle-id="0_1_1">-\n 
   \nclass="djdt-path">/<>/tests/panels/class="djdt-file">test_profiling.py in class="djdt-func">(class="djdt-lineno">54)\n  \n\n 
   0.003\n0.003\n0.000\n 
   0.000\n1\n  \n\n  class="djdt-profile-row djdt-highlighted   djToggleDetails_0 
djToggleDetails_0_1 djToggleDetails_0_1_1" id="profilingMain_0_1_1_1">\n 
   \n  \n 
  \n  class="djProfileToggleDetails djToggleSwitch" 
data-toggle-name="profilingMain" data-toggle-id="0_1_1_1">-\n 
 \nclass="djdt-path">/<>/tests/class="djdt-file">views.py in class="djdt-func">listcomp_view(class="djdt-lineno">54)\n  \n\n 
   0.003\n0.003\n0.003\n 
   0.003\n1\n  \n\n  class="djdt-profile-row   djToggleDetails_0 djToggleDetails_0_1 
djToggleDetails_0_1_1 djToggleDetails_0_1_1_1" 
id="profilingMain_0_1_1_1_1">\n\n  data-djdt-styles="paddingLeft:64px">\n\n  class="djNoToggleSwitch">\n\nclass="djdt-stack">class="djdt-path">/usr/lib/python3/dist-packages/django/class="djdt-file">shortcuts.py in class="djdt-func">render(class="djdt-lineno">17)\n  \n\n 
   0.000\n0.000\n0.000\n 
   0.000\n1\n  \n\n 
\n\n'


--
Ran 142 tests in 1.281s

FAILED (failures=1, skipped=20)

Bug#1061752: python-django-tagging ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-django-tagging
Version: 1:0.5.0-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: test_tag_get_from_model 
(tagging.tests.tests.TestTagFieldInForms.test_tag_get_from_model)

--
Traceback (most recent call last):
  File "/<>/tagging/tests/tests.py", line 1142, in 
test_tag_get_from_model

self.assertEquals(FormTest.tags, 'test1 test2 test3 titi toto')
^
AttributeError: 'TestTagFieldInForms' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: test_view_404 
(tagging.tests.tests.TestTaggedObjectList.test_view_404)

--
Traceback (most recent call last):
  File "/<>/tagging/tests/tests.py", line 1227, in 
test_view_404

self.get_view('/unavailable/', code=404)
  File "/<>/tagging/tests/tests.py", line 1197, in get_view
self.assertEquals(response.status_code, code)
^
AttributeError: 'TestTaggedObjectList' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: test_view_dynamic 
(tagging.tests.tests.TestTaggedObjectList.test_view_dynamic)

--
Traceback (most recent call last):
  File "/<>/tagging/tests/tests.py", line 1212, in 
test_view_dynamic

self.get_view('/tag/', expected_items=1)
  File "/<>/tagging/tests/tests.py", line 1197, in get_view
self.assertEquals(response.status_code, code)
^
AttributeError: 'TestTaggedObjectList' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: test_view_related 
(tagging.tests.tests.TestTaggedObjectList.test_view_related)

--
Traceback (most recent call last):
  File "/<>/tagging/tests/tests.py", line 1215, in 
test_view_related

response = self.get_view('/static/related/',
   ^
  File "/<>/tagging/tests/tests.py", line 1197, in get_view
self.assertEquals(response.status_code, code)
^
AttributeError: 'TestTaggedObjectList' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: test_view_static 
(tagging.tests.tests.TestTaggedObjectList.test_view_static)

--
Traceback (most recent call last):
  File "/<>/tagging/tests/tests.py", line 1209, in 
test_view_static

self.get_view('/static/', expected_items=2)
  File "/<>/tagging/tests/tests.py", line 1197, in get_view
self.assertEquals(response.status_code, code)
^
AttributeError: 'TestTaggedObjectList' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


--
Ran 75 tests in 0.534s

FAILED (errors=5)

Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'

[Dave Hibberd]

Hi there,

Thanks for the bug and turning around a patch so quickly - it didn't show up in 
my test, I wonder what was different about my config!

I'll build and test in a clean environment later on and upload when I can!

Cheers,
DH

-- 
  Hibby
  MM0RFN

On Mon, 29 Jan 2024, at 2:57 AM, Harlan Lieberman-Berg wrote:
> tag 1061692 +patch
> thanks
>
> I've tested it, and it seems that manually adding the path to
> d/install fixes the problem fine.  Patch attached.
>
> Sincerely,
>
> -- 
> Harlan Lieberman-Berg
> ~hlieberman
>
> Attachments:
> * 0001-Ensure-stock-configs-are-installed-Closes-1061692.patch

Bug#1061753: python-jieba ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-jieba
Version: 0.42.1-3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="cd {dir}/test; 
PATH=$PATH:{build_dir} python{version} {dir}/test/jieba_test.py" 
dh_auto_test
I: pybuild base:305: cd /<>/test; 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/<>/.pybuild/cpython3_3.12_jieba/build 
python3.12 /<>/test/jieba_test.py
/<>/.pybuild/cpython3_3.12_jieba/build/jieba/__init__.py:44: 
SyntaxWarning: invalid escape sequence '\.'

  re_han_default = re.compile("([\u4E00-\u9FD5a-zA-Z0-9+#&\._%\-]+)", re.U)
/<>/.pybuild/cpython3_3.12_jieba/build/jieba/__init__.py:46: 
SyntaxWarning: invalid escape sequence '\s'

  re_skip_default = re.compile("(\r\n|\s)", re.U)
/<>/.pybuild/cpython3_3.12_jieba/build/jieba/finalseg/__init__.py:78: 
SyntaxWarning: invalid escape sequence '\.'

  re_skip = re.compile("([a-zA-Z0-9]+(?:\.\d+)?%?)")
Traceback (most recent call last):
  File "/<>/test/jieba_test.py", line 9, in 
from imp import reload
ModuleNotFoundError: No module named 'imp'
E: pybuild pybuild:391: test: plugin custom failed with: exit code=1: cd 
/<>/test; 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/<>/.pybuild/cpython3_3.12_jieba/build 
python3.12 /<>/test/jieba_test.py

Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-json-log-formatter
Version: 0.5.2-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
= test session starts 
==

platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0
cachedir: .tox/py312/.pytest_cache
rootdir: /<>
collected 29 items

tests.py ...FF

=== FAILURES 
===
_ 
JSONFormatterTest.test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided 
_


self = testMethod=test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided>


def 
test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided(self):

logger.info('Sign up', extra={'fizz': 'bazz'})
json_record = json.loads(log_buffer.getvalue())
expected_fields = set([
'message',
'time',
'fizz',
])
>   self.assertEqual(set(json_record), expected_fields)
E   AssertionError: Items in the first set but not the second:
E   'taskName'

tests.py:72: AssertionError
-- Captured log call 
---

INFO test:tests.py:65 Sign up
_ 
JSONFormatterTest.test_message_and_time_are_in_json_record_when_extra_is_blank 
_


self = testMethod=test_message_and_time_are_in_json_record_when_extra_is_blank>


def test_message_and_time_are_in_json_record_when_extra_is_blank(self):
logger.info('Sign up')
json_record = json.loads(log_buffer.getvalue())
expected_fields = set([
'message',
'time',
])
>   self.assertEqual(set(json_record), expected_fields)
E   AssertionError: Items in the first set but not the second:
E   'taskName'

tests.py:62: AssertionError
-- Captured log call 
---

INFO test:tests.py:56 Sign up
=== warnings summary 
===

tests.py: 28 warnings
  /<>/json_log_formatter/__init__.py:123: 
DeprecationWarning: datetime.datetime.utcnow() is deprecated and 
scheduled for removal in a future version. Use timezone-aware objects to 
represent datetimes in UTC: datetime.datetime.now(datetime.UTC).

extra['time'] = datetime.utcnow()

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info 

FAILED 
tests.py::JSONFormatterTest::test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided
FAILED 
tests.py::JSONFormatterTest::test_message_and_time_are_in_json_record_when_extra_is_blank
== 2 failed, 27 passed, 28 warnings in 0.17s 
===

py312: exit 1 (0.36 seconds) /<>> pytest -s tests.py pid=5939

Bug#1061755: python-mitogen ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-mitogen
Version: 0.3.4-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: utils_test (unittest.loader._FailedTest.utils_test)
--
ImportError: Failed to import test module: utils_test
Traceback (most recent call last):
  File "/usr/lib/python3.12/unittest/loader.py", line 394, in 
_find_test_path

module = self._get_module_from_name(name)
 
  File "/usr/lib/python3.12/unittest/loader.py", line 337, in 
_get_module_from_name

__import__(name)
  File "/<>/tests/utils_test.py", line 1, in 
import mitogen.core
  File "/<>/mitogen/core.py", line 63, in 
import imp
ModuleNotFoundError: No module named 'imp'


--
Ran 55 tests in 0.003s

FAILED (errors=55)

Bug#1061756: python-twilio ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-twilio
Version: 7.7.1+ds1-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
=== FAILURES 
===
___ ClientValidationJwtTest.test_jwt_payload 
___


self = testMethod=test_jwt_payload>


def test_jwt_payload(self):
vp = ValidationPayload(
method='GET',
path='/Messages',
query_string='PageSize=5&Limit=10',
signed_headers=['authorization', 'host'],
all_headers={'authorization': 'foobar', 'host': 
'api.twilio.com'},

body='foobar'
)
expected_hash = 
'4dc9b67bed579647914587b0e22a1c65c1641d8674797cd82de65e766cce5f80'


jwt = ClientValidationJwt('AC123', 'SK123', 'CR123', 'secret', vp)

>   self.assertDictContainsSubset({
'hrh': 'authorization;host',
'rqh': expected_hash,
'iss': 'SK123',
'sub': 'AC123',
}, jwt.payload)
E   AttributeError: 'ClientValidationJwtTest' object has no 
attribute 'assertDictContainsSubset'


tests/unit/jwt/test_client_validation.py:234: AttributeError
___ ClientValidationJwtTest.test_jwt_signing 
___


self = testMethod=test_jwt_signing>


def test_jwt_signing(self):
vp = ValidationPayload(
method='GET',
path='/Messages',
query_string='PageSize=5&Limit=10',
signed_headers=['authorization', 'host'],
all_headers={'authorization': 'foobar', 'host': 
'api.twilio.com'},

body='foobar'
)
expected_hash = 
'4dc9b67bed579647914587b0e22a1c65c1641d8674797cd82de65e766cce5f80'


private_key = rsa.generate_private_key(
public_exponent=65537,
key_size=2048,
backend=default_backend()
)
public_key = 
private_key.public_key().public_bytes(Encoding.PEM, PublicFormat.PKCS1)
private_key = private_key.private_bytes(Encoding.PEM, 
PrivateFormat.PKCS8, NoEncryption())


jwt = ClientValidationJwt('AC123', 'SK123', 'CR123', 
private_key, vp)

decoded = ClientValidationJwt.from_jwt(jwt.to_jwt(), public_key)

>   self.assertDictContainsSubset({
'hrh': 'authorization;host',
'rqh': expected_hash,
'iss': 'SK123',
'sub': 'AC123',
}, decoded.payload)
E   AttributeError: 'ClientValidationJwtTest' object has no 
attribute 'assertDictContainsSubset'


tests/unit/jwt/test_client_validation.py:271: AttributeError
__ JwtTest.test_encode_decode 
__


self = 

def test_encode_decode(self):
test_start = self.now()

jwt = DummyJwt('secret_key', 'issuer', subject='hey', 
payload={'sick': 'sick'})

decoded_jwt = Jwt.from_jwt(jwt.to_jwt(), 'secret_key')

self.assertGreaterEqual(decoded_jwt.valid_until, self.now() + 3600)
self.assertGreaterEqual(decoded_jwt.nbf, test_start)
self.assertEqual(decoded_jwt.issuer, 'issuer')
self.assertEqual(decoded_jwt.secret_key, 'secret_key')
self.assertEqual(decoded_jwt.algorithm, 'HS256')
self.assertEqual(decoded_jwt.subject, 'hey')

self.assertEqual(decoded_jwt.headers, {'typ': 'JWT', 'alg': 
'HS256'})

>   self.assertDictContainsSubset({
'iss': 'issuer',
'sub': 'hey',
'sick': 'sick',
}, decoded_jwt.payload)
E   AttributeError: 'JwtTest' object has no attribute 
'assertDictContainsSubset'


tests/unit/jwt/test_jwt.py:206: AttributeError

Bug#1061757: subnetcalc outputs 6to4 value as stderr

[Sakirnth Nagarasa]

Package: subnetcalc
Version: 2.4.21-1

Hello

When I give a public IPv6 subnet as argument for subnetcalc the 6to4
address outputs as stderr.

To reproduce you can do:
subnetcalc ${public_ipv6_subnet} 2> stderr

Thanks and greetings
Saki

Bug#1061758: python-xmlrunner ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python-xmlrunner
Version: 3.2.0-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
ERROR: test_xmlrunner_non_ascii 
(tests.testsuite.XMLTestRunnerTestCase.test_xmlrunner_non_ascii)

--
Traceback (most recent call last):
  File "/<>/tests/testsuite.py", line 314, in 
test_xmlrunner_non_ascii

runner.run(suite)
  File "/<>/xmlrunner/runner.py", line 67, in run
test(result)
  File "/usr/lib/python3.12/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
   ^^^
  File "/usr/lib/python3.12/unittest/suite.py", line 122, in run
test(result)
  File "/usr/lib/python3.12/unittest/case.py", line 692, in __call__
return self.run(*args, **kwds)
   ^^^
  File "/usr/lib/python3.12/unittest/case.py", line 662, in run
result.stopTest(self)
  File "/<>/xmlrunner/result.py", line 330, in stopTest
self.callback()
  File "/<>/xmlrunner/result.py", line 238, in callback
test_info.test_finished()
  File "/<>/xmlrunner/result.py", line 180, in test_finished
self.test_result.stop_time - self.test_result.start_time
 ^^^
AttributeError: '_XMLTestResult' object has no attribute 'start_time'. 
Did you mean: 'stop_time'?


--
Ran 82 tests in 0.076s

FAILED (errors=1, skipped=7, expected failures=1)
Test failed: 

Bug#1061759: python3-antlr4 ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:python3-antlr4
Version: 4.9.1-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]

ERROR: testContiguous1 (TestIntervalSet.TestIntervalSet.testContiguous1)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 55, in testContiguous1

self.assertEquals(1,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testContiguous2 (TestIntervalSet.TestIntervalSet.testContiguous2)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 64, in testContiguous2

self.assertEquals(1,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testDistinct1 (TestIntervalSet.TestIntervalSet.testDistinct1)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 37, in testDistinct1

self.assertEquals(2,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testDistinct2 (TestIntervalSet.TestIntervalSet.testDistinct2)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 46, in testDistinct2

self.assertEquals(2,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testOverlapping1 (TestIntervalSet.TestIntervalSet.testOverlapping1)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 72, in testOverlapping1

self.assertEquals(1,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testOverlapping2 (TestIntervalSet.TestIntervalSet.testOverlapping2)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 80, in testOverlapping2

self.assertEquals(1,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


==
ERROR: testOverlapping3 (TestIntervalSet.TestIntervalSet.testOverlapping3)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_antlr4-python3-runtime/build/test/TestIntervalSet.py", 
line 90, in testOverlapping3

self.assertEquals(1,len(s.intervals))
^
AttributeError: 'TestIntervalSet' object has no attribute 
'assertEquals'. Did you mean: 'assertEqual'?


--
Ran 56 tests in 0.067s

FAILED (errors=7)

Bug#1061760: sasview ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:sasview
Version: 5.0.6-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
 python3 setup.py docs update
running docs
= check for sasmodels at /<>/sasmodels/doc 
== !!WARNING!! sasmodels directory not found. Cannot build model docs. ==
Traceback (most recent call last):
  File "/<>/setup.py", line 292, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
107, in setup

return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 185, in setup

return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 201, in run_commands

dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 969, in run_commands

self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File "/<>/setup.py", line 106, in run
import build_sphinx
  File "/<>/docs/sphinx-docs/build_sphinx.py", line 16, in 


import imp
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:30: execute_after_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:20: binary] Error 2

Bug#1061761: snakemake ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:snakemake
Version: 7.32.4-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

see
https://launchpadlibrarian.net/711666054/buildlog_ubuntu-noble-amd64.snakemake_7.32.4-1_BUILDING.txt.gz

for the complete build log.

[...]

Bug#1061762: suricata: please enable dpdk

[Alexandra N. Kossovsky]

Package: suricata
Version: 1:7.0.2-1~bpo12+1
Severity: wishlist

Suricata can work with DPDK, but this feature is not enabled in the
Debian package.  Could you enable it, please?



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

Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.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)

Versions of packages suricata depends on:
ii  dpkg 1.21.22
ii  init-system-helpers  1.65.2
ii  libbpf1  1:1.1.0-1
ii  libc62.36-9+deb12u3
ii  libcap-ng0   0.8.3-1+b3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libevent-pthreads-2.1-7  2.1.12-stable-8
ii  libgcc-s112.2.0-14
ii  libhiredis0.14   0.14.1-3
ii  libhtp2  1:0.5.45-1~bpo12+1
ii  libhyperscan55.4.0-2
ii  libjansson4  2.14-2
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4.1
ii  liblz4-1 1.9.4-1
ii  libmagic11:5.44-3
ii  libmaxminddb01.7.1-1
ii  libnet1  1.1.6+dfsg-3.2
ii  libnetfilter-log11.0.2-3
ii  libnetfilter-queue1  1.0.5-3
ii  libnfnetlink01.0.2-2
ii  libpcap0.8   1.10.3-1
ii  libpcre2-8-0 10.42-1
ii  libyaml-0-2  0.2.5-1
ii  python3  3.11.2-1+b1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages suricata recommends:
ii  python3  3.11.2-1+b1
pn  snort-rules-default  
pn  suricata-update  

Versions of packages suricata suggests:
pn  libtcmalloc-minimal4  

-- debconf-show failed

--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)

Bug#1061763: ufw ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:ufw
Version: 0.36.2-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
==
ERROR: test_write_to_file 
(tests.unit.test_util.UtilTestCase.test_write_to_file)

Test write_to_file()
--
Traceback (most recent call last):
  File "/<>/tests/unit/test_util.py", line 607, in 
test_write_to_file

self.assertEquals(out, search)
^
AttributeError: 'UtilTestCase' object has no attribute 'assertEquals'. 
Did you mean: 'assertEqual'?


--
Ran 49 tests in 0.211s

FAILED (errors=24)

--
Unit tests summary
--
Total=8 (Passed=2, Failed=6)

Bug#1061764: unattended-upgrades ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:unattended-upgrades
Version: 2.9.1+nmu4
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
Running ./test_pep484.py with python3
s
--
Ran 0 tests in 0.000s

NO TESTS RAN (skipped=1)
make[2]: *** [Makefile:9: check] Error 5
make[2]: Leaving directory '/<>/test'
make[1]: *** [debian/rules:16: override_dh_auto_test] Error 2

5 is a new exit value when all tests are skipped.

Bug#1010806: apt: Avoid color output on monochrome terminals

[Axel Scheepers]

1010...@bugs.debian.org

On Thu, 26 May 2022 11:03:25 +0200 Axel Scheepers
 wrote:
> Or the other way around as I proposed. The entire problem of knowing what
> and how to use color goes away when curses is used. Would you accept a
> patch for using that instead?

I've forgot about this but how about the following?

#include 
#include 

int
ncolors(void)
{
int ncolors = -1;

if (setupterm(NULL, 1, NULL) == OK) {
ncolors = tigetnum("colors");
del_curterm(cur_term);
}

return ncolors;
}

This doesn't initialise the terminal so you can still do the
progressbar without clearing the screen and/or use hardcoded ansi
codes for colors if you want. It returns the number of colors for the
used terminal or -1 if color is not supported. Maybe the progressbar
should be optional in that case too. I think it would be a nice
addition and one doesn't have to use apt-get  and/or apt-cache
instead.
Also, maybe using italics, bold and reverse video instead of colors
can be considered? They usually do the right thing with either
background. Anyway, I hope you can implement the above function to
make at least monochrome and/or dumb terminals behave.

Kind regards,
Axel

Bug#1061765: vmdb2 ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:vmdb2
Version: 0.28-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
dh_auto_build
I: pybuild base:305: /usr/bin/python3.11 setup.py build
I: pybuild base:305: /usr/bin/python3 setup.py build
bash format.sh
[WARNING] Deprecated: --self-contained. use --embed-resources --standalone
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
./check
Running unit tests 
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22, 
in 

import imp
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


Build finished at 2024-01-29T10:47:03Z

Bug#1061766: xmds2 ftbfs with Python 3.12 as default

[Matthias Klose]

Package: src:xmds2
Version: 3.1.0+dfsg2-7
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails to build:

[...]
dh clean --with python3
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
cd xpdeint; waf/waf-light configure
Traceback (most recent call last):
  File "/<>/xpdeint/waf/waf-light", line 166, in 
from waflib import Scripting
  File "/<>/xpdeint/waf/waflib/Scripting.py", line 10, in 

from waflib import Utils, Configure, Logs, Options, ConfigSet, 
Context, Errors, Build, Node
  File "/<>/xpdeint/waf/waflib/Configure.py", line 16, in 

from waflib import ConfigSet, Utils, Options, Logs, Context, Build, 
Errors
  File "/<>/xpdeint/waf/waflib/Options.py", line 14, in 


from waflib import Logs, Utils, Context, Errors
  File "/<>/xpdeint/waf/waflib/Context.py", line 9, in 


import os, re, imp, sys
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:56: override_dh_auto_clean] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: clean] Error 2

Bug#1010806: apt: Avoid color output on monochrome terminals

[Axel Scheepers]

Using 'ncolors' for both function and variable isn't really nice but
as is the function will exit when you use it with an unknown terminal
which might not be ok. Maybe using the following would be better;

#include 
#include 

int
ncolors(void)
{
int err, n = -1;

if (setupterm(NULL, 1, &err) == OK) {
n = tigetnum("colors");
del_curterm(cur_term);
}

return n;
}

You should also link ncurses (which brings in a bit of cruft).
Kind regards,
Axel

On Mon, Jan 29, 2024 at 1:53 PM Axel Scheepers
 wrote:
>
> 1010...@bugs.debian.org
>
> On Thu, 26 May 2022 11:03:25 +0200 Axel Scheepers
>  wrote:
> > Or the other way around as I proposed. The entire problem of knowing what
> > and how to use color goes away when curses is used. Would you accept a
> > patch for using that instead?
>
> I've forgot about this but how about the following?
>
> #include 
> #include 
>
> int
> ncolors(void)
> {
> int ncolors = -1;
>
> if (setupterm(NULL, 1, NULL) == OK) {
> ncolors = tigetnum("colors");
> del_curterm(cur_term);
> }
>
> return ncolors;
> }
>
> This doesn't initialise the terminal so you can still do the
> progressbar without clearing the screen and/or use hardcoded ansi
> codes for colors if you want. It returns the number of colors for the
> used terminal or -1 if color is not supported. Maybe the progressbar
> should be optional in that case too. I think it would be a nice
> addition and one doesn't have to use apt-get  and/or apt-cache
> instead.
> Also, maybe using italics, bold and reverse video instead of colors
> can be considered? They usually do the right thing with either
> background. Anyway, I hope you can implement the above function to
> make at least monochrome and/or dumb terminals behave.
>
> Kind regards,
> Axel

Bug#1061767: mc not able to open/view rar files

[Torsten Wohlfarth]

Package: mc
Version: 3:4.8.30-1
Severity: normal
X-Debbugs-Cc: t...@siduction.org

Dear Maintainer,

mc is not able to open/view rar files.

   * What led up to the situation?

try to open a rar-file

   * What was the outcome of this action?

vfs errors an not seeing the content of that rar file

   * What outcome did you expect instead?

see the content of that rar-file

A little patch does get the ability of that back:

--- mc-4.8.30.orig/src/vfs/extfs/helpers/urar.in
+++ mc-4.8.30/src/vfs/extfs/helpers/urar.in
@@ -113,7 +113,7 @@ mcrar5fs_list ()
.
 mcrarfs_list ()
 {
-[ x$UNRAR_VERSION = x6 -o x$UNRAR_VERSION = x5 ] && mcrar5fs_list "$@" ||
mcrar4fs_list "$@"
+[ x$UNRAR_VERSION != x4 ] && mcrar5fs_list "$@" || mcrar4fs_list "$@"
 }
.
 mcrarfs_copyin ()


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

Kernel: Linux 6.8.0-rc2-siduction-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mc depends on:
ii  libc6 2.37-14
ii  libext2fs21.47.0-2+b1
ii  libglib2.0-0  2.78.3-2
ii  libgpm2   1.20.7-10+b2
ii  libslang2 2.3.3-3
ii  libssh2-1 1.11.0-4
ii  mc-data   3:4.8.30-2

Versions of packages mc recommends:
ii  mailcap 3.70+nmu1
ii  perl5.38.2-3
ii  sensible-utils  0.0.20
ii  unzip   6.0-28

Versions of packages mc suggests:
pn  arj  
ii  atril [pdf-viewer]   1.26.1-4
ii  bzip21.0.8-5+b2
pn  dbview   
ii  djvulibre-bin3.5.28-2+b1
pn  epub-utils   
ii  file 1:5.45-2+b1
ii  genisoimage  9:1.1.11-3.4
pn  gv   
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  libaspell-dev0.60.8.1-1+b1
ii  lynx 2.9.0rel.0-2
pn  odt2txt  
ii  okular [pdf-viewer]  4:23.08.1-2
ii  poppler-utils22.12.0-2+b1
pn  python   
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2023.20230311.66589-8
ii  unar 1.10.7+ds1+really1.10.1-2+b3
ii  w3m  0.5.3+git20230121-2+b2
pn  wimtools 
ii  zip  3.0-13

-- no debconf information

Bug#1061644: octave-dev: The package should include an ld.so.conf fragment pointing to the shared libraries

[Rafael Laboissière]

Control: tags -1 - moreinfo + confirmed

* Antony N. Donovan  [2024-01-28 21:44]:


Without the octave-dev.conf fragment in place, compile the attached file using

$ ​mkoctfile --link-stand-alone embedded.cc -o embedded

when I run created executable I see

 $ ./embedded
 ./embedded: error while loading shared libraries: liboctinterp.so.10: cannot 
open shared object file: No such file or directory

After putting octave-dev.conf in /etc/ld.so.conf.d and running ldconfig I see

 $ ./embedded
 Available Octave Graphics Toolkits:
 fltk
 gnuplot

Please let me know if you have any other questions or need anything else from 
me.


Thank you for the example. I can reproduce the issue and I am hereby 
tagging this bug report accordingly.


Best,

Rafael

Bug#1061678: passt: apparmor denies access to /run/user/$UID/libvirt/qemu/run/passt/

[Stefano Brivio]

Andi, thanks for reporting this.

Andrea,

On Sun, 28 Jan 2024 17:16:38 +0100
"Andreas B. Mundt"  wrote:

> Package: passt
> Version: 0.0~git20231230.f091893-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: a...@debian.org
> 
> Hi,
> 
> I tried to run a VM using libvirt with user mode networking and
> 'passt':
> …
> 
>   
>   
>   
> 
> …
> Starting the machine fails and the log shows:
>kernel: audit: type=1400 audit(1706457189.881:713): apparmor="DENIED" 
> operation="mknod" …
>libvirtd[752859]: internal error: Child process (passt --one-off
>--socket 
> /run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0.socket
>--pid 
> /run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0-passt.pid
>[…]
>PID file open: Permission denied

I was trying to find out why I don't hit this on my system, and there I
have, in /etc/apparmor.d/usr.sbin.libvirtd:

owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,

but at the end of the discussion we had back then, you submitted this
as part of the libvirt patch (then merged as commit 7a39b04d683f
"apparmor: Enable passt support"):

owner /{,var/}run/libvirt/qemu/passt/* rw,

which, I guess, only works when root uses virsh to start the guests.

I suppose we need both rules to cover both root and non-root cases?

> I guess the path to socket and pid file is not allowed from
> '/etc/apparmor.d/usr.bin.passt'. After 'aa-teardown' it works as
> expected.   
> 
> To Reproduce the issu:
>  passt --debug --one-off \
>   --socket /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0.socket 
> \
>   --pid /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0-passt.pid

Andi, this is actually expected: what passt(1) itself needs as AppArmor
is provided by its abstraction, /etc/apparmor.d/abstractions/passt.

This is sourced by /etc/apparmor.d/usr.bin.passt as an example of stand-alone
usage, as well as from /etc/apparmor.d/usr.sbin.libvirtd.

Then, in libvirtd's policy, specific rules cover the paths for socket
and PID files as needed by libvirtd itself. To solve this, we need a
change in libvirtd's policy. You can try adding:

owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,

in the 'profile passt' block of /etc/apparmor.d/usr.sbin.libvirtd, and
it should work.

> Thanks and best regards,
> 
>   Andi
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-5-amd64 (SMP w/4 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 passt depends on:
> ii  libc6  2.37-13
> 
> passt recommends no packages.
> 
> Versions of packages passt suggests:
> ii  apparmor  3.0.12-1+b2
> 
> -- no debconf information

-- 
Stefano

Bug#1061370: gcc-14 ftbfs on armel

[Luca Boccassi]

Control: affects -1 systemd

On Fri, 26 Jan 2024 20:10:40 +0100 Matthias Klose 
wrote:
> On 24.01.24 09:58, Emanuele Rocca wrote:
> > Hi Matthias,
> > 
> > On 2024-01-23 09:01, Matthias Klose wrote:
> >> This is a long standing, re-occurring issue which never has been
> >> forwarded and committed by the armel ports to GCC upstream.
> > 
> > You seem to be aware of previous occurrences of this issue. Please
share
> > the details you have available such as bug numbers, commits, and so
> > forth.
> > 
> > More in general though there have been several important issues
with
> > armel lately, not least the fact that there is very little hardware
> > still supported by the kernel (essentially just the Raspberry Pi
Zero
> > and 1 AIUI [0]). It seems to me that the time has come to seriously
> > consider whether supporting armel as an official port still makes
sense.
> > 
> > [0]
https://salsa.debian.org/kernel-team/linux/-/commit/b53e2d881063b060934bee3da9378da3b5b5387b
> > 
> 
> disabled ada, now ftbs with go.
> 
> if you care about the Pi Zero, then please get involved upstream. 
> Listening to ARM guys, armv5t doesn't seem to raise any interest
these days.
> 
> Also having LLVM build failures, still targeting armv4t didn't raise
any 
> attention to the Debian armel porters.
> 
> So let's just say there is no man power to address issues, and
probably 
> also lack of interest.

This causes systemd to FTBFS on armel since the new upload of
libatomic-14. No other architecture is affected.

cc  -o systemd-cryptsetup 
systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o 
systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o 
systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o 
systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed 
-Wl,--no-undefined -fstack-protector 
'-Wl,-rpath,$ORIGIN/src/shared:' 
-Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group 
src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so 
/usr/lib/arm-linux-gnueabi/libssl.so /usr/lib/arm-linux-gnueabi/libcrypto.so 
-Wl,--end-group -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common
/usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to 
`libat_test_and_set_1_i2'
collect2: error: ld returned 1 exit status

On the Bugzilla report a patch has been linked, would it be possible to
backport it, please?

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644147.html

-- 
Kind regards,
Luca Boccassi


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

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Michael Stone]

On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more 
confusion, and would make coreutils incompatible with FreeBSD again.


Reverting makes more sense than the current situation. I do not 
understand why you seem to value FreeBSD compatibility more than 
compatibility with the vast majority of installed coreutils/linux

systems.

Yes, it's not a good place to be. Surely current coreutils is better 
than what Debian is doing.


You've introduced a silent incompatibility and I'm trying to find some 
way to make that clear. If upstream would provide a better solution I 
would certainly use it. I have despaired of there being such since your 
attitude thus far seems to be entirely dismissive of compatibility 
concerns.


Another possibility is to add a warning that is emitted only at the 
end of 'cp'. The warning would occur only if the exit code differs 
because of this cp -n business.


You'd only emit a notification of a change in behavior if some 
(potentially uncommon/rarely encountered) situation arises which would 
actually trigger breakage? So people can't prepare ahead of time and 
change their script to handle the necessary change in logic, they can 
only maybe figure out why something broke at 2am when the uncommon event 
occurred?


At the end of the day, -n is basically a useless option with unknowable 
semantics which should be avoided by everyone. In the past it was an 
option which wasn't portable between coreutils/linux and freebsd systems, 
and I guess you've "fixed" that (by making it an option everyone should 
avoid entirely), but let's be honest about how common that concern was.

Bug#1061768: vulkan-loader: new upstream release 1.3.275.0

[Simon McVittie]

Source: vulkan-loader
Version: 1.3.268.0-1
Severity: wishlist

A new upstream release vulkan-sdk-1.3.275.0 is available.

smcv

Bug#718446: tracker-extract possibly prevents shutdown to complete

[Vincent Lefevre]

On 2013-07-31 23:41:49 +0200, Sebastian Niehaus wrote:
> Am 31.07.2013 23:15, schrieb Michael Biebl:
> 
> >> I suppose the other processes regarding NFS are okay to be running after 
> >> /etc/init.d/sendsigs but tracker-extract should have been finished. 
> > 
> > Are you using NFS for your $HOME directory?
> 
> No, $HOME is on the maschine's local disk.
> 
> The NFS file system however is mounted into one user's home like
> 
> /home/user1/nfs

IMHO, the process should stop immediately at shutdown and not try
to finish its task first.

When I upgraded a machine from stable to testing in December 2023,
tracker-extract was also preventing the shutdown (always, AFAIK),
and I had no NFS, just the local disk. However, in my case,
tracker-extract (gst-plugin-scan) was yielding a crash in nouveau

2023-12-19T03:10:02.176832+01:00 qaa tracker-extract-3[1967]: 
nvc0_screen_create:1077 - Error allocating PGRAPH context for M2MF: -16
2023-12-19T03:10:02.177550+01:00 qaa kernel: [ cut here 
]
2023-12-19T03:10:02.177568+01:00 qaa kernel: nouveau :01:00.0: timeout
[...]
2023-12-19T03:10:02.177710+01:00 qaa kernel: CPU: 3 PID: 1967 Comm: 
gst-plugin-scan Tainted: GW  6.5.0-5-amd64 #1  Debian 6.5.13-1

and gst-plugin-scan even survived SIGKILL:

[...]
2023-12-19T03:13:06.240298+01:00 qaa systemd[2079]: tracker-extract-3.service: 
State 'final-sigterm' timed out. Killing.
2023-12-19T03:13:06.240435+01:00 qaa systemd[2079]: tracker-extract-3.service: 
Killing process 2150 (gst-plugin-scan) with signal SIGKILL.
2023-12-19T03:13:40.973708+01:00 qaa kernel: INFO: task gst-plugin-scan:2150 
blocked for more than 120 seconds.
2023-12-19T03:13:40.973803+01:00 qaa kernel:   Tainted: GW  
6.5.0-5-amd64 #1 Debian 6.5.13-1
2023-12-19T03:13:40.973810+01:00 qaa kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
2023-12-19T03:13:40.973816+01:00 qaa kernel: task:gst-plugin-scan state:D 
stack:0 pid:2150  ppid:2079   flags:0x0006
[...]
2023-12-19T03:14:36.240345+01:00 qaa systemd[2079]: tracker-extract-3.service: 
Processes still around after final SIGKILL. Entering failed mode.
[...]

So perhaps in this particular case, there was nothing that could
be done on the tracker-extract side, but I'm wondering.

Since then, the nouveau issue has been fixed, but I had removed
tracker-extract earlier, and I didn't try again to see whether
the problem was solved about it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1061769: Unexpected VLAN behavior with KEA DHCP

[kristofer.hansson]

Package: kea-dhcp4-server
Version: 2.2.0-6

Hi, this version (and from what I believe all versions) of kea-dhcp4-server
(and probably kea-dhcp6-server) handles vlan tagged traffic in a quite
unintuitive way. When the server is set up in raw socket mode it will accept all
broadcasted DHCP requests regardless of VLAN tagging. It will then send a
response untagged, again regardless of initial VLAN tag. See below for a packet
trace where this happens.

This has been reported to the ISC team quite some time ago here:
https://gitlab.isc.org/isc-projects/kea/-/issues/1117.
A patch has been provided to the ISC team which they have not applied (I can't
say why): https://github.com/isc-projects/kea/pull/119.
The file that is patched has been more or less unchanged since the patch was
created and should still apply (it did for me on 2.2.0-6).

This behavior was not present in isc-dhcp-server as they filtered out VLAN
tagged broadcasts from what I can tell, so the behavior is changed between the
two DHCP server services.

As I see it there are two things that shouldn't happen here:
1. A DHCP server not explicitly configured to listen to VLAN traffic should not
   respond to that traffic.
2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should
   respond on the same VLAN network.

My suggestion would be to include the patch 
(https://github.com/isc-projects/kea/pull/119)
to filter out any tagged traffic, as this is inline with how dhcpd from
isc-dhcp-server worked.

Packet trace of a DHCP broadcast offer/request comming in on VLAN 20 and being
returned untagged.
$ tcpdump -evnni eth0 port bootps or port bootpc
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 
bytes
11:09:56.861903 98:90:96:c1:ff:a0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 346: vlan 20, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, 
id 60207, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:c1:ff:a0, length 300, xid 0xf7a80c8d, Flags [none]
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Parameter-Request (55), length 14:
  Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway 
(3), Domain-Name-Server (6)
  Hostname (12), Domain-Name (15), MTU (26), BR (28)
  Static-Route (33), Lease-Time (51), Server-ID (54), RN (58)
  RB (59), Unknown (119)
MSZ (57), length 2: 1472
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
SLP-NA (80), length 0""
Unknown (145), length 1: 1
11:09:56.862416 e2:82:0f:6b:8e:b9 > 98:90:96:c1:ff:a0, ethertype IPv4 (0x0800), 
length 341: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), 
length 327)
10.101.64.1.67 > 10.101.64.100.68: BOOTP/DHCP, Reply, length 299, xid 
0xf7a80c8d, Flags [none]
  Your-IP 10.101.64.100
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Subnet-Mask (1), length 4: 255.255.255.0
Default-Gateway (3), length 4: 10.101.64.1
Domain-Name-Server (6), length 4: 10.101.64.1
MTU (26), length 2: 1350
Lease-Time (51), length 4: 600
Server-ID (54), length 4: 10.101.64.1
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
11:09:56.862829 98:90:96:c1:ff:a0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 346: vlan 20, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, 
id 45786, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
98:90:96:c1:ff:a0, length 300, xid 0xf7a80c8d, Flags [none]
  Client-Ethernet-Address 98:90:96:c1:ff:a0
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Requested-IP (50), length 4: 10.101.64.100
DHCP-Message (53), length 1: Request
Server-ID (54), length 4: 10.101.64.1
Parameter-Request (55), length 14:
  Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway 
(3), Domain-Name-Server (6)
  Hostname (12), Domain-Name (15), MTU (26), BR (28)
  Static-Route (33), Lease-Time (51), Server-ID (54), RN (58)
  RB (59), Unknown (119)
MSZ (57), length 2: 1472
Client-ID (61), length 19: hardware-type 255, 
96:c1:ff:a0:00:01:00:01:2d:14:50:63:98:90:96:c1:ff:a0
Unknown (145), length 1: 1
11:09:56.864127 e2:82:0f:6b:8e:b9 > 98:90:96:c1:ff:a0, ethertype IPv4 (0x0800), 
length 341: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), 
length 327)
10.101.6

Bug#1061770: ipmitool: unsupported LAN parameter lookup command returns an error

[Frederic Van Espen]

Package: ipmitool
Version: 1.8.19-4
Severity: normal
Tags: patch upstream

Dear Maintainer,

Upstream version of ipmitool contains an unresolved issue:
https://github.com/ipmitool/ipmitool/issues/388

Personally seen this on an iLo4 BMC:
~# ipmitool -v lan print
Loading IANA PEN Registry...
IANA PEN registry open failed: No such file or directory
Running Get VSO Capabilities my_addr 0x20, transit 0, target 0
Invalid completion code received: Invalid command
Discovered IPMB address 0x0
Set in Progress : Set Complete
Auth Type Support   :
Auth Type Enable: Callback :
: User :
: Operator :
: Admin:
: OEM  :
IP Address Source   : Static Address
IP Address  : 10.0.4.24
Subnet Mask : 255.255.255.0
MAC Address : d0:67:26:9c:9f:23
SNMP Community String   : public
Get LAN Parameter 'IP Header' command failed: Unsupported parameter

As a consequence none of the other parameters are displayed.

Since the github repo is archived it does not look like a fix can be
expected upstream any time soon.

There's a patch available on a fork on github that fixes it for me:
https://github.com/Cray-HPE/ipmitool/commit/b7c0d66cd6b9eaf45648f6b2651b6ef5158de811

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

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

Versions of packages ipmitool depends on:
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
pn  libfreeipmi17  
ii  libreadline8   8.2-1.3
ii  libssl33.0.11-1~deb12u2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages ipmitool recommends:
pn  openipmi  

ipmitool suggests no packages.

Bug#1025559: fwupd: dependency on transitional policykit-1 package

[Diederik de Haas]

On Wed, 2 Aug 2023 16:44:39 +0100 Simon McVittie  wrote:
> Control: tags -1 + patch
> 
> On Tue, 06 Dec 2022 at 13:22:40 +, Simon McVittie wrote:
> > This package has a Depends and/or Build-Depends on the transitional
> > package policykit-1, which has been separated into polkitd, pkexec and
> > (deprecated) polkitd-pkla packages.
> 
> This package doesn't seem to use pkexec, so please consider the attached
> patch, also available as
> .

This MR was merged and AFAICT uploaded with version 1.9.7-1, so this bug
can/should be closed with that version?


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

Bug#718446: tracker-extract possibly prevents shutdown to complete

[Simon McVittie]

On Mon, 29 Jan 2024 at 15:22:31 +0100, Vincent Lefevre wrote:
> However, in my case,
> tracker-extract (gst-plugin-scan) was yielding a crash in nouveau
> 
> 2023-12-19T03:10:02.176832+01:00 qaa tracker-extract-3[1967]: 
> nvc0_screen_create:1077 - Error allocating PGRAPH context for M2MF: -16
> 2023-12-19T03:10:02.177550+01:00 qaa kernel: [ cut here 
> ]
> 2023-12-19T03:10:02.177568+01:00 qaa kernel: nouveau :01:00.0: timeout
> [...]
> 2023-12-19T03:10:02.177710+01:00 qaa kernel: CPU: 3 PID: 1967 Comm: 
> gst-plugin-scan Tainted: GW  6.5.0-5-amd64 #1  Debian 6.5.13-1

That's certainly a kernel/driver bug. In principle it should not be
possible for Tracker to cause a crash in kernel code (was this an OOPS
or a BUG message or what?), even if it wanted to do this intentionally.

> and gst-plugin-scan even survived SIGKILL:
> 
> [...]
> 2023-12-19T03:13:06.240298+01:00 qaa systemd[2079]: 
> tracker-extract-3.service: State 'final-sigterm' timed out. Killing.
> 2023-12-19T03:13:06.240435+01:00 qaa systemd[2079]: 
> tracker-extract-3.service: Killing process 2150 (gst-plugin-scan) with signal 
> SIGKILL.
> 2023-12-19T03:13:40.973708+01:00 qaa kernel: INFO: task gst-plugin-scan:2150 
> blocked for more than 120 seconds.

If it has got sufficiently wedged in kernel code that even SIGKILL won't
delete the process, then there isn't going to be anything further that
either Tracker or systemd can do to resolve that.

smcv

Bug#1061771: Can't hear other people on meet.google.com

[Jochen Sprickerhof]

Package: chromium
Version: 121.0.6167.85-1
Severity: normal

Hi,

I can't hear others on meet.google.com, though I hear the connected ping
and others seem to hear me as well. Also Jitsi works.
Downgrading to the version in testing makes it work again.

Cheers Jochen


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

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

Versions of packages chromium depends on:
ii  chromium-common121.0.6167.85-1
ii  libasound2 1.2.10-3
ii  libatk-bridge2.0-0 2.50.0-1+b1
ii  libatk1.0-02.50.0-1+b1
ii  libatomic1 14-20240127-1
ii  libatspi2.0-0  2.50.0-1+b1
ii  libc6  2.37-14
ii  libcairo2  1.18.0-1+b1
ii  libcups2   2.4.7-1+b1
ii  libdbus-1-31.14.10-4
ii  libdouble-conversion3  3.3.0-1+b1
ii  libdrm22.4.120-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2+b2
ii  libflac12  1.4.3+ds-2+b1
ii  libfontconfig1 2.14.2-6+b1
ii  libfreetype6   2.13.2+dfsg-1+b1
ii  libgbm123.3.4-1
ii  libgcc-s1  14-20240127-1
ii  libglib2.0-0   2.78.3-2
ii  libgtk-3-0 3.24.40-2
ii  libjpeg62-turbo1:2.1.5-2+b2
ii  libjsoncpp25   1.9.5-6+b2
ii  liblcms2-2 2.14-2
ii  libminizip11:1.3.dfsg-3+b1
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.96.1-1
ii  libopenh264-7  2.4.0+dfsg-1
ii  libopenjp2-7   2.5.0-2+b2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-4
ii  libpng16-161.6.40-3
ii  libpulse0  16.1+dfsg1-3
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 14-20240127-1
ii  libwebp7   1.3.2-0.3
ii  libwebpdemux2  1.3.2-0.3
ii  libwebpmux31.3.2-0.3
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.7-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.6.0-1
ii  libxml22.9.14+dfsg-1.3+b2
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages chromium recommends:
ii  chromium-sandbox  121.0.6167.85-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.37-14
ii  libjsoncpp25  1.9.5-6+b2
ii  libstdc++614-20240127-1
ii  libx11-6  2:1.8.7-1
ii  libxnvctrl0   525.125.06-1
ii  x11-utils 7.7+6
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   121.0.6167.85-1
ii  fonts-liberation   1:2.1.5-3
ii  libgl1-mesa-dri23.3.4-1
pn  libu2f-udev
pn  notification-daemon
pn  system-config-printer  
pn  upower 

Versions of packages chromium-sandbox depends on:
ii  libc6  2.37-14

-- no debconf information

Bug#1061772: RFP: jujutsu -- Git-compatible VCS that is both simple and powerful

[Antoine Beaupre]

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

* Package name: jujutsu
  Version : 0.13.0
  Upstream Contact: Martin von Zweigbergk 
* URL : https://martinvonz.github.io/jj/
* License : Apache-2.0
  Programming Lang: Rust
  Description : Git-compatible VCS that is both simple and powerful

Jujutsu is a powerful version control system for software
projects. You use it to get a copy of your code, track changes to the
code, and finally publish those changes for others to see and use. It
is designed from the ground up to be easy to use—whether you're new or
experienced, working on brand new projects alone, or large scale
software projects with large histories and teams.

Jujutsu is unlike most other systems, because internally it abstracts
the user interface and version control algorithms from the storage
systems used to serve your content. This allows it to serve as a VCS
with many possible physical backends, that may have their own data or
networking models—like Mercurial or Breezy, or hybrid systems like
Google's cloud-based design, Piper/CitC.

Today, we use Git repositories as a storage layer to serve and track
content, making it compatible with many of your favorite Git-based
tools, right now! All core developers use Jujutsu to develop Jujutsu,
right here on GitHub. But it should hopefully work with your favorite
Git forges, too.

We combine many distinct design choices and concepts from other
version control systems into a single tool. Some of those sources of
inspiration include:

 * Git: We make an effort to be fast—with a snappy UX, efficient
   algorithms, correct data structures, and good-old-fashioned
   attention to detail. The default storage backend uses Git
   repositories for "physical storage", for wide interoperability and
   ease of onboarding.

 * Mercurial & Sapling: There are many Mercurial-inspired features,
   such as the revset language to select commits. There is no explicit
   index or staging area. Branches are "anonymous" like Mercurial, so
   you don't need to make up a name for each small change. Primitives
   for rewriting history are powerful and simple. Formatting output is
   done with a robust template language that can be configured by the
   user.

 * Pijul & Darcs: Jujutsu keeps track of conflicts as first-class
   objects in its model; they are first-class in the same way commits
   are, while alternatives like Git simply think of conflicts as
   textual diffs. While not as rigorous as systems like Darcs and
   Pijul (which are based on a formalized theory of patches, as
   opposed to snapshots), the effect is that many forms of conflict
   resolution can be performed and propagated automatically.

And it adds several innovative, useful features of its own:

 * Working-copy-as-a-commit: Changes to files are recorded
   automatically as normal commits, and amended on every subsequent
   change. This "snapshot" design simplifies the user-facing data
   model (commits are the only visible object), simplifies internal
   algorithms, and completely subsumes features like Git's stashes or
   the index/staging-area.

 * Operation log & undo: Jujutsu records every operation that is
   performed on the repository, from commits, to pulls, to
   pushes. This makes debugging problems like "what just happened?" or
   "how did I end up here?" easier, especially when you're helping
   your coworker answer those questions about their repository! And
   because everything is recorded, you can undo that mistake you just
   made with ease. Version control has finally entered the 1960s!

 * Automatic rebase and conflict resolution: When you modify a commit,
   every descendent is automatically rebased on top of the
   freshly-modified one. This makes "patch-based" workflows a
   breeze. If you resolve a conflict in a commit, the resolution of
   that conflict is also propagated through descendants as well. In
   effect, this is a completely transparent version of git rebase
   --update-refs combined with git rerere, supported by design.

[!WARNING] The following features are available for use, but experimental; they 
may have bugs, backwards incompatible storage changes, and user-interface 
changes!

 * Safe, concurrent replication: Have you ever wanted to store your
   version controlled repositories inside a Dropbox folder? Or
   continuously backup repositories to S3? No? Well, now you can!

   The fundamental problem with using filesystems like Dropbox and
   backup tools like rsync on your typical Git/Mercurial repositories
   is that that they rely on local filesystem operations being atomic,
   serialized, and non-concurrent with respect to other reads and
   writes—which is not true when operating on distributed file
   systems, or when operations like concurrent file copies (for
   backup) happen while lock files are being held.

   Jujutsu is instead designed to be safe under concurr

Bug#1061773: tayga: Refuses to run with RFC 8215 prefix ("Cannot use reserved address")

[Darsey Litzenberger]

Package: tayga
Version: 0.9.2-8
Severity: normal

RFC 8215[1] allocates 64:ff9b:1::/48 as a block of well-known prefixes 
for networks that contain more than one NAT64 translator.  However, 
tayga refuses to run when one of those prefixes is configured.


For example, when "prefix 64:ff9b:1:fffe::/96" is specified in 
tayga.conf, it aborts with the following error message:


  Cannot use reserved address 64:ff9b:1:fffe::/96 in prefix directive, 
aborting...
  Starting userspace NAT64: tayga failed!

[1] https://tools.ietf.org/html/rfc8215

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

Kernel: Linux 6.1.0-16-amd64 (SMP w/1 CPU thread; 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 tayga depends on:
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
ii  sysvinit-utils [lsb-base]  3.06-4

tayga recommends no packages.

tayga suggests no packages.

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

-- no debconf information

Bug#996329: pal: re glib error(s)

[Oliver Schode]

Package: pal
Version: 0.4.3-9
Followup-For: Bug #996329

Actually appears to be the same bug as reported earlier. I don't think
it's important, the duplicate should be closed.

Interactive mode obviously got never fully implemented to put it mildly,
and what's left is aging badly. Not too surprising considering the
application is 20 years old, the current version about 15 and the
package is unmaintained. If the curses interface wasn't entirely useless
by now, its usefulness could still be doubted. It should have been left
out from the package, that would've also removed the ncurses
dependencies, perhaps glib's too. Pal is still doing its trick as a
simple command line utility, or what it originally was likely intented
to be. But that would probably call for a maintainer. At least it should
be made clear that the .pal files are supposed to be maintained
manually, it's easy to crash the whole thing from the TUI, not much
harder to garble your event files.

Regards,
Oliver

Bug#1061774: nmu: pngcheck_3.0.3-1

[Filip Hroch]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pngch...@packages.debian.org
Control: affects -1 + src:pngcheck

Dear Release Team,

may I ask you to rebuild pngcheck package against to
the current version of zlib?

I'm maintainer of fitspng package having bug #1059970,
and I found that the bug is not related on fitspng itself.
Actually, it is caused by pngcheck during CI tests
verification. The current binary of pngcheck is compiled
against an old zlib yet, and needs a recompilation.

A test run under sid (as well as trixie) has revealed:

   x@trixiesid:/tmp/xxx$ pngcheck hippo.png
   zlib warning:  different version (expected 1.2.13, using 1.3)

   OK: hippo.png (139x152, 24-bit RGB, non-interlaced, 38.7%).

The string can be identified as the part of the source of pngcheck.c
(https://salsa.debian.org/debian/pngcheck/-/blob/debian/master/pngcheck.c)
which compares versions of the run-time zlib and the zlib compiled in:
...
} else if (strcmp(zlib_version, ZLIB_VERSION) != 0) {
  fprintf(stderr, "zlib warning:  different version (expected %s,"
" using %s)\n\n", ZLIB_VERSION, zlib_version);
}
..
In my opinion, the test on a zlib version is greatly valuable,
although it may create doubts during those transitional phases.

Thank you,
FH

nmu pngcheck_3.0.3-1 . ANY . -m "Rebuild against a new version of zlib."

Bug#1061775: shlibs is stricter than it needs to be

[Steinar H. Gunderson]

Package: libzstd-dev
Version: 1.5.5+dfsg2-2
Severity: normal

Hi,

debian/rules contains

  dh_makeshlibs -plibzstd1 -V'libzstd1 (>= 1.5.5)' --add-udeb=libzstd1-udeb

Would it be possible to change it to 1.5.4? I don't see anything between 1.5.4
and 1.5.5 that would mean 1.5.5-built packages wouldn't work on 1.5.4,
and this would allow trixie-built .debs to be installable on bookworm.
(Of course, it would break if upstream truly introduces new APIs, but that's
fine.)

Ideally, of course, one would ship a .symbols file instead of .shlibs,
but that requires more careful tracking.


-- System Information:
Debian Release: 12.4
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.0 (SMP w/56 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libzstd-dev depends on:
ii  libzstd1  1.5.5+dfsg2-2

libzstd-dev recommends no packages.

libzstd-dev suggests no packages.

-- debconf-show failed

Bug#1061776: fail2ban: Wrong journalmatch for sshd jail

[Laurent Bigonville]

Package: fail2ban
Version: 1.0.2-2
Severity: serious
Tags: sid trixie bookworm

Hello,

The default journalmatch for ssh the following:

filter.d/sshd.conf: journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd

But the .service file for ssh in debian is called ssh.service, not 
sshd.service


If I run journalctl _SYSTEMD_UNIT=sshd.service  _COMM=sshd, I get no 
entries.


If I run journalctl _SYSTEMD_UNIT=ssh.service  _COMM=sshd , I get the logs

I think there are still something broken with the switch to journald

The configuration should be changed to: "_SYSTEMD_UNIT=ssh.service 
_COMM=sshd" IMVHO


Kind regards,

Laurent Bigonville

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Pádraig Brady]

On 29/01/2024 14:01, Michael Stone wrote:

On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:

I'm not sure reverting would be best. It would introduce more
confusion, and would make coreutils incompatible with FreeBSD again.


Reverting makes more sense than the current situation. I do not
understand why you seem to value FreeBSD compatibility more than
compatibility with the vast majority of installed coreutils/linux
systems.


Yes, it's not a good place to be. Surely current coreutils is better
than what Debian is doing.


You've introduced a silent incompatibility and I'm trying to find some
way to make that clear. If upstream would provide a better solution I
would certainly use it. I have despaired of there being such since your
attitude thus far seems to be entirely dismissive of compatibility
concerns.


That's a bit unfair.  The current upstream -n behavior is with a view
to being _more_ compat across all systems.
Now I agree this may not be worth it in this case,
but it is a laudable goal.


Another possibility is to add a warning that is emitted only at the
end of 'cp'. The warning would occur only if the exit code differs
because of this cp -n business.


You'd only emit a notification of a change in behavior if some
(potentially uncommon/rarely encountered) situation arises which would
actually trigger breakage? So people can't prepare ahead of time and
change their script to handle the necessary change in logic, they can
only maybe figure out why something broke at 2am when the uncommon event
occurred?


Yes I agree with this point, mostly.
Outputting a diagnostic would help users diagnose what's going on,
and help users to fix forward and avoid their problematic -n usage.
But yes, the crux of the issue with fixing issues as they occur,
is it depends on the state of the destination and so can become an issue
at any time.  Now I previously did an audit with github and debian code search
and noticed very few problematic uses of cp -n, but that does miss
the mountain of private code.


At the end of the day, -n is basically a useless option with unknowable
semantics which should be avoided by everyone. In the past it was an
option which wasn't portable between coreutils/linux and freebsd systems,
and I guess you've "fixed" that (by making it an option everyone should
avoid entirely), but let's be honest about how common that concern was.


Right, that's why I'm still leaning towards my proposal in the last mail.
  - revert to previous exit success -n behavior
  - document -n as deprecated
  - provide --update=noclobber to give exit failure functionality
- BTW, it probably makes sense to print a diagnostic for each skipped file 
here
  as it's exceptional behavior, for which we're exiting with failure for.
  - the existing --update=none provides the exit success functionality

With the above in place for the next coreutils release,
then debian could remove its noisy patch.

thanks,
Pádraig

Bug#1061370: gcc-14 ftbfs on armel

[Emanuele Rocca]

Hi Luca,

On 2024-01-29 01:33, Luca Boccassi wrote:
> This causes systemd to FTBFS on armel since the new upload of
> libatomic-14. No other architecture is affected.
> 
> cc  -o systemd-cryptsetup 
> systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o 
> systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o 
> systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o 
> systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed 
> -Wl,--no-undefined -fstack-protector 
> '-Wl,-rpath,$ORIGIN/src/shared:' 
> -Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group 
> src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so 
> /usr/lib/arm-linux-gnueabi/libssl.so /usr/lib/arm-linux-gnueabi/libcrypto.so 
> -Wl,--end-group -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common
> /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to 
> `libat_test_and_set_1_i2'
> collect2: error: ld returned 1 exit status

>From the build logs at [1] it seems that a mix of GCC 13 and 14 packages
was used, is this expected?

Toolchain package versions: binutils_2.41.90.20240122-1 dpkg-dev_1.22.4 
g++-13_13.2.0-10 gcc-13_13.2.0-10 libc6-dev_2.37-14 libstdc++-13-dev_13.2.0-10 
libstdc++6_14-20240127-1 linux-libc-dev_6.6.13-1

[1] 
https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=armel&ver=255.3-2&stamp=1706528229&raw=0

Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

[Michael Stone]

On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote:

You've introduced a silent incompatibility and I'm trying to find some
way to make that clear. If upstream would provide a better solution I
would certainly use it. I have despaired of there being such since your
attitude thus far seems to be entirely dismissive of compatibility
concerns.


That's a bit unfair.  The current upstream -n behavior is with a view
to being _more_ compat across all systems.
Now I agree this may not be worth it in this case,
but it is a laudable goal.


You are saying that again without explicitly acknowledging that "being 
_more_ compat" in this case means "becoming _incompat_ with the vast 
majority of installed systems". IMO it could be reasonably phrased as 
"being more compatible across all systems in the long term when all 
existing legacy systems are gone", but the key here is that I read 
"_more_ compat across all systems" as dismissing the coreutils installed 
base as part of "all systems". I understand that may not be/have been 
the intent, but I also can't help feeling the way that I do when the 
benefits of compatability with freebsd are repeatedly emphasized while 
the costs of incompatibility with the coreutils installed base are 
dismissed with something along the lines of "we'll see what breaks". (If 
the costs of incompatibility are really that low in this case, why would 
compatability be a worthwhile goal in this case?)


I do wish that more users had noticed the change earlier and that we're 
fairly deep into a mess, but it's not always easy to see the impact of 
what seems like a relatively minor patch. I do appreciate that the new 
version printed some diagnostics when the change was triggered, as that 
certainly helped call attention to scripts which were impacted.



With the above in place for the next coreutils release,
then debian could remove its noisy patch.


I would certainly align with that, and the sooner the better to decrease 
the chances that different distributions handle this in different ways 
or we get to the point of having to release in an interim state. If you 
commit a final version I'll apply that patch if the next release isn't 
imminent.

Bug#1061370: gcc-14 ftbfs on armel

[Luca Boccassi]

On Mon, 29 Jan 2024 at 16:38, Emanuele Rocca  wrote:
>
> Hi Luca,
>
> On 2024-01-29 01:33, Luca Boccassi wrote:
> > This causes systemd to FTBFS on armel since the new upload of
> > libatomic-14. No other architecture is affected.
> >
> > cc  -o systemd-cryptsetup 
> > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-keyfile.c.o 
> > systemd-cryptsetup.p/src_cryptsetup_cryptsetup.c.o 
> > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-pkcs11.c.o 
> > systemd-cryptsetup.p/src_cryptsetup_cryptsetup-tpm2.c.o -Wl,--as-needed 
> > -Wl,--no-undefined -fstack-protector 
> > '-Wl,-rpath,$ORIGIN/src/shared:' 
> > -Wl,-rpath-link,/home/bluca/systemd/foo/src/shared -Wl,--start-group 
> > src/shared/libsystemd-shared-255.so /lib/arm-linux-gnueabi/libcryptsetup.so 
> > /usr/lib/arm-linux-gnueabi/libssl.so 
> > /usr/lib/arm-linux-gnueabi/libcrypto.so -Wl,--end-group 
> > -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--warn-common
> > /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: undefined reference to 
> > `libat_test_and_set_1_i2'
> > collect2: error: ld returned 1 exit status
>
> From the build logs at [1] it seems that a mix of GCC 13 and 14 packages
> was used, is this expected?
>
> Toolchain package versions: binutils_2.41.90.20240122-1 dpkg-dev_1.22.4 
> g++-13_13.2.0-10 gcc-13_13.2.0-10 libc6-dev_2.37-14 
> libstdc++-13-dev_13.2.0-10 libstdc++6_14-20240127-1 linux-libc-dev_6.6.13-1
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=armel&ver=255.3-2&stamp=1706528229&raw=0

The package name is 'libatomic1' and it's not versioned after the GCC
major version like the rest, so it seems to be all working as
intended.

Bug#1061775: shlibs is stricter than it needs to be

[Peter Pentchev]

On Mon, Jan 29, 2024 at 04:58:47PM +0100, Steinar H. Gunderson wrote:
> Package: libzstd-dev
> Version: 1.5.5+dfsg2-2
> Severity: normal
> 
> Hi,
> 
> debian/rules contains
> 
>   dh_makeshlibs -plibzstd1 -V'libzstd1 (>= 1.5.5)' --add-udeb=libzstd1-udeb
> 
> Would it be possible to change it to 1.5.4? I don't see anything between 1.5.4
> and 1.5.5 that would mean 1.5.5-built packages wouldn't work on 1.5.4,
> and this would allow trixie-built .debs to be installable on bookworm.
> (Of course, it would break if upstream truly introduces new APIs, but that's
> fine.)

Hmmm, my understanding might be wrong, but when using dh_makeshlibs
directly without a symbols file, isn't it going to be a problem if
a program is built against libzstd 1.5.5 and it uses the new
ZSTD_CCtx_setFParams() function?

> Ideally, of course, one would ship a .symbols file instead of .shlibs,
> but that requires more careful tracking.

Now that is interesting. I actually prefer using symbols files for
shared libraries when possible for obvious reasons, but I was still
under the impression that the libzstd upstream build system was not
ready for that - see e.g.
  
https://salsa.debian.org/pkg-rpm-team/libzstd/-/commit/7f600c89ec9dffefd0017190313dbc9a050b8798
and, hence,
  https://github.com/facebook/zstd/pull/2501

...and I just realized that !2501 was merged back in version 1.5.1!
Huh. That's actually pretty cool, so now I can start using a symbols
file for libzstd, too!

OK, so since I still believe that lowering the version given to
dh_makeshlibs would break programs that use the two new functions in
1.5.5, what do you think about the idea to start using symbols files
instead? With some careful backporting (for my build purposes only),
I believe I could craft a symbols file that would go back all the way to
version 1.5.1. That's earlier than the 1.5.4 version in bookworm, so
I think it might still suit your goal?

Thanks for bringing this up - I really hadn't noticed that
the "really export symbols with care" merge request had been merged!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1040417: docker-compose V1 is depreciated

[Michael Kesper]

Dear maintainers,

On Wed, 16 Aug 2023 20:39:25 -0300 Leandro Cunha 
 wrote:

Hi,

I've been talking to one of them these days and he's been busy lately.
But he said next month he should work on it. I should see if I can
help with something too.


As this software is really critical regarding security and does not get 
ANY patches from upstream since May 2021 please remove it from Debian.


https://docs.docker.com/compose/migrate/#can-i-still-use-compose-v1-if-i-want-to

The final Compose V1 release, version 1.29.2, was May 10, 2021. These 
packages haven't received any security updates since then. Use at your 
own risk.


Best
Michael

Bug#1061775: shlibs is stricter than it needs to be

[Steinar H. Gunderson]

On Mon, Jan 29, 2024 at 06:42:41PM +0200, Peter Pentchev wrote:
> Hmmm, my understanding might be wrong, but when using dh_makeshlibs
> directly without a symbols file, isn't it going to be a problem if
> a program is built against libzstd 1.5.5 and it uses the new
> ZSTD_CCtx_setFParams() function?

If that function is new in 1.5.5, then indeed, yes. I didn't see that
from the changelog, but perhaps I misunderstood something or it just
flew under the radar.

> Huh. That's actually pretty cool, so now I can start using a symbols
> file for libzstd, too!

Nice!

> OK, so since I still believe that lowering the version given to
> dh_makeshlibs would break programs that use the two new functions in
> 1.5.5, what do you think about the idea to start using symbols files
> instead?

I fully agree this would be the best solution, yes, assuming manpower exists
for it. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1061774: nmu: pngcheck_3.0.3-1

[David da Silva Polverari]

On Mon, Jan 29, 2024 at 04:45:59PM +0100, Filip Hroch wrote:
> Dear Release Team,
> 
> may I ask you to rebuild pngcheck package against to
> the current version of zlib?
> 
> I'm maintainer of fitspng package having bug #1059970,
> and I found that the bug is not related on fitspng itself.
> Actually, it is caused by pngcheck during CI tests
> verification. The current binary of pngcheck is compiled
> against an old zlib yet, and needs a recompilation.
> 
In my opinion, there is no need for a rebuild. This is just a warning
that upstream deemed useful to include on the program. If tests are
failing because of that, I believe that fitspng tests are the ones that
should be updated to take that behaviour into account (using
allow-stderr and grepping for the 'OK', for example). If zlib's SONAME
hasn't changed, there's not need to link against a newer version.

Regards,
David

Bug#1061777: ITP: aresponses -- Asyncio response mocking. Similar to the responses library used for 'requests'

[Patrick ZAJDA]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: aresponses
  Version : 3.0.0
  Upstream Contact: Bryce Drennan 
* URL : https://github.com/aresponses/aresponses
* License : MIT/Copyright (c) 2016 CircleUp Network, Inc
  Programming Lang: Python
  Description : Asyncio response mocking. Similar to the responses library 
used for 'requests'

Aresponse is an asyncio testing server for mocking external services.
Features:
 - Fast mocks using actual network connections
 - allows mocking some types of network issues
 - use regular expression matching for domain, path, method, or body
 - works with https requests as well (by switching them to http requests)
 - works with callables

Compared to similar packages, documentation provides more instruction and usage 
is really easyer within less lines.
Flexibility is also right for this lib when needing to test connection using 
AIOHTTP and instructions are included in the documentation to use Aresmonse 
with aiohttp test framework.
I use it to test PySMSBoxNet [1].
[1]: https://github.com/Nardol/pysmsboxnet

I need a sponsor for this package, idealy I wish to maintain this package by 
being a member of the Python Team.

Best regards,

Patrick

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEF6TZmSao+HhR4xlgnUrTW+onPcoFAmW33BIACgkQnUrTW+on
PcqsGg/7BqDd9kDfIzP+Z0uhTVGhwT4I6s5JGq+8yVpXuH0YEVxzNId4bUtP+ZTG
58njDbxjIUC8MnZntbNpgkjHhXbXIUTJusxkMQMZpMIVW2FjYfnEWHywZXuhvAOR
aaFYV9OHnUARPg59/Q1YtDlBnja7sQkvMMGsGtbObBQbmINU3cUnO2h5//qPqaJZ
XzpwgFuhWuIef8Iz+Jce65eEz0xugQX5nE9jmM5XSUssQ/WJ6q24xVaCXsgDHUu5
kuqCo7byhjlDgVLNc0o9Aoeowih+aPLn1D1CQvIkdlT8jGPzXUg63O7d+Xy2VC/1
GTxNvQPk34PpctmfM6p3PiDFS+T/3ivwmUbSA45tC7SWSFolhihu+GV8hg+Rx3w5
6xvV3TjoCVxSX3FP5/73/SzYA1Y4ifgaL1fYQVL8i8YUFqhxlaJkc6Pc4x6RTlyw
Zt35IF0lc7FPmY+jQCcCk7oBhWGr4gjWqbmWjtGi4O+b3rSVgi4WgRRy6drb7u8J
i2a3+ZeWhZ4fdAlxJFq9eRlA7oEdoqM7IVRlsjVIrSrhrf0ektx71lPMRK4/fIKP
ZSYedj2uf7ikbXLf5A1UHN8VXNqx3ZNtDe1qXDXVY7XZQ/y/buLg3fuSRarhJIvp
Z4cMzD5ntB+ev+UhKgREy0CDpF05IQZPg2hf2vG11JAV6VUqslw=
=yU7j
-END PGP SIGNATURE-

Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1

[Adam D. Barratt]

On Sun, 2024-01-28 at 16:38 -0600, Timothy Pearson wrote:
> 
> > The version in the topic also implies a higher version than the
> > unstable upload, whereas the stable upload needs a lower version -
> > either -6.3+deb12u1 or -6.4~deb12u1 depending on whether you take
> > the
> > approach of adding the new patches on top of the existing stable
> > version, or backporting the unstable upload as a whole. It looks
> > like
> > the effect would be identical in this case afaict, so it's purely a
> > matter of preference.
> 
> I will useg -6.4~deb12u1 for simplicity, since we are tracking the
> unstable version in this update.  I inadvertently made an error in
> the bug report subject line.

Sorry for missing a detail here, but if you're going for that approach
then the changelog should follow the style it would for an upload to
backports - i.e. taking the unstable upload, including the changelog
entry for -6.4, and prepending a new stanza for -6.4~deb12u1 with an
entry similar to "Rebuild for bookworm". Does that make sense?

Regards,

Adam

Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1

[Timothy Pearson]

- Original Message -
> From: "Adam D. Barratt" 
> To: "Timothy Pearson" , "1061652" 
> <1061...@bugs.debian.org>
> Sent: Monday, January 29, 2024 11:21:44 AM
> Subject: Re: Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1

> On Sun, 2024-01-28 at 16:38 -0600, Timothy Pearson wrote:
>> 
>> > The version in the topic also implies a higher version than the
>> > unstable upload, whereas the stable upload needs a lower version -
>> > either -6.3+deb12u1 or -6.4~deb12u1 depending on whether you take
>> > the
>> > approach of adding the new patches on top of the existing stable
>> > version, or backporting the unstable upload as a whole. It looks
>> > like
>> > the effect would be identical in this case afaict, so it's purely a
>> > matter of preference.
>> 
>> I will useg -6.4~deb12u1 for simplicity, since we are tracking the
>> unstable version in this update.  I inadvertently made an error in
>> the bug report subject line.
> 
> Sorry for missing a detail here, but if you're going for that approach
> then the changelog should follow the style it would for an upload to
> backports - i.e. taking the unstable upload, including the changelog
> entry for -6.4, and prepending a new stanza for -6.4~deb12u1 with an
> entry similar to "Rebuild for bookworm". Does that make sense?
> 
> Regards,
> 
> Adam

Yes, that makes sense to me.  First time I'm proposing a new stable update
package that isn't a security update, so appreciate the patience and
assistance!diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog	2021-10-16 08:11:19.0 -0500
+++ rss-glx-0.9.1/debian/changelog	2024-01-29 11:26:00.0 -0600
@@ -1,3 +1,18 @@
+rss-glx (0.9.1-6.4~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for Bookworm (Closes: #1061652)
+
+ -- Timothy Pearson   Mon, 29 Jan 2024 11:26:00 -0600
+
+rss-glx (0.9.1-6.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
+(Closes: #1061507)
+  * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)
+
+ -- Timothy Pearson   Sat, 27 Jan 2024 08:41:00 -0600
+
 rss-glx (0.9.1-6.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/patches/glfinish.patch rss-glx-0.9.1/debian/patches/glfinish.patch
--- rss-glx-0.9.1/debian/patches/glfinish.patch	1969-12-31 18:00:00.0 -0600
+++ rss-glx-0.9.1/debian/patches/glfinish.patch	2024-01-25 10:43:27.0 -0600
@@ -0,0 +1,12 @@
+Index: rss-glx-0.9.1/src/driver.c
+===
+--- rss-glx-0.9.1.orig/src/driver.c
 rss-glx-0.9.1/src/driver.c
+@@ -238,6 +238,7 @@
+ 
+ 		if (drawEnabled) {
+ 			hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
++			glFinish();
+ 
+ 			glXSwapBuffers (XStuff->display, XStuff->window);
+ 		}
diff -Nru rss-glx-0.9.1/debian/patches/series rss-glx-0.9.1/debian/patches/series
--- rss-glx-0.9.1/debian/patches/series	2021-10-16 08:05:56.0 -0500
+++ rss-glx-0.9.1/debian/patches/series	2024-01-27 08:46:13.0 -0600
@@ -2,3 +2,4 @@
 pixelcity-cpp.patch
 readme.patch
 include-cstddef.patch
+glfinish.patch
diff -Nru rss-glx-0.9.1/debian/rules rss-glx-0.9.1/debian/rules
--- rss-glx-0.9.1/debian/rules	2011-05-27 10:01:25.0 -0500
+++ rss-glx-0.9.1/debian/rules	2024-01-27 08:45:36.0 -0600
@@ -15,12 +15,12 @@
 override_dh_auto_configure:
 	dh_auto_configure -- --with-configdir=/usr/share/xscreensaver/config \
 		--with-kdessconfigdir=/usr/share/kde4/services/ScreenSavers \
-		--bindir=/usr/lib/xscreensaver --enable-static=no \
+		--bindir=/usr/libexec/xscreensaver --enable-static=no \
 		LDFLAGS=-Wl,--as-needed
 
 override_dh_auto_install:
 	dh_auto_install
-	mv $(CURDIR)/debian/rss-glx/usr/lib/xscreensaver/rss-glx_install.pl \
+	mv $(CURDIR)/debian/rss-glx/usr/libexec/xscreensaver/rss-glx_install.pl \
 		$(CURDIR)/debian/rss-glx/usr/bin/rss-glx_install
 	cp $(CURDIR)/debian/desktop_files/*.desktop \
 		$(CURDIR)/debian/rss-glx/usr/share/applications/screensavers

Bug#1061778: RFS: vhba-module/20211218-1 [ITP] -- VHBA virtual host bus adapter module

[Matteo Bini]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vhba-module":

 * Package name : vhba-module
   Version  : 20211218-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : GPL-2+, CC0-1.0
   Section  : kernel

The source builds the following binary packages:

  vhba-dkms - VHBA virtual host bus adapter module

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

  https://mentors.debian.net/package/vhba-module/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vhba-module/vhba-module_20211218-1.dsc

Changes for the initial release:

 vhba-module (20211218-1) unstable; urgency=low
 .
   * Initial release, closes: #983402, #983403.

Regards,

-- 
Matteo Bini

Bug#1061779: RFS: libmirage/3.2.7-1 [ITP] -- CD-ROM image access library

[Matteo Bini]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : libmirage
   Version  : 3.2.7-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : GPL-2+, CC0-1.0
   Section  : libs

The source builds the following binary packages:

  libmirage11 - CD-ROM image access library
  gir1.2-mirage-3.2 - CD-ROM image access library (typelib files)
  libmirage11-dev - CD-ROM image access library (development files)
  libmirage11-doc - CD-ROM image access library (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libm/libmirage/libmirage_3.2.7-1.dsc

Changes for the initial release:

 libmirage (3.2.7-1) unstable; urgency=low
 .
   * Initial release, closes: #983444.

Regards,

-- 
Matteo Bini

Bug#718446: tracker-extract possibly prevents shutdown to complete

[Vincent Lefevre]

On 2024-01-29 15:03:44 +, Simon McVittie wrote:
> On Mon, 29 Jan 2024 at 15:22:31 +0100, Vincent Lefevre wrote:
> > However, in my case,
> > tracker-extract (gst-plugin-scan) was yielding a crash in nouveau
> > 
> > 2023-12-19T03:10:02.176832+01:00 qaa tracker-extract-3[1967]: 
> > nvc0_screen_create:1077 - Error allocating PGRAPH context for M2MF: -16
> > 2023-12-19T03:10:02.177550+01:00 qaa kernel: [ cut here 
> > ]
> > 2023-12-19T03:10:02.177568+01:00 qaa kernel: nouveau :01:00.0: timeout
> > [...]
> > 2023-12-19T03:10:02.177710+01:00 qaa kernel: CPU: 3 PID: 1967 Comm: 
> > gst-plugin-scan Tainted: GW  6.5.0-5-amd64 #1  Debian 
> > 6.5.13-1
> 
> That's certainly a kernel/driver bug. In principle it should not be
> possible for Tracker to cause a crash in kernel code (was this an OOPS
> or a BUG message or what?), even if it wanted to do this intentionally.

No OOPS / BUG messages, just "nouveau :01:00.0: timeout". Xorg
also triggered this error. This was due to missing symbolic links
in the firmware-misc-nonfree package:

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1061727: [Debichem-devel] Bug#1061727: gromacs: please add support for loong64

[Nicholas Breen]

On Mon, Jan 29, 2024 at 07:51:04AM +, wuruilong wrote:
> Source: gromacs
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
> The attached patch fixes the compilation error problem in the loong64 
> architecture, and the local compilation passes.

Thank you for working on this!  I think the patch would best be applied
upstream, for the benefit of all distributions.  They prefer to take
gitlab merge requests.  Is that something you'd be willing to submit
(you're certainly in a better position to answer questions!), or would
you like me to do so?

https://manual.gromacs.org/current/dev-manual/contribute.html



-- 
Nicholas Breen
nbr...@debian.org

Bug#1061780: python3-argcomplete: zsh support not in description

[Jakub Wilk]

Package: python3-argcomplete
Version: 3.1.4-1

The package description mentions only bash, but zsh is supported too 
since v3.0.



--
Jakub Wilk

Bug#1061774: nmu: pngcheck_3.0.3-1

[Sebastian Ramacher]

Control: reassign -1 fitspng 2.0-1
Control: retitle -1 fitspng: prints warnings on zlib updates

On 2024-01-29 13:56:14 -0300, David da Silva Polverari wrote:
> On Mon, Jan 29, 2024 at 04:45:59PM +0100, Filip Hroch wrote:
> > Dear Release Team,
> > 
> > may I ask you to rebuild pngcheck package against to
> > the current version of zlib?
> > 
> > I'm maintainer of fitspng package having bug #1059970,
> > and I found that the bug is not related on fitspng itself.
> > Actually, it is caused by pngcheck during CI tests
> > verification. The current binary of pngcheck is compiled
> > against an old zlib yet, and needs a recompilation.
> > 
> In my opinion, there is no need for a rebuild. This is just a warning
> that upstream deemed useful to include on the program. If tests are
> failing because of that, I believe that fitspng tests are the ones that
> should be updated to take that behaviour into account (using
> allow-stderr and grepping for the 'OK', for example). If zlib's SONAME
> hasn't changed, there's not need to link against a newer version.

The warning is mostly pointless for Debian. Minimum requirements are
expressed via dependencies and if zlib's ABI breaks it has to change its
SONAME.

Reassinging to fitspng.

Cheers
-- 
Sebastian Ramacher

Bug#1060275: asterisk: Codec translation notice

[List Support]

Le 27/01/2024 à 19:03, Jonas Smedegaard a écrit :

[...]

I went through debian asterisk source file and all patches, nowhere I
found nothing like "lost frames(s)". I thought third-party/resample
could be the missing part but as I didn´t find reference to it in the
stock asterisk source...

That phrase exists in debian/patches/2016_opus_plc.patch which is
derived from Xopus/enable_native_plc.patch which (thanks to
debian/watch) is fetched from original at
https://github.com/traud/asterisk-opus/blob/asterisk-13.7/enable_native_plc.patch


OK. Questions:

. what does mean plc ?

. opus is not used in my case so why I receive those notice ? (Reminder: 
allow=!all,g722,alaw,ulaw)


. asterisk-13.7 : can we still believe this patch is adapted to latest 
asterisk versions ?


. in src I see /* not DEBUG but NOTICE because of WARNING in 
main/cannel.c:__ast_queue_frame */


DEBUG should be more suitable but as I don´t understant above sentance ...

--
Daniel

Bug#1061688: rtl8821: WARNING: CPU: 37 PID: 1366 at drivers/iommu/dma-iommu.c:1091 iommu_dma_unmap_page+0x7d/0x90

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Jan 28, 2024 at 06:02:44PM +, Breno Leitao wrote:
> Package: src:linux
> Version: 6.6.13-1
> Severity: critical
> X-Debbugs-Cc: lei...@debian.org
> 
> 
> System is crashing from time to time with the most recent kernel
> (6.6.13).
> 
> I was able to get the last kernel messages, and it is related to
> dma-iommu. I am not sure why the system is crashing, since I didn't have
> kdump, but, there is a clear warning in the wifi driver.
> 
> 
>   Jan 28 17:05:21.414052 xeon kernel: Process accounting resumed
>   Jan 28 17:05:21.530027 xeon kernel: warning: `atop' uses wireless 
> extensions which will stop working for Wi-Fi 7 hardware; use nl80211
>   Jan 28 17:05:21.550117 xeon kernel: espeakup[1527]: memfd_create() 
> called without MFD_EXEC or MFD_NOEXEC_SEAL set
>   Jan 28 17:05:21.586066 xeon kernel: NET: Registered PF_QIPCRTR protocol 
> family
>   Jan 28 17:05:21.606106 xeon kernel: block nvme3n1: No UUID available 
> providing old NGUID
>   Jan 28 17:05:25.354046 xeon kernel: rfkill: input handler disabled
>   Jan 28 17:05:27.294079 xeon kernel: wlp134s0: authenticate with 
> 80:72:15:b4:aa:6d
>   Jan 28 17:05:27.694105 xeon kernel: wlp134s0: send auth to 
> 80:72:15:b4:aa:6d (try 1/3)
>   Jan 28 17:05:27.702030 xeon kernel: wlp134s0: authenticated
>   Jan 28 17:05:27.710089 xeon kernel: wlp134s0: associate with 
> 80:72:15:b4:aa:6d (try 1/3)
>   Jan 28 17:05:27.718085 xeon kernel: wlp134s0: RX AssocResp from 
> 80:72:15:b4:aa:6d (capab=0x1011 status=0 aid=6)
>   Jan 28 17:05:27.718145 xeon kernel: wlp134s0: associated
>   Jan 28 17:05:27.730080 xeon kernel: wlp134s0: Limiting TX power to 23 
> (23 - 0) dBm as advertised by 80:72:15:b4:aa:6d
>   Jan 28 17:05:31.799817 xeon systemd-journald[764]: 
> /var/log/journal/338f646113274ac1b9a4e000c0f8c95c/user-1000.journal: Journal 
> file uses a different sequence number ID, rotating.
>   Jan 28 17:05:32.074056 xeon kernel: rfkill: input handler enabled
>   Jan 28 17:05:33.862039 xeon kernel: rfkill: input handler disabled
>   Jan 28 17:05:45.370136 xeon kernel: logitech-hidpp-device 
> 0003:046D:406D.0008: HID++ 4.5 device connected.
>   Jan 28 17:40:26.302054 xeon kernel: rtlwifi: AP off, try to reconnect 
> now
>   Jan 28 17:40:26.302220 xeon kernel: wlp134s0: Connection to AP 
> 80:72:15:b4:aa:6d lost
>   Jan 28 17:40:30.661645 xeon kernel: wlp134s0: authenticate with 
> 80:72:15:b4:aa:6a
>   Jan 28 17:40:30.661756 xeon kernel: wlp134s0: 80 MHz not supported, 
> disabling VHT
>   Jan 28 17:40:30.680151 xeon kernel: wlp134s0: send auth to 
> 80:72:15:b4:aa:6a (try 1/3)
>   Jan 28 17:40:30.686063 xeon kernel: wlp134s0: authenticated
>   Jan 28 17:40:30.686136 xeon kernel: wlp134s0: associate with 
> 80:72:15:b4:aa:6a (try 1/3)
>   Jan 28 17:40:30.696593 xeon kernel: wlp134s0: RX AssocResp from 
> 80:72:15:b4:aa:6a (capab=0x1411 status=0 aid=2)
>   Jan 28 17:40:30.702085 xeon kernel: wlp134s0: associated
>   Jan 28 17:40:36.710058 xeon kernel: wlp134s0: deauthenticated from 
> 80:72:15:b4:aa:6a (Reason: 2=PREV_AUTH_NOT_VALID)
>   Jan 28 17:42:36.946218 xeon kernel: [ cut here ]
>   Jan 28 17:42:36.946357 xeon kernel: WARNING: CPU: 37 PID: 1366 at 
> drivers/iommu/dma-iommu.c:1091 iommu_dma_unmap_page+0x7d/0x90
>   Jan 28 17:42:36.946403 xeon kernel: Modules linked in: ccm 
> snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr binfmt_misc 
> intel_rapl_msr intel_rapl_common intel_uncore_frequency 
> intel_uncore_frequency_common isst_if_common skx_edac nfit libnvdimm 
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm rtl8821ae 
> btcoexist irqbypass rtl_pci ghash_clmulni_intel rtlwifi sha512_ssse3 
> sha256_ssse3 mac80211 sha1_ssse3 snd_hda_codec_realtek aesni_intel 
> snd_hda_codec_generic crypto_simd cryptd snd_hda_codec_hdmi ledtrig_audio 
> libarc4 snd_hda_intel rapl snd_intel_dspcfg snd_intel_sdw_acpi intel_cstate 
> snd_hda_codec cfg80211 snd_hda_core snd_hwdep iTCO_wdt snd_pcm rfkill 
> snd_timer intel_pmc_bxt mei_me intel_uncore iTCO_vendor_support snd pcspkr 
> ioatdma mei watchdog soundcore intel_pch_thermal dca joydev acpi_pad 
> acpi_power_meter sg evdev msr parport_pc ppdev lp parport loop nvme_fabrics 
> dm_mod efi_pstore configfs nfnetlink ip_tables x_tables autofs4 ext4 crc16 
> mbcache jbd2 crc32c_generic speakup_soft speakup hid_logitech_hidpp 
> hid_logitech_dj
>   Jan 28 17:42:36.946556 xeon kernel:  nouveau sr_mod hid_generic sd_mod 
> cdrom usbhid drm_exec hid gpu_sched video nvme i2c_algo_bit 
> drm_display_helper nvme_core cec t10_pi rc_core drm_ttm_helper ahci ttm 
> xhci_pci crc64_rocksoft drm_kms_helper crc64 libahci xhci_hcd crc_t10dif 
> libata crct10dif_generic drm mxm_wmi usbcore crc32_pclmul scsi_mod 
> crct10dif_pclmul i2c_i801 crc32c_intel crct10dif_common lpc_ich vmd i2c_smbus 
> usb_common scsi_common wmi button
>   

Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2024-01-29 at 11:30 -0600, Timothy Pearson wrote:
> 
> 
> - Original Message -
> > From: "Adam D. Barratt" 
> > To: "Timothy Pearson" , "1061652"
> > <1061...@bugs.debian.org>
> > Sent: Monday, January 29, 2024 11:21:44 AM
> > y for missing a detail here, but if you're going for that approach
> > then the changelog should follow the style it would for an upload
> > to
> > backports - i.e. taking the unstable upload, including the
> > changelog
> > entry for -6.4, and prepending a new stanza for -6.4~deb12u1 with
> > an
> > entry similar to "Rebuild for bookworm". Does that make sense?
> 
[...]
> Yes, that makes sense to me.  First time I'm proposing a new stable
> update package that isn't a security update, so appreciate the
> patience and assistance!

No problem, thanks for the quick follow-ups.

One final thing:

+  * Rebuild for Bookworm (Closes: #1061652)

Please don't close the release.d.o bug in your changelog - we'll close
it once the update is actually in stable, i.e. after a point release.

With the Closes: removed, please feel free to upload.

Regards,

Adam

Bug#1061781: ansible fails autopkg tests with Python 3.12 as the default

[Matthias Klose]

Package: src:ansible
Version: 7.7.0+dfsg-3
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]
297s 
297s 
297s  Running tests in ansible_collections/amazon/aws
297s 
297s 
297s This version of ansible-test cannot be executed with Python version 
3.12.1. Supported Python versions are: 3.9, 3.10, 3.11
297s autopkgtest [13:34:20]: test unit-tests-stable: 
---]

298s unit-tests-stableFAIL non-zero exit status 1
298s autopkgtest [13:34:21]: test unit-tests-stable:  - - - - - - - - - 
- results - - - - - - - - - -
298s autopkgtest [13:34:21]: test unit-tests-stable:  - - - - - - - - - 
- stderr - - - - - - - - - -
298s This version of ansible-test cannot be executed with Python version 
3.12.1. Supported Python versions are: 3.9, 3.10, 3.11

298s autopkgtest [13:34:21]:  summary

Bug#1061782: ansible-core fails its autopkg tests with Python 3.12

[Matthias Klose]

Package: src:ansible-core
Version: 2.14.13-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]
231s autopkgtest [13:33:12]: test unit: [---
231s This version of ansible-test cannot be executed with Python version 
3.12.1. Supported Python versions are: 3.9, 3.10, 3.11

231s autopkgtest [13:33:12]: test unit: ---]
231s autopkgtest [13:33:12]: test unit:  - - - - - - - - - - results - - 
- - - - - - - -

231s unit FAIL non-zero exit status 1
232s autopkgtest [13:33:13]: test unit:  - - - - - - - - - - stderr - - 
- - - - - - - -
232s This version of ansible-test cannot be executed with Python version 
3.12.1. Supported Python versions are: 3.9, 3.10, 3.11

232s autopkgtest [13:33:13]:  summary
232s unit FAIL non-zero exit status 1

Bug#1061783: apprise fails its autopkg tests with Python 3.12

[Matthias Klose]

Package: src:apprise
Version: 1.7.1-1
Severity: important
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]
523s === FAILURES 
===
523s  test_apprise_trans_add 


523s
523s @pytest.mark.skipif(
523s 'gettext' not in sys.modules, reason="Requires gettext")
523s def test_apprise_trans_add():
523s """
523s API: Apprise() Gettext add
523s
523s """
523s
523s # This throws internally but we handle it gracefully
523s al = AppriseLocale.AppriseLocale()
523s with environ('LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG'):
523s # English is the default/fallback type
523s >   assert al.add('en') is True
523s E   AssertionError: assert False is True
523s E+  where False = >('en')
523s E+where > = 
.add

523s
523s test/test_apprise_translations.py:212: AssertionError
523s === short test summary info 

523s SKIPPED [1] test/test_plugin_glib.py:48: Skipping dbus-python based 
tests

523s SKIPPED [1] test/test_plugin_syslog.py:42: Skipping syslog based tests
523s SKIPPED [1] test/test_apprise_translations.py:232: Unique Windows 
test cases

523s SKIPPED [1] test/test_asyncio.py:44: Requires Python 3.0 to 3.6
523s SKIPPED [1] test/test_plugin_fcm.py:905: Requires that cryptography 
NOT be installed

523s SKIPPED [1] test/test_plugin_growl.py:73: Requires gntp
523s SKIPPED [1] test/test_plugin_growl.py:131: Requires gntp
523s SKIPPED [1] test/test_plugin_growl.py:327: Requires gntp
523s SKIPPED [1] test/test_plugin_mqtt.py:86: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:126: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:160: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:179: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:195: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:215: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:223: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:233: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:265: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:288: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:306: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:323: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:338: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:354: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:370: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:390: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_mqtt.py:410: Requires that `paho-mqtt` 
is installed
523s SKIPPED [1] test/test_plugin_simplepush.py:120: Requires that 
cryptography NOT be installed
523s SKIPPED [1] test/test_plugin_windows.py:193: Requires win32api, 
win32con, and win32gui
523s FAILED test/test_apprise_translations.py::test_apprise_trans_add - 
AssertionE...
523s == 1 failed, 423 passed, 27 skipped in 44.44s 
==

Bug#1061229: numpydoc: Failing autopkgtest

[s3v]

Hi,

"-W" option in [1] leads to treat warnings as errors during
documentation build.
I guess is safe to remove this option for downstream users.

Thanks for your work.

Kind Regards

[1] 
https://sources.debian.org/src/numpydoc/1.6.0-1/numpydoc/tests/tinybuild/Makefile/#L8

Bug#1060275: asterisk: Codec translation notice

[Jonas Smedegaard]

Quoting List Support via Pkg-voip-maintainers (2024-01-29 19:02:57)
> 
> Le 27/01/2024 à 19:03, Jonas Smedegaard a écrit :
> > [...]
> >> I went through debian asterisk source file and all patches, nowhere I
> >> found nothing like "lost frames(s)". I thought third-party/resample
> >> could be the missing part but as I didn´t find reference to it in the
> >> stock asterisk source...
> > That phrase exists in debian/patches/2016_opus_plc.patch which is
> > derived from Xopus/enable_native_plc.patch which (thanks to
> > debian/watch) is fetched from original at
> > https://github.com/traud/asterisk-opus/blob/asterisk-13.7/enable_native_plc.patch
> 
> OK. Questions:
> 
> . what does mean plc ?

The purpose of the patch is described at the top of the patch itself.


> . opus is not used in my case so why I receive those notice ? (Reminder: 
> allow=!all,g722,alaw,ulaw)

If you do not use opus, then configure your Asterisk instance to not
*load* the module which you don't want.


> . asterisk-13.7 : can we still believe this patch is adapted to latest 
> asterisk versions ?
> 
> . in src I see /* not DEBUG but NOTICE because of WARNING in 
> main/cannel.c:__ast_queue_frame */
> 
> DEBUG should be more suitable but as I don´t understant above sentance ...

I don't know which severity is more suitable for that code.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1061784: ariba fails its autopkg tests with Python 3.12

[Matthias Klose]

Package: src:ariba
Version: 2.14.7+ds-1
Severity: important
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]

333s No containers need to be restarted.
333s
333s No user sessions are running outdated binaries.
333s
333s No VM guests are running outdated hypervisor (qemu) binaries on 
this host.
338s (Reading database ... 119216 files and directories currently 
installed.)

338s Removing autopkgtest-satdep (0) ...
339s autopkgtest [13:35:08]: test test-example: [---
342s Traceback (most recent call last):
342s   File "/usr/bin/ariba", line 3, in 
342s import ariba
342s   File "/usr/lib/python3/dist-packages/ariba/__init__.py", line 57, 
in 

342s from ariba import *
342s   File "/usr/lib/python3/dist-packages/ariba/assembly.py", line 6, 
in 
342s from ariba import common, mapping, bam_parse, external_progs, 
ref_seq_chooser
342s   File "/usr/lib/python3/dist-packages/ariba/mapping.py", line 3, 
in 

342s from distutils.version import LooseVersion
342s ModuleNotFoundError: No module named 'distutils'
343s autopkgtest [13:35:12]: test test-example: ---]
343s test-example FAIL non-zero exit status 1
343s autopkgtest [13:35:12]: test test-example:  - - - - - - - - - - 
results - - - - - - - - - -

343s autopkgtest [13:35:12]:  summary
343s test-example FAIL non-zero exit status 1

Bug#1061785: automake-1.16 fails its autopkg tests with Python 3.12

[Matthias Klose]

Package: src:automake-1.16
Version: 1:1.16.5-1.3
Severity: important
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]
3716s PASS: t/programs-primary-rewritten.sh
3716s FAIL: t/py-compile-basic.sh
3717s FAIL: t/py-compile-basedir.sh
3717s FAIL: t/py-compile-destdir.sh
3717s PASS: t/py-compile-env.sh
3717s FAIL: t/py-compile-option-terminate.sh
3717s PASS: t/py-compile-usage.sh
3719s PASS: t/python.sh
3722s PASS: t/python2.sh
3724s FAIL: t/python3.sh
3726s FAIL: t/python10.sh
3727s PASS: t/python11.sh
3730s FAIL: t/python12.sh
3731s PASS: t/python-am-path-iftrue.sh
3733s PASS: t/python-missing.sh
3733s PASS: t/python-too-old.sh
3735s PASS: t/python-dist.sh
3738s FAIL: t/python-prefix.sh
3746s PASS: t/python-vars.sh
3749s FAIL: t/python-virtualenv.sh
3751s FAIL: t/python-pr10995.sh
3756s PASS: t/recurs-user.sh