Bug#1061543: indent: CVE-2024-0911

[Moritz Muehlenhoff]

On Fri, Jan 26, 2024 at 08:48:47PM +0100, Santiago Vila wrote:
> severity 1061543 important
> found 1061543 2.2.12-1
> found 1061543 2.2.12-4+deb12u2
> thanks
> 
> El 26/1/24 a las 8:52, Moritz Mühlenhoff escribió:
> > Source: indent
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: normal
> > Tags: security
> > 
> > Hi,
> > 
> > This was assigned CVE-2024-0911:
> > https://lists.gnu.org/archive/html/bug-indent/2024-01/msg1.html
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> [...]
> 
> Thanks for the report.
> 
> I've just applied the (code part of the) patch for unstable.
> 
> Can you confirm that proposed-updates is good enough to fix this in stable?
> (i.e. no DSA, like other recent previous indent CVEs).

Confirmed :-)

Cheers,
Moritz

Bug#1061660: liblwp-protocol-https-perl: Fail to verify certificates

[Christian Marillat]

On 28 janv. 2024 19:03, gregor herrmann  wrote:

> On Sun, 28 Jan 2024 18:44:02 +0100, Christian Marillat wrote:
>
>> > Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1
>> > from testing? If yes, which of the two hunks from [0] is causing the
>> > problem?
>> This issue doesn't exist with 6.11-1. I've seen this bug when 6.12 has
>> been installed.
>
> What doesn't help is that I've uploaded libio-socket-ssl-perl 2.085-1
> as well … (Although with minimal changes as well.)

Could you try to reprocduce this bug with the svt-av1 package ?

>> The attached patch isn't clean :
>
> Sorry, that was a diff of the upstream git tags.

This diff fix this issue.

Christian

Bug#1061727: gromacs: please add support for loong64

[wuruilong]

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.

wuruilong

-- 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=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 gromacs (2023.3-1) unstable; urgency=medium
 .
   * New upstream release.
 - Remove erfinv-portability.patch, included in this release.
Author: Nicholas Breen 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-01-29

--- gromacs-2023.3.orig/src/gromacs/hardware/architecture.h
+++ gromacs-2023.3/src/gromacs/hardware/architecture.h
@@ -46,12 +46,13 @@ namespace gmx
 //! Enum for GROMACS CPU hardware detection support
 enum class Architecture
 {
-Unknown, //!< Not one of the cases below
-X86, //!< X86
-Arm, //!< ARM
-PowerPC, //!< IBM PowerPC
-RiscV32, //!< 32-bit RISC-V
-RiscV64  //!< 64-bit RISC-V
+Unknown,//!< Not one of the cases below
+X86,//!< X86
+Arm,//!< ARM
+PowerPC,//!< IBM PowerPC
+RiscV32,//!< 32-bit RISC-V
+RiscV64,//!< 64-bit RISC-V
+Loongarch64 //!< 64-bit Loongarch   
 };
 
 //! Whether the compilation is targeting 32-bit x86.
@@ -81,6 +82,8 @@ static constexpr Architecture c_architec
 Architecture::RiscV32;
 #elif defined __riscv && defined __riscv_xlen && (__riscv_xlen == 64)
 Architecture::RiscV64;
+#elif defined __loongarch__ && defined __loongarch64
+   Architecture::Loongarch64;
 #else
 Architecture::Unknown;
 #endif
--- gromacs-2023.3.orig/src/gromacs/hardware/cpuinfo.cpp
+++ gromacs-2023.3/src/gromacs/hardware/cpuinfo.cpp
@@ -785,6 +785,9 @@ CpuInfo::Vendor detectProcCpuInfoVendor(
 { "riscv64", CpuInfo::Vendor::RiscV64 },
 { "riscv32", CpuInfo::Vendor::RiscV32 },
 { "riscv", CpuInfo::Vendor::RiscV32 }, // Must come after riscv64 to 
avoid misidentification
+   { "Loongson", CpuInfo::Vendor::Loongson },
+   { "loongarch64", CpuInfo::Vendor::Loongson },
+   { "loong64", CpuInfo::Vendor::Loongson },
 };
 
 // For each label in /proc/cpuinfo, compare the value to the name in the
@@ -1038,6 +1041,10 @@ CpuInfo CpuInfo::detect()
 {
 result.vendor_ = CpuInfo::Vendor::RiscV64;
 }
+else if (c_architecture == Architecture::Loongarch64)
+{
+result.vendor_ = CpuInfo::Vendor::Loongson;
+}
 
 #if defined __aarch64__ || (defined _M_ARM && _M_ARM >= 8)
 result.features_.insert(Feature::Arm_Neon);  // ARMv8 always has 
Neon
@@ -1100,6 +1107,7 @@ const std::string& CpuInfo::vendorString
 { Vendor::Hygon, "Hygon" },
 { Vendor::RiscV32, "RISC-V 32" },
 { Vendor::RiscV64, "RISC-V 64" },
+{ Vendor::Loongson, "Loongarch" },
 };
 
 return vendorStrings.at(vendor_);
--- gromacs-2023.3.orig/src/gromacs/hardware/cpuinfo.h
+++ gromacs-2023.3/src/gromacs/hardware/cpuinfo.h
@@ -88,6 +88,7 @@ public:
 Hygon,   //!< HygonGenuine
 RiscV32, //!< RISC-V 32 bit
 RiscV64, //!< RISC-V 64 bit
+Loongson,//!< Loongson
 };
 
 /*! \brief List of CPU features
--- gromacs-2023.3.orig/src/gromacs/timing/include/gromacs/timing/cyclecounter.h
+++ gromacs-2023.3/src/gromacs/timing/include/gromacs/timing/cyclecounter.h
@@ -138,6 +138,9 @@ typedef unsigned long long gmx_cycle
 
 typedef unsigned long gmx_cycles_t;
 
+#elif defined(__loongarch__) && defined(__GNUC__)
+typedef unsigned long long gmx_cycles_t;
+
 #else
 /*! \brief Integer-like datatype for cycle counter values
  *
@@ -394,6 +397,13 @@ static __inline gmx_cycles_t gmx_cycles_
 return ret;
 }
 
+#elif defined __loongarch__ && __loongarch64
+static __inline gmx_cycles_t gmx_cycles_read(void)
+{
+gmx_cycles_t ret;
+asm volatile("rdtime.d %0, $r0" : "=r"(ret));
+return ret;
+}
 
 #else
 
@@ -565,6 +575,14 @@ static __inline__ bool gmx_cycles_have_c

Bug#1059568: RFS: swaykbdd/1.4-1 -- Per-window keyboard layout switching daemon for Sway

[Tobias Frost]

Control: tags -1 moreinfo

Hi Sepi,

Am Thu, Dec 28, 2023 at 04:48:34PM +0200 schrieb Sepi Gair:
> I am looking for a sponsor for my package "swaykbdd":
> 
>  * Package name : swaykbdd
>Version  : 1.4-1
>Upstream contact : Artem Senichev 
>  * URL  : https://github.com/artemsen/swaykbdd
>  * License  : Expat
>  * Vcs  : https://salsa.debian.org/spg/swaykbdd
>Section  : x11

d/changelog needs to document every change you make on the packaging,
there are several undoucmented changes.

Remove the moreinfo tag when this has been fixed, and I'll upload the
package.

-- 
Cheers,
tobi

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-01-29 00:12:27)
> Maybe this bug report should cloned and reassigned to sbuild-qemu?

if you like (for example because you want to subscribe to it and notified when
it gets closed) then feel free to clone it. Personally, as long as the issue is
tracked some place obvious (and that includes a salsa MR) I'm fine with it as I
just want to make sure that the issue is not getting lost. Whether it gets
tracked in the debian bts or as a salsa MR dosen't matter to me. But as i said,
if for you, a bts issue makes more sense, feel free to clone.

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-01-29 00:07:08)
> What's *your* umask? Is it Debian default (022), by chance?

yes.

> This seems to work with Debian default umask (022):
> 
>   $ printf '%o\n' "$(( 0666 - 00022 ))"
>   644
> 
> but fails whenever a umask includes an octal digit equal to 7, due to
> the carryover:
> 
>   $ printf '%o\n' "$(( 0666 - 7 ))"
>   657
> 
> Shouldn't this use the bitwise AND combined with the bitwise NOT?
> 
>   $ umask
>   0007
>   $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
>   660
>   $ umask 022
>   $ umask
>   0022
>   $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
>   644
> 
> I would think that mmdebstrap-autopkgtest-build-qemu should run:
> 
>   chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"
> 
> Does it make sense to you?

I now have this locally. Is this attribution (name/email) correct?

>From 8410dc6636817c4e02cf9eba090a70051c494c48 Mon Sep 17 00:00:00 2001
From: Francesco Poli 
Date: Mon, 29 Jan 2024 08:28:53 +0100
Subject: [PATCH] mmdebstrap-autopkgtest-build-qemu: fix octal mode computation

---
 mmdebstrap-autopkgtest-build-qemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mmdebstrap-autopkgtest-build-qemu 
b/mmdebstrap-autopkgtest-build-qemu
index 5684cbe..1ed14db 100755
--- a/mmdebstrap-autopkgtest-build-qemu
+++ b/mmdebstrap-autopkgtest-build-qemu
@@ -357,7 +357,7 @@ echo "mmdebstrap $*"
 mmdebstrap "$@" || die "mmdebstrap failed"
 
 unshare -U -r --map-groups=auto chown 0:0 "$IMAGE"
-chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
+chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"
 
 echo "root=LABEL=autopkgtestvm rw console=ttyS0" > "$WORKDIR/cmdline"
 
-- 
2.39.2

> > Can you list some reasons why qcow2 should be preferred over
> > raw images?
> 
> 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.

I'm asking because I'm not the expert. :)

I asked in #debian-devel and f_g (Fabian Grünbichler) commented that the main
reasoning for choosing qcow over raw images is snapshot, link clone and backing
image support.

I don't think these features are useful for users of autopkgtest or sbuild with
these images. Or do you see a use for them in this area?

Thanks!

cheers, josch

signature.asc
Description: signature

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

[Paul Eggert]

On 2024-01-28 05:22, Pádraig Brady wrote:

At this stage it seems best for us go back to the original Linux 
behiavor (use case 3),
and to silently deprecate -n in docs to document the portability issues 
with it.


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


The recent Debian change indicates that their intent is to move to the 
FreeBSD behavior too. This would improve cross-platform portability and 
I don't think we should discourage that.




  $ cp -n /bin/true tmp
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead

This is problematic as:

  - It's noisy


Yes that's a problem, and I doubt whether we should mimic Debian.


  - There is no way to get the behavior of indicating failure if existing files 
present


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



  - The --update=none advice is only portable to newer coreutils


True, but that's not a deal-killer. No advice that we give can be 100% 
portable to all platforms.



We should also provide --update=noclobber for use case 1.
Having the control on the --update option, allows use to more clearly 
deprecate -n.


Adding an --update=noclobber sounds like a good thing to do.

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. We could stretch things a bit and have a 
configure-time option --enable-compat-warnings that builders like Debian 
could use if they want such warnings.

Bug#1061726: golang-github-drone-envsubst: please provide envsubst tool

[Bartosz Fenski]

Source: golang-github-drone-envsubst
Version: 1.0.3-3
Severity: wishlist

Dear Maintainer,

That library comes with envsubst tool which can be used separately in 
various scripts.


Please provide envsubst binary package with that tool.

regards

Bartosz Fenski

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

[Martin Pitt]

Package: libvirt-daemon
Version: 10.0.0-1

When creating a trivial VM and doing an external snapshot if the VM is *not* 
running,
deleting the snapshot fails. As root:

  qemu-img create -f qcow2 /var/lib/libvirt/images/test1.qcow2 10G
  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test1 --disk target=vda,path=/var/lib/libvirt/images/test1.qcow2
  virsh destroy test1
  virsh snapshot-create-as --domain test1 --name snap1 --disk-only --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap1
  virsh snapshot-delete test1 snap1

The last command fails with

| error: Failed to delete snapshot snap1
| error: internal error: unable to execute QEMU command 'block-commit': Could 
not open '/var/lib/libvirt/images/test1.qcow2': Permission denied

The error message may be a bit misleading -- this is the *image* file, which
has wide-open libvirt-qemu:libvirt-qemu 666 permissions. "test1-snap1" in the
same directory is much more restrictive root:root 644; but even trying to
chown/chmod that doesn't unbreak this. So perhaps it's trying to do something
funky to the actual image file after all.

It also happens with the automatically created disk image, which will then be
IDE "hda", not virtio "vda":

  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test2
  virsh destroy test2
  virsh snapshot-create-as --domain test2 --name snap1 --disk-only --diskspec 
hda,snapshot=external,file=/var/lib/libvirt/images/test2-snap1
  virsh snapshot-delete test2 snap1

It works when doing a snapshot from a *running* VM, either disk-only or with 
memory:

  virsh start test1
  virsh snapshot-create-as --domain test1 --name snap2 --disk-only --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap2
  virsh snapshot-create-as --domain test1 --name snap3 --memspec 
file=/var/lib/libvirt/qemu/snapshot/test1-snap3-memory  --diskspec 
vda,snapshot=external,file=/var/lib/libvirt/images/test1-snap3

Then both snap2 and snap3 can be deleted. But still not snap1, so the running
state matters at the time of snapshot creation, not deletion.

This also happens with libvirt 9.0.0-4 in Debian stable and libvirt
8.0.0-1ubuntu7.8 in Ubuntu 22.04 LTS, but curiously not with libvirt
9.6.0-1ubuntu1 in Ubuntu 23.10. It also works fine in Fedora, CentOS/RHEL 8/9,
and Arch Linux, so this is somehow specific to Debian.

I tried `aa-teardown` just in case it's apparmor, but that doesn't seem to
influence it.

There is no useful/relevant journal message about this other than the
"Permission denied" line that's already on stderr.

I also tried this as user:

  virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 
--wait 0 --name test1
  virsh destroy test1
  virsh snapshot-create-as --domain test1 --name snap1 --disk-only --diskspec 
hda,snapshot=external,file=$HOME/.local/share/libvirt/images/test1-snap1
  virsh snapshot-delete test1 snap1

This works as well. So this is specific to qemu:///system, session works fine.

Martin

Bug#1061687: u-boot-menu: Prevents kernel installation/removal when removed without purging

[Johannes Schauer Marin Rodrigues]

Hi,

On Sun, 28 Jan 2024 19:00:25 +0100 Tomasz Rybak  wrote:
> I'm running MNT Reform, so using non-Debian kernel. The rest of packages are
> from Debian.

hello, fellow Reform user. :)

> I'm not sure which solution would be better:
> a) Move required file from /usr/share to /etc (e.g. /etc/default?)
> b) leave it in /usr/share but mark as conffile.

The correct solution is

  c) check whether u-boot-menu was uninstalled before running this script and 
exit 0 otherwise

I implemented this here: 
https://salsa.debian.org/debian/u-boot-menu/-/merge_requests/15

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1061706: ITP: distrobuilder -- System container image builder for LXC and Incus

[Johannes Schauer Marin Rodrigues]

Hi,

On Sun, 28 Jan 2024 20:29:30 + Mathias Gibbens  wrote:
>  distrobuilder is an image building tool for LXC and Incus.

independent on whether this is packaged or not, could you complete the entry
for distrobuilder in this table?

https://wiki.debian.org/SystemBuildTools#General_tools

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1061724: time: Exit status not correct when program dies on signal

[Ulrich Wittenberg]

Package: time
Version: 1.9-0.1
Severity: important
X-Debbugs-Cc: ulrich.wittenb...@web.de

Dear Maintainer,

   * What led up to the situation?
 I profiled a program that allocated too much memory.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The program was killed by the OOM killer
   * What was the outcome of this action?
 time reported an exit status of zero
   * What outcome did you expect instead?
 I expected a negative value like the built-in time command

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

Kernel: Linux 5.10.0-27-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages time depends on:
ii  libc6  2.31-13+deb11u7

time recommends no packages.

time suggests no packages.

-- no debconf information

Ulrich Wittenberg
Senior Software Developer | KISTERS Oldenburg
Germany
M
T +49 441 93602 -156
ulrich.wittenb...@kisters.de
www.kisters.de

[cid:image001.png@01DA5289.868CE9F0]


Ulrich Wittenberg - Energy - KISTERS AG - Haselriege 13 - 26125 Oldenburg - DE 
| +49 441 93602 -156 | ulrich.wittenb...@kisters.de | www.kisters.de | 
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | 
Aufsichtsratsvorsitzender: Dr. Thomas Klevers
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorised 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.

Bug#1044055: Reopen

[Andreas Tille]

Control: reopen -1

I wrongly assumed that this issue has vanished.  Thus reopening the bug.

-- 
http://fam-tille.de

Bug#1061723: src:obs-studio: fails to migrate to testing for too long: FTBFS on ppc64el

[Paul Gevers]

Source: obs-studio
Version: 29.1.3+dfsg-2
Severity: serious
Control: close -1 30.0.2+dfsg-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1061420

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:obs-studio has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on ppc64el as reported in bug 1061420.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=obs-studio



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061722: src:graph-tool: fails to migrate to testing for too long: FTBFS on ppc64el

[Paul Gevers]

Source: graph-tool
Version: 2.58+ds-1
Severity: serious
Control: close -1 2.59+ds-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1060786

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:graph-tool has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build as reported in bug 1060786.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=graph-tool



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061421: Fails to start after an upgrade

[duck]

Control: tag -1 +help

Quack,

On 2024-01-24 19:04, Arto Jantunen wrote:


After a semi-recent upgrade (I'm not sure which one, as I don't reboot
or restart my session after each one) of testing wlgreet no longer
starts. Here is what I get when trying to start it under a manually
launched sway session:


Thanks for the report.
I stumbled onto the same problem but so far was not able to identify 
what's going on. Rebuilding the package does not help.
I guess it's related to libraries that are loaded dynamically, possibly 
mesa, but it does not seem like an ABI breakage.

I'll try to dig deeper but l’m open to suggestion.

Regards.
\_o<

--
Marc Dequènes

Bug#1061721: src:fortunes-it: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: fortunes-it
Version: 2.2-1
Severity: serious
Control: close -1 2.2-2
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:fortunes-it has been trying to migrate for 
31 days [2]. Hence, I am filing this bug.


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


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


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


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=fortunes-it



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061712: initramfs-tools: initramfs hooks do not seem to work on kernels above linux 6.5 (e.g. 6.6 or 6.7)

[Safir Secerovic]

Yes, this explains it.

I modified my omit kernel module hook and it works like a charm.

Thank You so much Bastian!
This bug report can be closed.

On Mon, Jan 29, 2024 at 12:02 AM Bastian Blank  wrote:

> Hi Safir
>
> On Sun, Jan 28, 2024 at 11:21:05PM +, Safir Secerovic wrote:
> > I have a custom hook that omits a kernel module being built into an
> initrd image.
>
> So it is a bug in your hook itself?
>
> > Until kernels 6.6 and above, the hook does not seem to take effect.
> > The module is not omitted from initrd image...
>
> So it matches modules in filename alone.  And since 6.6 the modules are
> compressed and named "module.ko.xz".
>
> Bastian
>
> --
> It is a human characteristic to love little animals, especially if
> they're attractive in some way.
> -- McCoy, "The Trouble with Tribbles", stardate 4525.6
>

Bug#1061712: initramfs-tools: initramfs hooks do not seem to work on kernels above linux 6.5 (e.g. 6.6 or 6.7)

[Bastian Blank]

Hi Safir

On Sun, Jan 28, 2024 at 11:21:05PM +, Safir Secerovic wrote:
> I have a custom hook that omits a kernel module being built into an initrd 
> image.

So it is a bug in your hook itself?

> Until kernels 6.6 and above, the hook does not seem to take effect.
> The module is not omitted from initrd image...

So it matches modules in filename alone.  And since 6.6 the modules are
compressed and named "module.ko.xz".

Bastian

-- 
It is a human characteristic to love little animals, especially if
they're attractive in some way.
-- McCoy, "The Trouble with Tribbles", stardate 4525.6

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

[Gayathri Berli]

Hi Debian folks,



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 mailto: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 
mailto:jfale...@redhat.com>>

 There is one open issues in pixman regarding to this commit changes which 
effecting the big-endian systems.

https://gitlab.freedesktop.org/pixman/pixman/-/issues/78

https://gitlab.freedesktop.org/pixman/pixman/-/issues/72


Thanks,

Gayathri

Bug#1061712: Acknowledgement (initramfs-tools: initramfs hooks do not seem to work on kernels above linux 6.5 (e.g. 6.6 or 6.7))

[Safir Secerovic]

Upon further testing with XanMod Kernel [1], version 6.7.2, initramfs-tools
package is
functioning properly.

So, this bug could be attributed to official Debian kernel images, 6.6 and
6.7 (in experimental).

I guess this bug could be closed now, and a new bug against
linux-image-amd64/etc.. could be opened instead.

Kind regards

[1] https://xanmod.org/

On Sun, Jan 28, 2024 at 5:27 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1061712:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061712.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian kernel team 
>
> If you wish to submit further information on this problem, please
> send it to 1061...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1061712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061712
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1061595: Debian Live 12.4.0 AMD64 Xfce Fails to Start Its Graphical Environment

[Professor Jeebs]

Thank you Johnathan / Steve,

It is working. Please feel free to close the bug report!

Turns out that it was either failing hardware (an old-ish HP laptop I am
becoming acquainted with for a family member), or more likely a failing
USB stick, with the definite possibility of a mix of both, though the
RAM in here seems fine :)

Your suggestions were perfect. This is why I love Debian and its
community. Technical excellence, and friendly-quick non-AI responses. I
admit I had already tried the suggestions, then wrote the bug report
from memory later that night. Please excuse the minor typos.

Summary of what was done, if it may help another person in the future:

After writing, `sync`. Then, `udisks2 power-off --block-device
`. And, even, replugging the stick, checking `head -c
 | sha512sum`, just to make sure it matched the signed and
verified checksum of the Debian Live Xfce image that was originally
downloaded. All of that checked out perfectly. So, it did throw me off
with the weird results I was observing. Besides the fail-safe kernel
panic, I was also occasionally receiving squashfs errors that went
previously unmentioned.

Whatever was, or is, wrong seems to be on my end.

More:

USB stick is a 16GB MOSDART, and instead of simply zeroing out its
original contents, I ran a `shred -n 1 /dev/xxx` on it... I know. Bad
for a solid state medium. I also have had no previous experience with
this brand. I am reasonably sure the problem has nothing to do with the
brand of pendrive, but compatibility can be a funny thing sometimes.

Thanks Again,

Professor Jeebs

Bug#1006531: [debian-mysql] Bug#1006531:

[Otto Kekäläinen]

Thanks!

This is pending now at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66

Bug#1057491: Additional information

[tony mancill]

On Fri, Jan 05, 2024 at 09:07:28PM +1300, Vladimir Petko wrote:
> [1] https://salsa.debian.org/java-team/beansbinding/-/merge_requests/3

Uploaded.  Thank you for the patch.

Bug#1061203: Ardour - GTK2 removal

[Robin Gareus]

Upcoming Ardour 8.3 no longer depends on GTK[mm]2.4.
It still depends on glibmm-2.4 (>=2.32.0) which is available in trixie.

We hope to release Ardour 8.3 (https://git.ardour.org/ardour/ardour) 
sometime mid February 2023, and it would be nice if DDs could check 
feasibility of packaging it beforehand.


see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967257


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053428: RFP: k9s -- Kubernetes CLI To Manage Your Clusters In Style!

[Daniel Echeverri]

Hello!

Thanks for starting with this! I don't have high golang skills but I really
want to help [1] :)

Regards.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061720
-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1061720: ITP: grype -- A vulnerability scanner for container images and filesystems

[Daniel Echeverri]

Package: wnpp
Owner: Daniel Echeverri 
Severity: wishlist

* Package name : grype
* Version : 0.74.3
* Upstream Author : Anchore, Inc.
* URL or Web page : https://github.com/anchore/grype
* License : ASL-2.0
* Description : A vulnerability scanner for container images and
filesystems.

Scan the contents of a container image or filesystem to find known
vulnerabilities.
Find vulnerabilities for major operating system packages:
- Alpine
- Amazon Linux
- BusyBox
- CentOS
- CBL-Mariner
- Debian
- Distroless
- Oracle Linux
- Red Hat (RHEL)
- Ubuntu
Find vulnerabilities for language-specific packages:
- Ruby (Gems)
- Java (JAR, WAR, EAR, JPI, HPI)
- JavaScript (NPM, Yarn)
- Python (Egg, Wheel, Poetry, requirements.txt/setup.py files)
- Dotnet (deps.json)
- Golang (go.mod)
- PHP (Composer)
- Rust (Cargo)
- Supports Docker, OCI and Singularity image formats.

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Here's the patchFrom 68fcfefd5ce34d4423d5a6b9e23ad4a4ec620378 Mon Sep 17 00:00:00 2001
From: Arnaud Rebillout 
Date: Mon, 29 Jan 2024 11:12:02 +0700
Subject: [PATCH] Add Kali to the list of distros with a merged-usr layout

---
 debian/bug-script| 4 
 debian/dpkg.postinst | 4 
 debian/rules | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/bug-script b/debian/bug-script
index 92b933da1..c690b12b6 100644
--- a/debian/bug-script
+++ b/debian/bug-script
@@ -30,6 +30,10 @@ check_merged_usr_via_aliased_dirs()
 # Ubuntu does not seem interested in it.
 return
 ;;
+  kali)
+# Kali neither.
+return
+;;
   esac
 
   for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
diff --git a/debian/dpkg.postinst b/debian/dpkg.postinst
index 113c8d53a..becfaafc8 100644
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -39,6 +39,10 @@ check_merged_usr_via_aliased_dirs()
 # Ubuntu does not seem interested in it.
 return
 ;;
+  kali)
+# Kali neither.
+return
+;;
   esac
 
   for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
diff --git a/debian/rules b/debian/rules
index f4b923542..0f56f4b0d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -89,7 +89,7 @@ override_dh_bugfiles:
 override_dh_compress:
 	dh_compress -Xspec/
 
-ifeq (,$(filter $(DEB_VENDOR),Debian Ubuntu))
+ifeq (,$(filter $(DEB_VENDOR),Debian Kali Ubuntu))
 execute_after_dh_install:
 	dh_install -pdpkg usr/sbin/dpkg-fsys-usrunmess
 
-- 
2.43.0

Bug#1061719: libqt6gui6:amd64: QT_QPA_PLATFORM=xcb doesn't seem to work

[Janusz S . Bień]

Package: libqt6gui6
Version: 6.4.2+dfsg-10
Severity: normal
X-Debbugs-Cc: none, Janusz S. Bień 
File: /usr/lib/x86_64-linux-gnu/qt6/plugins/platforms/libqxcb.so

A program which works correctly on X is crippled on Wayland, one of the
panels is not opened. I was advised to use xcb, but it does not have any
effect.

More information at the thread:

https://forum.qt.io/topic/154144/debian-after-upgrading-the-system-the-program-became-unusable-how-to-approach-the-problem/13?_=1706499698799

BTW, when reporting this problem with Emacs debian-bug I got a strange
warning that libqt6gui6 is not installed although apt install reports
"libqt6gui6 is already the newest version (6.4.2+dfsg-10)." Quite
possible that my QT installation is somehow messed up (I use it only for
compiling two QT programs). qtchooser reports 7 versions: 4 5 default
qt4-x86_64-linux-gnu qt4 qt5-x86_64-linux-gnu qt5. QTCreator reports
5.15.8 twice: /usr/lib/qt5/bin/qmake and
/usr/lib/x86_64-linux-gnu/qt5/bin/qmake.

I will appreciate your help

JSB

-- 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/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 libqt6gui6:amd64 depends on:
ii  fontconfig  2.14.1-4
ii  libc6   2.36-9+deb12u3
ii  libdrm2 2.4.114-1+b1
ii  libegl1 1.6.0-1
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libglx0 1.6.0-1
ii  libharfbuzz0b   6.0.0+dfsg-3
ii  libice6 2:1.0.10-1
ii  libinput10  1.22.1-1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libmd4c00.4.8-1
ii  libmtdev1   1.1.6-1
ii  libopengl0  1.6.0-1
ii  libpng16-16 1.6.39-2
ii  libqt6core6 [qt6-base-abi]  6.4.2+dfsg-10
ii  libqt6dbus6 6.4.2+dfsg-10
ii  libsm6  2:1.2.3-1
ii  libstdc++6  12.2.0-14
ii  libts0  1.22-1+b1
ii  libudev1252.19-1~deb12u1
ii  libx11-62:1.8.4-2+deb12u2
ii  libx11-xcb1 2:1.8.4-2+deb12u2
ii  libxcb-glx0 1.15-1
ii  libxcb-icccm4   0.4.1-1.1
ii  libxcb-image0   0.4.0-2
ii  libxcb-keysyms1 0.4.0-1+b2
ii  libxcb-randr0   1.15-1
ii  libxcb-render-util0 0.3.9-1+b1
ii  libxcb-render0  1.15-1
ii  libxcb-shape0   1.15-1
ii  libxcb-shm0 1.15-1
ii  libxcb-sync11.15-1
ii  libxcb-xfixes0  1.15-1
ii  libxcb-xkb1 1.15-1
ii  libxcb1 1.15-1
ii  libxkbcommon-x11-0  1.5.0-1
ii  libxkbcommon0   1.5.0-1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages libqt6gui6:amd64 recommends:
pn  qt6-gtk-platformtheme  
ii  qt6-qpa-plugins6.4.2+dfsg-10

libqt6gui6:amd64 suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Package: dpkg
Version: 1.22.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Guillem,

Kali Linux is a rolling distro based on Debian testing. We go with a
merged-usr layout for a while now, and therefore with patch away the
warning message regarding merged-usr-via-aliased-dirs. We also don't
install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.

Please find attached a patch that adds Kali to the list of distros with
a usr-merged layout, along Debian and Ubuntu.

Thanks for your consideration,

Arnaud

Bug#1061717: 4ti2: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: 4ti2
Version: 1.6.10+ds-1.1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
4ti2 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for 4ti2
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru 4ti2-1.6.10+ds/debian/changelog 4ti2-1.6.10+ds/debian/changelog
--- 4ti2-1.6.10+ds/debian/changelog 2023-07-15 14:23:50.0 +
+++ 4ti2-1.6.10+ds/debian/changelog 2024-01-29 03:41:47.0 +
@@ -1,3 +1,10 @@
+4ti2 (1.6.10+ds-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 29 Jan 2024 03:41:47 +
+
 4ti2 (1.6.10+ds-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 4ti2-1.6.10+ds/debian/control 4ti2-1.6.10+ds/debian/control
--- 4ti2-1.6.10+ds/debian/control   2023-07-15 13:32:01.0 +
+++ 4ti2-1.6.10+ds/debian/control   2024-01-29 03:41:47.0 +
@@ -30,7 +30,10 @@
  .
  This package provides the 4ti2 tool suite.
 
-Package: lib4ti2-0
+Package: lib4ti2-0t64
+Provides: ${t64:Provides}
+Replaces: lib4ti2-0
+Breaks: lib4ti2-0 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
diff -Nru 4ti2-1.6.10+ds/debian/lib4ti2-0.install 
4ti2-1.6.10+ds/debian/lib4ti2-0.install
--- 4ti2-1.6.10+ds/debian/lib4ti2-0.install 2023-07-15 13:18:30.0 
+
+++ 4ti2-1.6.10+ds/debian/lib4ti2-0.install 1970-01-01 00:00:00.0 
+
@@ -1,2 +0,0 @@
-usr/lib/*/lib4ti2*.so.*
-usr/lib/*/libzsolve.so.*
diff -Nru 4ti2-1.6.10+ds/debian/lib4ti2-0.lintian-overrides 
4ti2-1.6.10+ds/debian/lib4ti2-0.lintian-overrides
--- 4ti2-1.6.10+ds/debian/lib4ti2-0.lintian-overrides   2023-07-15 
13:18:30.0 +
+++ 4ti2-1.6.10+ds/debian/lib4ti2-0.lintian-overrides   1970-01-01 
00:00:00.0 +
@@ -1,5 +0,0 @@
-# The upstream team manage mathematically impossible intermediate computations
-# with exit(3); this sounds as a clumsy DEBUG policy rather than a design
-# issue, but still an issue that has to be fixed by the upstream team itself:
-# a request was sent to the upstream team -- Jerome Benoit 

-exit-in-shared-library
diff -Nru 4ti2-1.6.10+ds/debian/lib4ti2-0t64.install 
4ti2-1.6.10+ds/debian/lib4ti2-0t64.install
--- 4ti2-1.6.10+ds/debian/lib4ti2-0t64.install  1970-01-01 00:00:00.0 
+
+++ 4ti2-1.6.10+ds/debian/lib4ti2-0t64.install  2023-07-15 13:18:30.0 
+
@@ -0,0 +1,2 @@
+usr/lib/*/lib4ti2*.so.*
+usr/lib/*/libzsolve.so.*
diff -Nru 4ti2-1.6.10+ds/debian/lib4ti2-0t64.lintian-overrides 
4ti2-1.6.10+ds/debian/lib4ti2-0t64.lintian-overrides
--- 4ti2-1.6.10+ds/debian/lib4ti2-0t64.lintian-overrides1970-01-01 
00:00:00.0 +
+++ 4ti2-1.6.10+ds/debian/lib4ti2-0t64.lintian-overrides2024-01-29 
03:41:47.0 +
@@ -0,0 +1,6 @@
+# The upstream team manage mathematically impossible intermediate computations
+# with exit(3); this sounds as a clumsy DEBUG policy rather than a design
+# issue, but still an issue that has to be fixed by the upstream team itself:
+# a request was sent to the upstream team -- Jerome Benoit 

+exit-in-shared-library

Bug#1061716: clang-16: unable to find standard headers like

[Nick Lewycky]

Subject: clang-16: unable to find standard headers like 
Package: clang-16
Version: 1:16.0.6-19
Severity: normal

This broke recently:

```
$ echo '#include ' > cassert.cc
$ c++ cassert.cc
cassert.cc:1:10: fatal error: 'cassert' file not found
#include 
 ^
1 error generated.
```

My c++ is an /etc/alternatives pointer to /usr/bin/clang++ which is a 
symlink to /usr/lib/llvm-16/bin/clang++ .


```
$ c++ -v
Debian clang version 16.0.6 (19)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.7.4
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.5.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14
Candidate multilib: .;@m64
Selected multilib: .;@m64
```

Here's the clang -cc1 invocation, this shows the results of the driver 
search:


```
$ c++ -### cassert.cc
Debian clang version 16.0.6 (19)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
 "/usr/lib/llvm-16/bin/clang" "-cc1" "-triple" "x86_64-pc-linux-gnu" 
"-emit-obj" "-mrelax-all" "-disable-free" "-clear-ast-before-backend" 
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name" 
"cassert.cc" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" 
"-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" 
"-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" 
"-target-cpu" "x86-64" "-tune-cpu" "generic" "-mllvm" 
"-treat-scalable-fixed-error-as-warning" "-debugger-tuning=gdb" 
"-fcoverage-compilation-dir=/home/nicholas" "-resource-dir" 
"/usr/lib/llvm-16/lib/clang/16" "-internal-isystem" 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++" 
"-internal-isystem" 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/x86_64-linux-gnu" 
"-internal-isystem" 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/backward" 
"-internal-isystem" "/usr/lib/llvm-16/lib/clang/16/include" 
"-internal-isystem" "/usr/local/include" "-internal-isystem" 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../x86_64-linux-gnu/include" 
"-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" 
"-internal-externc-isystem" "/include" "-internal-externc-isystem" 
"/usr/include" "-fdeprecated-macro" 
"-fdebug-compilation-dir=/home/nicholas" "-ferror-limit" "19" 
"-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" 
"-fcolor-diagnostics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" 
"/tmp/cassert-0fb9fc.o" "-x" "c++" "cassert.cc"
 "/usr/bin/ld" "-pie" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" 
"-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" 
"a.out" "/lib/x86_64-linux-gnu/Scrt1.o" "/lib/x86_64-linux-gnu/crti.o" 

Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig

[Nathan Scott]

On Mon, Jan 1, 2024 at 1:47 AM Chris Hofstaedtler  wrote:
> [..]
>
> I see you've uploaded two new upstream versions since this bug was
> filed. Is there anything blocking inclusion of Helmut's patch?
>

Thank you for the reminder and thanks for the patch Helmut.
I'll get this into the next update (pcp-6.2.0 expected late next week).

cheers.

--
Nathan

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

[Harlan Lieberman-Berg]

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
From 9d9fc8e0a1b46af0c9bf13e7ff982af1b9e15c07 Mon Sep 17 00:00:00 2001
From: Harlan Lieberman-Berg 
Date: Sun, 28 Jan 2024 20:56:58 -0500
Subject: [PATCH] Ensure stock configs are installed (Closes: #1061692)

---
 debian/install | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/install b/debian/install
index d2033f8..af982ac 100644
--- a/debian/install
+++ b/debian/install
@@ -2,3 +2,4 @@ chirp/share/chirp.png /usr/share/pixmaps
 chirp/share/chirp.desktop /usr/share/applications
 chirp/share/*.png /usr/share/chirp
 chirp/locale/* /usr/lib/python3/dist-packages/chirp/locale
+chirp/stock_configs /usr/lib/python3/dist-packages/chirp
-- 
2.43.0

Bug#1052866: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Scott Talbert]

On Sun, 28 Jan 2024, Andreas Tille wrote:


Hi,

I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.


I suspect the issue is because dh-python is clobbering the *.egg-info 
directories in the tests directory during the 'clean' target.


While this is helpful in a lot of cases, it would be nice if there was a 
way to opt out of this behavior.


Scott

Bug#1061015: pygame-sdl2: FTBFS: Cannot assign type 'Sint64 (SDL_RWops *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'

[Simon McVittie]

On Sun, 28 Jan 2024 at 22:49:37 +0100, Alexandre Detiste wrote:
> Le jeu. 25 janv. 2024 à 11:15, Simon McVittie  a écrit :
> > I also don't understand where these new upstream releases are coming from,
> > because https://github.com/renpy/pygame_sdl2 only has tags for 8.1.0,
> > and there don't seem to be any recent commits that are relevant to
> > cython3 compatibility.
> 
> The release are coming from here.
> https://www.renpy.org/latest.html

Oh, do those tarball code-drops have changes that are newer than what's
in https://github.com/renpy/pygame_sdl2 git?

> pygame-sdl2 state (which is a very old fork of pygame) is in limbo,
> upstream is considering vendoring it inside the main tarball
> it is maybe already maintained in the main git three.

I see. Do I understand correctly that we would consider it to be a bug
for anything other than renpy to use pygame-sdl2?

If so, I think if I was the Debian maintainer of these packages,
I'd be very tempted to vendor pygame-sdl2 into renpy (using dpkg's
multiple-.orig-tarballs feature if upstream have not done similar
vendoring) so that there's only one Debian source package to keep track
of, and no possibility of version skew between renpy and its pygame fork.

smcv

Bug#1061715: passwdqc: install PAM module into /usr

[Michael Biebl]

Source: passwdqc
Version: 2.0.3-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. passwdqc installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru passwdqc-2.0.3/debian/changelog passwdqc-2.0.3/debian/changelog
--- passwdqc-2.0.3/debian/changelog 2023-06-27 06:45:41.0 +0200
+++ passwdqc-2.0.3/debian/changelog 2024-01-29 00:36:00.0 +0100
@@ -1,3 +1,10 @@
+passwdqc (2.0.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 29 Jan 2024 00:36:00 +0100
+
 passwdqc (2.0.3-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru passwdqc-2.0.3/debian/libpam-passwdqc.install 
passwdqc-2.0.3/debian/libpam-passwdqc.install
--- passwdqc-2.0.3/debian/libpam-passwdqc.install   2020-03-24 
08:05:10.0 +0100
+++ passwdqc-2.0.3/debian/libpam-passwdqc.install   2024-01-29 
00:35:51.0 +0100
@@ -1,3 +1,3 @@
-lib/*/security/pam_passwdqc.so
+usr/lib/*/security/pam_passwdqc.so
 usr/share/man/man8
 debian/pam-configs/passwdqc usr/share/pam-configs
diff -Nru passwdqc-2.0.3/debian/rules passwdqc-2.0.3/debian/rules
--- passwdqc-2.0.3/debian/rules 2023-06-27 06:41:40.0 +0200
+++ passwdqc-2.0.3/debian/rules 2024-01-29 00:35:37.0 +0100
@@ -14,4 +14,4 @@
dh_auto_build -- CFLAGS="-Wall -W $(CFLAGS) $(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)" LDFLAGS_shared_LINUX="--shared $(LDFLAGS)"
 
 override_dh_auto_install:
-   dh_auto_install -- SHARED_LIBDIR="$(LIBDIR)" SHARED_LIBDIR_REL="." 
DEVEL_LIBDIR="$(LIBDIR)" SECUREDIR="/lib/$(DEB_HOST_MULTIARCH)/security"
+   dh_auto_install -- SHARED_LIBDIR="$(LIBDIR)" SHARED_LIBDIR_REL="." 
DEVEL_LIBDIR="$(LIBDIR)" SECUREDIR="/usr/lib/$(DEB_HOST_MULTIARCH)/security"

Bug#1061714: oath-toolkit: install PAM module into /usr

[Michael Biebl]

Source: oath-toolkit
Version: 2.6.11-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. oath-toolkit installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru oath-toolkit-2.6.11/debian/changelog 
oath-toolkit-2.6.11/debian/changelog
--- oath-toolkit-2.6.11/debian/changelog2024-01-11 09:27:56.0 
+0100
+++ oath-toolkit-2.6.11/debian/changelog2024-01-29 00:30:56.0 
+0100
@@ -1,3 +1,10 @@
+oath-toolkit (2.6.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 29 Jan 2024 00:30:56 +0100
+
 oath-toolkit (2.6.11-1) unstable; urgency=medium
 
   * New upstream version 2.6.11
diff -Nru oath-toolkit-2.6.11/debian/libpam-oath.install 
oath-toolkit-2.6.11/debian/libpam-oath.install
--- oath-toolkit-2.6.11/debian/libpam-oath.install  2024-01-11 
09:15:28.0 +0100
+++ oath-toolkit-2.6.11/debian/libpam-oath.install  2024-01-29 
00:30:49.0 +0100
@@ -1 +1 @@
-lib/*/security/pam_oath.so
+usr/lib/*/security/pam_oath.so
diff -Nru oath-toolkit-2.6.11/debian/rules oath-toolkit-2.6.11/debian/rules
--- oath-toolkit-2.6.11/debian/rules2024-01-11 09:15:28.0 +0100
+++ oath-toolkit-2.6.11/debian/rules2024-01-29 00:30:34.0 +0100
@@ -16,7 +16,7 @@
dh_auto_configure -- \
--disable-rpath \
--disable-gtk-doc \
-   --with-pam-dir=/lib/$(DEB_HOST_MULTIARCH)/security
+   --with-pam-dir=/usr/lib/$(DEB_HOST_MULTIARCH)/security
 
 override_dh_auto_install:
dh_auto_install

Bug#1061713: pam-mysql: install PAM module into /usr

[Michael Biebl]

Source: pam-mysql
Version: 0.8.2-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. pam-mysql installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru pam-mysql-0.8.2/debian/changelog pam-mysql-0.8.2/debian/changelog
--- pam-mysql-0.8.2/debian/changelog2023-01-30 18:30:41.0 +0100
+++ pam-mysql-0.8.2/debian/changelog2024-01-29 00:26:06.0 +0100
@@ -1,3 +1,10 @@
+pam-mysql (0.8.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 29 Jan 2024 00:26:06 +0100
+
 pam-mysql (0.8.2-2) unstable; urgency=medium
 
   * [9f6980e] New patch: Update README.
diff -Nru pam-mysql-0.8.2/debian/rules pam-mysql-0.8.2/debian/rules
--- pam-mysql-0.8.2/debian/rules2023-01-30 11:28:34.0 +0100
+++ pam-mysql-0.8.2/debian/rules2024-01-29 00:26:05.0 +0100
@@ -7,7 +7,7 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-SECDIR = /lib/$(DEB_HOST_MULTIARCH)/security
+SECDIR = /usr/lib/$(DEB_HOST_MULTIARCH)/security
 
 %:
dh $@

Bug#1061712: initramfs-tools: initramfs hooks do not seem to work on kernels above linux 6.5 (e.g. 6.6 or 6.7)

[Safir Secerovic]

Package: initramfs-tools
Version: 0.142
Severity: important

I have a custom hook that omits a kernel module being built into an initrd 
image.
Until kernels 6.6 and above, the hook does not seem to take effect.
The module is not omitted from initrd image...

On Linux kernel 6.5 and below the behaviour is as expected.

I am willing to provide further information and corroborate further.

Thank You for your efforts.

Cheers,
Safir Secerovic


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 33M Jan 28 23:10 /boot/initrd.img-6.5.0-5-amd64
-rw-r--r-- 1 root root 37M Jan 28 23:10 /boot/initrd.img-6.6.13-amd64
-rw-r--r-- 1 root root 38M Jan 28 23:10 /boot/initrd.img-6.7-amd64
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.6.13-amd64 
root=UUID=c3ff1373-56d5-4688-a11c-6e60091817e4 ro quiet

-- resume
RESUME=UUID=e7f523b6-3618-4f79-ba28-773527575a14
-- /proc/filesystems
fuseblk
ext3
ext2
ext4
vfat

-- lsmod
Module  Size  Used by
ccm20480  3
rfcomm102400  16
snd_seq_dummy  12288  0
snd_hrtimer12288  1
snd_seq   114688  7 snd_seq_dummy
snd_seq_device 16384  1 snd_seq
cmac   12288  3
algif_hash 12288  1
algif_skcipher 12288  1
af_alg 36864  6 algif_hash,algif_skcipher
bnep   36864  2
btusb  86016  0
btrtl  32768  1 btusb
btintel57344  1 btusb
btbcm  24576  1 btusb
btmtk  16384  1 btusb
uvcvideo  147456  0
bluetooth1134592  44 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm
videobuf2_vmalloc  20480  1 uvcvideo
uvc12288  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 36864  1 uvcvideo
videodev  368640  2 videobuf2_v4l2,uvcvideo
videobuf2_common   77824  4 
videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
mc 94208  4 
videodev,videobuf2_v4l2,uvcvideo,videobuf2_common
cdc_acm49152  0
ecdh_generic   16384  2 bluetooth
iwlmvm589824  0
qrtr   57344  4
mac80211 1392640  1 iwlmvm
intel_rapl_msr 20480  0
intel_rapl_common  36864  1 intel_rapl_msr
edac_mce_amd   40960  0
libarc412288  1 mac80211
kvm_amd   184320  0
iwlwifi   544768  1 iwlmvm
kvm  1363968  1 kvm_amd
snd_hda_codec_realtek   192512  1
snd_hda_codec_generic   114688  1 snd_hda_codec_realtek
ledtrig_audio  12288  1 snd_hda_codec_generic
irqbypass  12288  1 kvm
crc32_pclmul   12288  0
snd_hda_codec_hdmi 90112  2
snd_hda_intel  61440  3
ghash_clmulni_intel16384  0
sha512_ssse3   53248  1
snd_intel_dspcfg   36864  1 snd_hda_intel
snd_intel_sdw_acpi 16384  1 snd_intel_dspcfg
hid_multitouch 32768  0
sha256_ssse3   32768  0
binfmt_misc28672  1
cfg80211 1343488  3 iwlmvm,iwlwifi,mac80211
snd_hda_codec 225280  4 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
sha1_ssse3 32768  0
snd_hda_core  147456  5 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep  20480  1 snd_hda_codec
r8169 114688  0
ucsi_acpi  12288  0
snd_pcm   192512  4 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
nls_ascii  12288  1
sp5100_tco 16384  0
realtek40960  1
nls_cp437  16384  1
typec_ucsi 61440  1 ucsi_acpi
aesni_intel   360448  6
mdio_devres12288  1 r8169
snd_timer  53248  3 snd_seq,snd_hrtimer,snd_pcm
watchdog   49152  1 sp5100_tco
ideapad_laptop 57344  0
vfat   20480  1
fat   102400  1 vfat
crypto_simd16384  1 aesni_intel
cryptd 28672  3 crypto_simd,ghash_clmulni_intel
rapl   20480  0
pcspkr 12288  0
sparse_keymap  12288  1 ideapad_laptop
typec 110592  1 typec_ucsi
platform_profile   12288  1 ideapad_laptop
thunderbolt   487424  0
wmi_bmof   12288  0
snd   155648  18 
snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
ccp   147456  1 kvm_amd
libphy237568  3 r8169,mdio_devres,realtek
soundcore  16384  1 snd
i2c_piix4  32768  0
k10temp12288  0
rfkill 40960  11 iwlmvm,bluetooth,ideapad_laptop,cfg80211
roles  16384  1 typec_ucsi
battery28672  0
button 24576  0
i2c_hid_acpi   

Bug#1061711: qbrz: upgrade warning: diff.py:345: SyntaxWarning: invalid escape sequence '\s'

[Paul Wise]

Package: qbrz
Version: 0.23.2+bzr1663-1
Severity: normal
File: /usr/lib/python3/dist-packages/breezy/plugins/qbrz/lib/diff.py
User: debian-pyt...@lists.debian.org
Usertags: python3.12

When upgrading qbrz I got a Python syntax warning:

   Preparing to unpack .../qbrz_0.23.2+bzr1663-1_all.deb ...
   Unpacking qbrz (0.23.2+bzr1663-1) over (0.23.2+bzr1659-1) ...
   Setting up qbrz (0.23.2+bzr1663-1) ...
   /usr/lib/python3/dist-packages/breezy/plugins/qbrz/lib/diff.py:345: 
SyntaxWarning: invalid escape sequence '\s'
 re_whitespaces = re.compile(b"\s+")
   
Probably this is caused by the Python 3.12 transition.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages qbrz depends on:
ii  python3   3.11.6-1
ii  python3-all   3.11.6-1
ii  python3-breezy3.3.4-1.1
ii  python3-fastbencode   0.2-1+b1
ii  python3-patiencediff  0.2.13-1+b1
ii  python3-pyqt5 5.15.10+dfsg-1

qbrz recommends no packages.

qbrz suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Sun, 28 Jan 2024 17:22:32 +0100 Johannes Schauer Marin Rodrigues
wrote:

[...]
> you found bugs in both sbuild as well as in mmdebstrap.

Well, actually *you* found the bugs, I have just attempted to run a
command and reported that it didn't work...
Credit where credit is due!:-)

> The fixes for sbuild are in this MR:
> 
> https://salsa.debian.org/debian/sbuild/-/merge_requests/54
> 
> Feel free to comment and improve on the code as well to get this forward.

I am not familiar with the sqbuild code base, so I won't comment on the
code style.
I am confident that the MR will fix the bug.

Thanks for preparing it!

Maybe this bug report should cloned and reassigned to sbuild-qemu?

> 
> The mmdebstrap bug is fixed here:
> 
> 
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/3e233e10dfe414e43b31d328eecb0c776afc2ec3
> 
> Thanks!

Good to see that this other bug is going to be fixed, as well.

I am looking forward to seeing all these changes uploaded to Debian.
Thanks a lot!


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


pgpJrtUhyHl1U.pgp
Description: PGP signature

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

[Francesco Poli]

On Sun, 28 Jan 2024 00:33:06 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-01-27 19:20:08)
[...]
> > My comments / suggestions for improvements:
> > 
> >   * I had to manually fix the permissions, since the image file was
> > originally created with the following weird ones:
> > 
> >   $ ls -l --si sid-amd64.img 
> >   -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> 
> those are some funny permission bits. When I run
> mmdebstrap-autopkgtest-build-qemu I get:
> 
> $ ls -lha disk.img
> -rw-r--r-- 1 josch josch 26G Jan 28 00:03 disk.img
> 
> Looks fine to me.

What's *your* umask? Is it Debian default (022), by chance?

> 
> > I think the file permissions should be set (possibly at the end of the
> > mmdebstrap-autopkgtest-build-qemu run) as they would "naturally" result
> > from the user's umask:
> > 
> >   $ cd /dev/shm
> >   $ touch foo
> >   $ ls -l --si foo 
> >   -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo
> 
> They are set, taking the user's umask into account. What is your umask?

Mine is James Bond's umask: 007 ;-)

  $ umask 
  0007

> 
> > That's why I manually changed the permissions at the end:
> > 
> >   $ chmod 660 sid-amd64.img
> >   $ ls -l --si sid_amd64.img
> >   -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> > 
> > I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
> > automatically.
> 
> Lets first understand the problem before adding a workaround.
> mmdebstrap-autopkgtest-build-qemu runs this command to set the permissions:
> 
> chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"

This seems to work with Debian default umask (022):

  $ printf '%o\n' "$(( 0666 - 00022 ))"
  644

but fails whenever a umask includes an octal digit equal to 7, due to
the carryover:

  $ printf '%o\n' "$(( 0666 - 7 ))"
  657

Shouldn't this use the bitwise AND combined with the bitwise NOT?

  $ umask
  0007
  $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
  660
  $ umask 022
  $ umask
  0022
  $ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
  644

I would think that mmdebstrap-autopkgtest-build-qemu should run:

  chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"

Does it make sense to you?

> 
> Could you add some debugging output to the script to figure out what went 
> wrong
> and where?

Feel free to suggest any further debug that could be useful, in case
the above reasoning is not enough to shed some light on what happened.

> 
> >   * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:
> > 
> >   $ cd /dev/shm
> >   $ ls -l -h sid-amd64.img
> >   -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> >   $ df -h .
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   tmpfs   7.7G  765M  7.0G  10% /dev/shm
> > 
> > Well, the mystery is solved by looking at the allocated size:
> > 
> >   $ ls -l -h -s sid-amd64.img 
> >   662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> > 
> > Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
> > .qcow2 images?
> 
> I don't understand why sparse files are confusing to you.

I am clearly not very used to seeing files where the allocated size
greatly differs from the total size:

  $ ls -n --si -s sid-amd64.img 
  694M -rw-rw 1 1000 1000 27G Jan 27 17:48 sid-amd64.img

I am more used to seeing files where the two sizes are approximately
equal:

  $ ls -n --si -s sid-autopkgtest-amd64.qcow2 
  950M -rw-r--r-- 1 1000 1000 950M Dec 30 17:55 sid-autopkgtest-amd64.qcow2

Not exactly equal, agreed:

  $ ls -n -s sid-autopkgtest-amd64.qcow2 
  927604 -rw-r--r-- 1 1000 1000 949878784 Dec 30 17:55 
sid-autopkgtest-amd64.qcow2
  $ calc '927604*1024'
  949866496

but very similar, indeed...

> Why would qcow images be less confusing?

Because it seems to me that their total and allocated sizes tend to be
more similar...

> Can you list some reasons why qcow2 should be preferred over
> raw images?

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.

> Compression comes to mind but that is at the cost of doing that
> compression in the first place and it is not obvious to me whether cpu cycles
> or disk space are more scarce. For example, my platform is an ARM Cortex A53.
> To give you some idea how slow it is: it takes 30 seconds before a youtube
> video starts playing. At the same time, the system has a 2 TB hard disk. I 
> much
> prefer a bigger disk image which needs less CPU when I want to create and use
> it. What is your use-case?

I just like to see smaller file sizes, whenever possible.
And I was speaking on the basis of 

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

[Timothy Pearson]

Control: tags - moreinfo

> You appear to have attached a debdiff between your upload to unstable
> and the package in stable. The request is for a debdiff between the
> package in stable and the package you intend to upload _to stable_.
> Please provide that, and remove the "moreinfo" tag once done.

Understood.  Corrected patch attached.
 
> 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.

Thank you!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-27 08:41:00.0 -0600
@@ -1,3 +1,12 @@
+rss-glx (0.9.1-6.4~deb12u1) bookworm; 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:41:00.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:41:00.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#846308: .

[Serafeim Zanikolas]

reassign 846308 ftp.debian.org
retitle 846308 RM: tpb -- RoQA; orphaned, abandoned upstream
thanks

tpb is orphaned, dead-upstream, has very few users, and its
functionality is largely covered by the acpid package (modulo OSD, which
major window managers do provide). the latest bug was filed 7y ago

Bug#1061603: openturns: FTBFS with Python 3.12 as default

[Pierre Gruet]

Control: tags -1 confirmed

Hi,

On Sat, 27 Jan 2024 09:36:09 +0200 Graham Inggs  wrote:
> Source: openturns
> Version: 1.21.1-4
> Severity: important
> Tags: ftbfs patch
> User: debian-pyt...@lists.debian.org
> Usertags: python3.12
>
> Hi Maintainer
>
> openturns FTBFS with Python 3.12 as the default version (i.e. with
> python3-defaults/3.12.1-1 from experimental). I've copied what I hope
> is the relevant part of the log below.
>
> The first failure is due to a change in Python 3.12, and fixed
> upstream [1]. The second failure is due to a change in SWIG 4.2.0,
> landing in unstable soon, see #1061392, and also fixed upstream [2].
>
> Regards
> Graham
>
>
> [1] 
https://github.com/openturns/openturns/commit/fe388ec3e7a8e23ba1a3f7eada320165cba86fca
> [2] 
https://github.com/openturns/openturns/commit/077b6d9d788ec6c4bbd972024ce0f94d3557f5c1

>
>
>
> 46/597 Test #576: pyinstallcheck_SpecFunc_std
> ***Failed 0.53 sec
> Traceback (most recent call last):
> File "/<>/python/test/t_SpecFunc_std.py", line 45, in 


> assert s1 == 0.0, "sum(x) nonzero"
> AssertionError: sum(x) nonzero
>
>
> 305/597 Test #837: pyinstallcheck_DiscreteCompoundDistribution_std
> ***Failed 0.31 sec
> Traceback (most recent call last):
> File 
"/<>/python/test/t_DiscreteCompoundDistribution_std.py",

> line 18, in 
> ott.assert_almost_equal(
> File 
"/<>/debian/tmp/usr/lib/python3/dist-packages/openturns/testing.py",

> line 174, in assert_almost_equal
> return _testing.assert_almost_equal(*args)
> ^^^
> RuntimeError: Value 0.00128141 is not close enough to 0.00128136
>
>


Thanks for the report, I am planning to upgrade to newest upstream 
version soon, and as you suggest, this will fix the test failures.


Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060848: (no subject)

[Matthias Geiger]

reopen 1060848

thanks


still present in the latest upload.


--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061710: gnome-terminal: Switch to GTK4 version

[Jeremy Bícha]

Source: gnome-terminal
Version: 3.50.1-1
Severity: wishlist

gnome-terminal has a preview release of a GTK4 version, 3.97.0.

However, we cannot switch to it until the GTK4 accessibility issue is
fixed that affects all GTK4 (or at least all GTK4 + vte) terminal
apps.

https://launchpad.net/bugs/2034395

https://gitlab.gnome.org/GNOME/gtk/-/issues/5912

Thank you,
Jeremy Bícha

Bug#1061015: pygame-sdl2: FTBFS: Cannot assign type 'Sint64 (SDL_RWops *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'

[Alexandre Detiste]

Le jeu. 25 janv. 2024 à 11:15, Simon McVittie  a écrit :
>
> Control: affects -1 + src:renpy
>
> On Tue, 16 Jan 2024 at 20:43:34 +0100, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> > > src/pygame_sdl2/rwobject.pyx:336:22: Cannot assign type 'Sint64 
> > > (SDL_RWops *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'. 
> > > Exception values are incompatible. Suggest adding 'noexcept' to type 
> > > 'Sint64 (SDL_RWops *) except? -1 nogil'.

> The changelog for pygame-sdl2 8.1.3-1 says the new upstream release is
> compatible with cython3, but that doesn't seem to be the case? But I
> also don't understand where these new upstream releases are coming from,
> because https://github.com/renpy/pygame_sdl2 only has tags for 8.1.0,
> and there don't seem to be any recent commits that are relevant to
> cython3 compatibility.

The release are coming from here.
https://www.renpy.org/latest.html

pygame-sdl2 state (which is a very old fork of pygame) is in limbo,
upstream is considering vendoring it inside the main tarball
it is maybe already maintained in the main git three.

8.2.0 was released yesterday but I didn't noticed it.

Greetings

Bug#1056852: python-cassandra-driver: ftbfs with cython 3.0.x

[Emmanuel Arias]

Hi!

Thanks for your work.

I forgot push my last changes. I have already fixed the two tests. One
of them is that upstream is using a deprecated method in tests [0]. The
other issue was that they still use asyncore [1].

Now I will upload python-cassandra-driver soon.

[0] https://github.com/datastax/python-driver/pull/1195
[1] https://datastax-oss.atlassian.net/browse/PYTHON-1366?focusedCommentId=55575

On Sat, Jan 27, 2024 at 08:44:32AM +0100, Andreas Tille wrote:
> Control: tags -1 help
> Control: tags -1 moreinfo
> 
> Hi,
> 
> I tried building the current status in Git and realised that the
> suggested patch is not sufficient.  I decided to relax the versioned
> dependency from cython[1] which at least let the configure and build
> step pass.  Unfortunately the cython3-legacy build dependency led to 5
> errors and thus I tried cython3 instead which only leads to 2 errrors
> which you can hopefully reproduce in a couple of minutes in Salsa CI[2]
> (I'm going AFK instantly so can not check any more).
> 
> May be it is appropriate to skip those two tests?  I'll leave this
> decision to you since I do not know this package sufficiently enough.
> 
> Hope this helps
> Andreas.
> 
> [1] 
> https://salsa.debian.org/python-team/packages/python-cassandra-driver/-/blob/debian/master/debian/patches/0006-relax_vesioned_cython_dependency.patch?ref_type=heads
> [2] 
> https://salsa.debian.org/python-team/packages/python-cassandra-driver/-/pipelines/631074
> 
> -- 
> http://fam-tille.de
> 

-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 
 ⠈⠳⣄


signature.asc
Description: PGP signature

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

[Antony N. Donovan]

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.

Thanks,
Antony


From: Rafael Laboissière 
Sent: Sunday, January 28, 2024 4:18 PM
To: Antony N. Donovan ; 1061...@bugs.debian.org 
<1061...@bugs.debian.org>
Cc: Debian Bug Tracking System 
Subject: Re: Bug#1061644: octave-dev: The package should include an ld.so.conf 
fragment pointing to the shared libraries

Control: tags -1 - patch + moreinfo

* Antony Donovan  [2024-01-27 15:52]:

> Package: octave-dev
> Version: 7.3.0-2
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> I installed octave-dev and after building a standalone executable with
> mkoctfile it failed to run.
>
> I realized that what was needed was an ld.so.conf fragment containing
> the directory where the shared libraries were located.
>
> I created that fragment, with the contents
> /usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf,
> put that file in /etc/ld.so.conf.d, and ran ldconfig.
>
> This fixed the issue of running the standalone octave executable.

Thank you for your bug report.

Could you please provide us with a complete example that reproduces
the bug?

Best,

Rafael Laboissière
#include 
#include 
#include 
#include 
#include 
#include 

int
main (void)
{
  // Create interpreter.

  octave::interpreter interpreter;

  try {
interpreter.initialize_load_path(true);
interpreter.initialize();

if (!interpreter.initialized()) {
  std::cerr << "Octave interpreter initialization failed!"
<< std::endl;
  return 2;
}

int status = interpreter.execute ();
if (status != 0) {
  std::cerr << "creating embedded Octave interpreter failed!"
<< std::endl;
  return status;
}
std::cout << "Available Octave Graphics Toolkits:" << std::endl;

octave_value_list ovl = octave::Favailable_graphics_toolkits(interpreter);
charMatrix tks = ovl(0).char_matrix_value();


octave_idx_type len = tks.rows();
for (octave_idx_type i = 0; i < len; i++) {
  std::cout << tks.row_as_string(i) << std::endl;
}

  } catch (const octave::exit_exception& ex) {
std::cerr << "Octave interpreter exited with status = "
  << ex.exit_status () << std::endl;
  } catch (const octave::execution_exception& ex) {
std::cerr << "error encountered in Octave evaluator!" <<
  ex.message() << std::endl;
  }

  return 0;
}

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

[Sébastien Villemot]

Le dimanche 28 janvier 2024 à 22:18 +0100, Rafael Laboissière a écrit :
> * Antony Donovan  [2024-01-27 15:52]:
> 
> > Package: octave-dev
> > Version: 7.3.0-2
> > Severity: normal
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > I installed octave-dev and after building a standalone executable with 
> > mkoctfile it failed to run.
> > 
> > I realized that what was needed was an ld.so.conf fragment containing 
> > the directory where the shared libraries were located.
> > 
> > I created that fragment, with the contents 
> > /usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf, 
> > put that file in /etc/ld.so.conf.d, and ran ldconfig.
> > 
> > This fixed the issue of running the standalone octave executable.
> 
> Thank you for your bug report.
> 
> Could you please provide us with a complete example that reproduces 
> the bug?

I suppose that the issue appears with option --link-stand-alone of
mkoctfile.

I’m not sure that modifying the dynamic linker configuration for the
whole system, as suggested by Antony, is the right thing to do,
especially for a feature that is seldom used (mkoctfile is primarily
used for building .oct and .mex files, not standalone executable).
Octave libraries are private on purpose.

Another solution is simply to set the rpath in the created ELF
executable.

I think we should ask upstream about the intended use of the --link-
stand-alone option, and about the proper way of dealing with dynamic
loading of private Octave libraries in that case.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

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

[Rafael Laboissière]

Control: tags -1 - patch + moreinfo

* Antony Donovan  [2024-01-27 15:52]:


Package: octave-dev
Version: 7.3.0-2
Severity: normal
Tags: patch

Dear Maintainer,

I installed octave-dev and after building a standalone executable with 
mkoctfile it failed to run.


I realized that what was needed was an ld.so.conf fragment containing 
the directory where the shared libraries were located.


I created that fragment, with the contents 
/usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf, 
put that file in /etc/ld.so.conf.d, and ran ldconfig.


This fixed the issue of running the standalone octave executable.


Thank you for your bug report.

Could you please provide us with a complete example that reproduces 
the bug?


Best,

Rafael Laboissière

Bug#1061525: does not boot from multi-device root filesystems

[Steinar H. Gunderson]

On Sun, Jan 28, 2024 at 10:06:48PM +0100, Steinar H. Gunderson wrote:
>>  - The initramfs scripts attempt to rewrite UUID= _back_ to a
>>single /dev device through probing, and give that to mount. It needs
>>to avoid doing so for (multi-device) bcachefs filesystems, or they
>>will never mount since they contain too few devices.
> Fix in #1060411.

Also a patch for klibc's fstype, though I figured afterwards that blkid seems
to work just fine, in #1061662.

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

Bug#1061525: does not boot from multi-device root filesystems

[Steinar H. Gunderson]

forward 1061525 https://savannah.gnu.org/bugs/index.php?65151
block 1061525 by 1060256
block 1061525 by 1060411 
tags 1061525 + patch
kthxbye

On Thu, Jan 25, 2024 at 10:44:04PM +0100, Steinar H. Gunderson wrote:
>  - Likewise, root= on the kernel command line must contain the UUID
>or the initramfs scripts will wait on some colon-separated device that does
>not (and will never) exist. grub-mkconfig must be updated to write root=
>_back_ from a colon-separated device list to a UUID; I don't know if there
>is already some kind of support for UUID-roots, but I think so.
>As of today, it fails with:
> 
>  /usr/sbin/grub-probe: error: failed to get canonical path of 
> `/dev/nvme1n1p1:/dev/dm-2'.

Patch in https://savannah.gnu.org/bugs/index.php?65151 .

>  - initramfs must contain mount.bcachefs, since that is the only thing
>that knows how to probe a UUID into multiple devices. This means that
>the Rust parts needs to be built again, too (see #1060256).

#1060256 now has a patch/unofficial package.

>  - The initramfs scripts attempt to rewrite UUID= _back_ to a
>single /dev device through probing, and give that to mount. It needs
>to avoid doing so for (multi-device) bcachefs filesystems, or they
>will never mount since they contain too few devices.

Fix in #1060411.

I've verified that this makes my multi-device root filesystem (specified with
UUID= in fstab, and without errors=remount-ro) configure GRUB and boot on its
own, without any obvious issues.

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

Bug#1031140: (no subject)

[Marco Moock]

closed in current release in experimental.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039365#57

Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression

[Nilesh Patra]

+Maytha who prepared the upload.

On Sun, Jan 28, 2024 at 05:05:55PM +, Julian Gilbey wrote:
> Hi Nilesh,
> 
> You did the last upload of this package - do you have any idea about
> this bug?

I've been trying to track it down for the past hour but I don't have a fix that 
I am confident about.
I initially thought it may have been due to some sort of overflow due to 
bitshift so I applied this patch

--- a/fuse/print.go
+++ b/fuse/print.go
@@ -119,7 +119,8 @@
 func (names *flagNames) set(flag int64, name string) {
entry := flagNameEntry{bits: flag, name: name}
for i := 0; i < 64; i++ {
-   if flag&(1< Best wishes,
> 
>Julian
> 
> - Forwarded message from Paul Gevers  -
> 
> Date: Sun, 28 Jan 2024 08:50:51 +0100
> From: Paul Gevers 
> Subject: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to
>   testing for too long: i386 autopkgtest regression
> To: sub...@bugs.debian.org
> 
> Source: golang-github-hanwen-go-fuse
> Version: 2.1.0+git20220822.58a7e14-1
> Severity: serious
> Control: close -1 2.4.2-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:golang-github-hanwen-go-fuse has been trying to migrate
> for 31 days [2]. Hence, I am filing this bug. The version in unstable fails
> its own autopkgtest on i386.
> 
> If a package is out of sync between unstable and testing for a longer period,
> this usually means that bugs in the package in testing cannot be fixed via
> unstable. Additionally, blocked packages can have impact on other packages,
> which makes preparing for the release more difficult. Finally, it often
> exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing. I
> have also tagged this bug to only affect sid and trixie, so it doesn't affect
> (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=golang-github-hanwen-go-fuse
> 
> 
> 
> 
> 
> - End forwarded message -
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1040971: ITP: hyprland -- dynamic tiling Wayland compositor based on wlroots

[Matthias Geiger]

Am 28.01.24 um 17:31 schrieb Alan M Varghese:

Hi,

Thanks for the heads up. I am still working on structuring all this 
properly.


So far, this is what I have:

https://salsa.debian.org/NyxTrail/hyprland


Regarding the sub-packages, udis86 seems to be based on a fork of 
another project of the same name:


https://github.com/canihavesomecoffee/udis86 (hyprland depends on this 
one)
Yeah, my packaging uses that one because it builds ootb whereas the 
original does not.


https://github.com/vmt/udis86 (this one is the original project)

There does not seem to be any official releases upstream (udis86) for 
the commit Hyprland depends on (commit: 5336633). In fact, their 
(udis86) latest release seems to be v1.7.2, on Sep 2 2013.


Considering how Hyprland likes to declare their dependencies based on 
non-release commits, I do not think we can depend on any release 
versions of these packages.
at least for udis86 (the fork) and hyprland-protocols this should be 
doable easily.



I have successfully moved libwlroots.so.* to a "private" directory 
under /usr/lib/hyprland and updated the RPATH on the Hyprland binary 
to reflect that. This seems to work fine so far.



It might be possible to exclude tracy (may be even remove it?), but I 
haven't explored this yet. In this case, the commit Hyprland 
references does have a release version. But, may be we should not 
depend on that?



Finally, the build output for hyprland-protocols are a few header 
files. So far I have been trying to include these in a 'hyprland-dev' 
package along with everything else under the 'installheaders' Make 
target.


If required, I think it should be trivial to move these headers to a 
hyprland-protocols-dev package.`



As I mentioned before, the source tarball from Hyprland includes the 
source for all these submodules.


Perhaps these modules should be considered a part of Hyprland itself 
since they are included verbatim in the source package? They also do 
not seem to generate any binaries (or other artifacts) that might 
pollute the rest of the system.



Debian policy states that one should exclude if possible:

https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies



Let me know if you have any thoughts/feedback. This is my first time 
building a package :)



iirc the hyprland-protocols is also tagged at a specific release 
corresponding to the commit; fwiw you can package everything in one 
source package and explore devendoring later as long as you document 
everything properly in d/copyright. I'd suggest you can start with 
hyprland-protocols; you can set the specific commit as version number.


Feel free to ask in case you got any questions.



--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061709: golang-github-heroku-docker-registry-client -- Client for the v2 Docker Registry API

[Mathias Gibbens]

Control: retitle -1 ITP: golang-github-heroku-docker-registry-client -- Client 
for the v2 Docker Registry API


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

Bug#1061709: golang-github-heroku-docker-registry-client -- Client for the v2 Docker Registry API

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-heroku-docker-registry-client
  Version : 0.0~git20211012.9463674-1
  Upstream Author : Heroku
* URL : https://github.com/heroku/docker-registry-client
* License : BSD-3-clause
  Programming Lang: Go
  Description : Client for the v2 Docker Registry API

 An API client for the V2 Docker Registry API, for Go applications.

  This is a dependency for packaging distrobuilder, and will be team-
maintained within the Go Packaging Team.


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

Bug#1061707: ITP: golang-github-antchfx-htmlquery -- XPath package for HTML query

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-antchfx-htmlquery
  Version : 1.3.0-1
  Upstream Author : antchfx
* URL : https://github.com/antchfx/htmlquery
* License : Expat
  Programming Lang: Go
  Description : XPath package for HTML query

 htmlquery is an XPath query package for HTML, letting you extract
 data or evaluate from HTML documents by an XPath expression.

  This is a dependency for packaging distrobuilder, and will be team-
maintained within the Go Packaging Team.


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

Bug#1061708: ITP: golang-github-mudler-docker-companion -- squash and unpack Docker images

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-mudler-docker-companion
  Version : 0.4.5-1
  Upstream Author : Ettore Di Giacinto
* URL : https://github.com/mudler/docker-companion
* License : GPLv3
  Programming Lang: Go
  Description : squash and unpack Docker images

 docker-companion is a candy mix of tools for docker written in
 Golang and directly using Docker API calls. As for now it allows
 to squash and unpack an image.

  This is a dependency for packaging distrobuilder, and will be team-
maintained within the Go Packaging Team.


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

Bug#1061706: ITP: distrobuilder -- System container image builder for LXC and Incus

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: distrobuilder
  Version : 3.0-1
  Upstream Author : Linux Containers Project
* URL : https://github.com/lxc/distrobuilder
* License : Apache-2.0
  Programming Lang: Go
  Description : System container image builder for LXC and Incus

 distrobuilder is an image building tool for LXC and Incus.
 .
 Its modern design uses pre-built official images whenever available and
 supports a variety of modifications on the base image. distrobuilder creates
 LXC or Incus images, or just a plain root file system, from a declarative
 image definition (in YAML format) that defines the source of the image, its
 package manager, what packages to install or remove for specific image
 variants, OS releases and architectures, as well as additional files to
 generate and arbitrary actions to execute as part of the image build process.
 .
 Incus images may also be compatible with Canonical's LXD.

  distrobuilder has been the preferred way to create lxc/LXD/Incus
images for several years now, replacing the legacy lxc-templates, but
hasn't yet been packaged for Debian. This package will be team-
maintained within the Go Packaging Team.


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

Bug#1061705: rust-bendy: dependency on rust-failure, that has security problems

[Alexander Kjäll]

Source: rust-bendy
Severity: normal
X-Debbugs-Cc: alexander.kj...@gmail.com

Dear Maintainer,

Please consider pulling in this commit:

https://github.com/P3KI/bendy/commit/5abd78e79f86766094a2e1841e8bbdd696089b01

As failure is unsound: https://rustsec.org/advisories/RUSTSEC-2019-0036.html

//Alex

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

Kernel: Linux 6.6.11-amd64 (SMP w/8 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

Bug#1061704: libcoap3: CVE-2024-0962

[Salvatore Bonaccorso]

Source: libcoap3
Version: 4.3.4-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/obgm/libcoap/issues/1310
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcoap3.

CVE-2024-0962[0]:
| A vulnerability was found in obgm libcoap 4.3.4. It has been rated
| as critical. Affected by this issue is the function get_split_entry
| of the file src/coap_oscore.c of the component Configuration File
| Handler. The manipulation leads to stack-based buffer overflow. The
| attack may be launched remotely. The exploit has been disclosed to
| the public and may be used. It is recommended to apply a patch to
| fix this issue. VDB-252206 is the identifier assigned to this
| vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-0962
https://www.cve.org/CVERecord?id=CVE-2024-0962
[1] https://github.com/obgm/libcoap/issues/1310
[2] https://github.com/obgm/libcoap/pull/1311
[3] 
https://github.com/obgm/libcoap/commit/2b28d8b0e9607e71a145345b4fe49517e052b7d9

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#988730: CVE-2017-18641

[Mathias Gibbens]

On Sun, 2024-01-28 at 08:44 +0100, Salvatore Bonaccorso wrote:
> Thanks for the update. Do you know of any plans of making
> distrobuilder available?

  Up to this point I don't know of anything concrete. There are a few
references over the years of people's desire to package it, but nothing
much more appears to have happened. I will file an ITP shortly for
distrobuilder, so it's at least on my radar to work on at some point in
the future.

Mathias


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

Bug#1061703: gnome-characters nocheck FTBFS: ../meson.build:47:14: ERROR: Program '/usr/bin/gjs-console' not found or not executable

[Helmut Grohne]

Source: gnome-characters
Version: 45.0-2
Severity: serious
Tags: ftbfs

Hi,

gnome-characters fails to build from source when built with the nocheck
build profile. A build ends with:

| Run-time dependency gjs-1.0 found: YES 1.78.1
| env[PKG_CONFIG_PATH]:
| env[PKG_CONFIG]: /usr/bin/mips64el-linux-gnuabi64-pkg-config
| ---
| Called: `/usr/bin/mips64el-linux-gnuabi64-pkg-config --variable=gjs_console 
gjs-1.0` -> 0
| stdout:
| /usr/bin/gjs-console
| ---
| Got pkg-config variable gjs_console : /usr/bin/gjs-console
| Program /usr/bin/gjs-console found: NO
| 
| ../meson.build:47:14: ERROR: Program '/usr/bin/gjs-console' not found or not 
executable
| dh_auto_configure: error: cd obj-mips64el-linux-gnuabi64 && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/mips64el-linux-gnuabi64 
-Dpython.bytecompile=-1 --cross-file 
/<>/debian/.debhelper/generated/_source/meson-cross-file.conf 
returned exit code 1
| make: *** [debian/rules:7: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Since trixie, a FTBFS with the nocheck build profile is considered
release-critical. The  annotation on the gjs build dependency
should be dropped or some change to the upstream build system should
enable building without gjs-console.

Helmut

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Patrice Duroux]

After a test, the patch at
https://gitlab.freedesktop.org/drm/amd/-/issues/3122#note_2252835
is working fine on my side.
Many thanks to Diederik!

Le dim. 28 janv. 2024 à 15:00, Diederik de Haas
 a écrit :
>
> Patrice,
>
> On Sunday, 28 January 2024 11:44:59 CET Linux regression tracking (Thorsten
> Leemhuis) wrote:
> > On 27.01.24 14:14, Salvatore Bonaccorso wrote:
> > > In Debian (https://bugs.debian.org/1061449) we got the following
> > > quotred report:
> > >
> > > On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
> > >> Giving a try to 6.7, here is a message extracted from dmesg:
> > >> [4.177226] [ cut here ]
> > >> [4.177227] WARNING: CPU: 6 PID: 248 at
> > >> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
> > >> construct_phy+0xb26/0xd60 [amdgpu]
> > >
> > > [...]
> >
> > Not my area of expertise, but looks a lot like a duplicate of
> > https://gitlab.freedesktop.org/drm/amd/-/issues/3122#note_2252835
> >
> > Mario (now CCed) already prepared a patch for that issue that seems to work.
>
> If you can build and test a kernel with the `test-patches` script like before
> with the attached patch, but *without* the previous patch (which just reverted
> commit b17ef04bf3a4346d66404454d6a646343ddc9749), that would be really useful.
>
> When you've done that, do a Reply-All to Thorsten Leemhuis' message so that
> everyone sees the results. Optionally also reply to the gitlab issue Thorsten
> mentioned.
>
> (It didn't seem useful to send these instructions to all the people/lists)

Bug#1061702: malcontent: install PAM module into /usr

[Michael Biebl]

Source: malcontent
Version: 0.11.1-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. malcontent installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru malcontent-0.11.1/debian/changelog malcontent-0.11.1/debian/changelog
--- malcontent-0.11.1/debian/changelog  2023-09-19 19:48:15.0 +0200
+++ malcontent-0.11.1/debian/changelog  2024-01-28 20:45:36.0 +0100
@@ -1,3 +1,10 @@
+malcontent (0.11.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sun, 28 Jan 2024 20:45:36 +0100
+
 malcontent (0.11.1-1) unstable; urgency=medium
 
   * Team upload
diff -Nru malcontent-0.11.1/debian/libpam-malcontent.install 
malcontent-0.11.1/debian/libpam-malcontent.install
--- malcontent-0.11.1/debian/libpam-malcontent.install  2023-09-19 
19:48:15.0 +0200
+++ malcontent-0.11.1/debian/libpam-malcontent.install  2024-01-28 
20:45:23.0 +0100
@@ -1,2 +1,2 @@
 debian/local/pam-configs/malcontent usr/share/pam-configs/
-lib/*/security/pam_malcontent.so
+usr/lib/*/security/pam_malcontent.so
diff -Nru malcontent-0.11.1/debian/rules malcontent-0.11.1/debian/rules
--- malcontent-0.11.1/debian/rules  2023-09-19 19:48:15.0 +0200
+++ malcontent-0.11.1/debian/rules  2024-01-28 20:45:06.0 +0100
@@ -10,7 +10,7 @@
 %:
dh $@
 
-meson_options := -Dpamlibdir=/lib/$(DEB_HOST_MULTIARCH)/security
+meson_options := -Dpamlibdir=/usr/lib/$(DEB_HOST_MULTIARCH)/security
 
 ifneq ($(filter libmalcontent-ui-%,$(binaries)),)
 meson_options += -Dui=enabled

Bug#1061701: nss-pam-ldapd: install PAM and NSS modules into /usr

[Michael Biebl]

Source: nss-pam-ldapd
Version: 0.9.12-4
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. nss-pam-ldapd installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru nss-pam-ldapd-0.9.12/debian/changelog 
nss-pam-ldapd-0.9.12/debian/changelog
--- nss-pam-ldapd-0.9.12/debian/changelog   2023-04-29 15:11:54.0 
+0200
+++ nss-pam-ldapd-0.9.12/debian/changelog   2024-01-28 20:40:03.0 
+0100
@@ -1,3 +1,10 @@
+nss-pam-ldapd (0.9.12-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM and NSS modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sun, 28 Jan 2024 20:40:03 +0100
+
 nss-pam-ldapd (0.9.12-4) unstable; urgency=medium
 
   * Auto-detect LDAP server host name instead of IP address (closes: #1023460)
diff -Nru nss-pam-ldapd-0.9.12/debian/libnss-ldapd.install 
nss-pam-ldapd-0.9.12/debian/libnss-ldapd.install
--- nss-pam-ldapd-0.9.12/debian/libnss-ldapd.install2023-04-29 
15:11:54.0 +0200
+++ nss-pam-ldapd-0.9.12/debian/libnss-ldapd.install2024-01-28 
20:39:06.0 +0100
@@ -1 +1 @@
-lib/*/libnss_ldap.so*
+usr/lib/*/libnss_ldap.so*
diff -Nru nss-pam-ldapd-0.9.12/debian/libpam-ldapd.install 
nss-pam-ldapd-0.9.12/debian/libpam-ldapd.install
--- nss-pam-ldapd-0.9.12/debian/libpam-ldapd.install2023-04-29 
15:11:54.0 +0200
+++ nss-pam-ldapd-0.9.12/debian/libpam-ldapd.install2024-01-28 
20:39:09.0 +0100
@@ -1,2 +1,2 @@
-lib/*/security/pam_ldap.so
+usr/lib/*/security/pam_ldap.so
 debian/pam-configs/ldap usr/share/pam-configs
diff -Nru nss-pam-ldapd-0.9.12/debian/rules nss-pam-ldapd-0.9.12/debian/rules
--- nss-pam-ldapd-0.9.12/debian/rules   2023-04-29 15:11:54.0 +0200
+++ nss-pam-ldapd-0.9.12/debian/rules   2024-01-28 20:38:59.0 +0100
@@ -14,8 +14,8 @@
 # pass extra flags to configure
 override_dh_auto_configure:
dh_auto_configure -- \
-   --libdir=/lib/$(DEB_HOST_MULTIARCH) \
-   --with-pam-seclib-dir=/lib/$(DEB_HOST_MULTIARCH)/security \
+   --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
+   
--with-pam-seclib-dir=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
--enable-warnings \
--enable-pynslcd \
PYTHON=python3

Bug#1061695: RM: retro-gtk -- RoM; unused library

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: retro-...@packages.debian.org
Control: affects -1 src:retro-gtk

Please remove retro-gtk from Debian. It has no remaining dependencies
and is basically unmaintained right now.

The library was only in Debian because of gnome-games-app which was
removed because it was no longer buildable or runnable.
gnome-games-app was renamed upstream to High Score but it was never
released. In a bug inquiring about its status, it was suggested that
maybe the app wouldn't use the retro library any more:
https://gitlab.gnome.org/World/highscore/-/issues/274

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression

[Shengjing Zhu]

Control: forwarded -1 https://github.com/hanwen/go-fuse/issues/502

On Mon, Jan 29, 2024 at 1:42 AM Julian Gilbey  wrote:
>
> Hi Nilesh,
>
> You did the last upload of this package - do you have any idea about
> this bug?
>

See https://github.com/hanwen/go-fuse/issues/502

--
Shengjing Zhu

Bug#1052826: Broken entrypoints package: actually a pybuild issue?

[Andreas Tille]

Am Sun, Jan 28, 2024 at 08:13:01PM +0100 schrieb julien.pu...@gmail.com:
> > 
> > upstream page[1] says:
> > 
> >   This package is in maintenance-only mode. New code should use the
> >   importlib.metadata module in the Python standard library to find
> > and load entry points.
> > 
> > So it seems we do not need adapt you patch very frequently since
> > no changes will be to be expected (but the dependencies of entrypoint
> > should be adapted.
> 
> Doesn't that mean that we should strive to RM entrypoints?

I'm fine with this but we need to fix the rdepends first.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1061698: pam-geoip: install PAM module into /usr

[Michael Biebl]

Source: pam-geoip
Version: 2.1.1-7
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. pam-geiop installs files into /lib, these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru pam-geoip-2.1.1/debian/changelog pam-geoip-2.1.1/debian/changelog
--- pam-geoip-2.1.1/debian/changelog2023-08-22 16:34:22.0 +0200
+++ pam-geoip-2.1.1/debian/changelog2024-01-28 20:29:05.0 +0100
@@ -1,3 +1,10 @@
+pam-geoip (2.1.1-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sun, 28 Jan 2024 20:29:05 +0100
+
 pam-geoip (2.1.1-7) unstable; urgency=medium
 
   * Remove leftover file in dh_clean.
diff -Nru pam-geoip-2.1.1/debian/libpam-geoip.lintian-overrides 
pam-geoip-2.1.1/debian/libpam-geoip.lintian-overrides
--- pam-geoip-2.1.1/debian/libpam-geoip.lintian-overrides   2023-08-22 
16:34:22.0 +0200
+++ pam-geoip-2.1.1/debian/libpam-geoip.lintian-overrides   2024-01-28 
20:29:05.0 +0100
@@ -1,3 +1,3 @@
-libpam-geoip: hardening-no-fortify-functions [lib/*/security/pam_geoip.so]
-libpam-geoip: hardening-no-bindnow [lib/*/security/pam_geoip.so]
+libpam-geoip: hardening-no-fortify-functions [usr/lib/*/security/pam_geoip.so]
+libpam-geoip: hardening-no-bindnow [usr/lib/*/security/pam_geoip.so]
 libpam-geoip: spare-manual-page [usr/share/man/man8/pam_geoip.8.gz]
diff -Nru pam-geoip-2.1.1/debian/patches/02-install-into-usr.patch 
pam-geoip-2.1.1/debian/patches/02-install-into-usr.patch
--- pam-geoip-2.1.1/debian/patches/02-install-into-usr.patch1970-01-01 
01:00:00.0 +0100
+++ pam-geoip-2.1.1/debian/patches/02-install-into-usr.patch2024-01-28 
20:29:04.0 +0100
@@ -0,0 +1,13 @@
+Index: pam-geoip-2.1.1/Makefile
+===
+--- pam-geoip-2.1.1.orig/Makefile  2024-01-26 21:46:08.0 +0100
 pam-geoip-2.1.1/Makefile   2024-01-28 20:29:02.525498983 +0100
+@@ -10,7 +10,7 @@
+ LDFLAGS=-shared
+ LIBS=-lpam -lmaxminddb -lm
+ CCFLAGS=-Wall
+-PAM_LIB_DIR=$(DESTDIR)/lib/$(MULTIARCH)/security
++PAM_LIB_DIR=$(DESTDIR)/usr/lib/$(MULTIARCH)/security
+ INSTALL=/usr/bin/install
+ 
+ all: pam_geoip.so doc
diff -Nru pam-geoip-2.1.1/debian/patches/series 
pam-geoip-2.1.1/debian/patches/series
--- pam-geoip-2.1.1/debian/patches/series   2023-08-22 16:34:22.0 
+0200
+++ pam-geoip-2.1.1/debian/patches/series   2024-01-28 20:28:49.0 
+0100
@@ -1 +1,2 @@
 01-missing-ldflags.diff
+02-install-into-usr.patch

Bug#1061699: kwallet-pam: install PAM module into /usr

[Michael Biebl]

Source: kwallet-pam
Version: 5.27.10-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. kwallet-pam installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru kwallet-pam-5.27.10/debian/changelog 
kwallet-pam-5.27.10/debian/changelog
--- kwallet-pam-5.27.10/debian/changelog2024-01-11 23:16:19.0 
+0100
+++ kwallet-pam-5.27.10/debian/changelog2024-01-28 20:35:31.0 
+0100
@@ -1,3 +1,10 @@
+kwallet-pam (5.27.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Sun, 28 Jan 2024 20:35:31 +0100
+
 kwallet-pam (5.27.10-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru kwallet-pam-5.27.10/debian/libpam-kwallet5.install 
kwallet-pam-5.27.10/debian/libpam-kwallet5.install
--- kwallet-pam-5.27.10/debian/libpam-kwallet5.install  2022-06-21 
21:23:53.0 +0200
+++ kwallet-pam-5.27.10/debian/libpam-kwallet5.install  2024-01-28 
20:35:23.0 +0100
@@ -1 +1 @@
-lib/*/security/pam_kwallet5.so
+usr/lib/*/security/pam_kwallet5.so
diff -Nru kwallet-pam-5.27.10/debian/rules kwallet-pam-5.27.10/debian/rules
--- kwallet-pam-5.27.10/debian/rules2022-06-21 21:23:53.0 +0200
+++ kwallet-pam-5.27.10/debian/rules2024-01-28 20:35:15.0 +0100
@@ -9,5 +9,5 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   -DCMAKE_INSTALL_LIBDIR="/lib/${DEB_HOST_MULTIARCH}" \
+   -DCMAKE_INSTALL_LIBDIR="/usr/lib/${DEB_HOST_MULTIARCH}" \
-DKDE_INSTALL_LIBEXECDIR="/usr/share/libpam-kwallet-common"

Bug#1060705: grub-pc: Symbol grub_env_get not found

[Bastian Germann]

Control: severity -1 important

Am 23.01.24 um 14:21 schrieb Julian Andres Klode:

If I don't hear other reports this week I'll have to assume that's a
fluke on your end - weird things happen sometimes - and close it.


Unfortunately, I did not have any time for this during this week -
the i386 machine is obviously not my main machine.
So I reduce severity that the package can migrate.

Bug#1061697: ITP: libcgi-tiny-perl -- module providing a modern interface to write CGI scripts

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcgi-tiny-perl
  Version : 1.002
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/CGI-Tiny
* License : Artistic-2.0
  Programming Lang: Perl
  Description : module providing a modern interface to write CGI scripts

CGI::Tiny provides a modern interface to write CGI scripts to dynamically
respond to HTTP requests as defined in RFC 3875. It is intended to be:

 * Minimal
 CGI::Tiny contains a small amount of code and (on modern Perls) no non-core
 requirements. No framework needed.

 * Simple
 CGI::Tiny is straightforward to use, avoids anything magical or surprising,
 and provides easy access to the most commonly needed features.

 * Robust
 CGI::Tiny's interface is designed to help the developer follow best
 practices and avoid common pitfalls and vulnerabilities by default.

 * Lazy
 CGI::Tiny only loads code or processes information once it is needed,
 so simple requests can be handled without unnecessary overhead.

 * Restrained
 CGI::Tiny is designed for the CGI protocol which executes the program again
 for every request. It is not suitable for persistent protocols like FastCGI
 or PSGI.

 * Flexible
 CGI::Tiny can be used with other modules to handle tasks like routing and
 templating, and doesn't impose unnecessary constraints to reading input or
 rendering output.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1061696: gnome-video-arcade: Remove unmaintained package?

[Jeremy Bícha]

Source: gnome-video-arcade
Version: 0.8.8-5
Severity: serious
X-Debbugs-CC: jo...@debian.org

Jordi, what do you think about removing gnome-video-arcade from Debian?

See https://bugs.debian.org/1061694

Thank you,
Jeremy Bícha

Bug#1052826: Broken entrypoints package: actually a pybuild issue?

[julien . puydt]

Hi,

Le dimanche 28 janvier 2024 à 08:17 +0100, Andreas Tille a écrit :
> Hi Jullien,
> 
> upstream page[1] says:
> 
>   This package is in maintenance-only mode. New code should use the
>   importlib.metadata module in the Python standard library to find
> and load entry points.
> 
> So it seems we do not need adapt you patch very frequently since
> no changes will be to be expected (but the dependencies of entrypoint
> should be adapted.

Doesn't that mean that we should strive to RM entrypoints?

Cheers,

J.Puydt

PS: I really mean "strive to" and not "do it":
$ ssh mirror.ftp-master.debian.org "dak rm -Rn entrypoints"
Will remove the following packages from unstable:

entrypoints |  0.4-2 | source
python3-entrypoints |  0.4-2 | all

Maintainer: Debian Python Team 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
intake: python3-intake
ipyparallel: python3-ipyparallel
jupyter-client: python3-jupyter-client
nbconvert: python3-nbconvert
python-altair: python3-altair

# Broken Build-Depends:
intake: python3-entrypoints
jupyter-client: python3-entrypoints
jupyter-notebook: python3-entrypoints
jupyterhub: python3-entrypoints
nbconvert: python3-entrypoints
nbsphinx: python3-entrypoints
oscrypto: python3-entrypoints
python-altair: python3-entrypoints
python-flake8: python3-entrypoints

Dependency problem found.

Bug#1061694: gnome-video-arcade: Please stop using libsoup2.4

[Jeremy Bícha]

Source: gnome-video-arcade
Version: 0.8.8-5
Severity: serious
Tags: trixie sid

We would like to stop building libsoup2.4 and only use libsoup3 instead.

gnome-video-arcade has been archived which means no bug reports, merge
requests, or code fixes are being accepted.

Maybe we should do like Fedora and remove gnome-video-arcade.

Probably lutris and retroarch or MAME itself are better choices.

Thank you,
Jeremy Bícha

Bug#1061693: budgie-extras: Please stop using libsoup2.4

[Jeremy Bícha]

Source: budgie-extras
Version: 1.7.1-1
Severity: important

We eventually want to stop using libsoup2.4 since libsoup3 is the
supported version of this library.

According to the NEWS and meson.build, it is now possible to use the
weathershow applet with libsoup3. That is the only part of
budgie-extras that uses libsoup.

Thank you,
Jeremy Bícha

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

[Harlan Lieberman-Berg]

Package: chirp
Version: 1:20240122-1
Severity: grave
X-Debbugs-Cc: deb...@jouellet.net, hlieber...@debian.org

Hello Dave, all,

Thank you for updating chirp! Unfortunately, it seems that pybuild may have
failed to pick up one of the necessary directories that contains the stock
configurations. Running `chirpw` instantly crashes with the following error:

Traceback (most recent call last):
  File "/usr/bin/chirpw", line 33, in 
sys.exit(load_entry_point('chirp==20240122', 'console_scripts', 'chirpw')())
 ^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/__init__.py", line 178, in 
chirpmain
mainwindow = main.ChirpMain(None, title='CHIRP')
 ^^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 414, in 
__init__
self.SetMenuBar(self.make_menubar())
^^^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 644, in 
make_menubar
self.OPEN_STOCK_CONFIG_MENU = self.add_stock_menu()
  ^
  File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 573, in 
add_stock_menu
in importlib_resources.files('chirp.stock_configs').iterdir()
   
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))

  File "/usr/lib/python3.11/importlib/resources/_common.py", line 53, in 
get_package
resolved = resolve(package)
   
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 44, in resolve
return cand if isinstance(cand, types.ModuleType) else 
importlib.import_module(cand)
   
^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'chirp.stock_configs'

Hopefully this is an easy fix!  Thanks for your help maintaining this.

73,

--
Harlan Lieberman-Berg (KC1CHE)
~hlieberman

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

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

Versions of packages chirp depends on:
ii  python3 [python3-supported-min]  3.11.4-5+b1
ii  python3-importlib-resources  6.0.1-1
ii  python3-requests 2.31.0+dfsg-1
ii  python3-serial   3.5-2
ii  python3-six  1.16.0-4
ii  python3-yattag   1.15.1-1
ii  wxpython-tools   4.2.1+dfsg-3

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information

Bug#1061691: kmscon: after installation of the package, no /etc/kmscon/kmscon.conf to be found.

[Daniel Tourde]

Package: kmscon
Version: 9.0.0-5
Severity: normal
X-Debbugs-Cc: daniel.tou...@caelae.se

Dear Maintainer,


   * I just installed kmscon and I tried to configure it.
   * apt install kmsconf
 cd /etc
   * I searched for a kmscon directory that I never found
 I found instead /etc/needrestart/conf.d/kmscon.conf
   * I expected a /etc/kmscon/kmscon.conf file I could edit
 The file in the needrestart directory should have disappeared after a 
reboot, I guess.


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

Kernel: Linux 6.6.13-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 kmscon depends on:
ii  init-system-helpers  1.66
ii  libc62.37-14
ii  libdrm2  2.4.120-1
ii  libegl1  1.7.0-1
ii  libgbm1  23.3.4-1
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.3-2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libpixman-1-00.42.2-1
ii  libsystemd0  255.3-1
pn  libtsm4  
ii  libudev1 255.3-1
ii  libxkbcommon01.6.0-1

kmscon recommends no packages.

kmscon suggests no packages.

Bug#1061690: python3-setuptools-gettext 0.1.10-1 makes breezy FTBFS

[Adrian Bunk]

Package: python3-setuptools-gettext
Version: 0.1.10-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:breezy

https://buildd.debian.org/status/logs.php?pkg=breezy=3.3.5-2

...
running build_mo
Traceback (most recent call last):
  File "/<>/setup.py", line 225, 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 "/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 131, in run
self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 318, 
in run_command
self.distribution.run_command(command)
  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 "/usr/lib/python3/dist-packages/setuptools_gettext/__init__.py", line 
113, in run
default_lang = self.gettext_default_language
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 107, 
in __getattr__
raise AttributeError(attr)
AttributeError: gettext_default_language
E: pybuild pybuild:391: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build

Bug#1061689: kdevelop512-libs: identified for time_t transition but no ABI in shlibs

[Steve Langasek]

Package: kdevelop512-libs
Version: 4:23.08.1-2
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Pino,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
kdevelop512-libs 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, kdevelop512-libs's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libKDevPlatformDebugger 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformDocumentation 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformInterfaces 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformLanguage 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformOutputView 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformProject 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformSerialization 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformShell 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformSublime 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformUtil 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformVcs 512 kdevelop512-libs (>= 4:23.08.1)
$

It is therefore not obvious that we should rename the package to
'kdevelop512-libs-t64' as part of this transition.

Looking at the archive, there are packages that depend on these libraries
built from other source packages, kdevelop-php and kdevelop-python.

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 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/kdevelop-dev/base/log.txt


signature.asc
Description: PGP signature

Bug#1061660: liblwp-protocol-https-perl: Fail to verify certificates

[gregor herrmann]

On Sun, 28 Jan 2024 18:44:02 +0100, Christian Marillat wrote:

> > Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1
> > from testing? If yes, which of the two hunks from [0] is causing the
> > problem?
> This issue doesn't exist with 6.11-1. I've seen this bug when 6.12 has
> been installed.

What doesn't help is that I've uploaded libio-socket-ssl-perl 2.085-1
as well … (Although with minimal changes as well.)
 
> The attached patch isn't clean :

Sorry, that was a diff of the upstream git tags.

From the debdiff:

#v+
diff -Nru liblwp-protocol-https-perl-6.11/lib/LWP/Protocol/https.pm 
liblwp-protocol-https-perl-6.12/lib/LWP/Protocol/https.pm
--- liblwp-protocol-https-perl-6.11/lib/LWP/Protocol/https.pm   2023-07-09 
17:10:32.0 +0200
+++ liblwp-protocol-https-perl-6.12/lib/LWP/Protocol/https.pm   2024-01-22 
18:51:33.0 +0100
@@ -56,7 +56,7 @@
 }
 }
 $self->{ssl_opts} = \%ssl_opts;
-return (%ssl_opts, $self->SUPER::_extra_sock_opts);
+return (%ssl_opts, MultiHomed => 1, $self->SUPER::_extra_sock_opts);
 }
 
 # This is a subclass of LWP::Protocol::http.
@@ -96,9 +96,12 @@
 if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
 *_upgrade_sock = sub {
my ($self,$sock,$url) = @_;
+# SNI should be passed there only if it is not an IP address.
+# Details: 
https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
+   my $host = $url->host_port() =~ m/:|^[\d.]+$/s ? undef : $url->host();
$sock = LWP::Protocol::https::Socket->start_SSL( $sock,
SSL_verifycn_name => $url->host,
-   SSL_hostname => $url->host,
+   SSL_hostname => $host,
$self->_extra_sock_opts,
);
$@ = LWP::Protocol::https::Socket->errstr if ! $sock;
#v-
 
> > Do the errors from qa.debian.org go away if you run uscan as
> > "PERL_LWP_SSL_VERIFY_HOSTNAME=1 uscan …"?
> Still the same. I also this bug with gitlab.

Hm …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1061687: u-boot-menu: Prevents kernel installation/removal when removed without purging

[Tomasz Rybak]

Package: u-boot-menu
Version: 4.2.3
Severity: normal
X-Debbugs-Cc: serp...@debian.org

I'm running MNT Reform, so using non-Debian kernel. The rest
of packages are from Debian.

When u-boot-menu is removed from system, but not purged
(i.e. "apt remove u-boot-menu" is run), any subsequent installation
or removal of kernel fails because of /etc/kernel/postinst.d/zz-u-boot-menu:
/etc/kernel/postinst.d/zz-u-boot-menu: 5: .: cannot open 
/usr/share/u-boot-menu/read-config: No such file
run-parts: /etc/kernel/postinst.d/zz-u-boot-menu exited with return code 2
dpkg: error processing package linux-image-6.6.13-reform2-arm64 (--configure):
 installed linux-image-6.6.13-reform2-arm64 package post-installation script 
subprocess returned error exit status 1

Basically apt remove leaves configuration files:
/etc
/etc/default
/etc/default/u-boot
/etc/kernel
/etc/kernel/postinst.d
/etc/kernel/postinst.d/zz-u-boot-menu
/etc/kernel/postrm.d
/etc/kernel/postrm.d/zz-u-boot-menu

but zz-u-boot-menu at the very beginning wants to read 
/usr/share/u-boot-menu/read-config
which is not in /etc - so deleted on removal.
Purging u-boot-menu fixes problem.

I'm not sure which solution would be better:
a) Move required file from /usr/share to /etc (e.g. /etc/default?)
b) leave it in /usr/share but mark as conffile.

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

Kernel: Linux 6.6.13-reform2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages u-boot-menu depends on:
ii  linux-base  4.9

Versions of packages u-boot-menu recommends:
ii  rsync  3.2.7-1+b1

Versions of packages u-boot-menu suggests:
ii  flash-kernel  3.107+reform1

Bug#1061686: kmscon: The removal of the kmscon package does not bring back the classical linux consoles

[Daniel Tourde]

Package: kmscon
Version: 9.0.0-5
Severity: important
X-Debbugs-Cc: daniel.tou...@caelae.se

Dear Maintainer,

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

   * After an unsuccessful use of kmscon, I removed the package.
   * apt remove kmscon
   * The package was removed but when I rebooted the machine, I did not get my 
linux consoles back. 
   * The system to be in the same state than it was before I installed kmscon, 
that is to say with all the virtual consoles available (CTRL-ALT-Fn)
   * I suspect systemd is spooking somewhere

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

Kernel: Linux 6.6.13-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 kmscon depends on:
ii  init-system-helpers  1.66
ii  libc62.37-14
ii  libdrm2  2.4.120-1
ii  libegl1  1.7.0-1
ii  libgbm1  23.3.4-1
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.3-2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libpixman-1-00.42.2-1
ii  libsystemd0  255.3-1
pn  libtsm4  
ii  libudev1 255.3-1
ii  libxkbcommon01.6.0-1

kmscon recommends no packages.

kmscon suggests no packages.

Bug#1053946: tqdm and pandas 2.1 / python 3.12

[Rebecca N. Palmer]

Control: retitle 1058160 tqdm: tests failing/hanging in Python 3.12

That works for #1053946 (pandas 2.x), but #1058160 (python 3.12) is more 
than a single hanging test, and it's not immediately obvious what should 
be done.


Attempted fix (caution, currently just skips the hanging test) and 
failure logs:

https://salsa.debian.org/rnpalmer-guest/tqdm

Bug#1061685: kmscon: Cannot switch anymore between different VT after the installation of kmscon

[Daniel Tourde]

Package: kmscon
Version: 9.0.0-5
Severity: normal
X-Debbugs-Cc: daniel.tou...@caelae.se

Dear Maintainer,


   * I am trying to use kmscon instead of the classic Linux console
   * I installed kmscon, the I reboot the machine. I was able to access one 
console but that was it. The other ones (accessible by CTRL+ALT+Fn) are gone.
   * Only one usable console on my Linux machine. Trying to switch to the other 
ones was unsuccesful. I could not get back to the one working, aftwerward.
   * Many working console, using kmscon instead of the classical linux console.


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

Kernel: Linux 6.6.13-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 kmscon depends on:
ii  init-system-helpers  1.66
ii  libc62.37-14
ii  libdrm2  2.4.120-1
ii  libegl1  1.7.0-1
ii  libgbm1  23.3.4-1
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.3-2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libpixman-1-00.42.2-1
ii  libsystemd0  255.3-1
pn  libtsm4  
ii  libudev1 255.3-1
ii  libxkbcommon01.6.0-1

kmscon recommends no packages.

kmscon suggests no packages.

Bug#1061684: netdata-plugins-python: please drop extraneous/obsolete dependency on python3-six

[Alexandre Detiste]

Package: netdata-plugins-python
Version: 1.43.2-1
Severity: normal

Dear Maintainer,

Upstream a removed support for Python2 and usage on python3-six.

Last remaining traces upstream is the Six vendored inside
the vendored Urrlib3 that is devendored completely in Debian.

$ grep six -r /usr/lib/netdata/python.d/
$ 


So please remove python3-six from debian/control.


Greetings



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

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

Versions of packages netdata-plugins-python depends on:
ii  netdata-core 1.43.2-1+b1
ii  python3  3.11.6-1
ii  python3-six  1.16.0-4
ii  python3-urllib3  2.0.7-1
ii  python3-yaml 6.0.1-2

netdata-plugins-python recommends no packages.

Versions of packages netdata-plugins-python suggests:
ii  python3-psycopg2  2.9.9-1+b1
pn  python3-pymysql   
ii  python3-requests  2.31.0+dfsg-1

-- no debconf information

Bug#1053945: seaborn: test-failing warning in pandas 2.1

[Rebecca N. Palmer]

The above by itself wasn't enough, but what I have now pushed to Salsa 
is.  Please upload it.

Bug#1061660: liblwp-protocol-https-perl: Fail to verify certificates

[Christian Marillat]

On 28 janv. 2024 18:17, gregor herrmann  wrote:

[...]

> Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1
> from testing? If yes, which of the two hunks from [0] is causing the
> problem?

This issue doesn't exist with 6.11-1. I've seen this bug when 6.12 has
been installed.

The attached patch isn't clean :

,
| $ cat ~/https.diff |sudo patch -p1 -R --dry-run 
| checking file usr/share/perl5/LWP/Protocol/https.pm
| Hunk #1 succeeded at 40 with fuzz 2 (offset -16 lines).
| Hunk #2 FAILED at 96.
| 1 out of 2 hunks FAILED
`

> Do the errors from qa.debian.org go away if you run uscan as
> "PERL_LWP_SSL_VERIFY_HOSTNAME=1 uscan …"?

Still the same. I also this bug with gitlab.

Christian

Bug#1044076: influxdb-python and pandas 2.1

[Rebecca N. Palmer]

That's not the only problem: some of the tests mix timestamps in 
slightly different formats (with and without fractional seconds), which 
is no longer allowed by default:

https://pandas.pydata.org/pandas-docs/version/2.1.4/whatsnew/v2.0.0.html#datetimes-are-now-parsed-with-a-consistent-format

The fix I currently have at
https://salsa.debian.org/rnpalmer-guest/influxdb-python
avoids this by changing the test data format, but I don't know enough 
about influxdb-python to say whether this is something that would come 
up in actual use.

Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression

[Julian Gilbey]

Hi Nilesh,

You did the last upload of this package - do you have any idea about
this bug?

Best wishes,

   Julian

- Forwarded message from Paul Gevers  -

Date: Sun, 28 Jan 2024 08:50:51 +0100
From: Paul Gevers 
Subject: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to
testing for too long: i386 autopkgtest regression
To: sub...@bugs.debian.org

Source: golang-github-hanwen-go-fuse
Version: 2.1.0+git20220822.58a7e14-1
Severity: serious
Control: close -1 2.4.2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing and
unstable for more than 30 days as having a Release Critical bug in testing
[1]. Your package src:golang-github-hanwen-go-fuse has been trying to migrate
for 31 days [2]. Hence, I am filing this bug. The version in unstable fails
its own autopkgtest on i386.

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

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

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

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

Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=golang-github-hanwen-go-fuse





- End forwarded message -

Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix

[Simon McVittie]

On Wed, 27 Dec 2023 at 14:18:25 +0100, Alexandre Detiste wrote:
> We agreed that there is too much intelligence in the generated, "unfixable"
> (unless someone takes the time to repack the game), generated .deb's;
> and that some or most of this intelligence should be moved
> to automatically upgradable game-data-packager-runtime.

The more often I see bugs in our generated .deb that cannot be fixed
without regenerating and reinstalling the .deb, which we could have
fixed in a new upload if it was structured differently, the more sure
I am that this is the way we should be going.

As a design principle, we should be trying to make sure that each generated
.deb only contains:

- files that we cannot legally redistribute
- an absolute minimum of "glue" which is so simple that it cannot have bugs
  (for example a symlink to an executable, icon or .desktop file provided
  by g-d-p-runtime is usually better than shipping an executable, icon
  or .desktop file in the generated .deb itself)

> So actually (option a) the .desktop file would looks like this:
> > > +Exec=/usr/share/games/game-data-packager[runtime] 
> > > fate-of-atlantis-en-data

The .desktop file, itself, is something that can have bugs (for example
missing Keywords, or referencing an icon that no longer exists), and
there is no legal or technical reason why we can't write .desktop files
that are Free Software and put them in game-data-packager-runtime, which
would let us fix their bugs whenever we want to by uploading a new version
of g-d-p. So we might as well do that!

> [option c proposal]
> pre-generated .desktop files shipped in game-data-packager-runtime at a
> unusual place & a symlink in the generated .deb's to activate it

Yes, this is the way.

We already generate ut99.deb containing a symlink
/usr/share/applications/ut99.desktop -> 
../games/game-data-packager-runtime/ut99.desktop
pointing to a .desktop file that we can change as much as we want to.
More of this, please!

I see that Sébastien has been contributing launcher glue for old
binary-only Loki games like Railroad Tycoon 2, and this seems a completely
reasonable way to handle such games.

But, having said that:

> option 'a' would implies that g-d-p-runtime has access to g-d-p data to
> make the magic happen; a dependency we don't currently have

Whenever we find a situation where we want this, we can ship a
subset of g-d-p data in g-d-p-runtime. We effectively already
*do* ship a subset of g-d-p data in g-d-p-runtime: the files
/usr/share/games/game-data-packager-runtime/launch-*.json contain inputs
for the gdp-launcher multi-engine launcher.

As an implementation choice, we've separated the data for g-d-p
(data/ut99.yaml) from the data for the launcher (data/launch-ut99.yaml.in),
but we can restructure that any time we want to - the exact division
between those two is private to the game-data-packager source package, and
does not form part of a stable API.

(For scummvm, where all the games follow a common pattern and have
more similarities than differences, it would perhaps be better to
have a dedicated scummvm launcher rather than reusing the multi-engine
gdp-launcher program, but either is fine.)

The closest thing to a stable API here is that iortcw and openjk rely on
the existence of /usr/share/games/game-data-packager-runtime/gdp-launcher,
and the fact that when run as "openjk_sp" or similar, it knows how to look
up what game to launch.

> That could be an extra, tiny, scummvm.json generated at build time
> with the absolute minimal required infos:
> the mapping from package name to scummvm-id-of-the-day,
> + ... ?

Yes, this.

smcv

Bug#1061595: Debian Live 12.4.0 AMD64 Xfce Fails to Start Its Graphical Environment

[Jonathan Carter]

I couldn't reproduce the xfce issue, it started just fine on a Dell 
Optiplex 7010. Did you run sync after the dd completed?

Bug#1061660: liblwp-protocol-https-perl: Fail to verify certificates

[gregor herrmann]

Control: tag -1 + unreproducible

On Sun, 28 Jan 2024 09:07:00 +0100, Christian Marillat wrote:

> uscan from devscipts package fail to verify certificates afetr upgrading
> to liblwp-protocol-https-perl 6.12-1

Thanks for your bug report.
 
> ,
> | uscan warn: In watchfile debian/watch, reading webpage
> |   https://qa.debian.org/watch/sf.php/pcre/ failed: 500 SSL upgrade failed: 
> hostname verification failed
> | uscan warn: In watchfile debian/watch, reading webpage
> |   https://qa.debian.org/watch/sf.php/mjpeg/ failed: 500 SSL upgrade failed: 
> hostname verification failed
> | uscan warn: In watchfile debian/watch, reading webpage
> |   https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags failed: 500 SSL upgrade 
> failed: SSL connect attempt failed error:0A000410:SSL routines::sslv3 alert 
> handshake failure
> | uscan warn: In watchfile debian/watch, reading webpage
> |   https://qa.debian.org/watch/sf.php/synfig/ failed: 500 SSL upgrade 
> failed: hostname verification failed
> `

I was a bit skeptical that these issues come from
liblwp-protocol-https-perl, as the changes between 6.11 and 6.12 are
small[0], and the errors sound like different issues:
- "hostname verification failed" might be the change in HTTP::Tiny …
  or no, as that validates SSL certs; the error "hostname verification
  failed" comes from libio-socket-ssl-perl
- "routines::sslv3 alert handshake failure" sounds like an openssl
  configuration thing


Interestingly I can't reproduce the issue which makes diving into the
problem a bit hard:


% cat qa-sf-watch 
version=4
https://qa.debian.org/watch/sf.php/pcre/ .*@ANY_VERSION@@ARCHIVE_EXT@


% cat gitlab-watch 
version=4
https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags .*@ANY_VERSION@@ARCHIVE_EXT@


% for w in qa-sf-watch gitlab-watch; do uscan --report --watchfile $w --package 
abc --upstream-version 123; done
%


Does it work for you if you downgrade liblwp-protocol-https-perl to 6.11-1
from testing? If yes, which of the two hunks from [0] is causing the
problem?
Do the errors from qa.debian.org go away if you run uscan as
"PERL_LWP_SSL_VERIFY_HOSTNAME=1 uscan …"?


Does anyone else reading along have any ideas?


Cheers,
gregor


[0]
diff --git a/lib/LWP/Protocol/https.pm b/lib/LWP/Protocol/https.pm
index 16fce19..01a800b 100644
--- a/lib/LWP/Protocol/https.pm
+++ b/lib/LWP/Protocol/https.pm
@@ -56,7 +56,7 @@ EOT
 }
 }
 $self->{ssl_opts} = \%ssl_opts;
-return (%ssl_opts, $self->SUPER::_extra_sock_opts);
+return (%ssl_opts, MultiHomed => 1, $self->SUPER::_extra_sock_opts);
 }

 # This is a subclass of LWP::Protocol::http.
@@ -96,9 +96,12 @@ sub _get_sock_info
 if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
 *_upgrade_sock = sub {
my ($self,$sock,$url) = @_;
+# SNI should be passed there only if it is not an IP address.
+# Details: 
https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
+   my $host = $url->host_port() =~ m/:|^[\d.]+$/s ? undef : $url->host();
$sock = LWP::Protocol::https::Socket->start_SSL( $sock,
SSL_verifycn_name => $url->host,
-   SSL_hostname => $url->host,
+   SSL_hostname => $host,
$self->_extra_sock_opts,
);
$@ = LWP::Protocol::https::Socket->errstr if ! $sock;

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1061683: qemu-guest-agent.service does not restart on upgrade, loosing connectivity

[Lee Garrett]

Package: qemu-guest-agent
Version: 1:7.2+dfsg-7+deb12u3
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

today I noticed one of my VMs was not accessible via the guest agent. Turns out
that during upgrade it was stopped, but not restarted again. Since it can be
used for automation, I believe it's crucial that qemu-ga service tries harder to
stay alive.

Terminal logs below.

--->8->8->8->8->8->8->8->8->8->8--

root@comms:~# systemctl status qemu-guest-agent.service
○ qemu-guest-agent.service - QEMU Guest Agent
 Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
 Active: inactive (dead) since Sun 2023-12-10 06:36:40 CET; 1 month 18 days 
ago
   Duration: 1month 3w 16h 24min 38.992s
   Main PID: 205124 (code=exited, status=0/SUCCESS)
CPU: 1min 46.804s

Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:37 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec called: "/bin/sh -c rm 
-f -r /root/.ansible/tmp/ansible-tmp-1701362549.8043833-135706-120368687298004/ 
> /dev/null 2>
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid: 
619913
Dez 10 06:36:40 comms systemd[1]: Stopping qemu-guest-agent.service - QEMU 
Guest Agent...
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Deactivated 
successfully.
Dez 10 06:36:40 comms systemd[1]: Stopped qemu-guest-agent.service - QEMU Guest 
Agent.
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Consumed 1min 
46.804s CPU time.
root@comms:~# systemctl start qemu-guest-agent.service
root@comms:~# systemctl status qemu-guest-agent.service
● qemu-guest-agent.service - QEMU Guest Agent
 Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
 Active: active (running) since Sat 2024-01-27 22:32:06 CET; 2s ago
   Main PID: 1263386 (qemu-ga)
  Tasks: 2 (limit: 9475)
 Memory: 1.8M
CPU: 28ms
 CGroup: /system.slice/qemu-guest-agent.service
 └─1263386 /usr/sbin/qemu-ga

Jan 27 22:32:06 comms systemd[1]: Started qemu-guest-agent.service - QEMU Guest 
Agent.
root@comms:~# cat /lib/systemd/system/qemu-guest-agent.service
[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device

[Service]
ExecStart=-/usr/sbin/qemu-ga
Restart=always
RestartSec=0

[Install]

root@comms:~# zless /var/log/apt/history.log.1.gz
Start-Date: 2023-12-10  06:36:40
Commandline: /usr/bin/unattended-upgrade
Upgrade: qemu-guest-agent:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3), 
qemu-utils:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3)
End-Date: 2023-12-10  06:36:42

--->8->8->8->8->8->8->8->8->8->8--


Looking at the maintainer scripts, it looks like it gets stopped by this
section in the .preinst:

# End automatically added section
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ] 
; then
deb-systemd-invoke stop 'qemu-guest-agent.service' >/dev/null || true
fi
# End automatically added section

And nothing ever starts it again. My next guess was that the systemd unit might
not have been enabled, so I tried that:

root@comms:~# systemctl enable qemu-guest-agent.service 
Synchronizing state of qemu-guest-agent.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

It seems like it's only enabled by the udev device trigger, which is never
triggered on upgrade.

I think it's missing a `systemctl start qemu-guest-agent` in .postinstall, do
you agree?

Greets,
Lee

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

Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint 

Bug#1061682: crawl-tiles: New version available

[Davide Prina]

Package: crawl-tiles
Version: 2:0.28.0-1.1
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net

Dear Mainteiner,

there is a new version upstream as you can see here:
http://crawl.develz.org/release/
and here
https://github.com/crawl/crawl/releases

I see that the uscan rule is not correct and so it don't found new
vesions. 

Ciao
Davide

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

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

Versions of packages crawl-tiles depends on:
ii  crawl-common2:0.28.0-1.1
ii  crawl-tiles-data2:0.28.0-1.1
ii  fonts-dejavu-core   2.37-8
ii  libc6   2.37-13
ii  libfreetype62.13.2+dfsg-1+b1
ii  libgcc-s1   13.2.0-10
ii  libgl1  1.7.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  liblua5.1-0 5.1.5-9
ii  libsdl2-2.0-0   2.28.5+dfsg-3
ii  libsdl2-image-2.0-0 2.8.2+dfsg-1
ii  libsqlite3-03.45.0-1
ii  libstdc++6  13.2.0-10
ii  zlib1g  1:1.3.dfsg-3+b1

crawl-tiles recommends no packages.

crawl-tiles suggests no packages.

-- no debconf information