Bug#1068114: libfluidsynth-dev: package dependencies incongruent with libfluidsynth

[fabian]

Am 03.04.2024 01:22, schrieb Gravis:
Since you are basing dependencies on the generated pkg-config file then 
this
means that the libfluidsynth-dev package is built with 
enable-systemd=on while

the libfluidsynth package is being built with enable-systemd=off


What makes you think it is built without systemd support?

This is an excerpt from the build log:

"""
Miscellaneous support:
  D-Bus: yes
  LADSPA support:yes
  LASH support:  no
  NETWORK Support:   yes
IPV6 Support:yes
  Readline:  yes (NOTE: GPL library)
  systemd:   yes
  getopt:yes
"""

https://buildd.debian.org/status/fetch.php?pkg=fluidsynth&arch=amd64&ver=2.3.4-1%2Bb3&stamp=1711274976&raw=0

 - Fabian

Bug#1040417: docker-compose V1 is depreciated

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 16 Aug 2023 20:39:25 -0300 Leandro Cunha 
wrote:
> Hi,
> 
> I've been talking to one of them these days and he's been busy lately.
> But he said next month he should work on it. I should see if I can
> help with something too.
> 
Hi Leandro,

what's the status on this? As Michael noted below, compose V1 isn't maintained
upstream anymore and it'd be nice to switch to V2 in Debian. I know V2 is in
Go and might bring some challenges, but having some kind of status update
would be nice.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYM+NsACgkQ3rYcyPpX
RFueuAgAngIzIDQXahEH0cCH5dFNQ6UoOG/+T6SnjISECLgw7QEHdQIu/5sYn2ne
B+HpMF8jvTr/JVqYhoS4k1m/cpMs7C8FPN8LFypNleQmyHBq5FWDiyYTmQsjmuwh
ShmvFATRDVErVJln1OF4rUIRkJ1hUPk6dJwF3xMiN4ha/JcmpH3IUgH+qSmfgTFm
WKo4/JOctknw5amrsEcpC6Li/4qJEvqjYBsTUKqtVU8bja1UHVB6YXMSUmYxwavf
snd7tbV57r2CJ9jmTC3n9uDdVKIz1VHpmHrA2eboFQ5CVq+a+iavTMmuL7E6v6dZ
A4ia3PEezIrsQVQfPU/uoFfmOG37iA==
=Y8D4
-END PGP SIGNATURE-

Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py

[Martin-Éric Racine]

As see in 
:

"Distro packagers, please see info on the needed configuration file
addition (/etc/udev/rules.d/90-flowblade.rules) described in the link
to docs above."

Martin-Éric

Bug#1067977: openmotor: Please replace python3-appdirs dependency with platformdirs

[Bdale Garbee]

tags 1067977 +forwarded
thanks

Simon McVittie  writes:

> Package: openmotor
> Version: 0.5.0-2
> Severity: important
> Control: block 1060427 by -1
> Tags: trixie sid
> User: debian-pyt...@lists.debian.org
> Usertags: appdirs-removal
>
> python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
> that it should not be included in trixie[2]. A recommended replacement is
> python3-platformdirs[3], which is a fork of appdirs with a very similar API.
>
> Please migrate from appdirs to platformdirs or some other replacement,
> so that appdirs can be removed.

Filed as an issue with upstream:

  https://github.com/reilleya/openMotor/issues/225

Bdale


signature.asc
Description: PGP signature

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

[Thomas Orgis]

Hi again,

(after Easter hiatus … or rather xz backdoor meltdown?)

I had a stab at this, detecting a system that forces 64 bit offsets on
a 32 bit base in configure. This is to ensure that you do not encounter
the same symbol (like mpg123_tell() on two builds of the library on the
same platform offering a differing ABI (32 or 64 bit argument or return
value).

This is supposed to look like that:

$ CPPFLAGS=-D_FILE_OFFSET_BITS=64 ./configure
[…]
checking switched off_t size... 8
checking unswitched off_t size... 4
checking size of off_t... 8
configure: Detected system with enforced 64 bit offsets, dropping suffixless 
symbols for uncryptic ABI breakage.
checking if native off_t is already 64 bits... yes
[…]
  default offsets . 64
  explicit 64 bit offsets . no
  forced 64 bit offsets ... yes
[…]

This removes the ambiguous symbols from libmpg123.so and libsyn123.so.
With unchanged soversion, client code built for the earlier version
before the off_t/time_t 64 bit switch will fall in two categories:

1. Built with enabled large file support: Continues to work, no
   breakage.

2. Built without large file support: Will break early at runtime
   linking stage.

There might be applications that just use API not affected by off_t
changes and thus are fine either way.

Can you verify that the prospective 1.32.6 (named 1.32.6-dev) under

http://mpg123.org/snapshot/mpg123-1.32.6-dev+20240403022201.tar.bz2

works fine in the debian build and meets expectations? I'd do a proper
release of it soon, then.

It's up to you (Debian) to decide what to do with binary package naming
for the transition (it is your business anyway;-), but I feel strongly
about the change to avoid an existing symbol changing ABI with subtle
breakage. I also think it is reasonable not to invest work into yet
another set of wrappers to put 32 bit offsets on life suppport on a
system that follows the decision to enforce 64 bits. The setup of
wrappers and alias calls in mpg123 code is confusing enough already.


Alrighty then,

Thomas

Bug#1068294: RFH: liboqs -- library for quantum-safe cryptographic algorithms

[Andrius Merkys]

Package: wnpp
Severity: normal

In the light of recent calls to increase the quality and the bus factor 
of security-related packages, I request assistance with maintaining the 
liboqs package. I do not have enough time nor expertise to properly 
maintain liboqs alone.


The package is sid-only per upstream request (#1000303) and should stay 
this way until the upstream gives a green light.


I fail to keep up with upstream releases mostly due to the work needed 
to update debian/copyright. The upstream does a great job in applying 
REUSE standards on liboqs source, but as the package is in active 
development there usually are many changes to its source files.


The package description is:

liboqs is an open source C library for quantum-safe cryptographic 
algorithms. It provides a collection of open source implementations of 
quantum-safe key encapsulation mechanism (KEM) and digital signature 
algorithms; a common API for these algorithms; a test harness and 
benchmarking routines.


liboqs is part of the Open Quantum Safe (OQS) project, which aims to 
develop and integrate into applications quantum-safe cryptography to 
facilitate deployment and testing in real world contexts. In particular, 
OQS provides prototype integrations of liboqs into TLS and SSH, through 
OpenSSL and OpenSSH.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py

[Martin-Éric Racine]

Package: flowblade
Version: 2.14.0.1-1
Severity: important

$ flowblade 
FLOWBLADE MOVIE EDITOR 2.14.0.1
---
Launch script dir: /usr/bin
Running from installation...
modules path: /usr/share/flowblade/Flowblade
MLT found, version: 7.12.0
Failed to import module app.py to launch Flowblade!
ERROR: No module named 'usb1'
Installation was assumed to be at: /usr/share/flowblade/Flowblade


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

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

Versions of packages flowblade depends on:
ii  ffmpeg7:5.1.4-0+deb12u1
ii  frei0r-plugins1.8.0-1+b1
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0   1.74.0-3
ii  gir1.2-gtk-3.03.24.38-2~deb12u1
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  gmic  2.9.4-4+b4
ii  libmlt-data   7.12.0-1
ii  librsvg2-common   2.54.7+dfsg-1~deb12u1
ii  python3   3.11.2-1+b1
ii  python3-cairo 1.20.1-5+b1
ii  python3-dbus  1.3.2-4+b1
ii  python3-distutils 3.11.2-3
ii  python3-gi3.42.2-3+b1
ii  python3-gi-cairo  3.42.2-3+b1
ii  python3-mlt   7.12.0-1+b1
ii  python3-numpy 1:1.24.2-1
ii  python3-opencv4.6.0+dfsg-12
ii  python3-pil   9.4.0-1.1+b1
ii  swh-plugins   0.4.17-2

flowblade recommends no packages.

flowblade suggests no packages.

-- no debconf information

Bug#929265: IPOPT in Debian approaching 10 years old

[Jason Moore]

Hi,

IPOPT is now at 3.14.14, released Jan 2024. The Debian package is now
almost 10 years old. I'm assuming this Debian package is not being
maintained. How would one go about helping this package get updated to a
newer version?

Jason

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

Thanks, but can you sign this off?  Ty!
-- 
Sean Whitton

Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’

[Ben Westover]

Hello,

Since my last message, I have tried to reproduce this in several ways, 
e.g. an sbuild chroot in both qemu-user-static and on actual hardware 
(Raspberry Pi 2), and also a direct build on an armhf VM. It always 
builds successfully. Since then, there has been a new upstream release 
of xmrig, so I figured I would just upload and see if it still fails 
buildd. On the buildd log, it indeed fails with the same maes error.


This means xmrig thinks it's building on x86 and adds those flags, but 
this doesn't happen on arm64; only on armhf, only after the t64 
transition. It also doesn't happen on any of my systems but does on 
buildd and apparently your system. I guess I'll request guest access to 
an armhf porterbox and hope FTBFS happens there so I can debug this.


--
Ben Westover


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068292: haskell-pandoc build failed in loong64

[JiaLing Zhang]

Source: haskell-pandoc
Version: 3.1.3-1
Severity: normal
Tags: ftbfs
Usertags: loong64
X-Debbugs-Cc: zhangjial...@loongson.cn, fanp...@loongson.cn 
zhangdan...@loongson.cn

Dear Maintainer,

The haskell-pandoc build failed in buildd.debian.org for loong64 , The error 
log is  
https://buildd.debian.org/status/fetch.php?pkg=haskell-pandoc&arch=loong64&ver=3.1.3-1&stamp=1709428706&raw=0

The compile error is:

"
/usr/bin/ld.bfd: 
/usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o):
 relocation R_LARCH_B26 overflow 0xf5fec6a4
Dump relocate record:
stack top   relocation name symbol
at 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x0):
...
0x R_LARCH_NONE `' + 3(0x3)

at 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x4):
0x R_LARCH_GOT_PC_HI20  `main'
0x R_LARCH_RELAX`'

...


/usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o):
 in function `.LVL4':
(.text+0x38): relocation truncated to fit: R_LARCH_B26 against symbol 
`pthread_mutex_lock@@GLIBC_2.36' defined in .plt section in 
/usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o
/usr/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
ghc-9.4.7: `loongarch64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 880.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc returned exit"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 610
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 473
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 656
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25

"

When links there will have a "relocation R_LARCH_B26 overflow" for the binary 
too large . When we use 
DEB_SETUP_GHC_CONFIGURE_ARGS=--enable-executable-dynamic -O2  to build , this 
will build fine . 

Please , If we chould add this build options in Debian/rules ? If no ,How 
chould I do for this problem?


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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1068291: evolution: Spellcheck crashes evolution if a language installed in aspell, but missing in hunspell

[Nicholas Dreyer]

Package: evolution
Version: 3.46.4-2
Severity: normal
Tags: l10n
X-Debbugs-Cc: nick.dre...@centurylink.net

Dear Maintainer,

While aspell language packages installed show up for selection in "Edit ->
Preferences -> Composer Preferences -> Spell Checking -> Languages", if one of
those aspell languages is selected there and the corresponding hunspell
language package has not been installed, evolution will crash with a
"Segmentation fault" as soon as one tries to use that language for spell
checking.

Installing the required hunspell lanuage package resolved the issue.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1
ii  evolution-common3.46.4-2
ii  evolution-data-server   3.46.4-2
ii  libc6   2.36-9+deb12u4
ii  libcamel-1.2-64 3.46.4-2
ii  libecal-2.0-2   3.46.4-2
ii  libedataserver-1.2-27   3.46.4-2
ii  libevolution3.46.4-2
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libical33.0.16-1+b1
ii  libnotify4  0.8.1-1
ii  libwebkit2gtk-4.1-0 2.42.2-1~deb12u1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  psmisc  23.6-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.46.4-2
ii  evolution-plugin-pstimport   3.46.4-2
ii  evolution-plugins3.46.4-2
ii  yelp 42.2-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.40-1.1
ii  network-manager 1.42.4-1

-- no debconf information

Bug#1068290: python3-fastkml: ImportError since python3-pygeoif 1.4.0

[Tomas Janousek]

Hi,

On Wed, Apr 03, 2024 at 12:29:36AM +0100, Tomas Janousek wrote:

I believe this is because both shapely and pygeoif deprecated
asShape/as_shape respectively. The function is now called just "shape"
in both.
[…]
I think it might be okay to just patch fastkml/geometry.py to

   from shapely.geometry import shape as asShape
   …
   from pygeoif.geometry import shape as asShape

but it needs to be tested more thoroughly.


Yep, almost that. The following seems to work well (makes my CI pass):
https://github.com/liskin/liscopridge/commit/c44c3e6054af5a12bdf24d5687b6478d39480194#diff-e8ae9ced1dd6c13b4566c8a4a669116272e05115ce64aa743658523f4455ad5fR11

--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1068290: python3-fastkml: ImportError since python3-pygeoif 1.4.0

[Tomas Janousek]

Package: python3-fastkml
Version: 0.12-3
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: t...@nomi.cz

Dear Maintainer,

Since python3-pygeoif 1.4.0-1 appeared in Debian testing, fastkml cannot 
be imported at all:

In [1]: import fastkml
---
ImportError   Traceback (most recent call last)
File /usr/lib/python3/dist-packages/fastkml/geometry.py:39
 38 from shapely.geometry import Polygon
---> 39 from shapely.geometry import asShape
 40 from shapely.geometry.polygon import LinearRing

ImportError: cannot import name 'asShape' from 'shapely.geometry' 
(/usr/lib/python3/dist-packages/shapely/geometry/__init__.py)

During handling of the above exception, another exception occurred:

ImportError   Traceback (most recent call last)
Cell In[1], line 1
> 1 import fastkml

File /usr/lib/python3/dist-packages/fastkml/__init__.py:34
 32 from .atom import Contributor
 33 from .atom import Link
---> 34 from .kml import KML
 35 from .kml import Data
 36 from .kml import Document

File /usr/lib/python3/dist-packages/fastkml/kml.py:46
 44 import fastkml.atom as atom
 45 import fastkml.config as config
---> 46 import fastkml.gx as gx
 48 from .base import _BaseObject
 49 from .base import _XMLObject

File /usr/lib/python3/dist-packages/fastkml/gx.py:92
 89 from pygeoif.geometry import GeometryCollection
 91 from .config import GXNS as NS
---> 92 from .geometry import Geometry
 94 logger = logging.getLogger(__name__)
 97 class GxGeometry(Geometry):

File /usr/lib/python3/dist-packages/fastkml/geometry.py:46
 44 from pygeoif.geometry import MultiPoint, MultiLineString, 
MultiPolygon
 45 from pygeoif.geometry import LinearRing
---> 46 from pygeoif.geometry import as_shape as asShape
 48 import logging
 50 from pygeoif.geometry import GeometryCollection

ImportError: cannot import name 'as_shape' from 'pygeoif.geometry' 
(/usr/lib/python3/dist-packages/pygeoif/geometry.py)

I believe this is because both shapely and pygeoif deprecated 
asShape/as_shape respectively. The function is now called just "shape" 
in both.

Unfortunately, fastkml doesn't have a newer release compatible with 
recent pygeoif (or shapely) versions. There's only been a steady stream 
of 1.0.alphas, most of which are broken in various ways (I have a 
project that depends on fastkml so its CI has been notifying me of ways 
my project breaks with those alphas and I tried to work around these for 
a while but recently gave up and just pinned fastkml to 0.12).

I think it might be okay to just patch fastkml/geometry.py to

from shapely.geometry import shape as asShape
…
from pygeoif.geometry import shape as asShape

but it needs to be tested more thoroughly.

Also, fastkml 0.12 explicitly depends on pygeoif < 1.0, for good reason 
apparently, so it's a bit unfortunate that this dependency is relaxed in 
the Debian package. :-(

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-fastkml depends on:
ii  python33.11.6-1
ii  python3-dateutil   2.9.0-2
ii  python3-pkg-resources  68.1.2-2
ii  python3-pygeoif1.4.0-1

python3-fastkml recommends no packages.

python3-fastkml suggests no packages.

-- no debconf information

-- 
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1068288: openjdk-21: bootstrap builds required on armel and armhf

[Wookey]

On 2024-04-03 00:20 +0200, Sebastian Ramacher wrote:
> building openjdk-21 is currently still stuck on openjdk-21
> build-depending on itself:
> 
> https://buildd.debian.org/status/package.php?p=openjdk-21
> 
> 
> Somebody did the work to provide boostrap builds of openjdk-17 on armel
> and armhf. We need the same for openjdk-21.

Yes. I had a look at this. I was hoping to use the openjdk-17 to allow
building of openjdk-21. But it doesn't 'just work', because:

checking for version string... 21.0.3-ea+7-Debian-1
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/lib/jvm/java-17-openjdk-armhf is 
incorrect JDK version (openjdk version "17.0.11-ea" 2024-04-16 OpenJDK Runtime 
Environment (build 17.0.11-ea+7-Debian-1) OpenJDK Server VM (build 
17.0.11-ea+7-Debian-1, mixed mode, sharing)); ignoring
configure: (Your Boot JDK version must be one of: 20 21)
configure: error: The path given by --with-boot-jdk does not contain a valid 
Boot JDK

Now what I'm not sure is whether openjdk-21 _actually_ needs openjdk
20 (or 21), or if it just needs 'java', and has been set to '20 or 21'
for reasons of being able to drop -17 in due course.

Nor where these things are configured.

If it _does_ need -20, then can I build -20 with -17 or -19 with -17 and so on?

The advantage of going straight to -21 is that it's not in the archive already 
and 'just' needs a binary build.
and also -21 has had its build-deps modified for t64 dependencies. -20 and -19 
haven't been

-20 needs -19 (and jtreg7 but one can use -Pnocheck)
-19 needs -18 (and jtreg6 but one can use -Pnocheck)

So right now I'm not sure what the easiest path is.

Can I actually just build -21 with -17 if I can persuade the build system, or 
will something important break with that much version-skew?

can I build -19 with -17 (and appropriate t64 dep updates) (-18 is no longer in 
the archive so I really hope we don't need to go 18,19,20,21

Clues welcome on the best approach.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1068114: libfluidsynth-dev: package dependencies incongruent with libfluidsynth

[Gravis]

Package: libfluidsynth-dev
Version: 2.3.4-1+b3
Followup-For: Bug #1068114
X-Debbugs-Cc: noreply+debian.report...@adaptivetime.com

After investigating, there is definitely something amiss because the
CMakeList.txt reads:

if ( enable-systemd )
find_package ( Systemd )
set ( SYSTEMD_SUPPORT ${Systemd_FOUND} )
if ( SYSTEMD_SUPPORT )
list( APPEND PC_REQUIRES_PRIV "libsystemd")
endif ( SYSTEMD_SUPPORT )
endif ( enable-systemd )


Since you are basing dependencies on the generated pkg-config file then this
means that the libfluidsynth-dev package is built with enable-systemd=on while
the libfluidsynth package is being built with enable-systemd=off


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libfluidsynth-dev depends on:
ii  libasound2-dev   1.2.11-1+b1
ii  libdbus-1-dev1.14.10-4+b1
pn  libfluidsynth2   
ii  libfluidsynth3   2.3.4-1+b3
pn  libinstpatch-dev 
ii  libjack-dev  1:0.126.0-2+b2
ii  libpipewire-0.3-dev  1.0.4-3
ii  libpulse-dev 16.1+dfsg1-3+b1
ii  libreadline-dev  8.2-4
ii  libsdl2-dev  2.30.1+dfsg-4
pn  libsndfile-dev   
pn  libsystemd-dev   

libfluidsynth-dev recommends no packages.

libfluidsynth-dev suggests no packages.

Bug#1068289: ITP: wtmpdb -- Y2038 safe wtmp implementation

[Chris Hofstaedtler]

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

* Package name: wtmpdb
  Version : 0.11.0
  Upstream Contact: Thorsten Kukuk
* URL : https://github.com/thkukuk/wtmpdb
* License : BSD
  Programming Lang: C
  Description : Y2038 safe wtmp implementation

Replacement implementation of utmp/wtmp/last that is supposed to be
Y2038 safe. Provides PAM module to plug into the existing auth stack.

Git Repo will be at https://salsa.debian.org/debian/wtmpdb 

Bug#1068288: openjdk-21: bootstrap builds required on armel and armhf

[Sebastian Ramacher]

Source: openjdk-21
Version: 21.0.3~7ea-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org, debian-...@lists.debian.org

Hi Matthias, hi arm* porters

building openjdk-21 is currently still stuck on openjdk-21
build-depending on itself:

https://buildd.debian.org/status/package.php?p=openjdk-21

Dependency installability problem for openjdk-21 on armel:

openjdk-21 build-depends on:
- libcups2-dev:armel
libcups2-dev depends on:
- libcups2t64:armel (= 2.4.7-1.2)
openjdk-21 build-depends on:
- openjdk-21-jdk-headless:armel
openjdk-21-jdk-headless depends on:
- openjdk-21-jre-headless:armel (= 21.0.2+13-2)
openjdk-21-jre-headless depends on:
- libcups2:armel
libcups2t64 conflicts with:
- libcups2:armel (< 2.4.7-1.2)

Dependency installability problem for openjdk-21 on armhf:

openjdk-21 build-depends on:
- libcups2-dev:armhf
libcups2-dev depends on:
- libcups2t64:armhf (= 2.4.7-1.2)
openjdk-21 build-depends on:
- openjdk-21-jdk-headless:armhf
openjdk-21-jdk-headless depends on:
- openjdk-21-jre-headless:armhf (= 21.0.2+13-2)
openjdk-21-jre-headless depends on:
- libcups2:armhf
libcups2t64 conflicts with:
- libcups2:armhf (< 2.4.7-1.2)

Somebody did the work to provide boostrap builds of openjdk-17 on armel
and armhf. We need the same for openjdk-21.

Cheers
-- 
Sebastian Ramacher

Bug#1068252: urlview: (security) extract IMG URLs so users can see tracker pixels

[наб]

Control: tags -1 + wontfix unreproducible

On Tue, Apr 02, 2024 at 09:33:06PM +0200, Manny wrote:
> Tracker pixels are quite commonly used to snoop on email
> recipients. URLview ignores URLs that specify an image to render.
Inconsistent capitalisation (URLview here/urlview elsewhere)
and incoherent problem statement makes me think this first sentence
was produced by an LLM while farming for a security issue (note
also "(security)" in subject but Tags: wishlist). The lack of
cohesion and utter detachment from reality of the rest of this post
only drives this further for me.

À la mode?


signature.asc
Description: PGP signature

Bug#1043227: patch still valid? (opm-common: test failure on ppc64el with -O3)

[Markus Blatt]

Hi,

Concerning the patch: It seems like -O2 is the default in Debian now anyway.
Will the patch still work as it is?

I did some investigations on platti.debian.org. I have no idea what the problem
is. My hunch is that compiler optimization breaks the code here. If I add a
simple print statement like this then the test passes:

(sid_ppc64el-dchroot)blattms@platti:~/opm-common$ git diff  
opm/output/data/InterRegFlow.hpp
diff --git a/opm/output/data/InterRegFlow.hpp b/opm/output/data/InterRegFlow.hpp
index 0e1dadcc4..7e2aeabbe 100644
--- a/opm/output/data/InterRegFlow.hpp
+++ b/opm/output/data/InterRegFlow.hpp
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-
+#include 
 namespace Opm { namespace data {
 /// Intermediary Protocol to Linearise Per-Connection Flow Rates Into 
Subrange.
@@ -271,7 +271,7 @@ namespace Opm { namespace data {
 using sz_t = decltype(InterRegFlow::bufferSize());
 const auto& [begin, end] = this->elements_;
-
+std::cout<<"distance=";//<<  std::distance(begin, end);// << " size="<< 
InterRegFlow::bufferSize()<(std::distance(begin, end))
 == InterRegFlow::bufferSize();
 }
(sid_ppc64el-dchroot)blattms@platti:~/opm-common$

Best,

Markus

Bug#1068287: rpki-client configured with `--with-tal-dir=/etc/tals' not reflected in man page rpki-client(8) for skiplist default path

[Tobias Fiebig]

Package: rpki-client
Version: 8.2-2+b1
Severity: minor

rpki-client on debian bookworm is being built with `--with-tal-
dir=/etc/tals'. This affects default path for the skiplist.

However, rpki-client(8) still lists /etc/rpki/skiplist as the default
skiplist path.

I would suggest to update the manpage to list the correct default path
for debian builds.

Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults

[Bernhard Übelacker]

Hello,
I tried to reproduce this inside a minimal stable/bookworm VM
and received a qmlcachegen crash.

See attached file for details.
The resulting backtrace is quite similar to that found in:
  https://bugreports.qt.io/browse/QTBUG-117361

Might avoid the crash, but cannot say if this would make the build succeed.

Kind regards,
Bernhard


# 2024-04-02 stable/bookworm amd64 qemu VM

apt install systemd-coredump gdb libqt6qmlcompiler6-dbgsym
apt build-dep qt6-virtualkeyboard

mkdir /home/benutzer/source/qt6-virtualkeyboard/orig -p
cd/home/benutzer/source/qt6-virtualkeyboard/orig
apt source qt6-virtualkeyboard


cd /home/benutzer/source/qt6-virtualkeyboard
cp orig try1 -a
cd try1/qt6-virtualkeyboard-6.4.2+dfsg
DEB_BUILD_OPTIONS=parallel=1 dpkg-buildpackage


...
[110/301] cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
FAILED: src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
Segmentation fault (core dumped)
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
returned exit code 1
make: *** [debian/rules:8: binary] Fehler 1
dpkg-buildpackage: Fehler: Unterprozess debian/rules binary lieferte Exitstatus 
2
benutzer@debian:~/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg$



dmesg
[  431.390156] qmlcachegen[5680]: segfault at 0 ip 7fde080d0672 sp 
7ffe33185b60 error 4 in libQt6QmlCompiler.so.6.4.2[7fde0804d000+106000] 
likely on CPU 5 (core 5, socket 0)
[  431.390173] Code: 64 cd f7 ff 0f 1f 40 00 41 57 41 56 41 55 41 54 55 48 89 
fd 53 48 89 f3 48 83 ec 28 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 <48> 8b 06 
48 c7 06 00 00 00 00 4c 8b 27 48 89 07 4d 85 e4 74 10 4c



journalctl -e
Apr 02 22:45:36 debian systemd-coredump[5682]: [🡕] Process 5680 (qmlcachegen) 
of user 1000 dumped core.
   
   Stack trace of thread 5680:
   #0  0x7fde080d0672 n/a 
(libQt6QmlCompiler.so.6 + 0xa8672)
  

Bug#1019738: searchandrescue: FTBFS on riscv64: add library search path

[Bastian Germann]

I am uploading a NMU once again.
The debdiff is attached.diff -Nru searchandrescue-1.5.0+dfsg/debian/changelog 
searchandrescue-1.5.0+dfsg/debian/changelog
--- searchandrescue-1.5.0+dfsg/debian/changelog 2024-03-23 12:20:00.0 
+
+++ searchandrescue-1.5.0+dfsg/debian/changelog 2024-04-02 21:34:01.0 
+
@@ -1,3 +1,11 @@
+searchandrescue (1.5.0+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Take LD_LIBRARY_PATH into account. (Closes: #1019738)
+  * Drop empty icons.
+
+ -- Bastian Germann   Tue, 02 Apr 2024 21:34:01 +
+
 searchandrescue (1.5.0+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -5,7 +13,7 @@
   * Set Priority: optional.
   * Drop noop postinst.
   * Drop all lintian overrides which are invalid or not needed.
-  * Set LD_LIBRARY_PATH for configure. (Closes: #1019738)
+  * Set LD_LIBRARY_PATH for configure.
   * Convert to source format 3.0. (Closes: #1007284)
 
  -- Bastian Germann   Sat, 23 Mar 2024 12:20:00 +
diff -Nru searchandrescue-1.5.0+dfsg/debian/rules 
searchandrescue-1.5.0+dfsg/debian/rules
--- searchandrescue-1.5.0+dfsg/debian/rules 2024-03-23 12:20:00.0 
+
+++ searchandrescue-1.5.0+dfsg/debian/rules 2024-04-02 21:34:01.0 
+
@@ -12,7 +12,7 @@
dh_testdir
# Add here commands to configure the package.
# Modified to include dpkg-buildflags.
-   LD_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH) ./configure Linux 
--ignore-environments --CFLAGS="$(shell dpkg-buildflags --get CFLAGS)"
+   LD_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH) ./configure Linux
 
 
touch configure-stamp
@@ -63,9 +63,6 @@
install -d -g root -m 755 -o root 
`pwd`/debian/searchandrescue/usr/share/applications
install -m 644 debian/SearchAndRescue.desktop 
`pwd`/debian/searchandrescue/usr/share/applications/SearchAndRescue.desktop
 
-   # Icons
-   for r in 64x64 96x96 128x128 256x256; do install -d -g root -m 755 -o 
root `pwd`/debian/searchandrescue-common/usr/share/icons/hicolor/$${r}/apps; 
install -o root -g root -m 644 debian/icons/SearchAndRescue-$${r}.png 
`pwd`/debian/searchandrescue-common/usr/share/icons/hicolor/$${r}/apps/SearchAndRescue.png;done
-
# Un-bzip the manpage.
bunzip2 
`pwd`/debian/searchandrescue/usr/share/man/man6/SearchAndRescue.6.bz2
# Move it to the common package.

Bug#1061950: Debian 12 PHP 8.2.7 - GH-11972: RecursiveCallbackFilterIterator

[Andres Salomon]

On Tue, 30 Jan 2024 13:53:49 +0100 Sebastian Kraetzig 
 wrote:

[...]


With PHP 8.2.11 and newer, this issue does not exist anymore as it has been
fixed there. When it's fixed, the PHP script immediately exits without any
error message.

I suggest that the changes from
https://github.com/php/php-src/commit/ffd7018fcdd13ca2966149e5141197a02707aff1
get backported to PHP 8.2.7 on Debian 12 (Bookworm). When I apply these
changes on top of the above mentioned PHP version, the issue is resolved.
At the bottom, you’ll find our tested patch.



I would rather see a proposed-stable-update happen with some newer 
version of 8.2.x, which would additionally fix those low-priority CVEs 
from https://bugs.debian.org/1043477


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Daniel Kahn Gillmor]

Control: tags 1067796 + patch

On Thu 2024-03-28 13:09:48 +0800, Sean Whitton wrote:
> Please take a look into this test suite failure for your script.

The attached patch should clean things up now that argcomplete is
annotated.  in my local tests, the script runs and exits cleanly.

This patch is worth applying generally, but given the flux around mypy
typing, i would also be fine with just recording the output of mypy
--strict instead of failing hard on it.

 --dkg

From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 30 Jan 2024 15:40:58 -0500
Subject: [PATCH] email-print-mime-structure: clean up typechecking
 (argcomplete types are known)

(and, update copyright years)
---
 email-print-mime-structure | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index b7646e0..7635f53 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -2,7 +2,7 @@
 # PYTHON_ARGCOMPLETE_OK
 # -*- coding: utf-8 -*-
 
-# Copyright (C) 2019 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -39,6 +39,7 @@ import subprocess
 
 from argparse import ArgumentParser, Namespace
 from typing import Optional, Union, List, Tuple, Any
+from types import ModuleType
 from email.charset import Charset
 from email.message import Message
 
@@ -47,8 +48,9 @@ try:
 except ImportError:
 pgpy = None
 
+argcomplete:Optional[ModuleType]
 try:
-import argcomplete #type: ignore
+import argcomplete
 except ImportError:
 argcomplete = None
 
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1068265: RM: flint-arb -- RoQA; merged into flint

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: flint-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:flint-arb
User: ftp.debian@packages.debian.org
Usertags: remove

flint-arb has been merged into flint. See #1058814

Please remove flint-arb from the archive.

Cheers
-- 
Sebastian Ramacher

Bug#1068264: avfs: FTBFS on armel: ./src/xzread.c:185:(.text+0x1b0): undefined reference to `__atomic_fetch_add_8'

[Sebastian Ramacher]

Source: avfs
Version: 1.1.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=avfs&arch=armel&ver=1.1.5-1&stamp=1691158944&raw=0

/bin/bash ../libtool  --tag=CC   --mode=link arm-linux-gnueabi-gcc -I../include 
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_GNU_SOURCE 
-I/usr/include/neon -D_LARGEFILE64_SOURCE -DNE_LFS  -I/usr/include/fuse 
-D_FILE_OFFSET_BITS=64-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z,relro 
-Wl,-z,now -lpthread -ldl  -lneon-gnutls  -llzma  -lzstd  -Wl,-z,relro 
-Wl,-z,now -o runtest runtest.o ../lib/libavfs_static.la -lpthread -ldl  
-lneon-gnutls  -llzma  -lzstd 
libtool: link: arm-linux-gnueabi-gcc -I../include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_GNU_SOURCE 
-I/usr/include/neon -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/include/fuse 
-D_FILE_OFFSET_BITS=64 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
gzip_multimember_test gzip_multimember_test.o  ../lib/.libs/libavfs_static.a 
-lz -lbz2 -lpthread -ldl -lneon-gnutls -llzma -lzstd
libtool: link: arm-linux-gnueabi-gcc -I../include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_GNU_SOURCE 
-I/usr/include/neon -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/include/fuse 
-D_FILE_OFFSET_BITS=64 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -o testread testread.o 
 ../lib/.libs/libavfs_static.a -lz -lbz2 -lpthread -ldl -lneon-gnutls -llzma 
-lzstd
/usr/bin/ld: ../lib/.libs/libavfs_static.a(xzread.o): in function 
`xzfile_decompress':
./src/xzread.c:185:(.text+0x1b0): undefined reference to `__atomic_fetch_add_8'
libtool: link: arm-linux-gnueabi-gcc -I../include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_GNU_SOURCE 
-I/usr/include/neon -D_LARGEFILE64_SOURCE -DNE_LFS -I/usr/include/fuse 
-D_FILE_OFFSET_BITS=64 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z 
-Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -o runtest runtest.o  
../lib/.libs/libavfs_static.a -lz -lbz2 -lpthread -ldl -lneon-gnutls -llzma 
-lzstd
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:401: gzip_multimember_test] Error 1
make[2]: *** Waiting for unfinished jobs
/usr/bin/ld: ../lib/.libs/libavfs_static.a(xzread.o): in function 
`xzfile_decompress':
./src/xzread.c:185:(.text+0x1b0): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:409: testread] Error 1
/usr/bin/ld: ../lib/.libs/libavfs_static.a(xzread.o): in function 
`xzfile_decompress':
./src/xzread.c:185:(.text+0x1b0): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:405: runtest] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1019738: searchandrescue: FTBFS on riscv64: add library search path

[Bastian Germann]

Control: reopen -1
Control: notfixed -1 searchandrescue/1.5.0+dfsg-0.1

I did not read Paul's message properly and missed "allow environment variables",
so LD_LIBRARY_PATH is not taken into account.

The build also fails on arm64, mips64el, and ppc64el now.

Bug#1068263: FTS optimization error

[Petr Sorm]

Package: dovecot-fts-xapian
Version: 1.5.5-1+b2

Dear maintainer,

FTS optimization does not work well when an expunged message is not 
indexed. This happens when the message is expunged from a mailbox that 
is excluded from auto-indexing (usually Trash folder) and fts_autoindex 
is enabled. When this unindexed message is moved out of the mailbox its 
UID is put into an expungement database (sqlite file). FTS optimization 
takes this expunged UID and generates this type of error:


Error: FTS Xapian: Optimize UID=14 inexistant

This UID stays in the expungement DB forever and as time goes on, next 
optimizations generate more and more errors.


Steps to reproduce:

1) Use this settings

plugin {
fts = xapian
fts_xapian = partial=4 full=20 verbose=0
fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
}

2) Move a message into Trash folder and then expunge this message (I 
used IMAP client Roundcube).

3) Run this command: doveadm fts optimize -u u...@example.com


This issue is fixed in the upstream version 1.5.6. However, this version 
brings another bug that breaks indexing. So it is impossible to simply 
package the upstream version 1.5.6.


Best regards,
Petr Sorm

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Quanah Gibson-Mount]

--On Tuesday, April 2, 2024 11:32 PM +0200 Bernhard Übelacker 
 wrote:



On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina 
wrote:

2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747]
slapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0
error 4 in dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core
0, socket 2) 2024-01-24T09:38:16.810568+01:00 ldap kernel: [
1553.168761] Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3
48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00
<48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48


Hello,
I tried to get back to the source line of this dmesg output, maybe it is
of any help.

It points to:
dynlist_search at ../../../../../servers/slapd/overlays/dynlist.c:1817
1817(void)o.o_bd->be_search( &o, &r );

This is the same line shown in the attachment of the upstream bug report.


The fix for this issue is already committed upstream and was part of the 
OpenLDAP 2.5.17 and 2.6.7 releases.  Generally the requirement at this 
point would be for Debian to pull in the fix (if it hasn't already).


Regards,
Quanah

Bug#1068262: RM: libapache-mod-auth-kerb -- RoQA; not in (old)stable, security issues

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libapache-mod-auth-k...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:libapache-mod-auth-kerb
User: ftp.debian@packages.debian.org
Usertags: remove

#976156 states "libapache-mod-auth-kerb probably shouldn't be released
in its current form" and there is no action from anyone that is
interested in the package. So please remove the package from the
archive.

Cheers
-- 
Sebastian Ramacher

Bug#1067674: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1067674: fixed in folks 0.15.9-2)

[Matthias Klose]

Control: reopen -1

no, this doesn't help if the all build fails and other builds succeed.

Bug#1068260: RM: lix -- RoQA; RC buggy, unmaintained

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: l...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:lix
User: ftp.debian@packages.debian.org
Usertags: remove

Fails to build since 2021 (#999750). Please remove it from the archive.

Cheers
-- 
Sebastian Ramacher

Bug#1068261: ITP: quickflux -- Flux implementation for QML

[Mike Gabriel]

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

* Package name: quickflux
  Version : 1.0.3+git
  Upstream Contact: Ben Lau 
* URL : https://github.com/benlau/quickflux
* License : Apache-2.0
  Programming Lang: C++
  Description : Flux implementation for QML

 An implementation of Flux Application Architecture Framework from
 Facebook. It turns your QML application into a more modern and
 structured way.
 .
 This QML module is needed by several Lomiri apps such as telePORTS
 and Dekko.
 .
 This package will be maintained by the Debian UBports Packaging team.

Bug#1068259: RM: kinput2 -- RoQA; dead upstream, RC buggy, orphaned

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kinp...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:kinput2
User: ftp.debian@packages.debian.org
Usertags: remove

Orphaned since 2013 and now RC buggy (#1066714). Please remove it from
the archive.

Cheers
-- 
Sebastian Ramacher

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Bernhard Übelacker]

On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina  wrote:

2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747] slapd[13335]: 
segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29 d0 48 89 d7 
48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 
a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 
03 00 00 48


Hello,
I tried to get back to the source line of this dmesg output, maybe it is of any 
help.

It points to:
dynlist_search at ../../../../../servers/slapd/overlays/dynlist.c:1817
1817(void)o.o_bd->be_search( &o, &r );

This is the same line shown in the attachment of the upstream bug report.

Attached file shows how I got to this line.

Kind regards,
Bernhardslapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


error 4 == 0b0100
bit 0 ==0: no page found
bit 1 ==0: read access
bit 2 ==1: user-mode access

echo -n "find /b ..., ..., 0x" && \
echo "48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x48, 0x29, 0xd0, 0x48, 0x89, 0xd7, 0x48, 0x89, 0xc1, 0x31, 
0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 0x48, 0xab, 0x48, 0x8b, 0x84, 
0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 0xc7, 0x84, 0x24, 0xa0, 0x00, 
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x00, 0xff, 0x50, 0x78, 0x44, 
0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 0x0f, 0x85, 0x22, 0x03, 0x00, 
0x00, 0x48



# 2024-04-02 stable/bookworm amd64 qemu VM

apt install gdb slapd slapd-dbgsym

mkdir /home/benutzer/source/slapd/orig -p
cd/home/benutzer/source/slapd/orig
apt source slapd


gdb -q 
set width 0
set pagination off
file /usr/sbin/slapd
tb main
run 
call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
pipe info target | grep "\.text"
find /b 0x774874a0, 0x7748ccaa, 0x48, 0x29, 0xd0, 0x48, 0x89, 
0xd7, 0x48, 0x89, 0xc1, 0x31, 0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 
0x48, 0xab, 0x48, 0x8b, 0x84, 0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 
0xc7, 0x84, 0x24, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 
0x00, 0xff, 0x50, 0x78, 0x44, 0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 
0x0f, 0x85, 0x22, 0x03, 0x00, 0x00, 0x48
b * (0x7748a997 + 42)
info b
disassemble /r 0x7748a997, 0x7748a997 + 62
directory 
/home/benutzer/source/slapd/orig/openldap-2.5.13+dfsg/servers/slapd/overlays



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/slapd
Reading symbols from /usr/sbin/slapd...
Reading symbols from 
/usr/lib/debug/.build-id/40/63a68f1de0ddfe5b5d68cb4f6869587bda460a.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x20b50: file ../../../../servers/slapd/main.c, line 
408.
(gdb) run 
Starting program: /usr/sbin/slapd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe4d8) at 
../../../../servers/slapd/main.c:408
408 ../../../../servers/slapd/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
$1 = (void *) 0x557231f0
(gdb) pipe info target | grep "\.text"
0x55574aa0 - 0x556375c4 is .text
0x77fcc060 - 0x77ff0d51 is .text in 
/lib64/ld-linux-x86-64.so.2
0x77fc96b0 - 0x77fc9ced is .text in system-supplied DSO 
at 0x77fc9000
0x77f72260 - 0x77fa8f06 is .text in 
/lib/x86_64-linux-gnu/libldap-2.5.so.0
0x77f53670 - 0x77f5a22a is .text in 
/lib/x86_64-linux-gnu/liblber-2.5.so.0
0x77f365b0 - 0x77f47005 is .text in 
/lib/x86_64-linux-gnu/libsasl2.so.2
0x77ef9040 - 0x77f0e33c is .text in 
/lib/x86_64-linux-gnu/libcrypt.so.1
0x77edf010 - 0x77eeefdd is .text in 
/lib/x86_64-linux-gnu/libslapi-2.5.so.0
0x77ecb490 - 0x77ecf5e6 is .text in 
/lib/x86_64-linux-gnu/libltdl.so.7
0x77ec06e0 - 0x77ec415e is .text in 
/lib/x86_64-linux-gnu/libwrap.so.0
0x77d02380 - 0x77e55f2d is .text in 
/lib/x86_64-linux-gnu/libc.so.6
0x77a3aac0 - 0x77b69520 is .tex

Bug#1068258: RM: libauthen-krb5-perl -- RoQA; dead upstream, RC buggy

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libauthen-krb5-p...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:libauthen-krb5-perl
User: ftp.debian@packages.debian.org
Usertags: remove

>From #1065768:

Russ Allbery wrote:
> Authen::Krb5 has a bunch of stuff that dates from the pre-GSS-API era of
> Kerberos, and there were other things that at one point got me to start
> writing my own version of the same idea (although alas I never finished).
> In theory, one could delete the pieces of the module that try to do things
> that no one should really be doing from Perl and the rest of it remains
> somewhat useful, but given that upstream has archived the project, I would
> go ahead and remove it.

Cheers
-- 
Sebastian Ramacher

Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

[Sebastian Ramacher]

On 2024-04-02 07:13:38 +0100, Alastair McKinstry wrote:
> 
> On 01/04/2024 23:25, Sebastian Ramacher wrote:
> > > There is a transition to openmpi-5 / mpi-defaults which is stalled by the
> > > t64 transition.
> > > 
> > > It drops 32-bit support from OpenMPI.
> > > 
> > > Because of this, I don't think the solution is to  port 32-bit atomics for
> > > armel/armhf, as it will be removed in a few weeks/months.
> > > 
> > > While we didn't want the transitions to be done simultaneously, it might 
> > > be
> > > the best answer.
> > > 
> > > 
> > > What does the release team think?
> > Adding another transition on top will just delay the time_t transition
> > even more. So if we can avoid that, I'd prefer to not do this transition
> > now. Unfortunately, uploads such as the one of pmix that no dropped
> > support for 32 bit architectures (#1068211) are not really helpful.
> > 
> > Also, #1064810 has no information on test builds with the new
> > mpi-defaults on a 32 bit architecture. So has this transition been
> > tested?
> > 
> > Cheers
> 
> OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI.
> So it is technically not a transition, but breaks 32-bit builds.

Doesn't make it better. This is not the time to do that without tests
builds and bugs filed.

> The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH
> builds on all archs, but testing all dependencies of the change has not been
> tested, and I don't know how you would do that - setting up eg ratt to
> rebuild all on 32-bit archs (as everything on 64-bit will not have changed.)

Beside the easy part of chaning mpi-defaults, I count 30 something
packages that have explicit build dependencies on libopenmpi-dev. None
of those packages has bugs filed to change to mpich on 32 bit
architectures.

To be honest, I don't see these two changes (changing mpi-defaults to
mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be
preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32
bit until the time_t transition is done.

Cheers
-- 
Sebastian Ramacher

Bug#1068034: gross 1.0.2-4.1~deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068034 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: gross
Version: 1.0.2-4.1~deb11u1

Explanation: fix stack-based buffer overflow [CVE-2023-52159]

Bug#1061190: gnutls28 3.7.1-5+deb11u5 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1061190 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: gnutls28
Version: 3.7.1-5+deb11u5

Explanation: fix assertion failure verifying a certificate chain with a cycle 
of cross signatures [CVE-2024-0567]; fix timing side-channel attack inside 
RSA-PSK key exchange [CVE-2024-0553]

Bug#1068257: urlscan: (security) extract IMG URLs so users can see tracker pixels

[Manny]

Package: urlscan
Version: 0.9.5-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.urls...@sideload.33mail.com

Tracker pixels are quite commonly used to snoop on email
recipients. URLscan ignores URLs that specify an image to render.

Ideally there should be two lists of URLs:

  1) URLs that users might want to visit
  2) IMG URLs. This list can be useful in two ways:

 * Someone might want to view or fetch an image (though unlikely;
   they can always render the message in a GUI browser for that)

 * To view all possible urls that could be a tracker
   pixel. Tracker pixels cannot easily be detected
   programatically, so the URLs need to be presented in a way that
   makes it easy for a human to detect it manually.

It might also be useful for a user to have the option of tagging an
URL they determine to be a tracker pixel which could then be added to
a database of known tracker pixel URLs. Senders tend to make tracker
pixels unique per recipient, not per message. So when another message
from the same sender is fed to urlscan, it could recognize already
identified tracker pixels and highlight them in some way. And more
usefully, the DB could be queried by the MUA so tracked messages can
be highlighted to users in the MUA.

If this functionality is implemented, the developer should be mindful
of embedded images. It’s possible for IMG tags to contain an embedded
“URI image”, whereby a very long string in base64 encodes an
image. Syntax is described here:

  https://www.thesitewizard.com/html-tutorial/embed-images-with-data-urls.shtml

Such images are certainly not tracker pixels and should be
ignored. Though URI images would probably be ignored naturally since
they contain no URL anyway.

FYI, this same request was be submitted to the urlview project:

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

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

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

Versions of packages urlscan depends on:
ii  python33.9.2-3
ii  python3-urwid  2.1.2-1

Versions of packages urlscan recommends:
ii  libcanberra-gtk3-module  0.30-7

Versions of packages urlscan suggests:
ii  elinks [www-browser]  0.13.2-1+b1
ii  firefox-esr [www-browser] 102.6.0esr-1~deb11u1
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
ii  neomutt   20201127+dfsg.1-1.2
ii  ungoogled-chromium [www-browser]  90.0.4430.212-1.sid1
ii  w3m [www-browser] 0.5.3+git20210102-6

-- no debconf information

Bug#1068256: piglit: please remove the obsolete dependency on python3-six

[Alexandre Detiste]

Source: piglit
Version: 0~git20231002-24207f5be-1
Severity: normal

Dear Maintainer

python3-six was once usefull during the Python2->3 migration but should now be 
removed.

please trim the two lines in d/control.

https://wiki.debian.org/Python3-six-removal

Greetings

Bug#1068148: minidlna: CVE-2023-47430

[Salvatore Bonaccorso]

Hi Alexander,

On Tue, Apr 02, 2024 at 10:27:40PM +0300, Alexander Gerasiov wrote:
> On Sun, 31 Mar 2024 22:00:58 +0200
> Salvatore Bonaccorso  wrote:
> 
> > Source: minidlna
> > Version: 1.3.3+dfsg-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://sourceforge.net/p/minidlna/bugs/361/
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for minidlna.
> > 
> > CVE-2023-47430[0]:
> > | Stack-buffer-overflow vulnerability in ReadyMedia (MiniDLNA) v1.3.3
> > | allows attackers to cause a denial of service via via the
> > | SendContainer() function at tivo_commands.c.
> > 
> 
> Correct me if I'm wrong, but I didn't enable TiVo support in minidlna
> in Debian.
> So none of Debian releases are vulnerable.
> There was version 1.3.3+dfsg-0.2 which enables this flag, but I rolled
> this back in 1.3.3+dfsg-1

Ah you are right. I got tricked into the assessment seeing
tivo_commands.c. But there is a guard in the code 

 [...]
 18 #include "config.h"
 19 #ifdef TIVO_SUPPORT
 [...]
786 #endif // TIVO_SUPPORT

So yes, while the source package has the code, the binary packages
produced in Debian so have not the the issue.

Regards,
Salvatore

Bug#1067675: library package (arch any) depending on a "common" package with too strict version constraint

[Jeremy Bícha]

Cloning a bug in the way you did is not very helpful. mutter's
situation is different than folks.

The mutter binary package has Depends: mutter-common (>= ${source:Version})

That allows mutter to be binNMU'd.

An alternative is to do something like evolution which has this override:

dh_makeshlibs -V'libevolution (>= $(DEB_VERSION_UPSTREAM)),
libevolution (<< $(DEB_GNOME_NEXTVERSION))'

which translates to this when built on Unstable (3.50.3-1+b1) :

dh_makeshlibs -V'libevolution (>= 3.50.3), libevolution (<< 3.51)'

We do actually need the upstream version of the -common package to
match the other binary packages. I am not convinced there is even
value in switching to the evolution style since it seems rare for
there to be an upload after the first upload for an upstream version
(-2 or higher basically) where the fact that sometimes arch: all
builds slower than other architectures is enough of a problem in these
packages to make the packaging more complicated.

I would prefer to revert your Ubuntu diff for mutter so that if this
bug is fixed, it is fixed in Debian first.

Thank you,
Jeremy Bícha

Bug#1068255: dnf: dnf aborts with ImportError: cannot import name '_module' from partially initialized module 'libdnf'

[Michael Ivanov]

Package: dnf
Version: 4.14.0-4.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I have just tried to start up dnf and it aborts with a following error:

Traceback (most recent call last):
File "/usr/bin/dnf", line 61, in 
from dnf.cli import main
File "/usr/lib/python3/dist-packages/dnf/__init__.py", line 30, in 
import dnf.base
File "/usr/lib/python3/dist-packages/dnf/base.py", line 29, in 
import libdnf.transaction
File "/usr/lib/python3/dist-packages/libdnf/__init__.py", line 13, in

from . import module
File "/usr/lib/python3/dist-packages/libdnf/module.py", line 10, in 
from . import _module
ImportError: cannot import name '_module' from partially initialized module
'libdnf' (most likely due to a circular import) (/usr/lib/python3/dist-
packages/libdnf/__init__.py)

Python version is 3.11.8 (python package version is 3.11.8-3+b2)


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

Kernel: Linux 6.7.9-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnf depends on:
ii dnf-data 4.14.0-4.1
ii libmodulemd2 2.14.0-3+b1
ii python3 3.11.8-1
ii python3-dbus 1.3.2-5+b2
ii python3-dnf 4.14.0-4.1
ii sqlite3 3.45.2-1

dnf recommends no packages.

dnf suggests no packages.

-- no debconf information

Bug#1022073: Update to 1.3.0

[Adam]

I created merge requests in 2022 to update this package with a 
patchlevel update, and offered to do more updates, but I was unable to 
get any response.


I tried reaching out multiple times to the two previous maintainers via 
email and IRC, emailing the the authentication team, finding a mentor on 
IRC, pinging people via salsa, and even trying to track down anyone who 
could help on ActivityPub.


If someone is willing to find or be a mentor to me, and help with the 
release process, I'm still willing to put in the work to update the 
packages and make sure all the build tests continue to pass.


For reference, here are the merge requests that I submitted:

https://salsa.debian.org/auth-team/pam-u2f/-/merge_requests/8
https://salsa.debian.org/auth-team/pam-u2f/-/merge_requests/9
https://salsa.debian.org/auth-team/pam-u2f/-/merge_requests/10

I'm fairly new to creating packages and completely new to the release 
procedures, but I've been writing software and using Debian for decades, 
so after the first round of merges, I don't expect to require much of 
the mentor's time.


Thanks,
Adam


On 4/2/24 2:19 PM, Patrick Winnertz wrote:

retitle 1022073 new upstream release 1.3.0 is available
thanks

The last update of the u2f library is nearly 4 years(!) old. Please 
update to the latest version.
If you need help, please don't hesitate to ask, I'm happy to help here 
as I'm using yubikeys for all authentication processes.


With best regards
Patrick

Bug#1068254: python-monascaclient: please drop obsolete python3-six dependency

[Alexandre Detiste]

Source: python-monascaclient
Version: 2.8.0-2
Severity: normal

It's gone from upstream

tchet@brix /tmp/python-monascaclient $ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@brix /tmp/python-monascaclient $


Greetings

Bug#1067953: transition: flint

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-03-29 12:46:50 +, Torrance, Douglas wrote:
> Package: release.debian.org
> Control: affects -1 + src:flint
> X-Debbugs-Cc: fl...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: dtorra...@piedmont.edu
> Severity: normal
> 
> Dear Release Team,
> 
> I would like to request a transition slot for flint.  The recent upstream
> release 3.1.0 introduced the new soversion flint 19.  A new binary package,
> libflint19, was introduced in the source package flint 3.1.2-1~exp1, which
> cleared the NEW queue on March 28 and is now in experimental.
> 
> flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in
> the libflint18t64 binary package.  However, flint 3.0.1-3.1 had been
> previously uploaded for the t64 transition, shipping libflint.so.18 in
> the same binary package.  This is RC bug #1067226 and has resulted in
> several other RC bugs in reverse dependencies.

Please go ahead so that reverse dpeendencies can actually build again.

> An auto-flint tracker already exists for the t64 transition, but it doesn't
> take the new libflint19 package into account.  (Although perhaps this will
> update automatically at some point?)
> 
> binNMU's should be sufficient for each of flint's reverse dependencies:
> 
> * e-antic
> * gyoto
> * macaulay2
> * msolve
> * normaliz
> * polymake
> * singular

Please perform test builds or track the rebuilds for build failures.

Cheers

> 
> Ben file:
> 
> title = "flint";
> is_affected = (.build-depends ~ /\blibflint-dev\b/) | (.depends ~ 
> /\blibflint(?:18|18t64|19)\b/);
> is_good = .depends ~ /\blibflint19\b/;
> is_bad = .depends ~ /\blibflint18(?:t64)?\b/;
> 
> Thank you!



-- 
Sebastian Ramacher

Bug#1068253: RFS: gnome-online-accounts-gtk/3.50.1-1 [ITP] -- GUI Utility for logging into online accounts

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-online-accounts-gtk":

 * Package name : gnome-online-accounts-gtk
   Version  : 3.50.1-1
   Upstream contact : Clement Lefebvre 
 * URL  : https://github.com/linuxmint/gnome-online-accounts-gtk
 * License  : GPL-3
 * Vcs  :
https://github.com/ubuntubudgie/gnome-online-accounts-gtk/tree/debian
   Section  : misc

The source builds the following binary packages:

  gnome-online-accounts-gtk - GUI Utility for logging into online accounts

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

  https://mentors.debian.net/package/gnome-online-accounts-gtk/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-online-accounts-gtk/gnome-online-accounts-gtk_3.50.1-1.dsc

Changes for the initial release:

 gnome-online-accounts-gtk (3.50.1-1) unstable; urgency=medium
 .
 Initial version (Closes: #1068200)

Summary:
Upstream blog post https://blog.linuxmint.com/?p=4660

"GNOME Online Accounts, aka “GOA”, is a project which allows users to
connect to their data in the cloud. This project was only designed for
GNOME though so it doesn’t provide any front-end. It only provides
libraries (namely libgoa and libgoa-backend).

Other than GNOME, many desktop environments integrated a front-end to
these libraries in their control center: Cinnamon, Budgie, Unity, etc.

This project is important because it doesn’t just connect a desktop to
the cloud, it’s used by many applications and libraries. Among other
things you might use it to connect the Calendar application, the
Thunderbird email program or the file browser to your online data.

With GNOME 46, libgoa/libgoa-backend 3.50 moved to GTK4. It can no
longer be used by GTK3 applications.

To solve this problem a new XApp called GNOME Online Account GTK was
created. As any XApp its goal is to work for everybody, in any desktop
environment and in any Linux distribution.


Regards,
-- 
  David Mohammed

Bug#1068250: dracut: Consider switching to the fork dracut-ng

[Thomas Lange]

> On Tue, 02 Apr 2024 19:59:57 +0200, Jörg Behrmann 
>  said:


> Activity in dracut upstream has died down recently and though there is a 
version
> 60 of dracut in sid, upstream has not tagged such a release.
The upstream release process changed, so they do not tag the releases
any more.


> A fork of dracut has been started by some dracut developers at
> https://github.com/dracut-ng/dracut-ng
> It should be evaluated to switch to this fork.
Thanks for the info. I will carefully watch the work on this fork.

-- 
regards Thomas

Bug#1067326: mkdocstrings: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Dmitry Shachnev]

Hi Carsten!

On Wed, Mar 20, 2024 at 10:00:48PM +0100, Lucas Nussbaum wrote:
> Source: mkdocstrings
> Version: 0.24.1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> [...]
>
> The full build log is available from:
> http://qa-logs.debian.net/2024/03/19/mkdocstrings_0.24.1-1_unstable.log

Upstream released 0.24.2 today, which should fix this failure [1].

[1]: https://github.com/mkdocstrings/mkdocstrings/commit/c0d009000678a2cc

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1068148: minidlna: CVE-2023-47430

[Alexander Gerasiov]

On Sun, 31 Mar 2024 22:00:58 +0200
Salvatore Bonaccorso  wrote:

> Source: minidlna
> Version: 1.3.3+dfsg-1
> Severity: important
> Tags: security upstream
> Forwarded: https://sourceforge.net/p/minidlna/bugs/361/
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
> 
> 
> Hi,
> 
> The following vulnerability was published for minidlna.
> 
> CVE-2023-47430[0]:
> | Stack-buffer-overflow vulnerability in ReadyMedia (MiniDLNA) v1.3.3
> | allows attackers to cause a denial of service via via the
> | SendContainer() function at tivo_commands.c.
> 

Correct me if I'm wrong, but I didn't enable TiVo support in minidlna
in Debian.
So none of Debian releases are vulnerable.
There was version 1.3.3+dfsg-0.2 which enables this flag, but I rolled
this back in 1.3.3+dfsg-1

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#1068252: urlview: (security) extract IMG URLs so users can see tracker pixels

[Manny]

Package: urlview
Version: 0.9-21+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.urlv...@sideload.33mail.com

Tracker pixels are quite commonly used to snoop on email
recipients. URLview ignores URLs that specify an image to render.

We can perhaps configure the REGEXP variable to match  tags, but
then urlview cannot be used simultaneously for what it was intended
(to visit URLs).

In principle there should ideally be two lists of URLs (thus two
regular expressions):

  1) URLs that users might want to visit
  2) IMG URLs. This list can be useful in two ways:

 * Someone might want to view or fetch an image (though unlikely;
   they can always render the message in a GUI browser for that)

 * To view all possible urls that could be a tracker
   pixel. Tracker pixels cannot easily be detected
   programatically, so the URLs need to be presented in a way that
   makes it easy for a human to detect it manually.

It might also be useful for a user to have the option of tagging an
URL they determine to be a tracker pixel which could then be added to
a database of known tracker pixel URLs. Senders tend to make tracker
pixels unique per recipient, not per message. So when another message
from the same sender is fed to urlview, it could recognize already
identified tracker pixels and highlight them in some way. And more
usefully, the DB could be queried by the MUA so tracked messages can
be highlighted to users in the MUA.

If this functionality is implemented, the developer should be mindful
of embedded images. It’s possible for IMG tags to contain an embedded
“URI image”, whereby a very long string in base64 encodes an
image. Syntax is described here:

  https://www.thesitewizard.com/html-tutorial/embed-images-with-data-urls.shtml

Such images are certainly not tracker pixels and should be
ignored. Though such images would probably be ignored naturally since
they contain no URL anyway.

FYI, this same request will be submitted to the urlscan project.

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

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

Versions of packages urlview depends on:
ii  libc6   2.31-13+deb11u5
ii  libncurses6 6.2+20201114-2
ii  libtinfo6   6.2+20201114-2
ii  sensible-utils  0.0.14

Versions of packages urlview recommends:
ii  elinks [www-browser]  0.13.2-1+b1
ii  firefox-esr [www-browser] 102.6.0esr-1~deb11u1
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
ii  ungoogled-chromium [www-browser]  90.0.4430.212-1.sid1
ii  w3m [www-browser] 0.5.3+git20210102-6

Versions of packages urlview suggests:
pn  mutt  
pn  ncftp | lftp  
ii  wget  1.21-1+deb11u1

-- no debconf information

Bug#962021: forwarded upstream

[Vagrant Cascadian]

Control: fixed 962021 10.0.1-1

On 2022-04-19, Vagrant Cascadian wrote:
> On 2020-07-04, Bernhard M. Wiedemann wrote:
>> https://gitlab.com/graphviz/graphviz/-/merge_requests/1454
>> was easy, because I had the forked repo still around
>
> This was merged upstream:
>
>   
> https://gitlab.com/graphviz/graphviz/-/commit/9b758128c20f7a1d3bb2332327269c7d490ef055
>
> Which was included in 2.46.0.

This appears to be fixed in experimental, yay!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1022073: Update to 1.3.0

[Patrick Winnertz]

retitle 1022073 new upstream release 1.3.0 is available
thanks

The last update of the u2f library is nearly 4 years(!) old. Please 
update to the latest version.
If you need help, please don't hesitate to ask, I'm happy to help here 
as I'm using yubikeys for all authentication processes.


With best regards
Patrick

--

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.

Bug#1043686: Please provide a proper download location for beads

[Filippo Rusconi]

Greetings, Andreas!

On Saturday, March 30, 2024 9:41:40 PM CEST you wrote:

> Ping?
>
> Am Thu, Jan 25, 2024 at 12:46:17PM +0100 schrieb Andreas Tille:


I hope you are doing fine.

The beads code is here:

https://forgemia.inra.fr/pappso/beads

We do not use/develop that software anymore. But it might still be useful to 
the community.

In the hope I have answered your question correctly :-)

Most sincerely
Filippo


-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Researcher at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org


book: 
https://www.lavoisier.fr/livre/chimie/manuel-de-spectrometrie-de-masse-a-l-usage-des-biochimistes/rusconi/descriptif-9782743013417?combien=1
http://books.google.fr/books?
id=2NmguxmEI1sC&printsec=frontcover&dq=rusconi+f+lavoisier&hl=fr&sa=X&ei=nGGOUt2SH_Ly0gX0uIHoBQ&ved=0CDUQ6AEwAA#v=onepage&q&f=false

Institut Diversité, Écologie et Évolution du Vivant
Unité Génétique Quantitative et Évolution
Plateforme PAPPSO

Université Paris-Saclay, INRAE, UMR CNRS 8120, AgroParisTech
12, route 128, Bâtiment 680
91272 Gif-sur-Yvette
France

http://moulon.inrae.fr/ & http://pappso.inrae.fr/
Tel : +33 (0)1 69 33 23 54
Fax : +33 (0)1 69 33 23 40

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Aurelien Jarno]

control: found -1 glibc/2.37-15.1

Hi,

On 2024-04-01 16:23, Alejandro Colomar wrote:
> Package: glibc-doc
> Version: 2.38-6
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: a...@kernel.org, mar...@debian.org
> 
> Dear Maintainer,
> 
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:

Thanks, that sounds great that we can finally get rid out of those in
the debian package.

>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)
> 
> Debian's manpages-dev_6.7-1_all.deb has been the first package since
> that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
> upgrade manpages-dev due to a conflict with glibc-doc.
> 
>   $ sudo apt-get upgrade -V;
>   [...]
>   Do you want to continue? [Y/n] y
>   Reading changelogs... Done
>   (Reading database ... 404853 files and directories currently installed.)
>   Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
>   Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
>trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
> which is also in package glibc-doc 2.38-6
>   Errors were encountered while processing:
>/var/cache/apt/archives/manpages-dev_6.7-1_all.deb
>   needrestart is being skipped since dpkg has failed
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

I think this is actually not specific to the experimental version, those
manpages are also in the unstable version.

> Please, remove from glibc-doc those manual pages that conflict with
> manpages-dev.

Noted. However following the time_t transition, the glibc package does
not build anymore on 32-bit architectures (i have just opened #1059937
to make people aware of that), so uploading a new glibc now is probably
not the best idea.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Aurelien Jarno]

Source: glibc
Version: 2.37-15.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org

Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
-D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
except i386.

This has been partially fixed in the 2.37-15.1 NMU by adding
-U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:

| +-+
| | Encountered regressions that don't match expected failures. |
| +-+
| FAIL: conform/ISO/stdio.h/linknamespace
| FAIL: conform/ISO11/stdio.h/linknamespace
| FAIL: conform/ISO99/stdio.h/linknamespace
| FAIL: conform/POSIX/aio.h/linknamespace
| FAIL: conform/POSIX/dirent.h/linknamespace
| FAIL: conform/POSIX/fcntl.h/conform
| FAIL: conform/POSIX/fcntl.h/linknamespace
| FAIL: conform/POSIX/glob.h/conform
| FAIL: conform/POSIX/mqueue.h/conform
| FAIL: conform/POSIX/mqueue.h/linknamespace
| FAIL: conform/POSIX/stdio.h/linknamespace
| FAIL: conform/POSIX/sys/mman.h/linknamespace
| FAIL: conform/POSIX/sys/stat.h/conform
| FAIL: conform/POSIX/unistd.h/conform
| FAIL: conform/POSIX/unistd.h/linknamespace
| FAIL: conform/POSIX/utime.h/conform
| FAIL: conform/POSIX2008/aio.h/linknamespace
| FAIL: conform/POSIX2008/dirent.h/linknamespace
| FAIL: conform/POSIX2008/fcntl.h/conform
| FAIL: conform/POSIX2008/fcntl.h/linknamespace
| FAIL: conform/POSIX2008/glob.h/conform
| FAIL: conform/POSIX2008/mqueue.h/conform
| FAIL: conform/POSIX2008/mqueue.h/linknamespace
| FAIL: conform/POSIX2008/signal.h/conform
| FAIL: conform/POSIX2008/stdio.h/linknamespace
| FAIL: conform/POSIX2008/stdlib.h/linknamespace
| FAIL: conform/POSIX2008/sys/mman.h/linknamespace
| FAIL: conform/POSIX2008/sys/select.h/conform
| FAIL: conform/POSIX2008/sys/stat.h/conform
| FAIL: conform/POSIX2008/sys/statvfs.h/linknamespace
| FAIL: conform/POSIX2008/unistd.h/linknamespace
| FAIL: conform/UNIX98/aio.h/linknamespace
| FAIL: conform/UNIX98/dirent.h/linknamespace
| FAIL: conform/UNIX98/fcntl.h/conform
| FAIL: conform/UNIX98/fcntl.h/linknamespace
| FAIL: conform/UNIX98/glob.h/conform
| FAIL: conform/UNIX98/mqueue.h/conform
| FAIL: conform/UNIX98/mqueue.h/linknamespace
| FAIL: conform/UNIX98/stdio.h/linknamespace
| FAIL: conform/UNIX98/stdlib.h/linknamespace
| FAIL: conform/UNIX98/sys/mman.h/linknamespace
| FAIL: conform/UNIX98/sys/resource.h/linknamespace
| FAIL: conform/UNIX98/sys/statvfs.h/linknamespace
| FAIL: conform/UNIX98/sys/time.h/conform
| FAIL: conform/UNIX98/unistd.h/linknamespace
| FAIL: conform/UNIX98/utmpx.h/conform
| FAIL: conform/XOPEN2K/aio.h/linknamespace
| FAIL: conform/XOPEN2K/dirent.h/linknamespace
| FAIL: conform/XOPEN2K/fcntl.h/conform
| FAIL: conform/XOPEN2K/fcntl.h/linknamespace
| FAIL: conform/XOPEN2K/glob.h/conform
| FAIL: conform/XOPEN2K/mqueue.h/conform
| FAIL: conform/XOPEN2K/mqueue.h/linknamespace
| FAIL: conform/XOPEN2K/stdio.h/linknamespace
| FAIL: conform/XOPEN2K/stdlib.h/linknamespace
| FAIL: conform/XOPEN2K/sys/mman.h/linknamespace
| FAIL: conform/XOPEN2K/sys/resource.h/linknamespace
| FAIL: conform/XOPEN2K/sys/select.h/conform
| FAIL: conform/XOPEN2K/sys/statvfs.h/linknamespace
| FAIL: conform/XOPEN2K/sys/time.h/conform
| FAIL: conform/XOPEN2K/unistd.h/linknamespace
| FAIL: conform/XOPEN2K/utmpx.h/conform
| FAIL: conform/XOPEN2K8/aio.h/linknamespace
| FAIL: conform/XOPEN2K8/dirent.h/linknamespace
| FAIL: conform/XOPEN2K8/fcntl.h/conform
| FAIL: conform/XOPEN2K8/fcntl.h/linknamespace
| FAIL: conform/XOPEN2K8/ftw.h/conform
| FAIL: conform/XOPEN2K8/glob.h/conform
| FAIL: conform/XOPEN2K8/mqueue.h/conform
| FAIL: conform/XOPEN2K8/mqueue.h/linknamespace
| FAIL: conform/XOPEN2K8/signal.h/conform
| FAIL: conform/XOPEN2K8/stdio.h/linknamespace
| FAIL: conform/XOPEN2K8/stdlib.h/linknamespace
| FAIL: conform/XOPEN2K8/sys/mman.h/linknamespace
| FAIL: conform/XOPEN2K8/sys/resource.h/linknamespace
| FAIL: conform/XOPEN2K8/sys/select.h/conform
| FAIL: conform/XOPEN2K8/sys/stat.h/conform
| FAIL: conform/XOPEN2K8/sys/statvfs.h/linknamespace
| FAIL: conform/XOPEN2K8/sys/time.h/conform
| FAIL: conform/XOPEN2K8/unistd.h/linknamespace
| FAIL: conform/XOPEN2K8/utmpx.h/conform
| FAIL: conform/XPG4/dirent.h/linknamespace
| FAIL: conform/XPG4/fcntl.h/conform
| FAIL: conform/XPG4/fcntl.h/linknamespace
| FAIL: conform/XPG4/glob.h/conform
| FAIL: conform/XPG4/stdio.h/linknamespace
| FAIL: conform/XPG4/unistd.h/linknamespace
| FAIL: conform/XPG42/dirent.h/linknamespace
| FAIL: conform/XPG42/fcntl.h/conform
| FAIL: conform/XPG42/fcntl.h/linknamespace
| FAIL: conform/XPG42/glob.h/conform
| FAIL: conform/XPG42/stdio.h/linknamespace
| FAIL: conform/XPG42/stdlib.h/linknamespace
| FAIL: conform/XPG42/sys/mman.h/linknamespace
| FAIL: conform/XPG42/sys/resource.h/linknamespace
| FAIL: conform/XPG42/sys/statvfs.h/linknamespace
| FAIL: conform/XPG42/s

Bug#1059937: fio: FTBFS on riscv64: tries to uses rdcycle, privileged since kernel 6.6

[Aurelien Jarno]

Hi,

On 2024-01-22 12:59, Martin Steigerwald wrote:
> Thanks for the bug report, Aurelien.
> 
> Am Mittwoch, dem 03.01.2024 um 22:45 +0100 schrieb Aurelien Jarno:
> > Since the build daemons have been upgraded to kernel 6.6, fio FTBFS
> > with SIGILL in the testsuite. It is because the rdcycle instruction
> > has been changed to a privileged instruction starting with this kernel
> > version.
> >
> > A fix is available in the upstream repository [1]. Would it be
> > possible to include it in the next upload?
> 
> Sure. Instead of maintaining a patch for one version of fio and then
> removing it again however I prefer to wait for the next version of fio
> before the next upload.
> 
> Feel free to ping upstream about a new release.

There is now a new upstream version 3.37 that includes this fix.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1065221: Packaging multivolumefile?

[Andreas Tille]

Hi Yokota,

Am Sat, Mar 30, 2024 at 06:31:54PM +0100 schrieb Andreas Metzler:
> On 2024-03-30 Andreas Metzler  wrote:
> > I originally intended to file an ITP, but it probably makes more sense
> > to ask here:
> 
> > py7zr >= 0.16.0 requires multivolumefile by the same author. How about
> > packaging it under the debian-python umbrella?
> 
> Nevermind, YOKOTA Hiroshi already has done this and more and is looking
> for sponsors.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17

Thanks a lot for your packaging work.  My very personal sponsoring
policy is that I sponsor only team maintained packages.  If you move
your packages to DPT I'll happily sponsor your work. 

Kind regards
Andreas.

-- 
https://fam-tille.de

Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages

[Diederik de Haas]

On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: important
> Tags: upstream

I am/was inclined to remove that tag, but the problem is likely caused by 
firmware which is too old for the 'backported' patches that upstream applied.

> The driver fills the eventlog with millions !!! of messages, see below.
> It otherwise works. The problem can be reproduced on different NUC systems.

If you downgrade the kernel version, does the issue then go away?

> ** Kernel log:
> [30911.569896] BTRFS info (device sda4): disk space caching is enabled
> [30974.905443] net_ratelimit: 67420 callbacks suppressed
> [30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> [30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> [30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707

https://unix.stackexchange.com/a/721474 looks related and the solution is to 
upgrade the firmware to a newer version.
That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from Testing 
should be safe. Not sure if that version is new enough though.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
is the upstream repo and you could 'grab' the firmware files which `dmesg` 
reports it can't find.

> -- System Information:
> Debian Release: 12.5
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Versions of packages linux-image-6.1.0-18-amd64 is related to:
> ii  firmware-amd-graphics 20230210-5
> pn  firmware-atheros  
> pn  firmware-bnx2 
> pn  firmware-bnx2x
> pn  firmware-brcm80211
> pn  firmware-cavium   
> ii  firmware-intel-sound  20230210-5
> pn  firmware-intelwimax   
> pn  firmware-ipw2x00  
> pn  firmware-ivtv 
> ii  firmware-iwlwifi  20230210-5

My guess is that those 'backported' patches expect newer firmware then that.

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

Bug#1066011: whipper: Please drop dependencies on python3-distutils

[Louis-Philippe Véronneau]

The patch in question:

https://salsa.debian.org/python-team/packages/whipper/-/commit/574b58db64dc710796285793170482547135ad03

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1066011: whipper: Please drop dependencies on python3-distutils

[Louis-Philippe Véronneau]

tags 1066011 +patch
forwarded 1066011 https://github.com/whipper-team/whipper/issues/611
thanks

Thanks for opening this bug report. I've created a patch that fixes this 
issue. I'm planning on downgrading this bug to keep track of the 
upstream issue.


I haven't uploaded the fix yet, since I also need to add a new patch to 
migrate from setup.py to a pyproject.toml file. Still working on that.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1068250: dracut: Consider switching to the fork dracut-ng

[Jörg Behrmann]

Package: dracut
Version: 059-4
Severity: wishlist

Activity in dracut upstream has died down recently and though there is a version
60 of dracut in sid, upstream has not tagged such a release.

A fork of dracut has been started by some dracut developers at

https://github.com/dracut-ng/dracut-ng

It should be evaluated to switch to this fork.


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

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

Versions of packages dracut depends on:
ii  dracut-core  059-4

dracut recommends no packages.

Versions of packages dracut suggests:
ii  dracut-network  059-4

-- no debconf information

Bug#1063347: ITP: td -- telegram client library

[Mike Gabriel]

Hi Paul Liu,

On  Di 06 Feb 2024 14:59:00 CET, Ying-Chun Liu (PaulLiu) wrote:


Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: td
  Version : 1.8.0
  Upstream Contact: https://github.com/tdlib/td
* URL : https://core.telegram.org/tdlib
* License : Boost Software License 1.0
  Programming Lang: C++
  Description : telegram database library
  TDLib (Telegram Database Library) is a cross-platform, fully functional
  Telegram client. This library helps third-party developers create their
  own custom apps using the Telegram platform.


I am currently looking into packaging telePORTS, the Telegram of  
Ubuntu Touch for Debian. tdlib is a dependency of it.


Do you have any ETA when an upload of this can be expected in Debian  
unstable? Or asking the other way round: do you need some help?


light+love
Mike (aka sunweaver at d.o)
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpg9BRq8cWLj.pgp
Description: Digitale PGP-Signatur

Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec

[Noah Meyerhans]

Control: tags -1 + moreinfo

On Mon, Feb 12, 2024 at 10:42:31AM +0100, Alessandro Vesely wrote:
> /etc/init.d/spamd still uses --name instead of --exec.
> This is noticeable on shutdown, what the system waits 
> for some time trying to kill spamd, and then complains 
> something about its inability to track process names 
> and suggests to use --exec injstead.

I do not experience this when running under sysvinit on Debian 12 with
the following package versions:

ii  init-system-helpers 1.65.2   all  helper tools for all init 
systems
ii  spamd   4.0.0-6  all  Server for SpamAssassin spam 
filtering daemon
ii  sysvinit-core   3.06-4   amd64System-V-like init

When stopping spamd, there is no indication of any delay or other issue
terminating spamd.

Manual termination:
root@debian-sysv:~# /etc/init.d/spamd status
spamd is running.
root@debian-sysv:~# /etc/init.d/spamd stop
Stopping SpamAssassin Mail Filter Daemon: spamd.
root@debian-sysv:~# /etc/init.d/spamd status
spamd is not running ... failed!

Console output on shutdown:
root@debian-sysv:~# /etc/init.d/spamd status
spamd is running.
root@debian-sysv:~# shutdown -h now
...
Stopping SpamAssassin Mail Filter Daemon: spamd.
...

What is the specific warning you're seeing?  Is spamd actually running
when the init script is executing?

noah

Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages

[J. Pfennig]

Package: src:linux
Version: 6.1.76-1
Severity: important
Tags: upstream

Dear Maintainer,

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

The driver fills the eventlog with millions !!! of messages, see below.
It otherwise works. The problem can be reproduced on different NUC systems.
These are used as small servers, run a network bridge and hostapd. There
is no evidence that the problem depends on hostapd.

When the connection is idle the rate of reported errors goes down to a
few 10 per second. A larger stream of data (2GByte or so) produces
seveeral hundered tousand messages.

   * What led up to the situation?

iwlwifi is loaded with parameters as described in the debian wiki for
AX201 / Intel Nuc hardware:

options iwlwifi 11n_disable=8
options iwlmvm power_scheme=1

without power_scheme it frequently drops connections, with
power_scheme=1 it is stable. The effect of 11n_disable is unknown.

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

Needed to increase network message_cost to reduce logging:

echo 128 > /proc/sys/net/core/message_cost

   * What was the outcome of this action?
   * What outcome did you expect instead?

A driver that simply works.

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


-- Package-specific info:
** Version:
Linux version 6.1.0-18-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)

** Command line:
root=LABEL=alpha1_vol0 rootflags=subvol=/Volumes/Root-bookworm ro 
resume=alpha1_swap centauriswitch=static:apoint net.ifnames=0 mitigations=off 
security= quiet splash loglevel=3

** Not tainted

** Kernel log:
[30911.569896] BTRFS info (device sda4): disk space caching is enabled
[30974.905443] net_ratelimit: 67420 callbacks suppressed
[30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906356] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906681] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907014] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907319] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907576] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.908421] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.908744] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.906916] net_ratelimit: 216171 callbacks suppressed
[31102.906930] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911063] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911481] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911817] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912118] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912434] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912758] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913054] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913376] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.911440] net_ratelimit: 221524 callbacks suppressed
[31230.911453] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.911815] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912192] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912511] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912895] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913217] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913562] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913912] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.914255] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.915740] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912228] net_ratelimit: 213726 callbacks suppressed
[31358.912240] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912554] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912873] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914335] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914433] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914948] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915097] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915459] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915749] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.916034] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.915992] net_ratelimit: 205539 callbacks suppressed
[31486.916005] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.923781] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924153] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924548] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924860] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.925252] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.92553

Bug#1067982: [3dprinter-general] Bug#1067982: printrun: Please replace python3-appdirs dependency with platformdirs

[Rock Storm]

On Fri, 2024-03-29 at 14:59 +, Simon McVittie wrote:
> python3-appdirs is dead upstream[1] and its Debian maintainer has
> indicated
> that it should not be included in trixie[2]. A recommended replacement
> is
> python3-platformdirs[3], which is a fork of appdirs with a very
> similar API.
>=20
> Please migrate from appdirs to platformdirs or some other replacement,
> so that appdirs can be removed.

Dear Simon,

Thanks for your report. Printrun will not make it into Trixie anyway due
to bug #1050157 [1] so IMHO it should not block appdirs removal from
Trixie. I will report this upstream though so they migrate to a newer
library.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1050157


Thanks a lot,


--=20
=E2=A2=A0=E2=A3=A4=E2=A3=BC=E2=A3=A7=E2=A3=A4=E2=A1=84 Rock Storm
=E2=A3=B6=E2=A3=BF=E2=A0=8B=E2=A0=99=E2=A3=BF=E2=A3=B6=E2=A0=80https://gith=
ub.com/rockstorm101
=E2=A2=A8=E2=A0=BF=E2=A0=83=E2=A0=98=E2=A2=BF=E2=A1=85 C304 34B3 632C 464C =
2FAF C741 0439 CF52 C968 32FD

Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Colm Buckley]

On the other hand, though - creating this dependency *will* break workflows
and cause many unexpected side-effects, as it broke mine last month: I have
linux-headers-cloud-amd64 installed; when this package hit BPO, it brought
in linux-image-cloud-amd64, which grub then tracked as the most recent
kernel and booted into, causing (ironically) many drivers to be missing and
the system failed to boot correctly as a result (it is not a cloud server,
but it does build modules *for* cloud servers). It also brought my /boot to
98% full, fortunately this did not cause problems by itself, but obviously
came close to doing so.

It has been consistently asserted that installing superfluous image files
is harmless; I want to point out that this is anything but true, even aside
from the more philosophical issues around having "source" packages depend
on "binary" ones, and the precise meaning of "significant functionality" in
the Debian policy.

Colm


On Tue, 2 Apr 2024 at 17:57, Colm Buckley  wrote:

> Please explain. I am really sorry to be dragging this discussion out, but
> I honestly think there is some information I'm missing. Please tell me what
> I am missing here? ** PLEASE ** read it before replying; I am honestly not
> trying to undermine you, just point out a serious problem with the apparent
> logic.
>
> Your proposal is to have linux-headers-X depend on linux-image-X.
>
> But:
>
> * User installs linux-image-X and linux-headers-X
> * User builds modules for this image using DKMS or whatever
> * User then does "apt install linux-image-Y" - this is the exact scenario
> you hope to guard against?
> ... nothing brings in linux-headers-Y; the user is *still* left without
> their new modules.
>
> Your proposal will only work if the user remembers to upgrade -headers...
> which will fix the problem even without the dependency!
>
> I fully understand that there is a desire for users to keep linux-image-*
> and linux-headers-* in synch; my proposal is that a *further* package be
> created - linux-complete-VERSION - which depends on both of them. Users who
> have that package installed would always have the right thing happen. To
> encourage adoption, it could be in "Suggests" from each, and maybe even in
> DKMS?
>
> Colm
>
>
> On Tue, 2 Apr 2024 at 17:51, Bastian Blank  wrote:
>
>> On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote:
>> > ... but the proposed dependency wouldn't address that, right?
>>
>> Actually it does.  It ties all packages together with = dependencies.
>> For an upgrade, all packages need to be unpacked first and only then the
>> maintainer scripts can run.
>>
>> There are cases where this can be broken, but working most of the time
>> is better then working never.
>>
>> Bastian
>>
>> --
>> Prepare for tomorrow -- get ready.
>> -- Edith Keeler, "The City On the Edge of Forever",
>>stardate unknown
>>
>
>
> --
> Colm Buckley | c...@tuatha.org
>
>

-- 
Colm Buckley | c...@tuatha.org

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Luca Boccassi]

On Tue, 2 Apr 2024 at 16:52, Bastian Blank  wrote:
>
> On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> > Let's look at this the other way around: if there was no dependency, in
> > what scenario would things break and how?
>
> - linux-headers-bla and linux-image-bla are installed
> - linux-image-bla is uipgraded
> - no modules will be built, because the matching headers are missing

Got it, thanks, that makes sense to me as a problem and it would be
good to solve.

Is the root cause that the image and the headers package are published
and uploaded separately, due to signing?

Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2

[Andreas Beckmann]

Control: tag -1 - confirmed + moreinfo
Control: block -1 with 1063530

On 29/03/2024 18.08, Adam D. Barratt wrote:

On Fri, 2024-03-29 at 17:41 +0100, Andreas Beckmann wrote:

To smoothen some upgrade paths from buster -> bullseye -> bookworm we
need to add some Breaks+Replaces against obsolete packages.


node-babel7 currently FTBFS due to nodejs 18.19 in bookworm (+security), 
that seems to require a fix in node-undici first (#1063530) and probably 
a followup fix from node-babel7 7.20.15+ds1+~cs214.269.168-6, so maybe 
we should just rebuild the sid version as 
7.20.15+ds1+~cs214.269.168-6~deb12u1



Andreas

Bug#1068248: ruff: New upstream release

[Michael Fladischer]

Package: ruff
Version: 0.0.291+dfsg1-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

upstream has made some changes to the configuration sections in pyproject.toml
that ruff understands. Tests in other packages (e.b. python-xsdata) have started
to use the new configuration options and it would lighten the patch-load if ruff
were updated to its latest release (0.3.5 at the time of writing).

Regards,
Michael

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

Kernel: Linux 5.10.110-rockchip-rk3588 (SMP w/8 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ruff depends on:
ii  libc6  2.38-5
ii  libgcc-s1  14-20240330-1

ruff recommends no packages.

ruff suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmYMPfgbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqMR4H/2JUC9YyAVx6WtopF3kx
O4zOMrFVjFfhrtjcuB3i4Hka/R56sSB4FM213ucKGhITVJFJXPsUqwyq6M0VvTEC
miu6QiMD+F/Md6Q0r3jXxXxvWs7dafzrHa2KQV+G18WatTh5KFMWpIO96m34tQ8u
7FVUzhFYOfPH7ZyQtxNNjXJwe6HOiwY0kPMUP5qcJgKPiyRJbyN5X52Js78ywhOI
YcYym323bL/IoBtjqzxJtuqMH+Xy9knaXM8/Iq0hXc6nGVVxJImidGjOH/I4O3wD
oNn9X6YdoXcw03NNNxdJFARn3zPyNB83E3efQggGgfaEJxTfZ5PBvwoKv9G4926K
eN0=
=Xzr3
-END PGP SIGNATURE-

Bug#1068247: apt-transport-tor: add security-debug mirror to README

[Jakub Wilk]

Package: apt-transport-tor
Version: 0.5

Please add

 * security-debug.backend.mirrors.debian.org 
tor+http://i3hhdhcoozin2qyb5yhhufszgvhz6m2zfy6n6len2gjmetvbnnxcenyd.onion/

to README.md.

--
Jakub Wilk

Bug#1064931: RM: makedev -- RoQA; obsolete

[Chris Hofstaedtler]

Control: tags -1 - moreinfo

> Em ter., 27 de fev. de 2024 às 17:45, Chris Hofstaedtler
>  escreveu:
> > I propose to remove makedev. All its uses should be obsoleted by udev.
> >
> > The source package has some build requirements making building it
> > non-trivial in various environments (however the official buildds with
> > root support are fine).
> 
On Tue, Feb 27, 2024 at 07:04:09PM -0300, Guilherme Xavier wrote:
> I am not opposed to removing the referenced package if Debian decides
> that it is no longer relevant.

Given the buildds will probably also move away from full root
support very soon, I'm removing the moreinfo tag now, to accelerate
this.

Best,
Chris

Bug#1064976: Having headers depend on image - bad idea I think

[Bastian Blank]

Hi

On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote:
> This is a real problem - however I think it is *not* one which the change
> in dependency addresses; even if -headers-Y depends on -image-Y, step 3
> above will proceed without any conflicts (because the reverse dependency is
> not true). I think the only realistic way to address this (assuming we
> don't want to make -image depend on -headers) would be to have a
> linux-complete (not sold on the name) package series which depends on
> corresponding versions of both image and headers packages. Users who
> regularly build new modules should be encouraged to install this package
> and have it pull in suitable versions of both headers and image.

No, there is no "correct" solution.  Anything correct would need not
only moving the dependencies, but also the maintainer scripts, into one
package.  This is not going to be done without major restructuring.

So as long as there is no concept and support for that it will remain a
somewhat working solution.

Regards,
Bastian

-- 
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2

Bug#1064170: mediastreamer2: NMU diff for 64-bit time_t transition

[Dennis Filder]

X-Debbugs-CC: Steve Langasek , Sebastian Ramacher 


Can I get confirmation that this will get uploaded before the
autoremoval from testing on April 15th?  Message #17 has the fixed NMU
patch.

Regards.

Bug#1067308: python-meshplex: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-args=--ignore-glob=\*test_io\* returned exit code 13

[Drew Parsons]

Source: python-meshplex
Followup-For: Bug #1067308
Control: tags -1 ftbfs

I can't reproduce this error now.  It must have been resolved by a
separate library transition, or possibly a numpy update.

If 0.17.1-3 passes tests successfully then we can close this bug.

Bug#1068243: bsdgames: fails to configure

[Dr. Tobias Quathamer]

Am 02.04.24 um 17:19 schrieb Sven Joachim:

Package: bsdgames
Version: 2.17-31
Severity: serious

Your package fails to configure in a fresh installation (but not when
upgrading from a previous version).  This is what happens in a throwaway
chroot (unrelated lines stripped from apt/dpkg output):


Hi Sven,

thanks for the report, I've just discovered that issue at the time time 
as your bug report came in. :-)


It's fixed already, the upload is on its way.

Regards,
Tobias



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Bastian Blank]

On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> Let's look at this the other way around: if there was no dependency, in
> what scenario would things break and how?

- linux-headers-bla and linux-image-bla are installed
- linux-image-bla is uipgraded
- no modules will be built, because the matching headers are missing

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7

Bug#1068246: RFS: golang-modernc-file/1.0.8-1 [ITP] -- write ahead log in Go

[tous]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-modernc-file":

 * Package name : golang-modernc-file
   Version  : 1.0.8-1
   Upstream contact : Jan Mercl <0xj...@gmail.com>
 * URL  : https://modernc.org/file
 * License  : BSD-3-Clause
 * Vcs  : 
https://salsa.debian.org/go-team/packages/golang-modernc-file

   Section  : golang

The source builds the following binary packages:

  golang-modernc-file-dev - write ahead log in Go

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


  https://mentors.debian.net/package/golang-modernc-file/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-modernc-file/golang-modernc-file_1.0.8-1.dsc


Changes for the initial release:

 golang-modernc-file (1.0.8-1) unstable; urgency=medium
 .
   * Initial release (Closes: 1065568)

Regards,
--
  tous

Bug#1061060: javaws fails to run Supermicro (Aten) iKVM remote consoles

[Rich Otero]

I also encountered this problem after switching from Debian 10.9 to Debian
12.5. The Aten remote KVM provided by Supermicro motherboards relies on
JARs compressed by Pack200, so the application no longer works with
icedtea-netx and nvidia-openjdk-8-jre:

java.lang.UnsupportedOperationException: Pack200 compression is no longer
supported, cannot unpack
https://brody-ipmi:443/liblinux_x86_64__V1.0.8.jar.pack.gz
at
net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)
at
net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)
at
net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)
at
net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)

java.lang.UnsupportedOperationException: Pack200 compression is no longer
supported, cannot unpack
https://brody-ipmi:443/iKVM__V1.69.27.0x0.jar.pack.gz
at
net.sourceforge.jnlp.cache.ResourceDownloader.uncompressPackGz(ResourceDownloader.java:502)
at
net.sourceforge.jnlp.cache.ResourceDownloader.downloadPackGzFile(ResourceDownloader.java:400)
at
net.sourceforge.jnlp.cache.ResourceDownloader.downloadResource(ResourceDownloader.java:364)
at
net.sourceforge.jnlp.cache.ResourceDownloader.run(ResourceDownloader.java:117)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)

I think the relevant change was implemented in OpenJDK in December 2019:

https://hg.openjdk.org/jdk/jdk/rev/f236fd5d0c2c
https://bugs.openjdk.org/browse/JDK-8234542
https://bugs.openjdk.org/browse/JDK-8234596

On Wed, 17 Jan 2024 09:15:26 +0100 Christian Schwamborn <
c...@mail.architektur.tu-darmstadt.de> wrote:
> Package: icedtea-netx
> Version: 1.8.8-2
>
> In some more recent update of icedtea-netx, I can't determine which
> exactly, the pack200 libs must have been removed from javaws.jar
> Keeping older java versions around to access such devices can't help if
> javaws is unable to fetch the jar files from those as they might be
> compressed.
>
> Even recent system boards from Supermicro ship their jar libs as
> *.jar.pack.gz files. I know, it's deprecated for ages, but tell it to
> them. Even if they change it now, they won't update older firmwares and
> there are plenty around. Not only on server boards but all kind of
> enterprise equipment still running somewhere.
>
> Let me ask a question: Who uses javaws nowadays?
> My wild guess: Mostly people having to access hardware equipment, where
> 'the industry' even today implements their user interface with java
> beside the fact that java is one of the worst ideas someone came up with.
> Sure, the more recent versions of Supermicro boards (Fujitsu as well)
> also provide a html5 implementations, but sadly they are in some areas
> not as 'finished' as they should be, so I still have to rely on their
> java counterparts.
> I don't want to create a debate about security. Everyone running that
> sort of stuff should know not to expose those interfaces anywhere and
> has to hack half his java security settings anyway.

Bug#1068245: ITP: iwgtk -- lightweight graphical frontend to iwd

[Mark Hindley]

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

* Package name: iwgtk
  Version : 0.9
  Upstream Contact: Jesse Lentz 
* URL : https://github.com/J-Lentz/iwgtk
* License : GPL3+
  Programming Lang: C
  Description : Lightweight graphical frontend to iwd

iwgtk is a lightweight gtk4 frontend to iwd which provides similar
functionality to that of iwctl.
 
Features include viewing and connecting to available networks, managing known
networks, provisioning new networks via WPS or Wi-Fi Easy Connect and an
indicator (tray) icon displaying connection status and signal strength.

Mark

Bug#1068244: RFS: golang-modernc-lexer/1.0.5-1 [ITP] -- run time generator of action less scanners (lexeme recognizers)

[tous]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the package "golang-modernc-lexer":

 * Package name : golang-modernc-lexer
   Version  : 1.0.5-1
   Upstream contact : Jan Mercl <0xj...@gmail.com>
 * URL  : https://modernc.org/lexer
 * License  : BSD-3-Clause
 * Vcs  : 
https://salsa.debian.org/go-team/packages/golang-modernc-lexer

   Section  : golang

The source builds the following binary packages:

  golang-modernc-lexer-dev - run time generator of action less scanners 
(lexeme recognizers)


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


  https://mentors.debian.net/package/golang-modernc-lexer/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-modernc-lexer/golang-modernc-lexer_1.0.5-1.dsc


Changes for the initial release:

 golang-modernc-lexer (1.0.5-1) unstable; urgency=medium
 .
   * Initial release (Closes: 1065559)

Regards,
--
  tous

Bug#1068158: python-escript: FTBFS: RuntimeError: We do not current support different different dpkg-buildflags for C vs C++:

[Bo YU]

On Tue, Apr 2, 2024 at 11:19 PM Sebastian Ramacher  wrote:
>
> Hi
>
> On 2024-04-02 23:16:16 +0800, Bo YU wrote:
> > Tags: patch
> >
> > Hi,
> > >  File "/<>/site_scons/extractdebbuild.py", line 61:
> > >raise RuntimeError("We do not current support different different 
> > > dpkg-buildflags for C vs C++")
> > > make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2
> >
> > I have looked into this a bit.
> > As the error hint here, the default cflags in here when build is:
> >
> > ```
> > -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-
> > clash-protection -Wformat -Werror=format-security -fcf-protection 
> > -Wno-uninitialized
> > ```
> >
> > But cxxflags without[0] `-Werror=implicit-function-declaration` here. Is it
> > expected?
>
> It is expected. -Werror=implicit-function-declaration makes no sense in
> C++ since C++ simply does not support implicit function declarations.

Thanks for clarification.

Once cleared my local build, I will push this update again.

BR,
Bo
>
> Cheers
>

Bug#1064976: Having headers depend on image - bad idea I think

[Colm Buckley]

I wrote:

[...] From the maintainer's most recent comments, I believe that the
> problem is something like:
>
> * user has installed linux-headers and linux-image for kernel version X
> * user has built additional modules using DKMS which are installed into
> the running system
> * user upgrades linux-headers to version Y, new modules get rebuilt
> * user does not upgrade linux-image from X to Y, confusion results
>
> Having linux-image-Y be a dependency of linux-headers-Y does indeed
> address this problem, but [...]
>

The most recent comment (
https://lists.debian.org/debian-kernel/2024/04/msg00020.html) from the
maintainer indicates that he has a slightly different problem in mind:

* user has installed linux-headers and linux-image for version X
* user has built additional modules using DKMS, installed into the running
system
* user upgrades the *kernel image* to version Y but forgets to upgrade the
headers
* as a result, new kernel is missing important modules, confusion reigns

This is a real problem - however I think it is *not* one which the change
in dependency addresses; even if -headers-Y depends on -image-Y, step 3
above will proceed without any conflicts (because the reverse dependency is
not true). I think the only realistic way to address this (assuming we
don't want to make -image depend on -headers) would be to have a
linux-complete (not sold on the name) package series which depends on
corresponding versions of both image and headers packages. Users who
regularly build new modules should be encouraged to install this package
and have it pull in suitable versions of both headers and image.

Is this correct, Bastian? I'm sorry for taking so long to understand what
problem was being addressed here.

Colm


-- 
Colm Buckley | c...@tuatha.org

Bug#1068158: python-escript: FTBFS: RuntimeError: We do not current support different different dpkg-buildflags for C vs C++:

[Sebastian Ramacher]

Hi

On 2024-04-02 23:16:16 +0800, Bo YU wrote:
> Tags: patch
> 
> Hi,
> >  File "/<>/site_scons/extractdebbuild.py", line 61:
> >raise RuntimeError("We do not current support different different 
> > dpkg-buildflags for C vs C++")
> > make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2
> 
> I have looked into this a bit.
> As the error hint here, the default cflags in here when build is:
> 
> ```
> -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-
> clash-protection -Wformat -Werror=format-security -fcf-protection 
> -Wno-uninitialized
> ```
> 
> But cxxflags without[0] `-Werror=implicit-function-declaration` here. Is it
> expected?

It is expected. -Werror=implicit-function-declaration makes no sense in
C++ since C++ simply does not support implicit function declarations.

Cheers

> 
> 
> 
> Once we added the build flags for cxx[1] and sorted these config with
> compared, the built is okay.
> 
> [0]: 
> https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=ef90821fe45b99fa8c8c4279b9a74c30f59f491d
> [1]: 
> https://salsa.debian.org/science-team/python-escript/-/blob/debian/latest/debian/rules?ref_type=heads#L16
> 
> -- 
> Regards,
> --
>   Bo YU
> 

> diff -Nru python-escript-5.6/debian/changelog 
> python-escript-5.6/debian/changelog
> --- python-escript-5.6/debian/changelog   2023-12-10 18:53:54.0 
> +0800
> +++ python-escript-5.6/debian/changelog   2024-04-02 20:27:27.0 
> +0800
> @@ -1,3 +1,12 @@
> +python-escript (5.6-7) unstable; urgency=medium
> +
> +  * Team upload.
> +  * Add fix-dpkg-buildflags-on-c-c++.patch to fix ftbfs issue.
> +(Closes: #1068158)
> +  * No build dependencies issue again. (Closes: #1067385)
> +
> + -- Bo YU   Tue, 02 Apr 2024 20:27:27 +0800
> +
>  python-escript (5.6-6) unstable; urgency=medium
>  
>* Update patch for new buildflags. Closes: #1057593
> diff -Nru 
> python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch 
> python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch
> --- python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch  
> 1970-01-01 08:00:00.0 +0800
> +++ python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch  
> 2024-04-02 20:26:55.0 +0800
> @@ -0,0 +1,32 @@
> +Description: false postive for different build flags
> +  Do not support different different dpkg-buildflags for C vs C++
> +  In fact, cflags and cxxflags was the same with following config:
> +  cxxflags: -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=form
> +at-security -fcf-protection -Wno-uninitialized 
> -Werror=implicit-function-declaration
> +
> +  cflags:   -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-
> +clash-protection -Wformat -Werror=format-security -fcf-protection 
> -Wno-uninitialized
> + so sorted them can fix the issue.
> +
> +Author: Bo YU 
> +Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068158
> +Last-Update: 2024-04-02
> +---
> +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
> +--- a/site_scons/extractdebbuild.py
>  b/site_scons/extractdebbuild.py
> +@@ -57,8 +57,12 @@
> + mycflags=val
> + if key=="CXXFLAGS":
> + mycxxflags=val
> +-if mycflags is not None and mycxxflags is not None and 
> mycflags!=mycxxflags:
> +-raise RuntimeError("We do not current support different different 
> dpkg-buildflags for C vs C++")
> ++if mycflags is not None and mycxxflags is not None: 
> ++print(mycxxflags)
> ++print(mycflags)
> ++
> ++if sorted(mycflags.split()) != sorted(mycxxflags.split()):
> ++raise RuntimeError("We do not current support different 
> different dpkg-buildflags for C vs C++")
> + if usedflags[key] is None:
> + continue
> + res.append([usedflags[key],val])
> diff -Nru python-escript-5.6/debian/patches/py3.patch 
> python-escript-5.6/debian/patches/py3.patch
> --- python-escript-5.6/debian/patches/py3.patch   2023-12-10 
> 16:25:14.0 +0800
> +++ python-escript-5.6/debian/patches/py3.patch   2024-04-02 
> 17:40:23.0 +0800
> @@ -4,11 +4,9 @@
>  Last-Updated: 2020-03-09
>   Updated for python3.8
>  
> -Index: python-escript-5.6/site_scons/extractdebbuild.py
> -===
>  python-escript-5.6.orig/site_scons/extractdebbuild.py
> -+++ python-escript-5.6/site_scons/extractdebbuild.py
> -@@ -35,7 +35,7 @@ def getdebbuildflags():
> +--- a/site_scons/extractdebbuild.py
>  b/site_scons/extractdebbuild.py
> +@@ -35,7 +35,7 @@
> mycflags=None
> mycxxflags=None
> try:
> @@ -17,11 +15,9 @@
> except OSError:
>   return []
> res=[]
> -Index: python-escript-5.6/site_scons/dependencies.py
> -===
>  python-escrip

Bug#1068243: bsdgames: fails to configure

[Sven Joachim]

Package: bsdgames
Version: 2.17-31
Severity: serious

Your package fails to configure in a fresh installation (but not when
upgrading from a previous version).  This is what happens in a throwaway
chroot (unrelated lines stripped from apt/dpkg output):

,
| # apt install bsdgames
| Selecting previously unselected package bsdgames.
| Preparing to unpack .../bsdgames_2.17-31_amd64.deb ...
| Unpacking bsdgames (2.17-31) ...
| Setting up bsdgames (2.17-31) ...
| cp: cannot stat '/usr/share/games/bsdgames/phantasia/void': No such file or 
directory
| dpkg: error processing package bsdgames (--configure):
|  installed bsdgames package post-installation script subprocess returned 
error exit status 1
| Errors were encountered while processing:
|  bsdgames
| E: Sub-process /usr/bin/dpkg returned an error code (1)
`

See also the Salsa CI job at [1].


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


1. https://salsa.debian.org/games-team/bsdgames/-/jobs/5528281

Bug#1068158: python-escript: FTBFS: RuntimeError: We do not current support different different dpkg-buildflags for C vs C++:

[Bo YU]

Tags: patch

Hi,

 File "/<>/site_scons/extractdebbuild.py", line 61:
   raise RuntimeError("We do not current support different different dpkg-buildflags 
for C vs C++")
make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2


I have looked into this a bit.
As the error hint here, the default cflags in here when build is:

```
-g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-
clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wno-uninitialized
```

But cxxflags without[0] `-Werror=implicit-function-declaration` here. Is it
expected?



Once we added the build flags for cxx[1] and sorted these config with
compared, the built is okay.

[0]: 
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=ef90821fe45b99fa8c8c4279b9a74c30f59f491d
[1]: 
https://salsa.debian.org/science-team/python-escript/-/blob/debian/latest/debian/rules?ref_type=heads#L16

--
Regards,
--
  Bo YU

diff -Nru python-escript-5.6/debian/changelog 
python-escript-5.6/debian/changelog
--- python-escript-5.6/debian/changelog 2023-12-10 18:53:54.0 +0800
+++ python-escript-5.6/debian/changelog 2024-04-02 20:27:27.0 +0800
@@ -1,3 +1,12 @@
+python-escript (5.6-7) unstable; urgency=medium
+
+  * Team upload.
+  * Add fix-dpkg-buildflags-on-c-c++.patch to fix ftbfs issue.
+(Closes: #1068158)
+  * No build dependencies issue again. (Closes: #1067385)
+
+ -- Bo YU   Tue, 02 Apr 2024 20:27:27 +0800
+
 python-escript (5.6-6) unstable; urgency=medium
 
   * Update patch for new buildflags. Closes: #1057593
diff -Nru python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch 
python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch
--- python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch
1970-01-01 08:00:00.0 +0800
+++ python-escript-5.6/debian/patches/fix-dpkg-buildflags-on-c-c++.patch
2024-04-02 20:26:55.0 +0800
@@ -0,0 +1,32 @@
+Description: false postive for different build flags
+  Do not support different different dpkg-buildflags for C vs C++
+  In fact, cflags and cxxflags was the same with following config:
+  cxxflags: -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=form
+at-security -fcf-protection -Wno-uninitialized 
-Werror=implicit-function-declaration
+
+  cflags:   -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-
+clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wno-uninitialized
+ so sorted them can fix the issue.
+
+Author: Bo YU 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068158
+Last-Update: 2024-04-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/site_scons/extractdebbuild.py
 b/site_scons/extractdebbuild.py
+@@ -57,8 +57,12 @@
+ mycflags=val
+ if key=="CXXFLAGS":
+ mycxxflags=val
+-if mycflags is not None and mycxxflags is not None and 
mycflags!=mycxxflags:
+-raise RuntimeError("We do not current support different different 
dpkg-buildflags for C vs C++")
++if mycflags is not None and mycxxflags is not None: 
++print(mycxxflags)
++print(mycflags)
++
++if sorted(mycflags.split()) != sorted(mycxxflags.split()):
++raise RuntimeError("We do not current support different different 
dpkg-buildflags for C vs C++")
+ if usedflags[key] is None:
+ continue
+ res.append([usedflags[key],val])
diff -Nru python-escript-5.6/debian/patches/py3.patch 
python-escript-5.6/debian/patches/py3.patch
--- python-escript-5.6/debian/patches/py3.patch 2023-12-10 16:25:14.0 
+0800
+++ python-escript-5.6/debian/patches/py3.patch 2024-04-02 17:40:23.0 
+0800
@@ -4,11 +4,9 @@
 Last-Updated: 2020-03-09
  Updated for python3.8
 
-Index: python-escript-5.6/site_scons/extractdebbuild.py
-===
 python-escript-5.6.orig/site_scons/extractdebbuild.py
-+++ python-escript-5.6/site_scons/extractdebbuild.py
-@@ -35,7 +35,7 @@ def getdebbuildflags():
+--- a/site_scons/extractdebbuild.py
 b/site_scons/extractdebbuild.py
+@@ -35,7 +35,7 @@
mycflags=None
mycxxflags=None
try:
@@ -17,11 +15,9 @@
except OSError:
  return []
res=[]
-Index: python-escript-5.6/site_scons/dependencies.py
-===
 python-escript-5.6.orig/site_scons/dependencies.py
-+++ python-escript-5.6/site_scons/dependencies.py
-@@ -122,7 +122,7 @@ def call_python_config(bin=None):
+--- a/site_scons/dependencies.py
 b/site_scons/dependencies.py
+@@ -122,7 +122,7 @@
  cmd+='  
sp=subprocess.Popen([pythonroot+"python"+pyversion+"-config","--ldflags"], 
stdout=subprocess.PIPE)\n'
  cmd+='d=sp.stdout.readline().split()\n'
  cmd+="libdirs=[z[2:] for z in d if z.startswith(b'-L')]\n"
@@ -30,7 +26,7 @@
  cmd

Bug#1066248: [Pkg-electronics-devel] Bug#1066248: librnd: FTBFS: ../src/librnd/plugins/hid_lesstif/main.c:261:25: error: implicit declaration of function ‘lesstif_attr_sub_update_hidlib’ [-Werror=impl

[Bdale Garbee]

Peter Michael Green  writes:

> The functions in question are defined in 
> src/librnd/plugins/hid_lesstif/dialogs.c
> and used in src/librnd/plugins/hid_lesstif/main.c

Correct.  Upstream has fixed this and will have a new release on 10
April that I'm waiting for rather than patching the current Debian
sources.

> while working on this issue I discovered that the clean target was not
> cleaning up properly, so I fixed that too.

Thank you!  That's been on my to-do list, will talk to upstream about
the lingering files since his build structure should be cleaning up
after itself better, I think.

Bdale


signature.asc
Description: PGP signature

Bug#849741: Text to work around #898685

[Henrik Christian Grove]

Control: submitter -1 !

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Luca Boccassi]

On Tue, 2 Apr 2024 08:27:39 +0200 Bastian Blank 
wrote:
> On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote:
> > Why do dkms modules need the image installed to be built? At the
very
> > least they didn't use to, the headers were enough last time I had
to
> > deal with that stuff for the nvidia drivers
> 
> dkms is used to build modules for the kernel that is just being
> installed.  To do that it needs also the headers in matching
versions.
> 
> As the image can't depend on the headers, some other way was needed.

Sorry, I am still unable to understand the issue: dkms can and does
build modules for all installed _headers_ (plural). The fact that the
headers pull in a corresponding image does not change that fact, as far
as I can tell. In fact, it doesn't need any images at all, again as far
as I know.

Let's look at this the other way around: if there was no dependency, in
what scenario would things break and how?

-- 
Kind regards,
Luca Boccassi

Bug#1060407: gtkwave update for {bookworm,bullseye,buster}-security

[Adrian Bunk]

On Sun, Mar 31, 2024 at 01:52:40PM +0200, Moritz Mühlenhoff wrote:
> Hi Adrian,

Hi Moritz,

>...
> > debdiffs contain only changes to debian/
> 
> The bookworm/bullseye debdiffs looks good, please upload to security-master, 
> thanks!

both are now uploaded.

> Note that both need -sa, but dak needs some special attention when
> uploading to security-master. You'll need to wait for the ACCEPTED mail
> before you can upload the next one.

Done, but I am not sure this was necessary in this case since these are 
different upstream tarballs gtkwave_3.3.118.orig.tar.gz and 
gtkwave_3.3.104+really3.3.118.orig.tar.gz

(The contents also differs since as mentioned one is the GTK 2+3 
 upstream tarball and the other one is the GTK 1+2 upstream tarball.)

> Cheers,
> Moritz

cu
Adrian

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi everyone,

* Chris Hofstaedtler  [240330 01:42]:
> > So, after some of the current fog clears, src:util-linux could
[..]
> > 
> > Does this seem right?

I've put everything I know of into this wiki page:

   https://wiki.debian.org/PamLastlog2

I would invite you all to review / edit it as you see fit, and/or
start a discussion in this bug.

After we have something that we can agree on, I'd send it as a
proposed plan to debian-devel.

Please also let me know if you think it's fine as is.

Thanks!
Chris

Bug#1068242: bookworm-pu: package libtool/2.4.7-7~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Alastair McKinstry 

[ Reason ]
I'd like to rebuild libtool from sid in order to fix two RC bugs:
* missing Conflicts against an obsolete (now virtual) package name
  causing file conflicts on some upgrade paths of systems initially
  installed while the obsolete package was still a real package
* incorrect detection of the += feature causing problems for packages
  using it

[ Impact ]
Some upgrade paths not working (mostly triggered by QA tools).
Operator += not working.

[ Tests ]
Manual piuparts upgrade tests of the affected upgrade paths.
Both changes have been in sid since July without followup issues.

[ Risks ]
In case of regression, we could revert each of the two fixes
separately.

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

[ Changes ]

+libtool (2.4.7-7~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+  * Reinstate obsolete Breaks, Provides.
+
+ -- Andreas Beckmann   Thu, 28 Mar 2024 13:23:40 +0100
+
+libtool (2.4.7-7) unstable; urgency=medium
+
+  * Remove obsole Breaks: for oldstable , Provides: libltdl7-dev
+  * Replace Breaks: libltdl3-dev with Conflicts: libltdl3-dev.
+Thanks  Andreas Beckmann. Closes: #1041229
+
+ -- Alastair McKinstry   Mon, 17 Jul 2023 16:03:58 +0100
+
+libtool (2.4.7-6) unstable; urgency=medium
+
+  * Incorrect check for += operator causes func_append to fail
+Patch from Ernesto Alfonso. Closes: #1039612
+  * Standards-Version: 4.6.2
+  * Add Breaks/Replaces on libtldl3-dev. Closes: #1039583
+
+ -- Alastair McKinstry   Sat, 15 Jul 2023 09:09:39 +0100

 changelog   |   25 
 control |4 +
 patches/0090-shell-op.patch |  126 
 patches/series  |1
 4 files changed, 155 insertions(+), 1 deletion(-)

[ Other info ]
This is a rebuild of the package from sid with the removal of some
obsolete Breaks/Replaces reverted to minimize the diff from stable.
There is an unneeded and useless (because misspelled) Replaces being
added. I'm not fixing (i.e. dropping) that because it's harmless and I
do not want to deviate from sid too much.


Andreas
diff -Nru libtool-2.4.7/debian/changelog libtool-2.4.7/debian/changelog
--- libtool-2.4.7/debian/changelog  2022-11-23 12:34:12.0 +0100
+++ libtool-2.4.7/debian/changelog  2024-03-28 13:23:40.0 +0100
@@ -1,3 +1,28 @@
+libtool (2.4.7-7~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+  * Reinstate obsolete Breaks, Provides.
+
+ -- Andreas Beckmann   Thu, 28 Mar 2024 13:23:40 +0100
+
+libtool (2.4.7-7) unstable; urgency=medium
+
+  * Remove obsole Breaks: for oldstable , Provides: libltdl7-dev
+  * Replace Breaks: libltdl3-dev with Conflicts: libltdl3-dev.
+Thanks  Andreas Beckmann. Closes: #1041229
+
+ -- Alastair McKinstry   Mon, 17 Jul 2023 16:03:58 +0100
+
+libtool (2.4.7-6) unstable; urgency=medium
+
+  * Incorrect check for += operator causes func_append to fail
+Patch from Ernesto Alfonso. Closes: #1039612
+  * Standards-Version: 4.6.2
+  * Add Breaks/Replaces on libtldl3-dev. Closes: #1039583
+
+ -- Alastair McKinstry   Sat, 15 Jul 2023 09:09:39 +0100
+
 libtool (2.4.7-5) unstable; urgency=medium
 
   * Standards-Version: 4.6.1
diff -Nru libtool-2.4.7/debian/control libtool-2.4.7/debian/control
--- libtool-2.4.7/debian/control2022-11-23 12:34:12.0 +0100
+++ libtool-2.4.7/debian/control2024-03-28 13:23:32.0 +0100
@@ -13,7 +13,7 @@
 Section: devel
 Priority: optional
 Maintainer: Alastair McKinstry 
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://www.gnu.org/software/libtool/
 Vcs-Browser: https://salsa.debian.org:/mckinstry/libtool.git
@@ -96,6 +96,8 @@
 Section: libdevel
 Suggests: libtool-doc
 Provides: libltdl3-dev, libltdl7-dev
+Conflicts: libltdl3-dev
+Replaces: libbtldl3-dev
 Recommends: libtool
 Depends: libltdl7 (= ${binary:Version}), ${misc:Depends}, ${automake}
 Description: System independent dlopen wrapper for GNU libtool (headers)
diff -Nru libtool-2.4.7/debian/patches/0090-shell-op.patch 
libtool-2.4.7/debian/patches/0090-shell-op.patch
--- libtool-2.4.7/debian/patches/0090-shell-op.patch1970-01-01 
01:00:00.0 +0100
+++ libtool-2.4.7/debian/patches/0090-shell-op.patch2023-07-17 
17:03:58.0 +0200
@@ -0,0 +1,126 @@
+Author:  Ernesto Alfonso 
+Description: Incorrect check for += operator causes func_append to fail
+Bug-Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039612
+Forwarded: no
+Last-Updated: 2023-07-15
+
+--- a/bootstrap
 b/bootstrap
+@@ -227,7 +227,7 @@
+ 
+ # Source 

Bug#1068241: authselect: pam_lastlog.so is gone

[Chris Hofstaedtler]

Source: authselect
Version: 1.5.0-1

Hi,

it appears authselect references pam_lastlog.so. However, this
module has been disabled in PAM upstream, and is also no longer
shipped in Debian's PAM.

Please adapt your package.

Chris

Bug#1068240: nauty: autopkgtest regression in testing

[Graham Inggs]

Source: nauty
Version: 2.8.8+ds-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Sometime around 2024-01-23, nauty's autopkgtest regressed in testing
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/n/nauty/testing/amd64/


60s The following packages have unmet dependencies:
60s autopkgtest-satdep : Depends: libnauty2-dev but it is not installable
60s E: Unable to correct problems, you have held broken packages.
60s autopkgtest: WARNING: Test dependencies are unsatisfiable -
calling apt install on test deps directly for further data about
failing dependencies in test logs
60s Reading package lists...
60s Building dependency tree...
60s Reading state information...
60s Package libnauty2-dev is not available, but is referred to by
another package.
60s This may mean that the package is missing, has been obsoleted, or
60s is only available from another source
60s
60s E: Package 'libnauty2-dev' has no installation candidate
60s build-examples FAIL badpkg
60s blame: nauty
60s badpkg: Test dependencies are unsatisfiable. A common reason is
that your testbed is out of date with respect to the archive, and you
need to use a current testbed or run apt-get update or use -U.

Bug#1068239: jq: JSON filters can be fooled by \u0041 or other escapes in object names

[Joshua Hudson]

Package: jq
Version: 1.6-2.1
Severity: important

Consider this JSON file:

{
"\u0041PIModule": "/test2.dll",
"APIModule": "/test.dll"
}

On running jq .APIModule < test.json, the output is "/test.dll". The
expected output is "/test2.dll", "/test.dll", or alternately an error
message as this input file is in fact malformed. The order of the two
input lines does not matter: reversing the order in input does not
change the output.

This bug is security class, and was discovered by looking for a solution
to a security problem we uncovered in new development; however this is
not a security bug for everybody. Most people don't try to determine if
JSON input is trustworthy this way.

-- 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=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 jq depends on:
ii  libc6   2.36-9+deb12u4
ii  libjq1  1.6-2.1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

Bug#1067487: reopen since not fixed

[Rémi Letot]

Control:
reopen 1067487
thanks

Bug#1068238: ITP: gmobile -- mobile related helpers for glib based projects

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: gmobile
  Version : 0.1.0
  Upstream Contact: The Phosh developers
* URL : https://gitlab.gnome.org/World/Phosh/gmobile
* License : LGPL
  Programming Lang: C
  Description : mobile related helpers for glib based projects

The shared library is used by projects like phosh to determine device
tree compatibles, use suspend robust timers or query cutout and notch 
information.

Bug#1064976: Having headers depend on image - bad idea I think

[Colm Buckley]

Control: reopen 1064976

My apologies for the ping-pong; I do want to keep this open until the
discussion has completed. I will set out my thoughts below. I'm afraid this
is fairly long.

A brief history of this issue: in December 2023, the control file for
linux-headers-* was altered to include a dependency on linux-image-* (
https://salsa.debian.org/kernel-team/linux/-/merge_requests/903). As far as
I can tell, no bugreport was linked as a problem being addressed with this
change; the maintainer's comment was "A lot of problems arise if users use
headers of a different version then the associated image. The easiest
solution is to make them depend." Note that this dependency did not exist
in any previous version of linux-headers as far as I can determine; the
problems seem to be largely theoretical.

This change worked its way through the release pipeline and eventually
arrived in bookworm-backports around the end of February 2024, with the
promotion of the package linux-headers-6.6.13+bpo-amd64 (and others) to
backports. I immediately noticed the impact on my build server, and
submitted a bug report (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976) requesting that
it be reverted.

The maintainer defended the change, indicating that it was necessary for
people using dkms; when pressed on exactly what failed, he mentioned the
BTF warnings [1] but as far as I can tell, no specific user problem was
presented. Several attempts by myself and Luca Boccassi to determine what
problem was being addressed were not answered.

The bug was closed as WONTFIX a few days ago, but still there has been no
real explanation as to why the change was introduced in the first place. I
would like to go on the record here as saying (especially with the xz-utils
exploit still in everyone's memory), that we should be *extremely careful*
with changing things like dependency trees without very well-documented
reasons, *especially* for something as critical as the kernel packages. I
ordinarily try to be very respectful of maintainers' latitude and
discretion in packaging decisions, but here I am trying to ensure that a
serious problem is addressed in BPO before it gets promoted to stable. The
change is significant enough that I feel it deserves more discussion  and
attention than it has so far received.

Having re-read the thread a few times today, I feel that the BTF warnings
(which were originally presented as the main reason for this change) are a
red herring and not relevant. The new packaging of vmlinux.h does address
the issue of BPF builds for pretty much all users (it's true that build
pipelines will have to be adjusted, but the new system is a significant
improvement on the old). The discussion about BPF kernel modules does not
seem to be based on any real user activity, and to be honest it seems
somewhat self-contradictory - why would a kernel module need BPF in the
first place?

Let's consider the possible reasons for having the header package depend on
the image package:

>From Debian's policy documentation; "The Depends field should be used if
the depended-on package is required for the depending package to provide a
significant amount of functionality." So what functionality is provided by
linux-headers-*? I would posit initially that their main function is
unspecified apart from "having the header files for the specific kernel
exist under /usr/src", which clearly does not require the image package.

However, a major use case for the header files is to build kernel modules,
whether using DKMS or some other mechanism. But this use case *also* does
not require the image package; in fact this is the main reason the header
files were packaged as they are. Hundreds of thousands (at least) of Debian
users have been happily building kernel modules using linux-headers
packages without the corresponding image files for decades, and there are
no recent kernel changes which break this ability. The recent introduction
of vmlinux.h additionally addresses an edge case (building BPF programs)
which formerly *did* require a built image for its symbol table. So the
important piece of functionality also does not require the kernel image
package.

Now, given the maintainer's comments on the original PR and in this bug, I
suspect I understand the real reason for the change: in order to *run*
modules built using DKMS etc., obviously the corresponding kernel image
file needs to be present. From the maintainer's most recent comments, I
believe that the problem is something like:

* user has installed linux-headers and linux-image for kernel version X
* user has built additional modules using DKMS which are installed into the
running system
* user upgrades linux-headers to version Y, new modules get rebuilt
* user does not upgrade linux-image from X to Y, confusion results

Having linux-image-Y be a dependency of linux-headers-Y does indeed address
this problem, but I feel that it is fairly substantial overkill. There are
several refe