Bug#1064099: xfce4-session should recommend or suggest libglib2.0-bin for xflock4 to work

2024-02-16 Thread pdormeau
Package: xfce4-session
Version: 4.19.1-1
Severity: minor

Dear Maintainer,

xflock4 makes use of gdbus which is part of libglib2.0-bin package.

Regards

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

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

Versions of packages xfce4-session depends on:
ii  libatk1.0-02.50.0-1+b1
ii  libc6  2.37-15
ii  libcairo-gobject2  1.18.0-1+b1
ii  libcairo2  1.18.0-1+b1
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-3+b1
ii  libglib2.0-0   2.78.4-1
ii  libgtk-3-0 3.24.41-1
ii  libice62:1.0.10-1
ii  libpango-1.0-0 1.51.0+ds-4
ii  libpolkit-gobject-1-0  124-1
ii  libsm6 2:1.2.3-1
ii  libwnck-3-043.0-3
ii  libx11-6   2:1.8.7-1
ii  libxfce4ui-2-0 4.19.3-1
ii  libxfce4util7  4.19.2-1
ii  libxfconf-0-3  4.19.1-1
ii  x11-xserver-utils  7.7+10
ii  xfce4-settings 4.18.3-1
ii  xfconf 4.19.1-1

Versions of packages xfce4-session recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4
ii  dbus-x11 [dbus-session-bus]   1.14.10-4
ii  libpam-systemd [logind]   255.3-2
ii  systemd-sysv  255.3-2
ii  upower1.90.2-8
ii  xfce4-screensaver 4.18.2-1
ii  xfdesktop44.19.1-1
ii  xfwm4 4.18.0-1

Versions of packages xfce4-session suggests:
pn  fortune-mod  
ii  sudo 1.9.15p5-3

-- no debconf information



Bug#1064098: hepmc3: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: hepmc3
Version: 3.1.2-2
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
hepmc3 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 hepmc3
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'), (500, 'testing'), (500, 'stable'), (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 hepmc3-3.1.2/debian/changelog hepmc3-3.1.2/debian/changelog
--- hepmc3-3.1.2/debian/changelog   2019-09-19 06:14:37.0 +
+++ hepmc3-3.1.2/debian/changelog   2024-02-17 07:11:14.0 +
@@ -1,3 +1,10 @@
+hepmc3 (3.1.2-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sat, 17 Feb 2024 07:11:14 +
+
 hepmc3 (3.1.2-2) unstable; urgency=medium
 
   * Move doxygen from B-D-I to B-D. (Closes: #933629)
diff -Nru hepmc3-3.1.2/debian/control hepmc3-3.1.2/debian/control
--- hepmc3-3.1.2/debian/control 2019-09-19 04:23:06.0 +
+++ hepmc3-3.1.2/debian/control 2024-02-17 07:11:13.0 +
@@ -10,13 +10,16 @@
 Vcs-Git: https://salsa.debian.org/science-team/hepmc3.git
 Vcs-Browser: https://salsa.debian.org/science-team/hepmc3
 
-Package: libhepmc3
+Package: libhepmc3t64
+Provides: ${t64:Provides}
+Replaces: libhepmc3
+Breaks: libhepmc3 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: libhepmc3-search
+Recommends: libhepmc3t64-search
 Suggests: libhepmc3-dev, libhepmc3-search-dev
 Description: Event Record for Monte Carlo Generators
  The HepMC package is an object oriented event record written in C++ for
@@ -39,7 +42,7 @@
 Package: libhepmc3-dev
 Section: libdevel
 Architecture: any
-Depends: libhepmc3 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Depends: libhepmc3t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Recommends: libhepmc3-search-dev
 Suggests: hepmc3-doc
 Description: Event Record for Monte Carlo Generators - development files
@@ -60,10 +63,14 @@
  .
  This package provides development files for HepMC3.
 
-Package: libhepmc3-search
+Package: libhepmc3t64-search
+Provides: ${t64:Provides}
+X-Time64-Compat: libhepmc3-search
+Replaces: libhepmc3-search
+Breaks: libhepmc3-search (<< ${source:Version})
 Section: libs
 Architecture: any
-Depends: libhepmc3 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Depends: libhepmc3t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Suggests: hepmc3-doc
 Description: Monte Carlo event record FIO library -  search engine
  The HepMC package is an object oriented event record written in C++ for
@@ -86,7 +93,7 @@
 Package: libhepmc3-search-dev
 Section: libdevel
 Architecture: any
-Depends: libhepmc3-search (= ${binary:Version}), ${shlibs:Depends}, 
${misc:Depends}
+Depends: libhepmc3t64-search (= ${binary:Version}), ${shlibs:Depends}, 
${misc:Depends}
 Suggests: hepmc3-doc
 Description: Event Record for Monte Carlo Generators - development files for 
search engine
  The HepMC package is an object oriented event record written in C++ for
@@ -110,7 +117,7 @@
 Section: doc
 

Bug#1064096: gir-rust-code-generator FTBFS with librust-toml-dev 0.8

2024-02-16 Thread Adrian Bunk
Source: gir-rust-code-generator
Version: 0.18.3-1
Severity: serious
Tags: ftbfs
Control: close -1 0.19.0-1

https://buildd.debian.org/status/fetch.php?pkg=gir-rust-code-generator=sparc64=0.18.3-1=1708096231=0
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gir-rust-code-generator.html

...
   dh_auto_test -a -O--buildsystem=cargo
debian cargo wrapper: options, profiles, parallel, lto: ['parallel=16'] [] 
['-j16'] 0
debian cargo wrapper: rust_type, gnu_type: sparc64-unknown-linux-gnu, 
sparc64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', 
'-j16', '--target', 'sparc64-unknown-linux-gnu'],) {}
error: failed to select a version for the requirement `toml = "^0.7"`
candidate versions found which didn't match: 0.8.8
...
make: *** [debian/rules:16: binary-arch] Error 25



Bug#982010: Can sponsor vimb

2024-02-16 Thread Abhijith PA
Hello Mateusz.

I was lurking on mentors.debian.net and I found your package vimb. 
Seems like a nice package to have. I saw that you are looking for a 
sponsor. Well I can sponsor vimb package for you. Let me know. 

Thank you.

--a



Bug#1061866: adns: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
On Wed, Feb 07, 2024 at 07:05:22PM +, Ian Jackson wrote:
> Control: severity -1 important

> Ian Jackson writes ("Re: Bug#1061866: adns: NMU diff for 64-bit time_t 
> transition"):
> > I have just got an alert saying adns is now scheduled for autoremoval
> > due to #1061866.

> > My understanding was that you were intending to NMU to unstable after
> > "several days".  I have been holding off making an upload myself so as
> > not to interfere.

> I'm not sure if I should:

>  (i) wait

>  (ii) apply that patch (on top of what's in experimental)
>   and upload to experimental

>  (iii) apply that patch on top of what's in experimental
>and upload the result to sid.

> For now I am going to downgrade this bug in the hope that the current
> answer is (i).

> Regards,
> Ian.

Sorry for not being able to respond sooner.  Yes, 'wait' is the correct
answer.  The autoremoval warnings were an unexpected but foreseeable
side-effect.

-- 
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


signature.asc
Description: PGP signature


Bug#1064094: setuptools-scm-git-archive shouldn't be in trixie

2024-02-16 Thread Esa Peuha
Source: setuptools-scm-git-archive
Severity: serious

setuptools-scm-git-archive shouldn't be released as part of trixie.
It's broken with setuptools-scm 8 [1] and redundant starting with
setuptools-scm 7 [2], there is a removal request from unstable [3],
and apparently all the remaining source packages that still have
a build-dependency on it will remove it in future uploads.

[1] https://ci.debian.net/packages/s/setuptools-scm-git-archive
[2] https://github.com/Changaco/setuptools_scm_git_archive
[3] https://bugs.debian.org/1060027



Bug#1063298: xrootd: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
On Thu, Feb 08, 2024 at 06:09:57PM +0100, Mattias Ellert wrote:
> The package was updated in unstable

> xrootd 5.6.7-1

> If/when you update the package in experimental for the transition,
> please include the missing change in debian/rules mentioned in a
> previous comment to this bug.

Thanks. updated patch attached!


-- 
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
diff -Nru xrootd-5.6.7/debian/changelog xrootd-5.6.7/debian/changelog
--- xrootd-5.6.7/debian/changelog   2024-02-08 14:47:53.0 +
+++ xrootd-5.6.7/debian/changelog   2024-02-17 05:10:21.0 +
@@ -1,3 +1,10 @@
+xrootd (5.6.7-1.1~exp1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sat, 17 Feb 2024 05:10:21 +
+
 xrootd (5.6.7-1) unstable; urgency=medium
 
   * Update to version 5.6.7
diff -Nru xrootd-5.6.7/debian/control xrootd-5.6.7/debian/control
--- xrootd-5.6.7/debian/control 2023-12-11 16:15:37.0 +
+++ xrootd-5.6.7/debian/control 2024-02-17 05:10:02.0 +
@@ -72,7 +72,10 @@
  database servers. It provides enhanced capability along with lower
  latency and increased throughput.
 
-Package: libxrdapputils2
+Package: libxrdapputils2t64
+Provides: ${t64:Provides}
+Replaces: libxrdapputils2
+Breaks: libxrdapputils2 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -82,7 +85,10 @@
 Description: Utilities library for xrootd applications
  This package contains the xrootd utilities library for applications.
 
-Package: libxrdcrypto2
+Package: libxrdcrypto2t64
+Provides: ${t64:Provides}
+Replaces: libxrdcrypto2
+Breaks: libxrdcrypto2 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -92,7 +98,10 @@
 Description: Cryptograpic library for xrootd
  This package contains the xrootd cryptograpic library.
 
-Package: libxrdcryptolite2
+Package: libxrdcryptolite2t64
+Provides: ${t64:Provides}
+Replaces: libxrdcryptolite2
+Breaks: libxrdcryptolite2 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -102,23 +111,27 @@
 Description: Light version of cryptograpic library for xrootd
  This package contains the light version of the xrootd cryptograpic library.
 
-Package: libxrdutils3
+Package: libxrdutils3t64
+Provides: ${t64:Provides}
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends:
  ${shlibs:Depends},
  ${misc:Depends}
-Replaces:
+Replaces:libxrdutils3, 
  libxrdcephposix0 [i386 armel armhf mips mipsel powerpc],
  xrootd-ceph-plugins [i386 armel armhf mips mipsel powerpc]
-Breaks:
+Breaks:libxrdutils3 (<< ${source:Version}), 
  libxrdcephposix0 [i386 armel armhf mips mipsel powerpc],
  xrootd-ceph-plugins [i386 armel armhf mips mipsel powerpc]
 Description: Utilities library for xrootd
  This package contains the xrootd utilities library.
 
-Package: libxrdxml3
+Package: libxrdxml3t64
+Provides: ${t64:Provides}
+Replaces: libxrdxml3
+Breaks: libxrdxml3 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -143,17 +156,20 @@
 Multi-Arch: same
 Section: libdevel
 Depends:
- libxrdapputils2 (= ${binary:Version}),
- libxrdcrypto2 (= ${binary:Version}),
- libxrdcryptolite2 (= ${binary:Version}),
- libxrdutils3 (= ${binary:Version}),
- libxrdxml3 (= ${binary:Version}),
+ libxrdapputils2t64 (= ${binary:Version}),
+ libxrdcrypto2t64 (= ${binary:Version}),
+ libxrdcryptolite2t64 (= ${binary:Version}),
+ libxrdutils3t64 (= ${binary:Version}),
+ libxrdxml3t64 (= ${binary:Version}),
  ${misc:Depends}
 Description: Development files for xrootd
  This package contains header files and development libraries for xrootd
  development.
 
-Package: libxrdcl3
+Package: libxrdcl3t64
+Provides: ${t64:Provides}
+Replaces: libxrdcl3
+Breaks: libxrdcl3 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -166,7 +182,10 @@
 Description: Client library for xrootd
  This package contains the xrootd client library.
 
-Package: libxrdec1
+Package: libxrdec1t64
+Provides: ${t64:Provides}
+Replaces: libxrdec1
+Breaks: libxrdec1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -176,7 +195,10 @@
 Description: Erasure code library for xrootd
  This package contains the xrootd erasure code library.
 
-Package: libxrdffs3
+Package: libxrdffs3t64
+Provides: ${t64:Provides}
+Replaces: libxrdffs3
+Breaks: libxrdffs3 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -186,7 +208,10 @@
 Description: File protocol library for xrootd
  This package contains the xrootd file protocol library.
 
-Package: libxrdposix3
+Package: libxrdposix3t64
+Provides: ${t64:Provides}
+Replaces: libxrdposix3
+Breaks: 

Bug#1064093: gyoto: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: gyoto
Version: 2.0.2-1
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
gyoto 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 gyoto
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'), (500, 'testing'), (500, 'stable'), (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 gyoto-2.0.2/debian/changelog gyoto-2.0.2/debian/changelog
--- gyoto-2.0.2/debian/changelog2024-01-19 20:57:12.0 +
+++ gyoto-2.0.2/debian/changelog2024-02-17 04:28:42.0 +
@@ -1,3 +1,10 @@
+gyoto (2.0.2-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sat, 17 Feb 2024 04:28:42 +
+
 gyoto (2.0.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gyoto-2.0.2/debian/control gyoto-2.0.2/debian/control
--- gyoto-2.0.2/debian/control  2024-01-19 20:39:18.0 +
+++ gyoto-2.0.2/debian/control  2024-02-17 04:28:42.0 +
@@ -69,7 +69,10 @@
  MPI parallelization requires the mpi-default-bin package. Producing
  videos requires the python3-gyoto and python3-opencv packages.
 
-Package: libgyoto9
+Package: libgyoto9t64
+Provides: ${t64:Provides}
+Replaces: libgyoto9
+Breaks: libgyoto9 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
@@ -96,7 +99,7 @@
 Multi-Arch: same
 Section: libdevel
 Depends: ${shlibs:Depends}, ${misc:Depends},
- libgyoto9 (= ${binary:Version}),
+ libgyoto9t64 (= ${binary:Version}),
  libc-dev, libxerces-c-dev, libcfitsio-dev, libudunits2-dev,
  libboost-dev (>= 1.53.1), libboost-mpi-dev, mpi-default-dev,
  pkg-config
diff -Nru gyoto-2.0.2/debian/libgyoto9.examples 
gyoto-2.0.2/debian/libgyoto9.examples
--- gyoto-2.0.2/debian/libgyoto9.examples   2024-01-19 20:39:18.0 
+
+++ gyoto-2.0.2/debian/libgyoto9.examples   1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-doc/examples/*
diff -Nru gyoto-2.0.2/debian/libgyoto9.install 
gyoto-2.0.2/debian/libgyoto9.install
--- gyoto-2.0.2/debian/libgyoto9.install2024-01-19 20:39:18.0 
+
+++ gyoto-2.0.2/debian/libgyoto9.install1970-01-01 00:00:00.0 
+
@@ -1,2 +0,0 @@
-usr/lib/*/libgyoto.so.?.?.?
-usr/lib/*/gyoto/*/libgyoto*.so*
diff -Nru gyoto-2.0.2/debian/libgyoto9.links gyoto-2.0.2/debian/libgyoto9.links
--- gyoto-2.0.2/debian/libgyoto9.links  2024-01-19 20:39:18.0 +
+++ gyoto-2.0.2/debian/libgyoto9.links  1970-01-01 00:00:00.0 +
@@ -1,4 +0,0 @@
-#! /bin/sh
-src=`ls debian/tmp/usr/lib/*/libgyoto.so.?.?.? | sed 's|debian/tmp/||'`
-dst=`echo $src | sed 's/\.[0-9]*\.[0-9]*$//'`
-echo $src $dst
diff -Nru gyoto-2.0.2/debian/libgyoto9t64.examples 
gyoto-2.0.2/debian/libgyoto9t64.examples
--- gyoto-2.0.2/debian/libgyoto9t64.examples1970-01-01 00:00:00.0 
+
+++ gyoto-2.0.2/debian/libgyoto9t64.examples2024-01-19 20:39:18.0 
+
@@ -0,0 +1 @@
+doc/examples/*
diff -Nru gyoto-2.0.2/debian/libgyoto9t64.install 
gyoto-2.0.2/debian/libgyoto9t64.install
--- gyoto-2.0.2/debian/libgyoto9t64.install 1970-01-01 00:00:00.0 
+

Bug#1050383: reverting the fix

2024-02-16 Thread Thomas Lange
Hi,

I will revert this fix in FAI 6.2.1, because it broke other
things. Our LVM on soft RAID example does not work any more.

You application of using a hook for creating a md device and then set
disklist=/dev/md is not what setup-storage supports.
Why not use your heuristic and create then the disklist (of plain
disks) and let setup-storage create the md devices?

I'm not sure if we can fix your problem without breaking the normal
configs.

-- 
regards Thomas



Bug#1064086: Acknowledgement (/usr/share/doc/libapache2-mod-netcgi-apache/changelog.gz: libapache2-mod-netcgi-apache break apache)

2024-02-16 Thread Frédéric Loyer
We can fix it changing the /etc/apache2/mods-available/netcgi_apache.load

Simply changing the first line

LoadModule netcgi_module /usr/lib/apache2/modules/mod_netcgi_apache.so

(netcgi_module instead of netcgi_apache_module)

—
However, I had a new error:

[Sat Feb 17 05:05:36 2024] [Netcgi_apache_mod] error loading shared library: 
Sys_error("/usr/lib/ocaml/netcgi2-apache/netcgi_apache.cma: No such file or 
directory")

Curiously the netcgi_apache.load has the line

NetcgiRequire netcgi2-apache

And it search a netcgi_apache.cma file. 

--
Frédéric Loyer

> Le 17 févr. 2024 à 01:45, Debian Bug Tracking System  
> a écrit :
> 
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1064086: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064086.
> 
> 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 OCaml Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 1064...@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.
> 
> --
> 1064086: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064086
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



Bug#1064092: RFS: bitwise/0.50-1 -- Interactive bitwise operation in ncurses

2024-02-16 Thread Ramon Fried
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : bitwise
   Version  : 0.50-1
   Upstream contact : Ramon Fried 
 * URL  : https://github.com/mellowcandle/bitwise
 * License  : BSD-2-clause, GPL-3.0+, GFDL
 * Vcs  : [fill in URL of packaging vcs]
   Section  : science

The source builds the following binary packages:

  bitwise - Interactive bitwise operation in ncurses

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bitwise/bitwise_0.50-1.dsc

Changes since the last upload:

 bitwise (0.50-1) unstable; urgency=medium
 .
   * Bump to version 0.50
 Enhancements:
 - Add r command to reverse endianness (@tianrui-wei)
 - Allow shortening of commands (@soleen)
 Bug Fixes:
 - Disable mouse events in interactive command mode
 - Fix backward key not working in some terminals
 - Fix divide by zero crash
 - Fit bit function overflow (@soleen)
   * debian: update to standards version: 4.6.2
   * debian: Change build-depends (debhelper-compat to debhelper)
   * debian: Update copyright year
   * debian: Fix debian watch regex

Regards,
-- 
  Ramon Fried



Bug#1064091: hdf-eos4: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: hdf-eos4
Version: 2.20v1.00-1
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
hdf-eos4 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 hdf-eos4
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'), (500, 'testing'), (500, 'stable'), (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 hdf-eos4-2.20v1.00/debian/changelog 
hdf-eos4-2.20v1.00/debian/changelog
--- hdf-eos4-2.20v1.00/debian/changelog 2018-05-31 13:09:40.0 +
+++ hdf-eos4-2.20v1.00/debian/changelog 2024-02-17 03:44:04.0 +
@@ -1,3 +1,10 @@
+hdf-eos4 (2.20v1.00-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sat, 17 Feb 2024 03:44:04 +
+
 hdf-eos4 (2.20v1.00-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru hdf-eos4-2.20v1.00/debian/control hdf-eos4-2.20v1.00/debian/control
--- hdf-eos4-2.20v1.00/debian/control   2018-05-31 13:09:40.0 +
+++ hdf-eos4-2.20v1.00/debian/control   2024-02-17 03:44:03.0 +
@@ -14,7 +14,10 @@
  libgctp-dev,
  zlib1g-dev
 
-Package: libhdfeos0
+Package: libhdfeos0t64
+Provides: ${t64:Provides}
+Replaces: libhdfeos0
+Breaks: libhdfeos0 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -30,7 +33,7 @@
 Package: libhdfeos-dev
 Architecture: any
 Section: libdevel
-Depends: libhdfeos0 (= ${binary:Version}), ${misc:Depends}
+Depends: libhdfeos0t64 (= ${binary:Version}), ${misc:Depends}
 Multi-Arch: same
 Recommends: pkg-config
 Description:  Development files for the HDF-EOS4 library
diff -Nru hdf-eos4-2.20v1.00/debian/libhdfeos0.docs 
hdf-eos4-2.20v1.00/debian/libhdfeos0.docs
--- hdf-eos4-2.20v1.00/debian/libhdfeos0.docs   2018-05-31 13:09:40.0 
+
+++ hdf-eos4-2.20v1.00/debian/libhdfeos0.docs   1970-01-01 00:00:00.0 
+
@@ -1,2 +0,0 @@
-doc/HDFEOS-DEFINITION.TXT
-debian/README.sources
diff -Nru hdf-eos4-2.20v1.00/debian/libhdfeos0.install 
hdf-eos4-2.20v1.00/debian/libhdfeos0.install
--- hdf-eos4-2.20v1.00/debian/libhdfeos0.install2018-05-31 
13:09:40.0 +
+++ hdf-eos4-2.20v1.00/debian/libhdfeos0.install1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libhdfeos.so.*
diff -Nru hdf-eos4-2.20v1.00/debian/libhdfeos0.shlibs 
hdf-eos4-2.20v1.00/debian/libhdfeos0.shlibs
--- hdf-eos4-2.20v1.00/debian/libhdfeos0.shlibs 2018-05-31 13:09:40.0 
+
+++ hdf-eos4-2.20v1.00/debian/libhdfeos0.shlibs 1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-libhdfeos 0 libhdfeos0
diff -Nru hdf-eos4-2.20v1.00/debian/libhdfeos0t64.docs 
hdf-eos4-2.20v1.00/debian/libhdfeos0t64.docs
--- hdf-eos4-2.20v1.00/debian/libhdfeos0t64.docs1970-01-01 
00:00:00.0 +
+++ hdf-eos4-2.20v1.00/debian/libhdfeos0t64.docs2018-05-31 
13:09:40.0 +
@@ -0,0 +1,2 @@
+doc/HDFEOS-DEFINITION.TXT
+debian/README.sources
diff -Nru hdf-eos4-2.20v1.00/debian/libhdfeos0t64.install 
hdf-eos4-2.20v1.00/debian/libhdfeos0t64.install
--- hdf-eos4-2.20v1.00/debian/libhdfeos0t64.install 1970-01-01 
00:00:00.0 +
+++ 

Bug#1064090: hamlib: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: hamlib
Version: 4.5.5-3
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
hamlib 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 hamlib
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'), (500, 'testing'), (500, 'stable'), (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 hamlib-4.5.5/debian/changelog hamlib-4.5.5/debian/changelog
--- hamlib-4.5.5/debian/changelog   2023-11-27 16:01:42.0 +
+++ hamlib-4.5.5/debian/changelog   2024-02-17 03:23:46.0 +
@@ -1,3 +1,10 @@
+hamlib (4.5.5-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sat, 17 Feb 2024 03:23:46 +
+
 hamlib (4.5.5-3) unstable; urgency=medium
 
   * Team upload
diff -Nru hamlib-4.5.5/debian/control hamlib-4.5.5/debian/control
--- hamlib-4.5.5/debian/control 2023-11-27 16:01:42.0 +
+++ hamlib-4.5.5/debian/control 2024-02-17 03:23:45.0 +
@@ -32,7 +32,9 @@
 Vcs-Git: https://salsa.debian.org/debian-hamradio-team/hamlib.git
 Rules-Requires-Root: no
 
-Package: libhamlib4
+Package: libhamlib4t64
+Provides: ${t64:Provides}
+Replaces: libhamlib4
 Architecture: any
 Section: libs
 Multi-Arch: same
@@ -41,7 +43,7 @@
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
-Breaks:
+Breaks:libhamlib4 (<< ${source:Version}), 
  wsjtx (<< 2.4.0~),
  libhamlib-utils (<< 4.1),
 Description: Run-time library to control radio transceivers and receivers
@@ -57,7 +59,10 @@
  This package provides the C run-time form of the library. If you wish to
  develop software using this library you need the 'libhamlib-dev' package.
 
-Package: libhamlib++4
+Package: libhamlib++4t64
+Provides: ${t64:Provides}
+Replaces: libhamlib++4
+Breaks: libhamlib++4 (<< ${source:Version})
 Architecture: any
 Section: libs
 Multi-Arch: same
@@ -85,7 +90,7 @@
 Multi-Arch: same
 Depends:
  libc6-dev,
- libhamlib4 (= ${binary:Version}),
+ libhamlib4t64 (= ${binary:Version}),
  libusb-1.0-0-dev [linux-any hurd-any],
  ${misc:Depends},
 Description: Development library to control radio transceivers and receivers
@@ -108,9 +113,9 @@
 Multi-Arch: same
 Depends:
  libc6-dev,
- libhamlib++4 (= ${binary:Version}),
+ libhamlib++4t64 (= ${binary:Version}),
  libhamlib-dev (= ${binary:Version}),
- libhamlib4 (= ${binary:Version}),
+ libhamlib4t64 (= ${binary:Version}),
  ${misc:Depends},
 Description: Development C++ library to control radio transceivers and 
receivers
  Most recent amateur radio transceivers allow external control of their
@@ -193,7 +198,7 @@
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
- libhamlib4 (= ${binary:Version}),
+ libhamlib4t64 (= ${binary:Version}),
 Description: Utilities to support the hamlib radio control library
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
diff -Nru hamlib-4.5.5/debian/libhamlib++4.install 
hamlib-4.5.5/debian/libhamlib++4.install
--- hamlib-4.5.5/debian/libhamlib++4.install2023-11-27 16:01:42.0 
+
+++ hamlib-4.5.5/debian/libhamlib++4.install1970-01-01 

Bug#1064057: wsdd: Should install to /usr/bin/ instead of /usr/sbin/

2024-02-16 Thread Jeremy Bícha
On Fri, Feb 16, 2024 at 10:08 PM Matt Grant  wrote:
>
> Symlinking /usr/sbin/wsdd to /usr/bin to fix this path issue.
>
> 0.7.1 has the wsdd manpage in section 8.  IMHO Gvfs should execute wsdd
> from /usr/sbin as wsdd is not purely a user executable binary, but
> mostly used with Samba servers.

I think that deciding where to install a package based on its manpage
section could be backwards, but projects should include installers too
instead of leaving distros to figure it out.

I opened https://github.com/christgau/wsdd/issues/198 to request that
the manpage be moved to section 1.

While you originally packaged wsdd for Samba servers, I expect that it
will actually be used by far more people who are not running Samba
servers now that gvfs-daemons recommends it.

I don't think it is necessary or helpful at all to have wsdd
additionally in /usr/sbin/ . Arch Linux and Fedora package it as
/usr/bin/wsdd . I am unaware of any Debian package that has a symlink
/usr/bin/foo to /usr/sbin/foo (or the reverse).

https://src.fedoraproject.org/rpms/wsdd/blob/rawhide/f/wsdd.spec#_36
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wsdd#n25

Thank you,
Jeremy Bícha



Bug#1064089: gutenprint: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: gutenprint
Version: 5.3.4.20220624T01008808d602-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
gutenprint 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 gutenprint.

Please find the patch for this NMU attached.

Unfortunately, due to unrelated bugs (bug #1064088), your package fails to
build in unstable and therefore we will not be uploading an NMU for this.

-- 
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


signature.asc
Description: PGP signature


Bug#1064057: wsdd: Should install to /usr/bin/ instead of /usr/sbin/

2024-02-16 Thread Matt Grant

Symlinking /usr/sbin/wsdd to /usr/bin to fix this path issue.

0.7.1 has the wsdd manpage in section 8.  IMHO Gvfs should execute wsdd 
from /usr/sbin as wsdd is not purely a user executable binary, but 
mostly used with Samba servers.


On 17/02/24 03:40, Jeremy Bícha wrote:

Source: wsdd
Version: 2:0.7.0-2.1
Severity: important
Tags: patch trixie sid
Forwarded: https://salsa.debian.org/grantma/wsdd/-/merge_requests/2
Control: affects -1 src:gvfs

gvfs 1.53.90-1 now tries to use wsdd from $PATH but Debian's default
$PATH does not include /usr/sbin/

According to the latest version of the Filesystem Hierarchy System
(FHS) 3.0, § 3.16,
"/sbin contains binaries essential for booting, restoring, recovering,
and/or repairing the system in addition to the binaries in /bin. [18]
Programs executed after /usr is known to be mounted (when there are no
problems) are generally placed into /usr/sbin."

I don't believe wsdd is any of those categories.

I am filing as Important, but Serious may be appropriate. Debian
Policy § 9.1.1 requires compliance with the FHS with some exceptions
(which don't apply here).

References
---
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure

Thank you,
Jeremy Bícha




Bug#1064088: gutenprint: FTBFS in unstable

2024-02-16 Thread Steve Langasek
Source: gutenprint
Version: 5.3.4.20220624T01008808d602-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble

Dear maintainers,

gutenprint now fails to build from source in unstable.  Initially, it fails
to build because debian/libgutenprintui2-2.symbols expects symbols to be
present that are not part of this library's API but only a result of using
yacc internally.  Marking these symbols optional gets past this issue:

 (optional)yy_create_buffer@Base 5.3.0~pre1
 (optional)yy_delete_buffer@Base 5.3.0~pre1
 (optional)yy_flex_debug@Base 5.3.0~pre1
 (optional)yy_flush_buffer@Base 5.3.0~pre1
 (optional)yy_scan_buffer@Base 5.3.0~pre1
 (optional)yy_scan_bytes@Base 5.3.0~pre1
 (optional)yy_scan_string@Base 5.3.0~pre1
 (optional)yy_switch_to_buffer@Base 5.3.0~pre1
 (optional)yyalloc@Base 5.3.0~pre1
 (optional)yychar@Base 5.3.0~pre1
 (optional)yydebug@Base 5.3.1
[...]

But then the package fails because dh_missing complains about files
installed into debian/tmp not being included in any package:

[...]
make[1]: Leaving directory '/tmp/time-t/gutenprint-5.3.4.20220624T01008808d602'
   dh_missing
dh_missing: warning: usr/share/gutenprint/doc/reference-html/a2128.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/a2128.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c1723.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c1723.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c193.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c193.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c1974.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c1974.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c199.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c199.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c38.html exists in 
debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c38.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c463.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c463.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/c47.html exists in 
debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/c47.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/f14.html exists in 
debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/f14.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/index.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/index.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x1675.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x1675.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x1740.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x1740.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x2159.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x2159.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x270.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x270.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x66.html exists in 
debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x66.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x78.html exists in 
debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x78.html")
dh_missing: warning: usr/share/gutenprint/doc/reference-html/x961.html exists 
in debian/tmp but is not installed to anywhere (related file: 
"doc/developer/reference-html/x961.html")

While detecting missing files, dh_missing noted some files with a 
similar name to those
that were missing.  This error /might/ be resolved by replacing 
references to the
missing files with the similarly named ones that dh_missing found - 
assuming the content
is identical.

As an example, you might want to replace:
 * doc/developer/reference-html/a2128.html
with:
 * usr/share/gutenprint/doc/reference-html/a2128.html
in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
(Note it is possible the paths are not used verbatim but instead 
directories 
containing or globs matching them are used 

Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

2024-02-16 Thread Guillem Jover
Hi!

On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Loren M. Lang 

> * Package name: golang-github-cheggaaa-pb
>   Version : 3.1.5-1
>   Upstream Author : Sergey Cherepanov
> * URL : https://github.com/cheggaaa/pb
> * License : BSD-3-clause
>   Programming Lang: Go
>   Description : Console progress bar for Golang

> This is a dependency for pwru which is in RFP and I plan to complete packaging
> shortly. pwru is an eBPF-based Linux kernel networking debugger.

This is already packaged as:

  golang-github-cheggaaa-pb.v3-dev
  golang-gopkg-cheggaaa-pb.v2-dev
  golang-gopkg-cheggaaa-pb.v1-dev

Thanks,
Guillem



Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

2024-02-16 Thread Guillem Jover
Hi!

On Thu, 2024-02-15 at 16:48:43 -0800, Steve Langasek wrote:
> Control: forwarded -1 seli...@vger.kernel.org
> 
> Patch now forwarded upstream for review.
> 
> https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t

> On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote:
> > Well, "already" is not exactly correct, but the need to resolve this
> > critical showstopper bug in libselinux before making changes to the
> > toolchain behavior in unstable and breaking the world has affected the
> > timeline, yes.
> > 
> > I now have a tested patch that I've raised as an MP in salsa:
> > 
> >   https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9
> > 
> > I welcome review from the Debian libselinux maintainers prior to opening a
> > discussion with upstream.  (Which I will plan to do sometime Thursday
> > US/Pacific)

Thanks for preparing the patch. I checked it and left a comment on the
MR there.

Regards,
Guillem



Bug#1064087: RFS: asn/0.75.3-1 [ITP] -- network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace

2024-02-16 Thread aka oday
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : asn
   Version  : 0.75.3-1
   Upstream contact : Adriano nitefood
 * URL  : https://github.com/nitefood/asn/
 * License  : Expat
 * Vcs  : https://salsa.debian.org/marcos.rcarvalho/asn
   Section  : net

The source builds the following binary packages:

  asn - network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/asn/asn_0.75.3-1.dsc

Changes for the initial release:

 asn (0.75.3-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1064033)

Regards,


-- 
Marcos Rodrigues de Carvalho (aka oday) 



Bug#1064086: /usr/share/doc/libapache2-mod-netcgi-apache/changelog.gz: libapache2-mod-netcgi-apache break apache

2024-02-16 Thread Frederic LOYER
Package: libapache2-mod-netcgi-apache
Version: 4.1.9-1+b1
Severity: grave
File: /usr/share/doc/libapache2-mod-netcgi-apache/changelog.gz
Justification: renders package unusable

Dear Maintainer,

After installing libapache2-mod-netcgi-apache, apache can't start again.

The following error is produced:

netcgi_apache.load: Can't locate API module structure `netcgi_apache_module' in 
file /usr/lib/apache2/modules/mod_netcgi_apache.so: 
/usr/lib/apache2/modules/mod_netcgi_apache.so: undefined symbol: 
netcgi_apache_module
Action 'restart' failed.

The Apache server must be restarted after disabling the module.

(the same behaviour is also seen in Debian 11.9)


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

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

Versions of packages libapache2-mod-netcgi-apache depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.57-2
ii  libc6   2.36-9+deb12u4
ii  libocamlnet-ocaml-dev   4.1.9-1+b1

libapache2-mod-netcgi-apache recommends no packages.

libapache2-mod-netcgi-apache suggests no packages.

-- Configuration Files:
/etc/apache2/mods-available/netcgi_apache.load changed [not included]

-- no debconf information



Bug#1060898: apfs-dkms: fails to build module: super.c:17:10: fatal error: version.h: No such file or directory

2024-02-16 Thread Andreas Beckmann
Followup-For: Bug #1060898
Control: tag -1 patch

Hi,

attached you can find an overhaul of the package installation that also
fixes the missing version.h

Having the Debian revision included in the dkms module version is very
unusual, now this only uses the upstream version.

The Vcs-* URLs in the package point to an empty repository ... otherwise
you could have gotten a MR with a sequence of commits.


Andreas
diff -Nru linux-apfs-rw-0.3.7/debian/README.Debian 
linux-apfs-rw-0.3.7/debian/README.Debian
--- linux-apfs-rw-0.3.7/debian/README.Debian2021-09-28 12:55:19.0 
+0200
+++ linux-apfs-rw-0.3.7/debian/README.Debian1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-dkms build linux-apfs-rw/0+git20210928
diff -Nru linux-apfs-rw-0.3.7/debian/changelog 
linux-apfs-rw-0.3.7/debian/changelog
--- linux-apfs-rw-0.3.7/debian/changelog2024-01-21 17:29:59.0 
+0100
+++ linux-apfs-rw-0.3.7/debian/changelog2024-02-17 00:10:52.0 
+0100
@@ -1,3 +1,10 @@
+linux-apfs-rw (0.3.7-2) UNRELEASED; urgency=medium
+
+  * Overhaul package installation.
+  * Use upstream dkms.conf and ship genver.sh. (Closes: #1060898)
+
+ -- Andreas Beckmann   Sat, 17 Feb 2024 00:10:52 +0100
+
 linux-apfs-rw (0.3.7-1) unstable; urgency=medium
 
   * New upstream version. (Closes: #1060898)
diff -Nru linux-apfs-rw-0.3.7/debian/control linux-apfs-rw-0.3.7/debian/control
--- linux-apfs-rw-0.3.7/debian/control  2024-01-08 08:36:46.0 +0100
+++ linux-apfs-rw-0.3.7/debian/control  2024-02-17 00:10:52.0 +0100
@@ -13,7 +13,7 @@
 Package: apfs-dkms
 Architecture: all
 Depends: ${misc:Depends}
-Description: APFS module for linux, with experimental write support
+Description: APFS module for Linux, with experimental write support
  The Apple File System (APFS) is the copy-on-write filesystem currently used on
  all Apple devices. This module provides a degree of experimental support on
  Linux.
diff -Nru linux-apfs-rw-0.3.7/debian/dkms linux-apfs-rw-0.3.7/debian/dkms
--- linux-apfs-rw-0.3.7/debian/dkms 2022-01-10 15:25:20.0 +0100
+++ linux-apfs-rw-0.3.7/debian/dkms 2024-02-17 00:10:52.0 +0100
@@ -1,7 +1 @@
-PACKAGE_NAME="linux-apfs-rw"
-PACKAGE_VERSION="#MODULE_VERSION#"
-MAKE[0]="make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build"
-CLEAN="make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"
-AUTOINSTALL=yes
-BUILT_MODULE_NAME[0]="apfs"
-DEST_MODULE_LOCATION[0]=/extra
+dkms.conf
diff -Nru linux-apfs-rw-0.3.7/debian/install linux-apfs-rw-0.3.7/debian/install
--- linux-apfs-rw-0.3.7/debian/install  1970-01-01 01:00:00.0 +0100
+++ linux-apfs-rw-0.3.7/debian/install  2024-02-17 00:10:52.0 +0100
@@ -0,0 +1,5 @@
+Makefile   usr/src/linux-apfs-rw-${env:DEB_VERSION_UPSTREAM}/
+genver.sh  usr/src/linux-apfs-rw-${env:DEB_VERSION_UPSTREAM}/
+*.cusr/src/linux-apfs-rw-${env:DEB_VERSION_UPSTREAM}/
+*.husr/src/linux-apfs-rw-${env:DEB_VERSION_UPSTREAM}/
+lzfse  usr/src/linux-apfs-rw-${env:DEB_VERSION_UPSTREAM}/
diff -Nru linux-apfs-rw-0.3.7/debian/rules linux-apfs-rw-0.3.7/debian/rules
--- linux-apfs-rw-0.3.7/debian/rules2023-02-02 12:34:00.0 +0100
+++ linux-apfs-rw-0.3.7/debian/rules2024-02-17 00:10:52.0 +0100
@@ -2,25 +2,13 @@
 #export DH_VERBOSE = 1
 
 include /usr/share/dpkg/pkg-info.mk
-
-pdkms:=apfs-dkms
-sname:=linux-apfs-rw
-#$(shell dpkg-parsechangelog --show-field=Version|rev|cut -d- -f2-|rev)
+export DEB_VERSION_UPSTREAM
 
 %:
dh $@
 
 override_dh_auto_clean:
-   @echo CLEAN
 
 override_dh_auto_build:
-   @echo NO BUILD
 
 override_dh_auto_install:
-   @echo NO AUTO INSTALL
-
-override_dh_dkms:
-   dh_install Makefile *.c *.h lzfse usr/src/$(sname)-$(DEB_VERSION)
-   chmod 0644 debian/$(pdkms)/usr/src/$(sname)-$(DEB_VERSION)/*
-   chmod 0755 debian/$(pdkms)/usr/src/$(sname)-$(DEB_VERSION)/lzfse
-   dh_dkms -V $(DEB_VERSION)


Bug#1064085: gts: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: gts
Version: 0.7.6+darcs121130-5
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
gts 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 gts
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'), (500, 'testing'), (500, 'stable'), (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 gts-0.7.6+darcs121130/debian/Makefile.in 
gts-0.7.6+darcs121130/debian/Makefile.in
--- gts-0.7.6+darcs121130/debian/Makefile.in2021-11-11 16:18:31.0 
+
+++ gts-0.7.6+darcs121130/debian/Makefile.in2024-02-16 23:39:05.0 
+
@@ -1,9 +1,8 @@
-# Makefile.in generated by automake 1.11.1 from Makefile.am.
+# Makefile.in generated by automake 1.16.5 from Makefile.am.
 # @configure_input@
 
-# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
-# Inc.
+# Copyright (C) 1994-2021 Free Software Foundation, Inc.
+
 # This Makefile.in is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
@@ -15,6 +14,61 @@
 
 @SET_MAKE@
 VPATH = @srcdir@
+am__is_gnu_make = { \
+  if test -z '$(MAKELEVEL)'; then \
+false; \
+  elif test -n '$(MAKE_HOST)'; then \
+true; \
+  elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
+true; \
+  else \
+false; \
+  fi; \
+}
+am__make_running_with_option = \
+  case $${target_option-} in \
+  ?) ;; \
+  *) echo "am__make_running_with_option: internal error: invalid" \
+  "target option '$${target_option-}' specified" >&2; \
+ exit 1;; \
+  esac; \
+  has_opt=no; \
+  sane_makeflags=$$MAKEFLAGS; \
+  if $(am__is_gnu_make); then \
+sane_makeflags=$$MFLAGS; \
+  else \
+case $$MAKEFLAGS in \
+  *\\[\ \  ]*) \
+bs=\\; \
+sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
+  | sed "s/$$bs$$bs[$$bs $$bs  ]*//g"`;; \
+esac; \
+  fi; \
+  skip_next=no; \
+  strip_trailopt () \
+  { \
+flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
+  }; \
+  for flg in $$sane_makeflags; do \
+test $$skip_next = yes && { skip_next=no; continue; }; \
+case $$flg in \
+  *=*|--*) continue;; \
+-*I) strip_trailopt 'I'; skip_next=yes;; \
+  -*I?*) strip_trailopt 'I';; \
+-*O) strip_trailopt 'O'; skip_next=yes;; \
+  -*O?*) strip_trailopt 'O';; \
+-*l) strip_trailopt 'l'; skip_next=yes;; \
+  -*l?*) strip_trailopt 'l';; \
+  -[dEDm]) skip_next=yes;; \
+  -[JT]) skip_next=yes;; \
+esac; \
+case $$flg in \
+  *$$target_option*) has_opt=yes; break;; \
+esac; \
+  done; \
+  test $$has_opt = yes
+am__make_dryrun = (target_option=n; $(am__make_running_with_option))
+am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
 pkgdatadir = $(datadir)/@PACKAGE@
 pkgincludedir = $(includedir)/@PACKAGE@
 pkglibdir = $(libdir)/@PACKAGE@
@@ -34,21 +88,41 @@
 build_triplet = @build@
 host_triplet = @host@
 subdir = debian
-DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 

Bug#1064084: vinagre demands attention when mouse moved over unfocused background window in kde plasma

2024-02-16 Thread Patrick Plenefisch
Package: vinagre
Version: 3.22.0-8.1
Severity: normal
X-Debbugs-Cc: simonp...@gmail.com

A workaround is described here: https://discuss.kde.org/t/disable-focus-
request-alerting-attention-demand-orange-for-one-application/10611/5

STR is:
1. Launch a kde plasmashell session
2. launch vinagre
3. connect to a vnc server
4. focus another window (not vinagre)
5. mouseover vinagre
6. the taskbar entry is now orange


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

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

Versions of packages vinagre depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libavahi-common3 0.8-10
ii  libavahi-gobject00.8-10
ii  libavahi-ui-gtk3-0   0.8-10
ii  libc62.36-9+deb12u4
ii  libcairo21.16.0-7
ii  libfreerdp2-22.10.0+dfsg1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtk-vnc-2.0-0 1.3.1-1
ii  libsecret-1-00.20.5-3
ii  libspice-client-glib-2.0-8   0.42-1
ii  libspice-client-gtk-3.0-50.42-1
ii  libvte-2.91-00.70.6-2~deb12u1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1

vinagre recommends no packages.

vinagre suggests no packages.

-- no debconf information



Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

2024-02-16 Thread Loren M. Lang
Package: wnpp
Severity: wishlist
Owner: Loren M. Lang 

* Package name: golang-github-cheggaaa-pb
  Version : 3.1.5-1
  Upstream Author : Sergey Cherepanov
* URL : https://github.com/cheggaaa/pb
* License : BSD-3-clause
  Programming Lang: Go
  Description : Console progress bar for Golang

 Terminal progress bar for Go
 .
 Coverage Status (https://coveralls.io/github/cheggaaa/pb)
 .
 Installation
 .
   go get github.com/cheggaaa/pb/v3
 .
 Documentation for v1 bar available here (/README_V1.md).
 .
 Quick start
 .
   package main
 .
   import (
"time"
 .
"github.com/cheggaaa/pb/v3"
   )
 .
   func main() {
count := 10
 .
// create and start new bar
bar := pb.StartNew(count)
 .
// start bar from 'default' template
// bar := pb.Default.Start(count)
 .
// start bar from 'simple' template
// bar := pb.Simple.Start(count)
 .
// start bar from 'full' template
// bar := pb.Full.Start(count)
 .
for i := 0; i < count; i++ {
bar.Increment()
time.Sleep(time.Millisecond)
}
 .
// finish bar
bar.Finish()
   }
 .
 Result will be like this:
 .
   > go run test.go
   37158 / 10 [>___] 37.16% 916 
p/s
 .
 Settings
 .
   // create bar
   bar := pb.New(count)
 .
   // refresh info every second (default 200ms)
   bar.SetRefreshRate(time.Second)
 .
   // force set io.Writer, by default it's os.Stderr
   bar.SetWriter(os.Stdout)
 .
   // bar will format numbers as bytes (B, KiB, MiB, etc)
   bar.Set(pb.Bytes, true)
 .
   // bar use SI bytes prefix names (B, kB) instead of IEC (B, KiB)
   bar.Set(pb.SIBytesPrefix, true)
 .
   // set custom bar template
   bar.SetTemplateString(myTemplate)
 .
   // check for error after template set
   if err := bar.Err(); err != nil {
   return
   }
 .
   // start bar
   bar.Start()
 .
 Progress bar for IO Operations
 .
   package main
 .
   import (
"crypto/rand"
"io"
"io/ioutil"
 .
"github.com/cheggaaa/pb/v3"
   )
 .
   func main() {
var limit int64 = 1024 * 1024 * 500
 .
// we will copy 500 MiB from /dev/rand to /dev/null
reader := io.LimitReader(rand.Reader, limit)
writer := ioutil.Discard
 .
// start new bar
bar := pb.Full.Start64(limit)
 .
// create proxy reader
barReader := bar.NewProxyReader(reader)
 .
// copy from proxy reader
io.Copy(writer, barReader)
 .
// finish bar
bar.Finish()
   }
 .
 Custom Progress Bar templates
 .
 Rendering based on builtin text/template
 (https://pkg.go.dev/text/template) package. You can use existing pb's
 elements or create you own.
 .
 All available elements are described in the element.go (/v3/element.go)
 file.
 .
 All in one example:
 .
   tmpl := `{{ red "With funcs:" }} {{ bar . "<" "-" (cycle . "↖" "↗" "↘"
 "↙" ) "." ">"}} {{speed . | rndcolor }} {{percent .}} {{string .
 "my_green_string" | green}} {{string . "my_blue_string" | blue}}`
 .
   // start bar based on our template
   bar := pb.ProgressBarTemplate(tmpl).Start64(limit)
 .
   // set values for string elements
   bar.Set("my_green_string", "green").Set("my_blue_string", "blue")


This is a dependency for pwru which is in RFP and I plan to complete packaging
shortly. pwru is an eBPF-based Linux kernel networking debugger.



Bug#1064081: ITP: golang-github-cloudflare-cbpfc -- cBPF to C or eBPF compiler

2024-02-16 Thread Loren M. Lang
Package: wnpp
Severity: wishlist
Owner: Loren M. Lang 

* Package name: golang-github-cloudflare-cbpfc
  Version : 0.0~git20231012.992ed75-1
  Upstream Author : Cloudflare
* URL : https://github.com/cloudflare/cbpfc
* License : BSD-3-clause
  Programming Lang: Go
  Description : cBPF to C or eBPF compiler

 cbpfc
 .
 GoDoc (https://godoc.org/github.com/cloudflare/cbpfc)
 .
 cbpfc is a classic BPF (cBPF) to extended BPF (eBPF) compiler. It can
 compile cBPF to eBPF, or to C, and the generated code should be accepted
 by the kernel verifier.
 .
 cbpfc/clang (https://godoc.org/github.com/cloudflare/cbpfc/clang) is a
 simple clang wrapper for compiling C to eBPF.
 .
 Tests
 .
 Dependencies
 .
  * clang
* Path can be set via environment variable $CLANG
 .
 .
 Unprivileged
 .
  * go test -short
 .
 Full
 .
  * Requires:
* root or CAP_SYS_ADMIN to load XDP programs
* Recent (4.14+) Linux kernel
  * sudo go test


This is a dependency for pwru which is in RFP and I plan to complete packaging
shortly. pwru is an eBPF-based Linux kernel networking debugger.



Bug#1064062: iwd: CVE-2023-52161

2024-02-16 Thread Salvatore Bonaccorso
Hi,

On Fri, Feb 16, 2024 at 04:15:19PM +0100, Moritz Mühlenhoff wrote:
> Source: iwd
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for iwd.
> 
> CVE-2023-52161[0]:
> https://www.top10vpn.com/research/wifi-vulnerabilities/
> 
> While this mentions a patch for wpasupplication, it's not obvious
> if this was reported/fixed in iwd.

The iwd commit is
https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=6415420f1c92012f64063c131480ffcef58e60ca
.

Regards,
Salvatore



Bug#1063106: bctoolbox: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Hi Dennis,

On Thu, Feb 08, 2024 at 06:36:24PM +0100, Dennis Filder wrote:
> X-Debbugs-CC: Steve Langasek 

> The packages bctoolbox, belle-sip and linphone have been marked as
> affected by the 64-bit time_t transition.  However, all these packages
> currently have new versions staged in experimental because their
> library packages had soname bumps unrelated to the 64-bit time_t
> transition (which you already noticed for belle-sip).  As long as
> these staged versions actually make it into testing before the Trixie
> freeze there should be no need for these NMU diffs, correct?

There is perhaps no need for you to apply these diffs to your package; and
for any of these packages where you will be changing sonames, the diffs can
be dropped.  But without making this transition explict in unstable, *any*
no-change rebuild in the meantime, of any of these libraries or their
reverse-dependencies, would result in potentially RC-buggy ABI skew.  So our
intent would still be to NMU these to unstable even if the library
transition is subsequently superseded.

> > 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.

> I presume the need for "close together in time" is to prevent
> interoperability issues from cropping up in unstable between shared
> library versions on different sides of the time_t transition.  How
> timely would our staged versions need to be uploaded to unstable to
> obviate the need for the NMUs?  I ask because it is very difficult to
> say with a useful degree of certainty when these staged versions will
> actually reach testing.  Experience has shown that linphone stack
> transitions are prone to being afflicted by (sometimes multi-month)
> delays due to being blocked by other transitions, and I see no open
> bugreport for linphone on the release.debian.org pseudopackage, so
> Berni (who will do these uploads) apparently has not yet applied for a
> new transition slot.

Based on the above I think you should let us go ahead with the NMUs to
unstable and not worry about it, clobbering them later at your convenience.

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


signature.asc
Description: PGP signature


Bug#1064079: gsoap: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
Source: gsoap
Version: 2.8.132-2
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

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
gsoap 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 gsoap
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'), (500, 'testing'), (500, 'stable'), (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 gsoap-2.8.132/debian/changelog gsoap-2.8.132/debian/changelog
--- gsoap-2.8.132/debian/changelog  2024-01-25 10:34:59.0 +
+++ gsoap-2.8.132/debian/changelog  2024-02-16 21:13:23.0 +
@@ -1,3 +1,10 @@
+gsoap (2.8.132-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 16 Feb 2024 21:13:23 +
+
 gsoap (2.8.132-2) unstable; urgency=medium
 
   * Re-upload source only
diff -Nru gsoap-2.8.132/debian/control gsoap-2.8.132/debian/control
--- gsoap-2.8.132/debian/control2024-01-23 10:10:40.0 +
+++ gsoap-2.8.132/debian/control2024-02-16 21:13:23.0 +
@@ -19,7 +19,10 @@
 Vcs-Git: https://salsa.debian.org/ellert/gsoap.git
 Homepage: https://gsoap2.sourceforge.net/
 
-Package: libgsoap-2.8.132
+Package: libgsoap-2.8.132t64
+Provides: ${t64:Provides}
+Replaces: libgsoap-2.8.132
+Breaks: libgsoap-2.8.132 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
@@ -38,7 +41,7 @@
 Multi-Arch: same
 Depends:
  ${misc:Depends},
- libgsoap-2.8.132 (= ${binary:Version})
+ libgsoap-2.8.132t64 (= ${binary:Version})
 Description: Development libraries and headers for gSOAP
  The gSOAP toolkit provides a unique SOAP-to-C/C++ language binding for the
  development of SOAP Web Services and clients. Development libraries and
diff -Nru gsoap-2.8.132/debian/libgsoap-2.8.132.install 
gsoap-2.8.132/debian/libgsoap-2.8.132.install
--- gsoap-2.8.132/debian/libgsoap-2.8.132.install   2021-08-21 
17:50:53.0 +
+++ gsoap-2.8.132/debian/libgsoap-2.8.132.install   1970-01-01 
00:00:00.0 +
@@ -1,6 +0,0 @@
-/usr/lib/*/libgsoap-*.so
-/usr/lib/*/libgsoap++-*.so
-/usr/lib/*/libgsoapck-*.so
-/usr/lib/*/libgsoapck++-*.so
-/usr/lib/*/libgsoapssl-*.so
-/usr/lib/*/libgsoapssl++-*.so
diff -Nru gsoap-2.8.132/debian/libgsoap-2.8.132t64.install 
gsoap-2.8.132/debian/libgsoap-2.8.132t64.install
--- gsoap-2.8.132/debian/libgsoap-2.8.132t64.install1970-01-01 
00:00:00.0 +
+++ gsoap-2.8.132/debian/libgsoap-2.8.132t64.install2021-08-21 
17:50:53.0 +
@@ -0,0 +1,6 @@
+/usr/lib/*/libgsoap-*.so
+/usr/lib/*/libgsoap++-*.so
+/usr/lib/*/libgsoapck-*.so
+/usr/lib/*/libgsoapck++-*.so
+/usr/lib/*/libgsoapssl-*.so
+/usr/lib/*/libgsoapssl++-*.so
diff -Nru gsoap-2.8.132/debian/libgsoap-2.8.132t64.lintian-overrides 
gsoap-2.8.132/debian/libgsoap-2.8.132t64.lintian-overrides
--- gsoap-2.8.132/debian/libgsoap-2.8.132t64.lintian-overrides  1970-01-01 
00:00:00.0 +
+++ gsoap-2.8.132/debian/libgsoap-2.8.132t64.lintian-overrides  2024-02-16 
21:13:23.0 +
@@ -0,0 +1 @@
+libgsoap-2.8.132t64: package-name-doesnt-match-sonames libgsoap-2.8.132


Bug#993557: ITP: gnome-shell-extension-pop-shell -- keyboard-driven layer for GNOME with tiling window management

2024-02-16 Thread Martin Quinson
Hello David, 

did you manage to do any progress on this package, please? Where can I see your
current version? I'd like to help if possible.

Thanks, Mt


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


Bug#1032131: deb822-style sources.list

2024-02-16 Thread Julian Andres Klode
On Tue, Feb 28, 2023 at 07:00:57PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> David Prévot  (2023-02-28):
> > I may be late to the bookworm party but… It would be nice if d-i could
> > provide deb822-style sources.list (by default) for newly installed
> > machines.
> 
> This seems late indeed.

Hiya, we just flipped the switch for Ubuntu, I think it's about time
we switch apt-setup for trixie.

The path we picked for Ubuntu was to keep a transtional sources.list
file:

# Ubuntu sources have moved to the /etc/apt/sources.list.d/ubuntu.sources
# file, which uses the deb822 format. Use deb822-formatted .sources files
# to manage package sources in the /etc/apt/sources.list.d/ directory.
# See the sources.list(5) manual page for details.

We probably should use the same text with s/Ubuntu/Debian/;s/ubuntu/debian/.

Having the transitional commented sources.list helps various tools
that identify a debian-style system by looking at sources.list
presence and guides the user.

The Debian sources should then be in sources.list.d/debian.sources. See
the Docker images tianon builds for Debian, they have already switched
and provide (only) the debian.sources.

Thank you!
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature


Bug#1062753: Bug#1063401: atm-tools: has gained /usr/share/doc/libatm1/changelog.*

2024-02-16 Thread Steve Langasek
Thanks for the patch.  Attached is the consolidated patch for a subsequent
upload to experimental.


On Sat, Feb 10, 2024 at 01:55:30PM +0100, Andreas Metzler wrote:
> Control: tags -1 patch
> 
> On 2024-02-07 Andreas Beckmann  wrote:
> > Package: atm-tools
> > Version: 1:2.5.1-5.1~exp1
> [...]
> > atm-tools/experimental has gained two unexpected files, causing file
> > conflicts on upgrades:
> [...]
> > There is still an libatm1 dependency, and the new libatm1t64 dependency
> > seems to miss the epoch.
> 
> Hello,
> 
> Both issues are fixed by a one-line-change, a dh_lintian call should
> also be added.
> 
> diff -Nru linux-atm-2.5.1/debian/rules linux-atm-2.5.1/debian/rules
> --- linux-atm-2.5.1/debian/rules  2019-07-19 11:14:25.0 +0200
> +++ linux-atm-2.5.1/debian/rules  2024-02-10 13:31:02.0 +0100
> @@ -72,7 +72,7 @@
>   dh_testroot
>   dh_install --sourcedir=debian/tmp
>   rm debian/atm-tools/usr/share/man/man8/br2684ctl.8
> - dh_installdocs --link-doc=libatm1
> + dh_installdocs --link-doc=libatm1t64
>   dh_installinit --init-script=atm
>   dh_installsystemd --name=atm
>   dh_installman
> @@ -80,6 +80,7 @@
>   dh_link
>   dh_strip
>   dh_compress
> + dh_lintian
>   dh_fixperms
>   dh_makeshlibs -- -c4
>   dh_installdeb
> 
> cu Andreas
> 

-- 
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
diff -Nru linux-atm-2.5.1/debian/changelog linux-atm-2.5.1/debian/changelog
--- linux-atm-2.5.1/debian/changelog2023-12-20 21:41:15.0 +
+++ linux-atm-2.5.1/debian/changelog2024-02-16 21:08:19.0 +
@@ -1,3 +1,17 @@
+linux-atm (1:2.5.1-5.1~exp2) experimental; urgency=medium
+
+  * Fix issues with the previous NMU; thanks, Andreas Metzler 
+ Closes: #1063401.
+
+ -- Steve Langasek   Fri, 16 Feb 2024 21:08:19 +
+
+linux-atm (1:2.5.1-5.1~exp1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 23:16:33 +
+
 linux-atm (1:2.5.1-5) unstable; urgency=medium
 
   * QA upload.
diff -Nru linux-atm-2.5.1/debian/control linux-atm-2.5.1/debian/control
--- linux-atm-2.5.1/debian/control  2023-12-20 21:41:15.0 +
+++ linux-atm-2.5.1/debian/control  2024-02-02 23:16:33.0 +
@@ -46,7 +46,10 @@
  uses one of these protocols: RFC 1483 bridged (RFC 2684 bridged),
  RFC 1483 bridged (RFC 2684 routed), PPP over Ethernet (PPPoE).
 
-Package: libatm1
+Package: libatm1t64
+Provides: ${t64:Provides}
+Replaces: libatm1
+Breaks: libatm1 (<< ${source:Version})
 Section: libs
 Architecture: linux-any
 Multi-Arch: same
@@ -59,7 +62,7 @@
 Package: libatm1-dev
 Section: libdevel
 Architecture: linux-any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libatm1 (= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, libatm1t64 (= ${binary:Version})
 Provides: libatm-dev
 Description: Development files for compiling ATM programs
  Header files and development libraries for compiling ATM (Asynchronous 
diff -Nru linux-atm-2.5.1/debian/libatm1.install 
linux-atm-2.5.1/debian/libatm1.install
--- linux-atm-2.5.1/debian/libatm1.install  2019-07-19 09:14:25.0 
+
+++ linux-atm-2.5.1/debian/libatm1.install  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/libatm.so.*
diff -Nru linux-atm-2.5.1/debian/libatm1.symbols 
linux-atm-2.5.1/debian/libatm1.symbols
--- linux-atm-2.5.1/debian/libatm1.symbols  2019-07-19 09:14:25.0 
+
+++ linux-atm-2.5.1/debian/libatm1.symbols  1970-01-01 00:00:00.0 
+
@@ -1,43 +0,0 @@
-libatm.so.1 libatm1 #MINVER#
- __atmlib_fetch@Base 2.4.1-17~
- __t2q_get_rate@Base 2.4.1-17~
- alloc@Base 2.4.1-17~
- ans_byaddr@Base 2.4.1-17~
- ans_byname@Base 2.4.1-17~
- atm2text@Base 2.4.1-17~
- atm_equal@Base 2.4.1-17~
- atm_tcpip_port_mapping@Base 2.4.1-17~
- diag@Base 2.4.1-17~
- diag_dump@Base 2.4.1-17~
- diag_fatal_debug_hook@Base 2.4.1-17~
- expire_timers@Base 2.4.1-17~
- get_logfile@Base 2.4.1-17~
- get_verbosity@Base 2.4.1-17~
- kptr_eq@Base 2.4.1-17~
- kptr_print@Base 2.4.1-17~
- next_timer@Base 2.4.1-17~
- now@Base 2.4.1-17~
- pop_timer@Base 2.4.1-17~
- qos2text@Base 2.4.1-17~
- qos_equal@Base 2.4.1-17~
- read_netl@Base 2.4.1-17~
- sap2text@Base 2.4.1-17~
- sap_equal@Base 2.4.1-17~
- sdu2cell@Base 2.4.1-17~
- set_application@Base 2.4.1-17~
- set_logfile@Base 2.4.1-17~
- set_verbosity@Base 2.4.1-17~
- start_timer@Base 2.4.1-17~
- stop_timer@Base 2.4.1-17~
- text2atm@Base 2.4.1-17~
- text2ip@Base 2.4.1-17~
- text2qos@Base 2.4.1-17~
- text2sap@Base 2.4.1-17~
- timer_handler@Base 2.4.1-17~
- un_attach@Base 2.4.1-17~
- un_create@Base 2.4.1-17~
- un_recv@Base 2.4.1-17~
- 

Bug#1053944: q2-types: test failure with pandas 2.1 (Was: Bug#1044068: q2templates: FTBFS with pandas 2.0)

2024-02-16 Thread Andreas Tille
Control: tags -1 help

Hi again,

thanks again for your great help.  I admit I need some help for q2-types as
well.  While log in the bug report vanished you will easily find things like

  TypeError: read_csv() got an unexpected keyword argument 'squeeze'

when trying to build the package.

I've found an issue at pandas upstream[1] which inspired me to the patch

--- a/q2_types/sample_data/tests/test_transformer.py
+++ b/q2_types/sample_data/tests/test_transformer.py
@@ -28,8 +28,8 @@ class TestTransformers(TestPluginBase):
 obs = transformer(exp)

 # Squeeze equals true to return series instead of dataframe
-obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0,
-  squeeze=True)
+obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0)
+obs.squeeze("columns")

 assert_series_equal(exp, obs)

which is obviously wrong since it leads to

# Squeeze equals true to return series instead of dataframe
obs = pd.read_csv(str(obs), sep='\t', header=0, index_col=0)
obs.squeeze("columns")

>   assert_series_equal(exp, obs)


Probably a better solution can be found at stackoverflow[2] to use
DataFrame.squeeze('columns') but I'm simply lacking an example how to use
this.

Finally this is not the only error and I would appreciate any helping hint
(patch?) to get the package ported to recent pandas.

Kind regards
Andreas.

[1] https://github.com/pandas-dev/pandas/issues/43242
[2] 
https://stackoverflow.com/questions/76684141/why-am-i-getting-an-error-when-using-squeeze-keyword-in-read-csv


Am Fri, Feb 16, 2024 at 10:48:59AM +0100 schrieb s3v:
> ...
> Kind Regards

-- 
http://fam-tille.de



Bug#983494: (no subject)

2024-02-16 Thread cen
I've seen this in a fresh virt-manager bookworkm VM, uninstalling 
arch-test did the trick




Bug#1061341: Some headers are still unusable

2024-02-16 Thread Adrien Nader
On Fri, Feb 16, 2024, Adrien Nader wrote:
> I was able to analyze the library after modifying auth.h (actually
> cyrus/*.h) to use cyrus/strarray.h and skipping bitvector.h. The
> analysis returns that the library is both time_t and LFS sensitive. I
> will publish a report soon (hopefully this evening but I can't
> guarantee it).

I've pushed updated results. You can find the ones for cyrus-dev at
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-16T21%3A19%3A00/compat_reports/cyrus-dev/

-- 
Adrien



Bug#1064039: Unexpected string when using tmux with rxvt-unicode

2024-02-16 Thread Romain Francoise
Hi,

On Fri, Feb 16, 2024 at 10:42 AM Karine Crévecœur  wrote:
> I encounter a strange behaviour when I use tmux in rxvt-unicode since
> the version 3.4-1.

Yes, this is a bug in rxvt-unicode's support of OSC commands that is
exposed by tmux 3.4. There's an upstream fix here:

https://github.com/exg/rxvt-unicode/commit/417b540d6dba67d440e3617bc2cf6d7cea1ed968

I'll reassign this bug to rxvt-unicode.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/



Bug#1064078: RFS: smplayer/23.12.0+ds0-1 -- Complete front-end for MPlayer and mpv

2024-02-16 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : smplayer
   Version  : 23.12.0+ds0-1
   Upstream contact : Ricardo Villalba
 * URL  :https://smplayer.sourceforge.net/
 * License  : Expat, BSD-2-clause, LGPL-2.1+, LGPL-2+, BSD-3-clause, 
CC0-1.0, GPL-2+
 * Vcs  :https://salsa.debian.org/multimedia-team/smplayer
   Section  : video

The source builds the following binary packages:

  smplayer - Complete front-end for MPlayer and mpv
  smplayer-l10n - Complete front-end for MPlayer and mpv - translation files

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/s/smplayer/smplayer_23.12.0+ds0-1.dsc

Changes since the last upload:

 smplayer (23.12.0+ds0-1) unstable; urgency=medium
 .
   * New upstream release. (Closes: #1062700)
   * Add qtdeclarative5-dev to the dependencies.

Regards,
--
  Mateusz Łukasik


Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility

2024-02-16 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : qt5ct
   Version  : 1.8-1
   Upstream contact : [fill in name and email of upstream]
 * URL  :https://sourceforge.net/projects/qt5ct/
 * License  : BSD-2-clause
 * Vcs  :https://salsa.debian.org/qt-kde-team/extras/qt5ct
   Section  : utils

The source builds the following binary packages:

  qt5ct - Qt5 Configuration Utility

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/q/qt5ct/qt5ct_1.8-1.dsc

Changes since the last upload:

 qt5ct (1.8-1) unstable; urgency=medium
 .
   * New upstream release.
   * Remove patches included upstream.
   * Bump Standards-Version to 4.6.2, no changes needed.
   * Update d/copyright.
   * Add d/clean for fix fails to build source after successful build.
 (Closes: #1045559)
   * d/control: Remove build depends on obsolete package.

Regards,
--
  Mateusz Łukasik


Bug#1063842: openssh-server: Binding to a static IPv6 address causes sshd to fail at bootup

2024-02-16 Thread Timo Weingärtner
Hallo Colin Watson,

13.02.24 14:30 Colin Watson:
> On Tue, Feb 13, 2024 at 01:13:17PM +, Bert wrote:
> > I configured SSH with a static IPv6 ListenAddress.
> > During bootup, SSH tries to start before the IPv6 address has been fully
> > bound to the host (ie during duplicate address detection) This results in
> > SSH failing to start with "Cannot bind any address" and a return code of
> > 255. The systemd unit file for ssh contains
> > "RestartPreventExitStatus=255" which causes it to give up when it
> > encounters this error. In a cloud environment this is a critical failure
> > as it renders the host inaccessible. The same thing occurs if the static
> > IPv6 address is assigned a different way (eg via SLAAC or DHCPv6) If you
> > remove this line, systemd tries again and succeeds once the address has
> > been bound to the host. I generally also add "StartSec=15s" to prevent it
> > trying too frequently. This manual change is not persistent, as it gets
> > overwritten next time you update the package.
> I suggest that in such unusual configurations you should use the After=
> directive in the [Unit] section to ensure that ssh.service doesn't start
> until the relevant other systemd unit has been started.  You can do this
> in a way that persists across upgrades using a drop-in unit; see "man
> systemd.unit" or use "systemctl edit ssh.service".
> 
> However, a simpler solution might well be to remove ListenAddress and
> instead use firewall rules to restrict incoming SSH connections to only
> the desired address(es), as is recommended in README.Debian.

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965132

In some cases sshd just must not listen on wildcard.
Also consider the combination of another service listening on some IP 
addresses :22 and sshd on some other addresses :22 with the possibility that 
some of those IP addresses just will not come up for some reason and you want 
to access the host via already-up addresses to investigate/fix.

Therefore a solution using IP_FREEBIND is preferable IMO.

@Colin: what do you think about merging these two bugs and closing them by 
adding ssh@.socket?


Grüße
Timo

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


Bug#1064076: RFS: gxkb/0.9.5-1 -- X11 keyboard indicator and switcher

2024-02-16 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : gxkb
   Version  : 0.9.5-1
   Upstream contact : [fill in name and email of upstream]
 * URL  :https://zen-tools.github.io/gxkb
 * License  : PERMISSIVE, GAP, GPL-2+, BSD-3-clause
 * Vcs  :https://github.com/mati75/gxkb.git
   Section  : x11

The source builds the following binary packages:

  gxkb - X11 keyboard indicator and switcher

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.9.5-1.dsc

Changes since the last upload:

 gxkb (0.9.5-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since buster:
 + Build-Depends: Drop versioned constraint on libxklavier-dev.
 .
   [ Mateusz Łukasik ]
   * New upstream release.
   * Change from repack script to Files-Excluded in d/copyright.
   * Update d/watch.
   * Update d/copyright.

Regards,
--
  Mateusz Łukasik


Bug#1064075: RFS: openbox/3.6.1-12 [RC] -- standards-compliant, fast, light-weight and extensible window manager

2024-02-16 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : openbox
   Version  : 3.6.1-12
   Upstream contact : Dana Jansens
 * URL  :http://www.openbox.org
 * License  : GPL-2+, GPL-3+
 * Vcs  :https://github.com/mati75/openbox-debian
   Section  : x11

The source builds the following binary packages:

  openbox - standards-compliant, fast, light-weight and extensible window 
manager
  libobt2v5 - parsing library for openbox
  libobrender32v5 - rendering library for openbox themes
  openbox-dev - development files for the openbox window manager
  gnome-panel-control - command line utility to invoke GNOME panel run 
dialog/menu
  openbox-gnome-session - command line utility to run Openbox as GNOME session
  openbox-kde-session - command line utility to run Openbox as KDE SC session

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/o/openbox/openbox_3.6.1-12.dsc

Changes since the last upload:

 openbox (3.6.1-12) unstable; urgency=medium
 .
   * Drop useless html docs about compiling.
   * Add gnome-settings-daemon, gnome-panel, gnome-flashback to
 openbox-gnome-session depends. (Closes: #1050946)

Regards,
--
  Mateusz Łukasik


Bug#1064074: RFS: jgmenu/4.4.1-2 -- Simple X11 menu

2024-02-16 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : jgmenu
   Version  : 4.4.1-2
   Upstream contact : Johan Malm
 * URL  :https://jgmenu.github.io/
 * License  : LGPL-3+, Expat, GPL-2, LGPL-2+, GPL-2+
 * Vcs  :https://github.com/mati75/jgmenu
   Section  : x11

The source builds the following binary packages:

  jgmenu - Simple X11 menu
  jgmenu-xfce4-panel-applet - xfce4-panel applet for jgmenu

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.4.1-2.dsc

Changes since the last upload:

 jgmenu (4.4.1-2) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
 .
   [ Mateusz Łukasik ]
   * Backport upstream changes related to fix working with xfce4-panel.
 (Closes: #1063667)
   * Bump Standards Version to 4.6.2.
   * Add python3-gi, x11-xserver-utils to depends.

Regards,
--
  Mateusz Łukasik


Bug#1064073: Some obsolete Conky build flags found in the "debian/rules" file

2024-02-16 Thread Jmkr
Source: conky
Version: 1.19.6-1

Dear Maintainer,

while building Conky 1.19.6-1 from Debian Sid on my Debian 10 system. I noticed 
that the following build flags no longer seem to exist in the Conky source code:
BUILD_EVE
BUILD_WEATHER_METAR
BUILD_WEATHER_XOAP

Here is a link to the commit that dropped the weather related source code:
https://github.com/brndnmtthws/conky/commit/25e6598c90113e9924510a253ba508975cd463cd

For the "BUILD_EVE" flag I did not find the commit that dropped it, but at 
least "grep" was unable to find any "BUILD_EVE" strings in Conky source code 
files.

Unfortunately I also found that Conky 1.19.6-1 is still affected by the bug 
that causes it to crash on any config reload. This occurs when "use_xft = true" 
is in my config and it is reported as upstream issue 
"https://github.com/brndnmtthws/conky/issues/1538;. If you know about any 
workaround I would be grateful (I described details of how I built and tested 
Conky in a comment to that issue: 
"https://github.com/brndnmtthws/conky/issues/1538#issuecomment-1948943144;.).

By the way bug 791355 
("https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791355;) can probably be 
closed as the upstream issue 106 
("https://github.com/brndnmtthws/conky/issues/106;) was closed in 2018. Also 
bug 684425 ("https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684425;) could 
probably be closed (see my last comment to that bug for details).

Regards,
Jmkr



Bug#1062582: mkdocs-material: diff for NMU version 9.4.0-1.1

2024-02-16 Thread Boyuan Yang
Control: tags 1062582 + patch
Control: tags 1062582 + pending

Dear maintainer,

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

Regards.

diff -Nru mkdocs-material-9.4.0/debian/changelog 
mkdocs-material-9.4.0/debian/changelog
--- mkdocs-material-9.4.0/debian/changelog  2023-09-22 02:45:53.0 
-0400
+++ mkdocs-material-9.4.0/debian/changelog  2024-02-16 14:14:23.0 
-0500
@@ -1,3 +1,12 @@
+mkdocs-material (9.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Do not install files under /usr/share/ via override.
+    The override does not work after switching to pyproject build, and will 
break
+    dh_python3 handling. (Closes: #1062582)
+
+ -- Boyuan Yang   Fri, 16 Feb 2024 14:14:23 -0500
+
 mkdocs-material (9.4.0-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru mkdocs-material-9.4.0/debian/rules mkdocs-material-9.4.0/debian/rules
--- mkdocs-material-9.4.0/debian/rules  2023-09-22 02:45:53.0 -0400
+++ mkdocs-material-9.4.0/debian/rules  2024-02-16 14:14:19.0 -0500
@@ -1,9 +1,4 @@
 #! /usr/bin/make -f
 
-export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/mkdocs/themes/
-
 %:
    dh $@ --with python3 --buildsystem=pybuild
-
-override_dh_python3:
-   dh_python3 /usr/share/mkdocs/themes/



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


Bug#684425: conky-std: please implement an alternative way to distinguish among hwmon devices

2024-02-16 Thread Jmkr

This bug could probably be closed as it is now possible to use device names
instead of numbers for "${hwmon ...}". I tested that it works when I did my
build of Conky 1.19.6-1 from Debian Sid. It was implemented in the Conky 
commit "https://github.com/brndnmtthws/conky/commit/14e3b80c45254743e962f88d
027a7ea37bf59ee6".


Regards,
Jmkr



Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

2024-02-16 Thread Bastien ROUCARIES
Hi,

.
>
> I've given access to the js salsa team.
>
> [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/

It is not the node-long tree...
>



Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

2024-02-16 Thread Steve Langasek
On Fri, Feb 16, 2024 at 02:19:04PM +0100, Christoph Berg wrote:
> Re: Steve Langasek
> > Sorry, did you manage to get sensible a-c-c output?  Otherwise, how did you
> > determine that there was a single symbol affected?  The only compat_report
> > output I have shows *zero* symbols affected but also shows a bunch of
> > garbage output that makes me not trust it at all.

> That was in a different sub-thread on this bug:

>   For postgresql-16 (where libpq-dev comes from), the only symbol
>   affected seems to be pqWaitTimed as indicated above.

>   The good news is that the function is only used internally in libpq,
>   and by no external user:

>   https://codesearch.debian.net/search?q=pqWaitTimed=1
>   https://github.com/search?q=pqWaitTimed=code

>   (GitHub finds a bunch of instances, but these are all either
>   PostgreSQL itself, or vendored copies of libpq.)

Got it, thanks.  I've added it now to our "manual" override list and we will
not NMU. 
https://salsa.debian.org/vorlon/armhf-time_t/-/commit/3e2127d44325b60b4f3b3905f0c841899898f3fb

>   So I think we can safely ignore the difference and not rename libpq5.
>   (It has been named like that for 20 years and I really don't want to
>   break compatibility there.)

I have a different perspective, I find the idea of getting rid of the 'g'
decorator on libpam0 after 25+ years to be quite exciting and am looking
forward to it :-)

-- 
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


signature.asc
Description: PGP signature


Bug#1036912: pipewire-pulse: Solved running mpd in user mode

2024-02-16 Thread C.Ch.
Package: pipewire-pulse
Version: 0.3.65-3+deb12u1
Followup-For: Bug #1036912

Dear Maintainer,

Since mpd in Trixie is now installed by default in user mode I decided to try 
it to solve this problem.

First the instructions in the Debian Wiki are somewhat incomplete.

In user mode mpd reads mdp.conf from ~/.config/mpd

If you don't have this directory create it and copy mpd.conf there.

You need to edit mpd.conf to change the location of the configuration files:

db_file"~/.config/mpd/database"
playlist_directory "~/.config/mpd/playlists"
pid_file   "~/.config/mpd/pid"
state_file "~/.local/state/mpd/state"
sticker_file   "~/.config/mpd/sticker.sql"

You must create the playlists directory:

$ mkdir ~/.config/mpd/playlists

You must create the directory for the state file:

$ mkdir ~/.local/state/mpd

You must create and empty database file:

$ touch ~/.config/mpd/database


You are using systemd, comment or delete this line to log directly to systemd:

#log_file   "syslog"

You don't need to change your music directory from where it is.

Now you can follow the instructions from the Debian Wiki:

# As root, disable system service
systemctl disable --now mpd

# As user logged in the desktop session
systemctl --user enable mpd

Then start MPD:
systemctl --user start mpd

But I got an error mpd wouln't run. Using

$ systemctl --user status mpd.service

Showed this:

Feb 16 17:43:17 harpia mpd[1707]: exception: Failed to bind to 
'/run/mpd/socket'; Failed to bind socket: Permission deni>
Feb 16 17:43:17 harpia systemd[1689]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
Feb 16 17:43:17 harpia systemd[1689]: mpd.service: Failed with result 
'exit-code'.
Feb 16 17:43:17 harpia systemd[1689]: Failed to start mpd.service - Music 
Player Daemon.

Commenting this line in mpd.conf made the error go away and mpd now runs 
correctly.

#bind_to_address"/run/mpd/socket"


I changed the output from Pulseaudio to Pipewire.
This is the relevant section for Pipewire in mpd.conf:


#Pipewire 
audio_output {
type"pipewire"
name"PipeWire Sound Server"
}


I tried using a Pulseaudio output (under Pipewire) but got an error,
$ systemctl --user status mpd.service
Showed:

Feb 16 18:13:54 harpia mpd[1711]: exception: Failed to open "My Pulse Output" 
(pulse); failed to connect: Connection refused

I'm not going to close this bug. Obviously issues remain for Pulseaudio users 
and I'm too lazy to solve this these days. I recommend installing mpd in user 
mode and specify 
a Pipewire output.

Cheers



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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.65-3+deb12u1

Versions of packages pipewire-pulse recommends:
ii  wireplumber  0.4.13-1

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.65-3+deb12u1
ii  pulseaudio-utils  16.1+dfsg1-2+b1

-- no debconf information



Bug#1064072: raspi-firmware: post install script fails for non-raspi devices requiring brcmfmac43456 firmware

2024-02-16 Thread Krzysztof Aleksander Pyrkosz
Package: raspi-firmware
Version: 1.20220830+ds-1
Severity: important
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,

Pine64 RockPro64 requires firmware files that are currently packaged in
raspi-firmware, both in bookworm and sid:
$ dpkg -S brcm/brcmfmac43456
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.txt
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.clm_blob
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.bin

A post install script fails, with the following error:
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return 
code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1

There is no /boot/firmware on RP64.
Can we move these files to a spearate firmware package?
That would solve the issue.

Best regards,
Krzysztof


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

Kernel: Linux 6.1.0-17-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
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 raspi-firmware depends on:
ii  dosfstools  4.2-1
ii  dpkg1.21.22

raspi-firmware recommends no packages.

Versions of packages raspi-firmware suggests:
ii  bluez-firmware 1.2-9
pn  firmware-brcm80211 
pn  firmware-misc-nonfree  

-- no debconf information



Bug#1064071: RFP: hipblaslt -- portable interface for extended general matrix-matrix operations

2024-02-16 Thread Cordell Bloor
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

* Package name: hipblaslt
  Version : 6.0.2
* URL : https://github.com/ROCm/hipBLASLt
* License : Expat
  Programming Lang: C, C++, HIP
  Description : portable interface for extended general matrix-matrix 
operations

hipBLASLt is a library for general matrix-matrix operations that extends
the traditional BLAS interface to support more options controlling data
layout, data types, and algorithm selection. The hipBLASLt library is
implemented in the HIP programming language and is supplemented by tuned
assembly kernels.

The hipBLASLt library helps users port code using cuBLASLt to the AMD
ROCm platform. It is used by PyTorch for accelerating operations on
MI200 and MI300 GPU hardware.

The package is part of AMD's ROCm stack and would be maintained under
the Debian AI team umbrella.



Bug#1060038: RFS: gtklock-userinfo-module/2.1.0-1 [ITP] -- user info module for gtklock

2024-02-16 Thread Matthias Geiger
On Fri, 05 Jan 2024 12:13:29 +0800 Maytham Alsudany 
 wrote:

> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: werdah...@riseup.net
>
> Dear mentors,
>
> I am looking for a sponsor for my package "gtklock-userinfo-module":
>
>  * Package name : gtklock-userinfo-module
>    Version  : 2.1.0-1
>    Upstream contact : 
https://github.com/jovanlanik/gtklock-userinfo-module/issues
>  * URL  : 
https://github.com/jovanlanik/gtklock-userinfo-module

>  * License  : GPL-3+
>  * Vcs  : 
https://salsa.debian.org/Maytha8/gtklock-userinfo-module

>    Section  : misc
>
> The source builds the following binary packages:
>
>   gtklock-userinfo-module - user info module for gtklock
>
> To access further information about this package, please visit the 
following URL:

>
>   https://mentors.debian.net/package/gtklock-userinfo-module/
>
> Alternatively, you can download the package with 'dget' using this 
command:

>
>   dget -x 
https://mentors.debian.net/debian/pool/main/g/gtklock-userinfo-module/gtklock-userinfo-module_2.1.0-1.dsc

>
> Changes for the initial release:
>
>  gtklock-userinfo-module (2.1.0-1) unstable; urgency=medium
>  .
>    * Initial release. (Closes: #1059901)
>
> Kind regards,

> Maytham


Hi Maytham,

looks good so far.

Two minor nitpicks I spotted:  The build dependency on pkg-config should 
be changed to pkgconf as that package was renamed some time ago. Also, 
the Section: in d/control should be x11 since it is display-server related.


Furthermore, as the upstream readme states, the dependency on gtklock 
should probably be versioned like this in d/control: gtklock (>= 
${binary:Version}),  ( see Debian policy § 7.1).


Personal recommendation: look into setting up you repo DEP-14 style (and 
possible under the debian/ umbrella) as this will make maintaining in 
the long run easier imho.


best,

werdahias



Bug#1064070: RFP: cxxheaderparser -- python library for parsing C++ headers

2024-02-16 Thread Cordell Bloor
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

* Package name: cxxheaderparser
  Version : 1.3.1
  Upstream Contact: RobotPy Development Team 
* URL : https://github.com/robotpy/cxxheaderparser
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python library for parsing C++ headers

The cxxheaderparser library is used to parse syntactically valid C++
code and operate on the results. It provides both a visitor-style
interface to process the results as they are being parsed or the option
of a single data structure containing all parsed information.

This library is a successor to CppHeaderParser, which is a build
dependency of the AMD ROCm GPU profiling libraries used by PyTorch.
Specifically, CppHeaderParser is required for roctracer and parts of
rocm-hipamd. As CppHeaderParser has been deprecated by its authors,
those libraries will need to be migrated to cxxheaderparser.



Bug#1061463: Ardour not only crashing when exporting audio data

2024-02-16 Thread Chris Jölly
I want to add that Ardour not only crashes when exporting audio, it very 
often crashes during the following tasks as well:


* Using ZanAddSubFX as instrument in a MIDI track and trying to save the 
settings with save instrument from within ZynAddSubFX.


The probability to crash is very high when typing the file name in the 
Save instrument dialog of ZynAddSubFX.


(This does not happen when using an Ardour build of version 8.2.0 from 
ardour.org website)


* Crashing randomly when editing MIDI notes.

(This does not happen when using an Ardour build of version 8.2.0 from 
ardour.org website)



As the Ardour binary from ardour.org uses the same components on my 
Trixie system, like ZynAddSubFX (Zyn-Fusion UI) and JACK, those 
components are most likely not leading to the crashes.



This is the build configuration from the stable Ardour binary (taken 
from Ardours about dialog):



Build documentation: False
Debuggable build: False
Export all symbols (backtrace): False
Install prefix: /usr
Strict compiler flags: []
Internal Shared Libraries: True
Use External Libraries: False
Library exports hidden: True
Free/Demo copy: False

ALSA DBus Reservation: True
Architecture flags: None
ARM NEON support: False
Aubio: True
AudioUnits: False
Build target: x86_64
Canvas Test UI: False
Beatbox test app: False
CoreAudio: False
CoreAudio 10.5 compat: False
Debug RT allocations: False
Debug Symbols: False
Denormal exceptions: False
Dr. Mingw: False
FLAC: True
FPU optimization: True
FPU AVX512F support: False
FPU AVX/FMA support: True
Futex Semaphore: True
Freedesktop files: False
Libjack linking: weak
Libjack metadata: True
Lua Binding Doc: False
Lua Commandline Tool: True
LV2 UI embedding: True
LV2 support: True
LV2 extensions: True
LXVST support: True
Mac VST support: False
NI-Maschine: False
OGG: True
Phone home: True
Process thread timing: False
Program name: Ardour
Samplerate: True
PT format: True
PTW32 Semaphore: False
Threaded WaveViews: True
Translation: True
Unit tests: False
Use LLD linker: False
VST3 support: True
Windows VST support: False
Wiimote support: False
Windows key: Mod4>C compiler flags: ['-I/home/ardour/linux-x86_64-v5/ardour', 
'-I/home/ardour/linux-x86_64-v5/gtk/inst/include', '-DHAVE_RF64_RIFF', 
'-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-std=c99', 
'-pedantic', '-Wshadow', '-Wall', '-Wcast-align', '-Wextra', 
'-Wwrite-strings', '-Wunsafe-loop-optimizations', '-Wlogical-op', 
'-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', 
'-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', 
'-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', 
'-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', 
'-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', 
'-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-D_ISOC9X_SOURCE', 
'-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', 
'-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', 
'-Wstrict-prototypes', '-Wmissing-prototypes', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtk-2.0/include', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/pango-1.0', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/atk-1.0', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/cairo', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/pixman-1', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/gdk-pixbuf-2.0', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libpng16', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/harfbuzz', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/fribidi', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glib-2.0', 
'-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/glib-2.0/include', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/uuid', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/libxml2', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/freetype2', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/gtkmm-2.4', '-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtkmm-2.4/include', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atkmm-1.6', 
'-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-unix-print-2.0', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdkmm-2.4', 
'-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/gdkmm-2.4/include', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/giomm-2.4', 
'-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/giomm-2.4/include', 
'-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pangomm-1.4', 
'-isystem', 
'/home/ardour/linux-x86_64-v5/gtk/inst/lib/pangomm-1.4/include', 
'-isystem', 

Bug#1061341: Some headers are still unusable

2024-02-16 Thread Adrien Nader
Hi,

I am trying to update the time_t analysis and I'm seeing a couple issues
in headers. Note that I may also be doing something wrong and/or stupid
since I'm approaching this through a-c-c rather than as a regular user.

The two issues:
- at least auth.h (IIRC) refers to lib/strarray.h but the headers might
  rather be cyrus/strarray.h,
- cyrus/bitvector.h uses config.h which isn't shipped.

I was able to analyze the library after modifying auth.h (actually
cyrus/*.h) to use cyrus/strarray.h and skipping bitvector.h. The
analysis returns that the library is both time_t and LFS sensitive. I
will publish a report soon (hopefully this evening but I can't
guarantee it).

-- 
Adrien



Bug#997441: squirrel3: FTBFS: '! LaTeX Error: File `tgtermes.sty' not found.'

2024-02-16 Thread Matthias Geiger

On Sat, 23 Oct 2021 22:26:14 +0200 Lucas Nussbaum  wrote:
> Source: squirrel3
> Version: 3.1-8
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/debian/tmp/doc'
> > latexmk -pdf -dvi- -ps- 'reference.tex'
> > Rc files read:
> > /etc/LatexMk
> > latexmkrc
> > Latexmk: This is Latexmk, John Collins, 21 September 2021, version: 
4.75.

> > Rule 'pdflatex': File changes, etc:
> > Changed files, or newly in use since previous run(s):
> > 'reference.tex'
> > 
> > Run number 1 of rule 'pdflatex'
> > 
> > 
> > Running 'pdflatex -recorder "reference.tex"'
> > 
> > Latexmk: applying rule 'pdflatex'...
> > This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 
2022/dev/Debian) (preloaded format=pdflatex)

> > restricted \write18 enabled.
> > entering extended mode
> > (./reference.tex
> > LaTeX2e <2021-06-01> patch level 1
> > L3 programming layer <2021-08-27> (./sphinxmanual.cls
> > Document Class: sphinxmanual 2019/12/01 v2.3.0 Document class 
(Sphinx manual)

> > (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
> > Document Class: report 2021/02/12 v1.4n Standard LaTeX document class
> > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
> > (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty<>)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
> > (/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
> >
> > ! LaTeX Error: File `tgtermes.sty' not found.
> >

> > Type X to quit or  to proceed,

tags -1 patch

thanks


debdiff fixing this bug attached.


best,


werdahias

diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog  2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/changelog  2024-02-16 17:46:43.0 +0100
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix watch file to look for Github tags instead of releases 
+  * Build-depend on tex-gyre (Closes: #997441)
+
+ -- Matthias Geiger   Fri, 16 Feb 2024 17:46:43 +0100
+
 squirrel3 (3.1-8) unstable; urgency=medium
 
   * Change build dependency from texlive-generic-extra to
diff -Nru squirrel3-3.1/debian/control squirrel3-3.1/debian/control
--- squirrel3-3.1/debian/control2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/control2024-02-16 17:46:43.0 +0100
@@ -8,7 +8,8 @@
texlive,
texlive-latex-extra,
texlive-plain-generic,
-   latexmk
+   latexmk,
+   tex-gyre,
 Standards-Version: 4.4.0
 Homepage: http://squirrel-lang.org/
 Vcs-Git: https://salsa.debian.org/wolff-guest/squirrel3.git/
diff -Nru squirrel3-3.1/debian/watch squirrel3-3.1/debian/watch
--- squirrel3-3.1/debian/watch  2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/watch  2024-02-16 17:46:11.0 +0100
@@ -1,4 +1,4 @@
 version=4
 opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%squirrel-$1.tar.gz%" \
- https://github.com/albertodemichelis/squirrel/releases \
+ https://github.com/albertodemichelis/squirrel/tags \
  (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate


Bug#1064069: python3-looseversion: bogus package description

2024-02-16 Thread Jakub Wilk

Package: python3-looseversion
Version: 1.3.0-1

The package description is completely wrong:

$ apt-cache show python3-looseversion | grep-dctrl -s Description-en ''
Description-en: Python module for simple PAM authentications (Python 3)
 Provide an authenticate() function that will allow the caller to
 authenticate a user against the Pluggable Authentication Modules
 (PAM) on the system.
 .
 The module pam.py is a single file, implemented using ctypes, so
 no compilation is necessary. This package provides the pam.py
 module for Python 3.

--
Jakub Wilk



Bug#1063905: usrmerge breaks POSIX

2024-02-16 Thread Thorsten Glaser
reopen 1063905
severity 1063905 wishlist
retitle 1063905 mksh: add /usr/bin/mksh{,-static} to /etc/shells
tags 1063905 + pending
found 1063905 59c-23
# well /usr/bin/mksh, /usr/bin/mksh-static is not, see below
notfound 1063905 59c-22
thanks

Russ Allbery dixit:

>After some research with git blame, it appears that pkexec checks SHELL
>against /etc/shells because pkexec passes SHELL to the program that it
>executes (possibly in a different security context) and was worried about
>users being able to manipulate and potentially compromise programs across
>that security boundary by setting SHELL to some attacker-controlled value.

Ah okay, that makes sense.

>It is using /etc/shells as a list of possible valid values for that
>variable that are safe to pass on.

That… is probably not a bad guess, yes…

Thank you for going into this kind of extra research.
So I guess I’ll explicitly add this on the next sid upload
and I guess also have to ask about a fix in stable-p-u as
bookworm also requires this filesystem layout. The package
in bullseye used add-shell which (on merged-usr) introduced…

/bin/mksh
/usr/bin/mksh
/bin/mksh-static
/usr/lib/klibc/bin/mksh-static

… hmm. These. The forth one is the bogus one which caused
piuparts failure and was what got me to add code to work
around this add-shell misbehaviour in the first place. Is
this (I’m handling this as a feature request for inter‐
operability with some unrelated software in the presence
of the UsrMove filesystem layout) relevant enough to also
get this changed (by cherry-picking the maintainer script
change) to o-p-u? (Any SRMs reading this, feel free to say,
otherwise I’ll just use the normal reportbug way.)

If so, I’m thinking of checking whether the /usr/bin/ paths
exist and resolve to the same files as the /bin/ paths, so
the /usr/bin/ ones wouldn’t get added to FHS/FSSTND systems.
This runs in postinst, so dpkg-reconfigure would suffice to
update it, but AIUI the usrmerge package also adds shells.

(Note that, unlike add-shell and the newer update-shells, my
maintainer script code handles the local admin commenting out
lines and will not reintroduce them. This would count these
paths as distinct though, but I guess that one migrates the
filesystem layout only once anyway.)

There is also /bin/rmksh but that is deliberately not added
to /etc/shells so far. I’ve no idea why bash and ksh93 differ.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)



Bug#1063905: mksh: /usr/bin/mksh and /usr/bin/mksh-static are no longer in /etc/shells

2024-02-16 Thread Thorsten Glaser
Dixi quod…

>The OP’s $SHELL should not be set to /usr/bin/bash as that
>value is not in /etc/shells and not its canonical path in
>the first place.

And login(1) is clear that it sets $SHELL from the passwd
file, where it gets added by adduser which should honour
/etc/shells.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



Bug#1044068: q2templates: FTBFS with pandas 2.0

2024-02-16 Thread Andreas Tille
Hi,

thanks a lot for all your help!  I've just uploaded q2templates.  If you
have more hints to pandas2 related bugs these are very welcome.

Kind regards
Andreas.

Am Fri, Feb 16, 2024 at 02:29:15PM +0100 schrieb s3v:
> Hi,
> 
> sorry for writing again but, after removing override for auto_test in
> d/rules and s/python3/python3-all in d/control for Build-Depends,
> tests fail with Python 3.12:
> 
> dh_auto_clean
> I: pybuild base:305: python3.12 setup.py clean
> /build/q2templates-2023.9.0+ds/versioneer.py:422: SyntaxWarning: invalid 
> escape sequence '\s'
>   LONG_VERSION_PY['git'] = '''
> Traceback (most recent call last):
>   File "/build/q2templates-2023.9.0+ds/setup.py", line 14, in 
>     version=versioneer.get_version(),
>     
>   File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1481, in 
> get_version
>     return get_versions()["version"]
>    ^^
>   File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1413, in 
> get_versions
>     cfg = get_config_from_root(root)
>   ^^
>   File "/build/q2templates-2023.9.0+ds/versioneer.py", line 343, in 
> get_config_from_root
>     parser = configparser.SafeConfigParser()
>  ^
> AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. 
> Did you mean: 'RawConfigParser'?
> E: pybuild pybuild:391: clean: plugin distutils failed with: exit code=1: 
> python3.12 setup.py clean
> 
> Kind Regards
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de



Bug#1064068: font-manager shows the older version of two versions of the same font and prints “Fontconfig error: No writable cache directories” on the console

2024-02-16 Thread Al Ma
Package: fontconfig
Version: 2.14.1-4
Control: affects -1 font-manager
For the purpose of this bug report, let's assume you have two versions of the 
same font, say, Courier New (the real name is probably irrelevant, as we only 
need the same name):
/usr/share/fonts/truetype/msttcorefonts/cour.ttf
/usr/local/share/fonts/link_to_a_directory_on_a_nonroot_drive/cour.ttf
The tool gnome-font-viewer reports v2.82 for the first font file and a larger 
version for the second font file. The tool font-manager reports also v2.82 for 
Courier New. So a file with a larger version is ignored. This is not good and 
should be improved: whenever two versions of the same font are available, the 
larger one should be taken.
Upon starting the font-manager, we see 4 equal lines “Fontconfig error: No 
writable cache directories” on the console without further information.
Running
# fc-cache -r && fc-cache -fv && dpkg-reconfigure fontconfig fontconfig-cache
font-manager didn't help, and /var/log/syslog and dmesg show, subjectively, 
nothing of interest for this bug report.


Bug#1064067: libdemeter-perl: ships perl modules already packaged separately as libxray-scattering-perl, libxray-absorption-perl

2024-02-16 Thread Andreas Beckmann
Package: libdemeter-perl
Version: 0.9.27+ds6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../libdemeter-perl_0.9.27+ds6-1_amd64.deb ...
  Unpacking libdemeter-perl (0.9.27+ds6-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libdemeter-perl_0.9.27+ds6-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/perl5/Xray/Absorption/CL.pm', which is also 
in package libxray-absorption-perl 3.0.1-4
  Errors were encountered while processing:
   /var/cache/apt/archives/libdemeter-perl_0.9.27+ds6-1_amd64.deb

Why does the package have to ship its own Ifeffit.pm ? Anyway, the
Replaces against libifeffit-perl are missing corresponding Breaks.
But I'm not convinced that Breaks+Replaces is the correct solution here.


cheers,

Andreas


libxray-scattering-perl=3.0.1-3_libdemeter-perl=0.9.27+ds6-1.log.gz
Description: application/gzip


Bug#1064066: ocaml-mirage-crypto FTBFS on riscv64 with kernel >= 6.6

2024-02-16 Thread Adrian Bunk
Source: ocaml-mirage-crypto
Version: 0.11.2-1
Severity: important
Tags: ftbfs patch
Forwarded: https://github.com/mirage/mirage-crypto/pull/194

https://buildd.debian.org/status/fetch.php?pkg=ocaml-mirage-crypto=riscv64=0.11.2-1%2Bb3=1708088363=0

...
(cd _build/default/tests && ./test_entropy.exe)
Command got signal ILL.
File "tests/dune", line 20, characters 7-25:
20 |  (name test_random_runner)
^^
(cd _build/default/tests && ./test_random_runner.exe)
Command got signal ILL.
File "tests/dune", line 53, characters 7-14:
53 |  (name test_ec)
^^^
(cd _build/default/tests && ./test_ec.exe)
Command got signal ILL.
(cd _build/default/tests && ./test_symmetric_runner.exe)
accel: 
...
Ran: 183 tests in: 0.82 seconds.
OK
File "tests/dune", line 27, characters 7-21:
27 |  (name test_pk_runner)
^^
(cd _build/default/tests && ./test_pk_runner.exe)
Command got signal ILL.
...



Bug#1064054: qtbase-opensource-src-gles: CVE-2024-25580

2024-02-16 Thread James Addison
Source: qtbase-opensource-src-gles
Followup-For: Bug #1064054
Control: found -1 5.12.2+dfsg-1
Control: tags -1 patch
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
 quint32 bytesOfKeyValueData;
 };
 
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
 
 // Currently unused, declared for future reference
 struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
 */
 };
 
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32 
length)
 {
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
 
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH) 
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier, 
KTX_IDENTIFIER_LENGTH));
 }
 
 QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
 if (!device())
 return QTextureFileData();
 
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s", 
logName().constData());
 return QTextureFileData();
 }
 
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
 return QTextureFileData();
 }
 
 QTextureFileData texData;
 texData.setData(buf);
 
-texData.setSize(QSize(decode(header->pixelWidth), 
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32);   // Cap 
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)// 
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 - 
((levelLen + 3) % 4));
+texData.setSize(QSize(decode(header.pixelWidth), 
decode(header.pixelHeight)));
+texData.setGLFormat(decode(header.glFormat));
+texData.setGLInternalFormat(decode(header.glInternalFormat));
+texData.setGLBaseInternalFormat(decode(header.glBaseInternalFormat));
+
+texData.setNumLevels(decode(header.numberOfMipmapLevels));
+
+const quint32 bytesOfKeyValueData = decode(header.bytesOfKeyValueData);
+quint32 headerKeyValueSize;
+if (qAddOverflow(qktxh_headerSize, bytesOfKeyValueData, 
)) {
+qWarning(lcQtGuiTextureIO, "Overflow in size of key value data in 
header of KTX file %s",
+ 

Bug#1064053: qtbase-opensource-src: CVE-2024-25580

2024-02-16 Thread James Addison
Source: qtbase-opensource-src
Followup-For: Bug #1064053
Control: found -1
Control: found -1 5.12.2+dfsg-1

Replying to set the earliest version affected from the advisory blogpost[1],
and to (re)attach the patch from the duplicate bugreport.

[1]  
https://www.qt.io/blog/security-advisory-potential-buffer-overflow-when-reading-ktx-images
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
 quint32 bytesOfKeyValueData;
 };
 
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
 
 // Currently unused, declared for future reference
 struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
 */
 };
 
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32 
length)
 {
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
 
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH) 
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier, 
KTX_IDENTIFIER_LENGTH));
 }
 
 QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
 if (!device())
 return QTextureFileData();
 
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s", 
logName().constData());
 return QTextureFileData();
 }
 
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
 return QTextureFileData();
 }
 
 QTextureFileData texData;
 texData.setData(buf);
 
-texData.setSize(QSize(decode(header->pixelWidth), 
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32);   // Cap 
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)// 
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 - 
((levelLen + 3) % 4));
+texData.setSize(QSize(decode(header.pixelWidth), 
decode(header.pixelHeight)));
+texData.setGLFormat(decode(header.glFormat));
+texData.setGLInternalFormat(decode(header.glInternalFormat));
+texData.setGLBaseInternalFormat(decode(header.glBaseInternalFormat));
+
+texData.setNumLevels(decode(header.numberOfMipmapLevels));
+
+const quint32 bytesOfKeyValueData = 

Bug#1064065: libcap2-bin: captree is not packaged

2024-02-16 Thread Christophe Lohr
Package: libcap2-bin
Version: 1:2.66-5
Severity: minor

Dear Maintainer,
  Please note that the captree tool is not packaged (despite the presence of
the man page).

Best regards
Christophe


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

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

Versions of packages libcap2-bin depends on:
ii  libc62.37-15
ii  libcap2  1:2.66-5

Versions of packages libcap2-bin recommends:
ii  libpam-cap  1:2.66-5

libcap2-bin suggests no packages.

-- no debconf information



Bug#1064052: qt6-base: CVE-2024-25580

2024-02-16 Thread James Addison
Followup-For: Bug #1064052
Control: fixed -1 6.6.2+dfsg-1



Bug#1064064: bookworm-pu: package wayfire/0.7.4-3+deb12u1

2024-02-16 Thread Boyuan Yang
Package: release.debian.org
Control: affects -1 + src:wayfire
X-Debbugs-Cc: wayf...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
X-Debbugs-Cc: by...@debian.org
Severity: normal

[ Reason ]
Currently binary package wayfire-dev needs several other -dev packages
to work, but the dependency relationship is not documented. This will
result in the following errors when trying to use wayfire-dev alone:

Determining dependency 'wayfire' with pkg-config executable '/usr/bin/pkg-
config'
env[PKG_CONFIG_PATH]: /usr/lib/aarch64-linux-gnu/pkgconfig
Called `/usr/bin/pkg-config --modversion wayfire` -> 1
stderr:
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
Package 'cairo', required by 'wayfire', not found
Package 'pango', required by 'wayfire', not found
Package 'pangocairo', required by 'wayfire', not found
Package 'wayland-server', required by 'wayfire', not found
Package 'pixman-1', required by 'wayfire', not found
Package 'wlroots', required by 'wayfire', not found
Package 'wf-config', required by 'wayfire', not found

As a result, an upload adding such binary dependencies for the deb package
is needed.

The bug is documented at https://bugs.debian.org/1064011 .

[ Impact ]
If not approved, users of wayfire-dev will have to manually build-depends
on corresponding -dev packages in order to build software using wayfire
headers.

[ Tests ]
Manually tested on my machine.

[ Risks ]
Minimal risk. Only changes in binary dependencies involved.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Add binary dependencies on the following packages for wayfire-dev:
 + libwlroots-dev,
 + libcairo-dev,
 + libpango1.0-dev,
 + libwayland-dev,
 + libpixman-1-dev,
 + libwf-config-dev


Thanks,
Boyuan Yang

diff -Nru wayfire-0.7.4/debian/changelog wayfire-0.7.4/debian/changelog
--- wayfire-0.7.4/debian/changelog	2023-05-03 15:25:12.0 -0400
+++ wayfire-0.7.4/debian/changelog	2024-02-16 10:17:37.0 -0500
@@ -1,3 +1,10 @@
+wayfire (0.7.4-3+deb12u1) bookworm; urgency=medium
+
+  * debian/control: Add missing -dev package dependency for
+wayfire-dev package. (Closes: #1064011)
+
+ -- Boyuan Yang   Fri, 16 Feb 2024 10:17:37 -0500
+
 wayfire (0.7.4-3) unstable; urgency=medium
 
   * debian/control: Let libwf-utils-dev depends on libwf-utils0.
diff -Nru wayfire-0.7.4/debian/control wayfire-0.7.4/debian/control
--- wayfire-0.7.4/debian/control	2023-05-03 15:25:08.0 -0400
+++ wayfire-0.7.4/debian/control	2024-02-16 10:16:21.0 -0500
@@ -88,6 +88,12 @@
 Architecture: any
 Depends:
  ${misc:Depends},
+ libwlroots-dev,
+ libcairo-dev,
+ libpango1.0-dev,
+ libwayland-dev,
+ libpixman-1-dev,
+ libwf-config-dev,
 Description: 3D Wayland compositor (development files)
  Wayfire is a 3D Wayland compositor, inspired by Compiz and based on
  wlroots. It aims to create a customizable, extendable and lightweight


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


Bug#981017: Upstream PR

2024-02-16 Thread Martin Dosch

Dear Philippe,

I just locally rebuilt cd-paranoia with the patch from this PR: 
https://github.com/rocky/libcdio-paranoia/pull/38
This fixed the issue and whipper was able to determine the correct 
offset and to rip an album.


Best regards,
Martin


signature.asc
Description: PGP signature


Bug#1064063: plasma-workspace: CVE-2024-1433

2024-02-16 Thread Moritz Mühlenhoff
Source: plasma-workspace
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for plasma-workspace.

CVE-2024-1433[0]:
| A vulnerability, which was classified as problematic, was found in
| KDE Plasma Workspace up to 5.93.0. This affects the function
| EventPluginsManager::enabledPlugins of the file
| components/calendar/eventpluginsmanager.cpp of the component Theme
| File Handler. The manipulation of the argument pluginId leads to
| path traversal. It is possible to initiate the attack remotely. The
| complexity of an attack is rather high. The exploitability is told
| to be difficult. The patch is named
| 6cdf42916369ebf4ad5bd876c4dfa0170d7b2f01. It is recommended to apply
| a patch to fix this issue. The associated identifier of this
| vulnerability is VDB-253407. NOTE: This requires write access to
| user's home or the installation of third party global themes.

https://github.com/KDE/plasma-workspace/commit/6cdf42916369ebf4ad5bd876c4dfa0170d7b2f01


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

Please adjust the affected versions in the BTS as needed.



Bug#1064062: iwd: CVE-2023-52161

2024-02-16 Thread Moritz Mühlenhoff
Source: iwd
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for iwd.

CVE-2023-52161[0]:
https://www.top10vpn.com/research/wifi-vulnerabilities/

While this mentions a patch for wpasupplication, it's not obvious
if this was reported/fixed in iwd.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.



Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

2024-02-16 Thread Simon Josefsson
Sebastian Ramacher  writes:

> FAIL: krb5context
> =
>
> ==31890== 
> ==31890== Process terminating with default action of signal 11 (SIGSEGV)
> ==31890==  Access not within mapped region at address 0xBDB33984
> ==31890==at 0x4856C00: shishi_key_parse (in 
> /usr/lib/arm-linux-gnueabihf/libshishi.so.0.1.3)
> ==31890==  If you believe this happened as a result of a stack
> ==31890==  overflow in your program's main thread (unlikely but
> ==31890==  possible), you can try to increase the size of the
> ==31890==  main thread stack using the --main-stacksize= flag.
> ==31890==  The main thread stack size used in this run was 8388608.
> FAIL krb5context (exit status: 139)

Thanks for the report.  Could this be another arch-specific valgrind
behaviour change causing FTBFS?

It seems that at some point valgrind on armhf did not raise this error
message, so building gss worked fine.  Then valgrind on armhf changed
that lead to the error message above when building the old gss.

You use valgrind version 1:3.20.0-2.1 and the last successful build of
gss used valgrind version 1:3.18.1-1.1 see log:

https://buildd.debian.org/status/fetch.php?pkg=gss=armhf=1.0.4-1=1659802402=0

Given that gss builds use valgrind on other architectures successfully,
and has succeeded on this architecture before, I don't feel convinced
that valgrind has found a genuine gss/shishi problem here.  So I think
this bug can be reassigned to valgrind for analysis.

Some possible relevant links:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057693
https://tracker.debian.org/news/1482474/accepted-valgrind-13200-2-source-into-unstable/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224

Maybe valgrind should do a debci/autopkgtest test run on new valgrind on
gss or gsasl which has triggered similar bugs before?

/Simon


signature.asc
Description: PGP signature


Bug#1064061: wpa: CVE-2023-52160

2024-02-16 Thread Moritz Mühlenhoff
Source: wpa
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for wpa.

CVE-2023-52160[0]:
https://www.top10vpn.com/research/wifi-vulnerabilities/
https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baff


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.



Bug#1064060: wsdd: Split to client and server packages?

2024-02-16 Thread Jeremy Bícha
Source: wsdd
Version: 2:0.7.0-2.1
Severity: important
Tags: trixie sid
Control: affects -1 src:gvfs

gvfs 1.53.90-1 uses wsdd to find newer Windows network shares.

My initial understanding is that wsdd can be used both to advertise
network shares or to find network shares. gvfs only needs the "find"
behavior and gvfs calls wsdd from $PATH directly when needed.

I believe it is unwanted behavior for wsdd.service to be running for
gvfs's use case.

Therefore, please create a separate package for wsdd.service , perhaps
named wsdd-server

Thank you,
Jeremy Bícha



Bug#1064059: U-Boot: secure boot support

2024-02-16 Thread Heinrich Schuchardt

Package: u-boot-qemu
Version: 2024.01+dfsg-1
Severity: normal

debian/patches/qemu/efi-secure-boot.patch is not a good approach to 
enabling secure boot with U-Boot. Variables entered via the command line 
containing the security database will be stored on file but will not be 
loaded into U-Boot on the next boot.


If you want a version of U-Boot that supports secure boot properly, use 
CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security 
database which will be built into U-Boot. tools/efivar.py can be used to 
build that file.


Separate U-Boot binaries for secure and non-secure would have to be 
provided.


Existing EDK II packages provide secure boot. Hence I suggest to simply 
drop patch debian/patches/qemu/efi-secure-boot.patch.


Best regards

Heinrich



Bug#1064058: libxml-stream-perl: TLS/SSL broken with IO-Socket-SSL >= 2.078 when hostname verification is enabled

2024-02-16 Thread Manfred Stock
Package: libxml-stream-perl
Version: 1.24-4
Severity: normal
Tags: upstream
Control: affects -1 sendxmpp libnet-xmpp-perl

Dear Maintainers,

after upgrading to Debian Bookworm, we noticed that the sendxmpp command
line tool was not working anymore in our setup. During the investigation
of this issue, I noticed that downgrading IO-Socket-SSL to the version
in Bullseye made sendxmpp work again. I then started to try all versions
of IO-Socket-SSL between the version in Bullseye and the one in Bookworm
and found that it stopped working with version 2.078. Eventually, I came
up with a pull request [1] containing a patch that fixed it for us -
apparently, the way XML-Stream was using IO-Socket-SSL most likely
always resulted in the hostname verification to be done against the IP
address of the peer instead of an actual hostname, which was always
considered to be successful in IO-Socket-SSL < 2.078, but not anymore in
newer versions.

Since the upstream seems quite inactive, it might be worth considering
to add this or a similar patch to the package in Debian, as I came
across several other bug reports in the Debian BTS which might actually
be caused by this issue, like #986971 [2], #1032868 [3] and maybe also
#1050336 [4] - at least the error messages in the first two look very
similar to what I saw.

Cheers,
Manfred

[1]: https://github.com/dap/XML-Stream/pull/28
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986971
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032868
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050336

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libxml-stream-perl depends on:
ii  libauthen-sasl-perl2.1600-3
ii  libio-socket-ssl-perl  2.081-2
ii  perl   5.36.0-7+deb12u1

libxml-stream-perl recommends no packages.

Versions of packages libxml-stream-perl suggests:
ii  libnet-dns-perl  1.36-1

-- no debconf information



Bug#1064056: qtbase-opensource-src: CVE-2024-25580

2024-02-16 Thread James Addison
Source: qtbase-opensource-src
Followup-For: Bug #1064056
Control: forcemerge 1064053 -1 

Duplicate of #1064053; force merging this bugreport into that one.



Bug#1064057: wsdd: Should install to /usr/bin/ instead of /usr/sbin/

2024-02-16 Thread Jeremy Bícha
Source: wsdd
Version: 2:0.7.0-2.1
Severity: important
Tags: patch trixie sid
Forwarded: https://salsa.debian.org/grantma/wsdd/-/merge_requests/2
Control: affects -1 src:gvfs

gvfs 1.53.90-1 now tries to use wsdd from $PATH but Debian's default
$PATH does not include /usr/sbin/

According to the latest version of the Filesystem Hierarchy System
(FHS) 3.0, § 3.16,
"/sbin contains binaries essential for booting, restoring, recovering,
and/or repairing the system in addition to the binaries in /bin. [18]
Programs executed after /usr is known to be mounted (when there are no
problems) are generally placed into /usr/sbin."

I don't believe wsdd is any of those categories.

I am filing as Important, but Serious may be appropriate. Debian
Policy § 9.1.1 requires compliance with the FHS with some exceptions
(which don't apply here).

References
---
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure

Thank you,
Jeremy Bícha



Bug#1064056: qtbase-opensource-src: CVE-2024-25580

2024-02-16 Thread James Addison
Source: qtbase-opensource-src
Version: 5.15.10+dfsg-6
Severity: normal
Tags: patch security

Dear Maintainer,

Security advisory CVE-2024-25580, a buffer overflow affecting KTX image
handling in QT, has been announced[1], and the announcement includes patches
for various versions of QT including the v5.15 branch.

I've confirmed that the patch applies cleanly to qtbase-opensource-src versions
5.15.8+dfsg-11 (bookworm / stable) and 5.15.10+dfsg-6 (trixie / testing), and
have successfully compiled the trixie package.

Please find attached the v5.15 patch from upstream.
( sha256sum 7cc9bf74f696de8ec5386bb80ce7a2fed5aa3870ac0e2c7db4628621c5c1a731 )

Regards,
James

[1] - https://lists.qt-project.org/pipermail/announce/2024-February/000472.html
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
 quint32 bytesOfKeyValueData;
 };
 
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
 
 // Currently unused, declared for future reference
 struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
 */
 };
 
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32 
length)
 {
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
 
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH) 
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier, 
KTX_IDENTIFIER_LENGTH));
 }
 
 QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
 if (!device())
 return QTextureFileData();
 
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s", 
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s", 
logName().constData());
 return QTextureFileData();
 }
 
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s", 
logName().constData());
 return QTextureFileData();
 }
 
 QTextureFileData texData;
 texData.setData(buf);
 
-texData.setSize(QSize(decode(header->pixelWidth), 
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32);   // Cap 
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)// 
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 - 
((levelLen + 3) % 4));
+

Bug#1064055: nodejs: CVE-2023-46809 CVE-2024-22019 CVE-2024-21892

2024-02-16 Thread Moritz Mühlenhoff
Source: nodejs
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for nodejs.

CVE-2023-46809[0]:
https://nodejs.org/en/blog/vulnerability/february-2024-security-releases/#nodejs-is-vulnerable-to-the-marvin-attack-timing-variant-of-the-bleichenbacher-attack-against-pkcs1-v15-padding-cve-2023-46809---medium

CVE-2024-22019[1]:
https://nodejs.org/en/blog/vulnerability/february-2024-security-releases/#reading-unprocessed-http-request-with-unbounded-chunk-extension-allows-dos-attacks-cve-2024-22019---high

CVE-2024-21892[2]:
https://nodejs.org/en/blog/vulnerability/february-2024-security-releases/#code-injection-and-privilege-escalation-through-linux-capabilities-cve-2024-21892---high

There are some other issues, but they only affect the version in expeirimental.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-46809
https://www.cve.org/CVERecord?id=CVE-2023-46809
[1] https://security-tracker.debian.org/tracker/CVE-2024-22019
https://www.cve.org/CVERecord?id=CVE-2024-22019
[2] https://security-tracker.debian.org/tracker/CVE-2024-21892
https://www.cve.org/CVERecord?id=CVE-2024-21892

Please adjust the affected versions in the BTS as needed.



Bug#1064054: qtbase-opensource-src-gles: CVE-2024-25580

2024-02-16 Thread Moritz Mühlenhoff
Source: qtbase-opensource-src-gles
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qtbase-opensource-src-gles.

CVE-2024-25580[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2264423
https://download.qt.io/official_releases/qt/5.15/CVE-2024-25580-qtbase-5.15.diff


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

Please adjust the affected versions in the BTS as needed.



Bug#1064053: qtbase-opensource-src: CVE-2024-25580

2024-02-16 Thread Moritz Mühlenhoff
Source: qtbase-opensource-src
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qtbase-opensource-src.

CVE-2024-25580[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2264423
https://download.qt.io/official_releases/qt/5.15/CVE-2024-25580-qtbase-5.15.diff


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

Please adjust the affected versions in the BTS as needed.



Bug#1064052: qt6-base: CVE-2024-25580

2024-02-16 Thread Moritz Mühlenhoff
Source: qt6-base
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qt6-base.

CVE-2024-25580[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2264423
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=28ecb523ce8490bff38b251b3df703c72e057519


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

Please adjust the affected versions in the BTS as needed.



Bug#1064051: azure-uamqp-python: CVE-2024-25110

2024-02-16 Thread Moritz Mühlenhoff
Source: azure-uamqp-python
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for azure-uamqp-python.

CVE-2024-25110[0]:
| The UAMQP is a general purpose C library for AMQP 1.0. During a call
| to open_get_offered_capabilities, a memory allocation may fail
| causing a use-after-free issue and if a client called it during
| connection communication it may cause a remote code execution. Users
| are advised to update the submodule with commit `30865c9c`. There
| are no known workarounds for this vulnerability.

azure-uamqp-python appears bundle azure-uamqp-c, so presumably it's
also affected?

https://github.com/Azure/azure-uamqp-c/commit/30865c9ccedaa32ddb036e87a8ebb52c3f18f695
https://github.com/Azure/azure-uamqp-c/security/advisories/GHSA-c646-4whf-r67v


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

Please adjust the affected versions in the BTS as needed.



Bug#1064050: ITP: zellij -- a terminal workspace with batteries included

2024-02-16 Thread Arturo Borrero Gonzalez
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: zellij
  Version : 0.39.2
  Upstream Contact: Aram Drevekenin 
* URL : https://zellij.dev/
* License : MIT
  Programming Lang: Rust
  Description : a terminal workspace with batteries included

Zellij is a terminal workspace. It has the base functionality of a terminal 
multiplexer (similar to tmux or screen)
but includes many built-in features that would allow users to extend it and 
create their own personalized environment.

I plan to maintain this as part of the Rust Packaging workflow described in:
 https://wiki.debian.org/Teams/RustPackaging



Bug#1063712: check-dfsg-status: integration of monthly cron job with systemd-cron

2024-02-16 Thread Alexandre Detiste
Le dim. 11 févr. 2024 à 19:54, Holger Levsen  a écrit :
> ok, please ping this bug once it's in trixie.

It has migrated



Bug#1064010: Kernel not compiling missing file drm_irq.h

2024-02-16 Thread Pascal Hambourg

On 15/02/2024 at 18:08, Joshua Brickel wrote:


Whe running apt-get upgrade I get erors about the kernel installing/building
and it tells me to look in the file  /var/lib/dkms/evdi/1.7.0/build/make.log


Are you doing an installation or an upgrade ? From/to which version(s) ?


make[2]: *** [/usr/src/linux-
headers-6.1.0-18-common/scripts/Makefile.build:255:
/var/lib/dkms/evdi/1.7.0/build/evdi_ioc32.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /var/lib/dkms/evdi/1.7.0/build/evdi_main.c:20:
/var/lib/dkms/evdi/1.7.0/build/evdi_drv.h:24:10: fatal error:
drm/drm_irq.h: No such file or directory
   24 | #include 


This looks like bug#1017058 
 which was 
fixed in evdi 1.12.0 available in bookworm. Your evdi version 1.7.0 
seems to be outdated, even bullseye has evdi 1.9.0.




Bug#1064049: gnome: When using Debian/KDE and installing Gnome via apt, Gnome uses KDE decorations & mouse pointer

2024-02-16 Thread Marc Fouquet
Package: gnome
Version: 1:43+1
Severity: normal
Tags: d-i
X-Debbugs-Cc: marc.fouq...@gmx.de

Dear Maintainer,

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

   * What led up to the situation?

In installed Debian from the Image with KDE.

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

Changed my mind and used "apt install gnome".

   * What was the outcome of this action?

Gnome works, but windows have KDE decorations and the desktop uses the KDE 
mouse pointer. There is no immediately obvious way to change this.

   * What outcome did you expect instead?

That gnome looks like gnome.

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


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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-10
ii  cheese   43.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  evolution3.46.4-2
ii  evolution-plugins3.46.4-2
ii  file-roller  43.0-1
ii  gnome-calendar   43.1-2
ii  gnome-clocks 43.0-1
ii  gnome-color-manager  3.36.0-1+b1
ii  gnome-core   1:43+1
ii  gnome-maps   43.5-2~deb12u1
ii  gnome-music  42.1-1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-tweaks 42~beta-4
ii  gnome-weather43.0-1
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  libgsf-bin   1.14.50-1
ii  libproxy1-plugin-networkmanager  0.4.18-1.2
ii  libreoffice-calc 4:7.4.7-1+deb12u1
ii  libreoffice-gnome4:7.4.7-1+deb12u1
ii  libreoffice-impress  4:7.4.7-1+deb12u1
ii  libreoffice-writer   4:7.4.7-1+deb12u1
ii  network-manager-gnome1.30.0-2
ii  orca 43.1-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  rygel-playbin0.42.1-1
ii  rygel-tracker0.42.1-1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  totem-plugins43.0-2
ii  xdg-user-dirs-gtk0.11-1

Versions of packages gnome recommends:
ii  gnome-games   1:43+1
ii  gnome-initial-setup   43.2-6
ii  gnome-remote-desktop  43.3-1
ii  transmission-gtk  3.00-2.1+deb12u1

Versions of packages gnome suggests:
pn  alacarte  
pn  empathy   
pn  firefox-esr-l10n-all | firefox-l10n-all   
pn  goobox | sound-juicer 
pn  polari
pn  vinagre   
pn  webext-ublock-origin-firefox | webext-ublock-origin-chromium  

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme43-1
ii  at-spi2-core  2.46.0-5
ii  baobab43.0-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  eog   43.2-1
ii  evince43.1-2+b1
ii  evolution-data-server 3.46.4-2
ii  fonts-cantarell   0.303.1-1
ii  gdm3  43.0-3
ii  gkbd-capplet  3.28.1-1
ii  glib-networking   2.74.0-4
ii  gnome-backgrounds 43.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-calculator  1:43.0.1-2
ii  gnome-characters  43.1-1+deb12u1
ii  gnome-contacts43.1-1
ii  gnome-control-center  1:43.6-2~deb12u1
ii  gnome-disk-utility43.0-1
ii  gnome-font-viewer 43.0-1
ii  gnome-keyring 42.1-1+b2
ii  gnome-logs43.0-1
ii  gnome-menus   3.36.0-1.1
ii  gnome-online-accounts 3.46.0-1
ii  gnome-session 43.0-1+deb12u1
ii  gnome-settings-daemon 43.0-4
ii  gnome-shell   43.9-0+deb12u1
ii  gnome-shell-extensions43.1-1
ii  gnome-software43.5-1~deb12u1
ii  gnome-sushi   43.0-2
ii  gnome-system-monitor  42.0-2
ii  gnome-terminal   

Bug#1064048: fcitx5: No german keyboard after fresh Debian/KDE install

2024-02-16 Thread Marc Fouquet
Package: fcitx5
Version: 5.0.21-3
Severity: important
Tags: l10n d-i
X-Debbugs-Cc: marc.fouq...@gmx.de

Dear Maintainer,

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

   * What led up to the situation?

A fresh install of Debian/KDE from the Live CD.

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

Selected german locale during the installation.

   * What was the outcome of this action?

KDE menu text was german, but the keyboard layout was not. The appropriate KDE 
setting dialog (region/language) complained about missing fcitx.
At the time I had no idea what this was. A non-technical user would have 
aborted the installation attempt at this point and switched back to windows.

To solve this, I dis the following:

> apt install fcitx5
- Add fcitx5 to KDE autorun.
> fcitx5-config

I am still not sure, if this was the intended way, the KDE settings page for 
the input method is still not functional (the error message is gone, but there 
are no options to select).
Only fcitx5-config works for changing keyboard options.

   * What outcome did you expect instead?

- Having a working german keyboard when selecting it in the installer.
- The keykoard selection (Regionaleinstellungen => Eingabemethode) in the KDE 
settings App should be functional.

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


-- Package-specific info:

--- Fcitx5 Diagnose output ---

# System Info:
1.  `uname -a`:

Linux kamino 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux

2.  `lsb_release -a`:

Distributor ID: Debian
Description:Debian GNU/Linux 12 (bookworm)
Release:12
Codename:   bookworm

3.  `lsb_release -d`:

Description:Debian GNU/Linux 12 (bookworm)

4.  `/etc/lsb-release`:

`/etc/lsb-release` not found.

5.  `/etc/os-release`:

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

6.  Desktop Environment:

Desktop environment is `kde`.

7.  XDG SESSION TYPE:

XDG_SESSION_TYPE='x11'

8.  Bash Version:

BASH_VERSION='5.2.15(1)-release'

# Environment:
1.  DISPLAY:

DISPLAY=':0'


WAYLAND_DISPLAY=''

2.  Keyboard Layout:

1.  `setxkbmap`:

xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwertz)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include "pc+de+inet(evdev)" };
xkb_geometry  { include "pc(pc104)" };
};

2.  `xprop`:

_XKB_RULES_NAMES(STRING) = "evdev", "pc104", "de", "", ""

3.  Locale:

1.  All locales:

C
C.utf8
POSIX
de_DE.utf8

2.  Current locale:

LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

4.  Directories:

1.  Home:

/home/fouquet

2.  `${XDG_CONFIG_HOME}`:

Environment variable `XDG_CONFIG_HOME` is not set.

Current value of `XDG_CONFIG_HOME` is `~/.config` 
(`/home/fouquet/.config`).

3.  Fcitx5 Settings Directory:

Current fcitx5 settings directory is `~/.config/fcitx5` 
(`/home/fouquet/.config/fcitx5`).

5.  Current user:

The script is run as fouquet (1000).

# Fcitx State:
1.  executable:

Found fcitx5 at `/usr/bin/fcitx5`.

2.  version:

Fcitx version: `5.0.21`

3.  process:

Found 2 fcitx5 processes:

   1913 fcitx5
  44115 fcitx5

4.  `fcitx5-remote`:

`fcitx5-remote` works properly.

5.  DBus interface:

Using `dbus-send` to check dbus.

Owner of DBus name `org.fcitx.Fcitx5` is `:1.62`.

PID of DBus name `org.fcitx.Fcitx5` owner is `1913`.

Debug information from dbus:

   Group [x11::0] has 47 InputContext(s)
  IC [18b56efa163542dea5eabc524a55315b] program: frontend:ibus cap:52 
focus:0
  IC [d29f070f0f274233a19f76ddb41d8df3] program: frontend:ibus cap:52 
focus:0
  IC [b5824b1e5a93484898286a3506e09689] program: frontend:ibus cap:52 
focus:0
  IC [e4ea6071605e40dba968e201f9dd9971] program: frontend:ibus cap:12 
focus:0
  IC [b79c3e929e06497797ba6cec2271592e] program: frontend:ibus cap:12 
focus:0
  IC [b2ec1c4d42a24eff8d122de5368e2dd4] program: 

Bug#1044068: q2templates: FTBFS with pandas 2.0

2024-02-16 Thread s3v
Hi,

sorry for writing again but, after removing override for auto_test in
d/rules and s/python3/python3-all in d/control for Build-Depends,
tests fail with Python 3.12:

dh_auto_clean
I: pybuild base:305: python3.12 setup.py clean
/build/q2templates-2023.9.0+ds/versioneer.py:422: SyntaxWarning: invalid escape 
sequence '\s'
  LONG_VERSION_PY['git'] = '''
Traceback (most recent call last):
  File "/build/q2templates-2023.9.0+ds/setup.py", line 14, in 
    version=versioneer.get_version(),
    
  File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1481, in get_version
    return get_versions()["version"]
   ^^
  File "/build/q2templates-2023.9.0+ds/versioneer.py", line 1413, in 
get_versions
    cfg = get_config_from_root(root)
  ^^
  File "/build/q2templates-2023.9.0+ds/versioneer.py", line 343, in 
get_config_from_root
    parser = configparser.SafeConfigParser()
 ^
AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did 
you mean: 'RawConfigParser'?
E: pybuild pybuild:391: clean: plugin distutils failed with: exit code=1: 
python3.12 setup.py clean

Kind Regards



Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

2024-02-16 Thread Christoph Berg
Re: Steve Langasek
> Sorry, did you manage to get sensible a-c-c output?  Otherwise, how did you
> determine that there was a single symbol affected?  The only compat_report
> output I have shows *zero* symbols affected but also shows a bunch of
> garbage output that makes me not trust it at all.

That was in a different sub-thread on this bug:

  For postgresql-16 (where libpq-dev comes from), the only symbol
  affected seems to be pqWaitTimed as indicated above.

  The good news is that the function is only used internally in libpq,
  and by no external user:

  https://codesearch.debian.net/search?q=pqWaitTimed=1
  https://github.com/search?q=pqWaitTimed=code

  (GitHub finds a bunch of instances, but these are all either
  PostgreSQL itself, or vendored copies of libpq.)

  So I think we can safely ignore the difference and not rename libpq5.
  (It has been named like that for 20 years and I really don't want to
  break compatibility there.)

Christoph



Bug#1039889: recommends old ffmpeg libs

2024-02-16 Thread Phillip Berndt
Hi Don,

this probably got lost. Could you build & upload the package, please?

I double checked, the package still builds without warning (except for
one complaint by groff about the manpage, which I think we can live
with and which I'll fix upstream for the next releast).

Thanks,
Phillip

Am Mo., 5. Feb. 2024 um 11:12 Uhr schrieb Spitzenpfeil, Robert
:
>
>
> Any news on this?
>
> pqiv used to be able to playback videos (mp4 / mpg) on debian 11 (and
> still after updating to 12).
>
> With a fresh install of debian 12 (pqiv 2.12) pqiv cannot do this anymore.
>
>
> Robert
>



Bug#1064043: closed by Michael Biebl (Re: Bug#1064043: systemd: /etc/fstab x-systemd.automount mount points, x-systemd.idle-timeout changes not effective)

2024-02-16 Thread David Sauvage - AdaLabs Ltd



On 2/16/24 16:01, Michael Biebl wrote:

Am 16.02.24 um 12:51 schrieb David Sauvage - AdaLabs Ltd:


the changes are not applied even after restarting the mount unit 
mnt-resource.mount. (when already mounted or not)




Have you restarted the corresponding mnt-resource.automount unit as well?


changes updated successfully after restarting mnt-resource.automount 
unit as well.


Sorry for the noise.



Bug#1064043: closed by Michael Biebl (Re: Bug#1064043: systemd: /etc/fstab x-systemd.automount mount points, x-systemd.idle-timeout changes not effective)

2024-02-16 Thread Michael Biebl

Am 16.02.24 um 12:51 schrieb David Sauvage - AdaLabs Ltd:


the changes are not applied even after restarting the mount unit 
mnt-resource.mount. (when already mounted or not)




Have you restarted the corresponding mnt-resource.automount unit as well?





OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1064042: gsettings-desktop-schemas: regression: LC_TIME=en_GB.utf8 uses 12-hour time format

2024-02-16 Thread Jeremy Bícha
Control: severity -1 serious

By the way, as a workaround, you can either:
1. Open the GNOME Settings app. Click System in the sidebar. Then
click Date & Time and change the Time Format.
2. Or run this command:
gsettings set org.gnome.desktop.interface clock-format '24h'

While this is perhaps a minor issue, it is disruptive enough that we
can delay lettting gsettings-desktop-schemas migrate to Testing, even
if this ends up being the code that we ultimately use. So I'm bumping
the severity for now.

This will also delay the latest version of gnome-control-center from
reaching Testing so this is temporary.

Thank you,
Jeremy Bícha



Bug#1064043: closed by Michael Biebl (Re: Bug#1064043: systemd: /etc/fstab x-systemd.automount mount points, x-systemd.idle-timeout changes not effective)

2024-02-16 Thread David Sauvage - AdaLabs Ltd



the changes are not applied even after restarting the mount unit 
mnt-resource.mount. (when already mounted or not)


Regards,



Bug#1064042: gsettings-desktop-schemas: regression: LC_TIME=en_GB.utf8 uses 12-hour time format

2024-02-16 Thread Jörg-Volker Peetz

Hello Simon,

thank you very much for taking care.

Regards,
Jörg.



Bug#1064047: node-expat FTBFS: test failures

2024-02-16 Thread Adrian Bunk
Source: node-expat
Version: 2.4.0+ds-2
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=node-expat=riscv64=2.4.0%2Bds-2%2Bb1=1707898560=0
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-expat.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
NODE_PATH=lib vows --spec ./test/**/*.js
 
  ♢ node-expat 
  
  single element
✗ simple 
»
actual expected 
 
[["startElement","r",{}],["endElement","r"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ single element with attribute 
»
actual expected 
 
[["startElement","r",{"foo":"bar"}],["endElement","r"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ single elemeht with differently quoted attributes 
»
actual expected 
 

[["startElement","r",{"foo":"bar","baz":"quux","test":"tset"}],["endElement","r"]]
 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ single element with namespaces 
»
actual expected 
 

[["startElement","r",{"xmlns":"http://localhost/","xmlns:x":"http://example.com/"}],["endElement","r;]]
 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ single element with text content 
»
actual expected 
 
[["startElement","r",{}],["text","foo"],["endElement","r"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✓ single element with text content and line break
✗ single element with CDATA content 
»
actual expected 
 
[["startElement","r",{}],["startCdata"],["text","Hello, 
world!"],["endCdata"],["endElement","r"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✓ single element with entity text
✓ single element with umlaut text
✗ from buffer 
»
actual expected 
 
[["startElement","foo",{}],["text","bar"],["endElement","foo"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
  entity declaration
✓ a billion laughs
  processing instruction
✗ with parameters 
»
actual expected 
 
[["processingInstruction","i","like xml"]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ simple 
»
actual expected 
 
[["processingInstruction","dragons",""]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ XML declaration with encoding 
»
actual expected 
 
[["xmlDecl","1.0","UTF-8",true]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
✗ XML declaration 
»
actual expected 
 
[["xmlDecl","1.0",null,true]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
  comment
✗ simple 
»
actual expected 
 
[["comment"," no comment "]] 
 // /usr/share/nodejs/vows/lib/assert/macros.js:14
  unknownEncoding with single-byte map
✓ Windows-1252
  unknownEncoding with single-byte map using iconv
✓ Windows-1252
  error
✓ tag name starting with ampersand
  reset
✓ complete doc without error
✓ incomplete doc without error
✓ with doc error
  corner cases
✓ parse empty string
✓ Escaping of ampersands
✓ parsing twice the same document with the same parser instance should be 
fine
  statistics
✓ line number
✓ column number
✓ byte index
  stop and resume
✓ should have worked
  Stream interface read file
✓ startElement and endElement events
✓ end event
✓ close event
 
✗ Broken » 20 honored ∙ 12 broken (7.435s) 
  
make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1


Bug#1058392: python-oauth2client: FTBFS: failed tests

2024-02-16 Thread Olivier Gayot
Package: python-oauth2client
Followup-For: Bug #1058392
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

Python 3.12 dropped support in unittest.TestCase for assertRaisesRegexp and
assertEquals. These two functions were provided as a compability layer
since their deprecation in Python 3.2.

In Ubuntu, the attached patch was applied to achieve the following:

  * Replace obsolete assert* calls (dropped from Python 3.12) with their
correct alternative to fix FTBFS.
 - debian/patches/python312-support.patch

Thanks for considering the patch.


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

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
diff -Nru python-oauth2client-4.1.3/debian/patches/python312-support.patch 
python-oauth2client-4.1.3/debian/patches/python312-support.patch
--- python-oauth2client-4.1.3/debian/patches/python312-support.patch
1970-01-01 01:00:00.0 +0100
+++ python-oauth2client-4.1.3/debian/patches/python312-support.patch
2024-02-16 10:51:37.0 +0100
@@ -0,0 +1,252 @@
+Description: Fix use of obsolete assert statements dropped in Python 3.12
+ Since Python 3.2, assertEquals and assertRaisesRegexp (+ others) have been
+ deprecated in favor of assertEqual and assertRaisesRegex.
+ In Python 3.12, the deprecated names got dropped, causing oauth2client to
+ FTBFS.
+ .
+ The patch is not meant for upstream inclusion since the project upstream is
+ deprecated (in favor of python-google-auth) and the repository is read only.
+Author: Olivier Gayot 
+Bug-Debian: https://bugs.debian.org/1058392
+Forwarded: not-needed
+Last-Update: 2024-02-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/contrib/appengine/test_appengine.py
 b/tests/contrib/appengine/test_appengine.py
+@@ -906,7 +906,7 @@
+ self.decorator = decorator
+ self.test_required()
+ http = self.decorator.http()
+-self.assertEquals('foo_access_token',
++self.assertEqual('foo_access_token',
+   http.request.credentials.access_token)
+ 
+ # revoke_uri is not required
+--- a/tests/contrib/test_devshell.py
 b/tests/contrib/test_devshell.py
+@@ -205,7 +205,7 @@
+ def test_no_refresh_token(self):
+ with _AuthReferenceServer():
+ creds = devshell.DevshellCredentials()
+-self.assertEquals(None, creds.refresh_token)
++self.assertIsNone(creds.refresh_token)
+ 
+ @mock.patch('oauth2client.client._UTCNOW')
+ def test_reads_credentials(self, utcnow):
+--- a/tests/contrib/test_keyring_storage.py
 b/tests/contrib/test_keyring_storage.py
+@@ -104,7 +104,7 @@
+autospec=True) as get_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+ credentials = store.get()
+-self.assertEquals(None, credentials)
++self.assertIsNone(credentials)
+ get_password.assert_called_once_with('my_unit_test', 'me')
+ 
+ def test_get_with_malformed_json_credentials_stored(self):
+@@ -113,7 +113,7 @@
+autospec=True) as get_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+ credentials = store.get()
+-self.assertEquals(None, credentials)
++self.assertIsNone(credentials)
+ get_password.assert_called_once_with('my_unit_test', 'me')
+ 
+ def test_get_and_set_with_json_credentials_stored(self):
+@@ -139,7 +139,7 @@
+return_value=None,
+autospec=True) as set_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+-self.assertEquals(None, store.get())
++self.assertIsNone(store.get())
+ 
+ store.put(credentials)
+ 
+--- a/tests/test_client.py
 b/tests/test_client.py
+@@ -436,7 +436,7 @@
+ 'File {0} \(pointed by {1} environment variable\) does not '
+ 'exist!'.format(
+ nonexistent_file, client.GOOGLE_APPLICATION_CREDENTIALS))
+-with 
self.assertRaisesRegexp(client.ApplicationDefaultCredentialsError,
++with self.assertRaisesRegex(client.ApplicationDefaultCredentialsError,
+  expected_err_msg):
+ client._get_environment_variable_file()
+ 
+@@ -541,7 +541,7 @@
+ "'{1}' 

Bug#1064046: pam-python: install PAM module into /usr

2024-02-16 Thread Michael Biebl
Source: pam-python
Version: 1.1.0~git20220701.1d4e111-0.5
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-python 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 1: this change includes moving the .so into a multiarch path which
is recommended on Debian nowadays.

Note 2: 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-python-1.1.0~git20220701.1d4e111/debian/changelog 
pam-python-1.1.0~git20220701.1d4e111/debian/changelog
--- pam-python-1.1.0~git20220701.1d4e111/debian/changelog   2024-02-07 
08:07:10.0 +0100
+++ pam-python-1.1.0~git20220701.1d4e111/debian/changelog   2024-02-16 
11:55:28.0 +0100
@@ -1,3 +1,10 @@
+pam-python (1.1.0~git20220701.1d4e111-0.6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module into multiarch path in /usr. (Closes: #-1)
+
+ -- Michael Biebl   Fri, 16 Feb 2024 11:55:28 +0100
+
 pam-python (1.1.0~git20220701.1d4e111-0.5) unstable; urgency=medium
 
   * debian/patches:
diff -Nru pam-python-1.1.0~git20220701.1d4e111/debian/libpam-python.install 
pam-python-1.1.0~git20220701.1d4e111/debian/libpam-python.install
--- pam-python-1.1.0~git20220701.1d4e111/debian/libpam-python.install   
2022-10-23 01:00:22.0 +0200
+++ pam-python-1.1.0~git20220701.1d4e111/debian/libpam-python.install   
2024-02-16 11:55:28.0 +0100
@@ -1 +1 @@
-lib/security/pam_python.so
+usr/lib/*/security/pam_python.so
diff -Nru pam-python-1.1.0~git20220701.1d4e111/debian/rules 
pam-python-1.1.0~git20220701.1d4e111/debian/rules
--- pam-python-1.1.0~git20220701.1d4e111/debian/rules   2022-10-23 
00:56:15.0 +0200
+++ pam-python-1.1.0~git20220701.1d4e111/debian/rules   2024-02-16 
11:55:28.0 +0100
@@ -4,6 +4,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+include /usr/share/dpkg/architecture.mk
+
+export LIBDIR = /usr/lib/$(DEB_HOST_MULTIARCH)/security
+
 %:
dh $@ --with python3 --system=pybuild
 


Bug#1063782: python-oauth2client: FTBFS with flask 3

2024-02-16 Thread Olivier Gayot
Package: python-oauth2client
Followup-For: Bug #1063782
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

Flask 3.0 dropped support for _app_ctx_stack and _request_ctx_stack.
Those attributes were deprecated since Flask 2.2.

In Ubuntu, the attached patch was applied to achieve the following:

  * Replace use of flask._app_ctx_stack (dropped from flask 3) by flask.g to
fix FTBFS. (LP: #2052771)
 - debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch


Thanks for considering the patch.


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

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
diff -Nru 
python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch
 
python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch
--- 
python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch
1970-01-01 01:00:00.0 +0100
+++ 
python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch
2024-02-16 10:51:37.0 +0100
@@ -0,0 +1,43 @@
+Description: Use flask.g instead of flask._app_ctx_stack
+ In flask 2.2, _app_ctx_stack and _request_ctx_stack got deprecated in favor of
+ using flask.g. The compatibility layer was dropped from flask 3, which now 
raises:
+   E ImportError: cannot import name '_app_ctx_stack' from 'flask'
+ Replaced by the use of flask.g as mentioned in the documentation.
+ .
+ The patch is not meant for upstream inclusion since the project upstream is
+ deprecated (in favor of python-google-auth) and the repository is read only.
+Author: Olivier Gayot 
+Bug-Ubuntu: https://launchpad.net/bugs/2052771
+Bug-Debian: https://bugs.debian.org/1063782
+Forwarded: not-needed
+Last-Update: 2024-02-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/oauth2client/contrib/flask_util.py
 b/oauth2client/contrib/flask_util.py
+@@ -170,8 +170,8 @@
+ 
+ try:
+ from flask import Blueprint
+-from flask import _app_ctx_stack
+ from flask import current_app
++from flask import g as flask_g
+ from flask import redirect
+ from flask import request
+ from flask import session
+@@ -434,12 +434,10 @@
+ @property
+ def credentials(self):
+ """The credentials for the current user or None if unavailable."""
+-ctx = _app_ctx_stack.top
++if not hasattr(flask_g, _CREDENTIALS_KEY):
++flask_g.google_oauth2_credentials = self.storage.get()
+ 
+-if not hasattr(ctx, _CREDENTIALS_KEY):
+-ctx.google_oauth2_credentials = self.storage.get()
+-
+-return ctx.google_oauth2_credentials
++return flask_g.google_oauth2_credentials
+ 
+ def has_credentials(self):
+ """Returns True if there are valid credentials for the current 
user."""
diff -Nru python-oauth2client-4.1.3/debian/patches/series 
python-oauth2client-4.1.3/debian/patches/series
--- python-oauth2client-4.1.3/debian/patches/series 2023-08-17 
18:22:35.0 +0200
+++ python-oauth2client-4.1.3/debian/patches/series 2024-02-16 
10:51:37.0 +0100
@@ -1,3 +1,5 @@
+flask3-use-g-instead-of-app_ctx_stack.patch
 skip-network-doing-unit-test.patch
 remove-broken-tests.patch
 fix-hmac.new-call-in-py3.8.patch


  1   2   >