Bug#1055891: transition: gdal

[Paul Gevers]

Hi

On 19-11-2023 07:32, Sebastiaan Couwenberg wrote:
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, 
and libgdal-grass from unstable due to the tight coupling.


If it doesn't happen automatically and there is a tight coupling, where 
is the tight coupling missing in the package relations?


Paul
PS: I didn't check the situation, merely commented on the words in the 
e-mail that confused me.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055891: transition: gdal

[Sebastiaan Couwenberg]

For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, 
and libgdal-grass from unstable due to the tight coupling.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1056215: vulkan-tools: vulkaninfo tool can't be installed

[Steven Friedrich]

Package: vulkan-tools
Severity: important

Dear Maintainer,

Vulcan Info Center missing vulkaninfo, apt can't find package.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Bug#1056214: RM: doctorj -- ROM; dead upstream; obsolete

[tony mancill]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: doct...@packages.debian.org
Control: affects -1 + src:doctorj

doctorj [1] has a low popcon, is dead upstream (the latest upstream
release is May of 2013, and the last commit was January of 2014 [2]),
and its functionality has (long) been supplanted by the linter that
comes with the JDK's built-in javadoc command.  For these reasons, I
don't think the package should be included in trixie.

This is a team-maintained package.  I proposed the RM one week ago [3].

Thank you,
tony

[1] https://tracker.debian.org/pkg/doctorj
[2] https://github.com/jpace/doctorj
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052498#25


signature.asc
Description: PGP signature

Bug#1056213: {sysvinit-core,initscripts}.postinst: please support DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Source: sysvinit
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

Hi,

when creating chroots for architectures that are in the process of being
bootstrapped without yet having emulation support, it is not possible to run
maintainer scripts inside the foreign architecture chroot as the tools they
call cannot be executed. The solution to that problem is to run maintainer
scripts from the chroot directory without doing a chroot call first and instead
use the $DPKG_ROOT environment variable to communicate the location of the
chroot directory that the tools called by the maintainer script should operate
on. By default, for normal installations, that environment variable is set, but
empty. For more information see:
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

Support for this mode was already added to all packages in the essential set,
apt, systemd-sysv as well as build-essential. I'm now trying to add
support to the packages required to set up a system using sysv-init.
Having support DPKG_ROOT support for another init system than systemd is
useful to create chroots for architectures or kernels (like GNU Hurd)
that do not have systemd support.

I put my patch in this MR:
https://salsa.debian.org/debian/sysvinit/-/merge_requests/11

We tested it in our CI environment and it produces a bit-by-bit
identical chroot with DPKG_ROOT compared to a normal installation.

https://salsa.debian.org/helmutg/dpkg-root-demo/

Since the DPKG_ROOT variable is empty on normal installations, the patch
should have no effect in the normal case.

Thanks!

cheers, josch

Bug#1033305: chromium: try enabling use_thin_lto for faster build

[Daniel Richard G.]

On Sat, 2023 Nov 18 20:37-05:00, Andres Salomon wrote:
>
> I still haven't messed around with thinlto yet, but my primary concern 
> at this point is that various ARM build machines keep running out of 
> memory while building chromium. In particular, on armhf the arm-ubc-* 
> buildds run out of memory and kill the build,

On armhf, it's not possible to enable ThinLTO, because the final link
requires more than 4 GB RAM. (I tried a full build in an armhf Docker
container running under QEMU, on a system with 48 GB RAM, and still
it failed.) I haven't tried i386, but presumably the same issue will
occur there.

(Is there a way to have official Debian packages be cross-compiled? This
is a case where native compilation isn't ideal.)

> as you can see on 
> https://buildd.debian.org/status/logs.php?pkg=chromium=armhf

There's something unrelated going on there, doubtful it's any kind of
OOM at that point in the build. I think you'd have to peek at syslog to
get an answer. Could be a hardware issue, for all the log shows.

> I'm wondering if thinlto would possibly result in faster/less-memory-
> intensive object (or bitcode or whatever) generation that might work
> better on platforms with less memory? Do you know offhand how memory
> usage of thinlto compares to what we (debian) do now (no LTO at all)?

I'm not aware of LTO, in general, helping much with run-time memory
usage. But it's supposed to make things run faster to some degree, and I
figure that alone would be welcome on the less-beefy platforms.


By the way, I've been meaning to write in with a related issue. ThinLTO
currently fails on ppc64el, with this GN error:

begin build log excerpt
gn gen out/Release --args="clang_use_chrome_plugins=false ... use_thin_lto=true 
..."
ERROR at //build/config/compiler/BUILD.gn:696:5: Assertion failed.
assert(use_lld, "LTO is only supported with lld")
^-
LTO is only supported with lld
See //build/config/BUILDCONFIG.gn:333:3: which caused the file to be included.
  "//build/config/compiler:afdo",
  ^-
make[1]: *** [debian/rules:164: override_dh_auto_build-arch] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:127: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
end build log excerpt

(Credit to Luiz Guzman @ Trisquel Linux for bringing this to my attention:
https://github.com/ungoogled-software/ungoogled-chromium-debian/issues/334#issuecomment-1767888316)

The issue comes down to this conditional in build/config/BUILDCONFIG.gn:

  # Set to true when compiling with the Clang compiler.
  is_clang = current_os != "linux" ||
 (current_cpu != "s390x" && current_cpu != "s390" &&
  current_cpu != "ppc64" && current_cpu != "ppc" &&
  current_cpu != "mips" && current_cpu != "mips64" &&
  current_cpu != "riscv64")

The assumption underlying that logic is clearly incorrect in the Debian
context. Perhaps we should just hard-code it to true.

I don't know if there are other ramifications of is_clang=false in the
ppc64el build. I sent a note to Tim about this, but never heard back.

Bug#986232: RE: ITP organicmaps

[Matthias Geiger]

On Thu, 1 Jun 2023 23:16:58 +0200 (CEST) matthias.geiger1...@tutanota.de 
wrote:


>Note: I built with the 3party/ dir excluded via d/copyright.
>
>libtess2, open-location-code, succinct, sdf_image and liboauthcpp 
would need packaging from scratch at a first glance. I'd also nudge 
upstream to check if a cpp lib is present in the system first >before 
utilizing the vendored ones. I'd also would welcome teamwork / 
contributions here. I think this is a great application to have in 
debian at some point.


So after some more hacking away I finally got CMake to go past 
configure. The compilation errors out of course because it looks for the 
absolute header path under 3party.


The first library not in debian the build log mentions is succint. 
That'd be a starting point imho. Progress is at 
https://salsa.debian.org/werdahias/organicmaps. I'll look more into this 
later.


log attached.

best,

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

   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- \
-DCMAKE_BUILD_TYPE="Release" \
-DWITH_SYSTEM_PROVIDED_3PARTY=ON
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_BUILD_TYPE=Release -DWITH_SYSTEM_PROVIDED_3PARTY=ON ..
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using compiler GNU 13.2.0
-- Using Unity Build with batch 50, export UNITY_DISABLE=1 or use 
-DUNITY_DISABLE=ON to disable it.
-- export COLORS_DISABLE=1 or use -DCOLORS_DISABLE=ON to disable colored 
compiler output.
Setting PLATFORM_LINUX to true
-- Build type: Release
-- Using ld.gold
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE  
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so   
-- Found WrapOpenGL: TRUE  
-- Could NOT find XKB (missing: XKB_LIBRARY XKB_INCLUDE_DIR) (Required is at 
least version "0.5.0")
-- Found WrapVulkanHeaders: /usr/include  
-- Found the following ICU libraries:
--   uc (required): /usr/lib/x86_64-linux-gnu/libicuuc.so
--   i18n (required): /usr/lib/x86_64-linux-gnu/libicui18n.so
--   data (required): /usr/lib/x86_64-linux-gnu/libicudata.so
-- Found ICU: /usr/include (found version "72.1") 
-- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version 
"2.13.2") 
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.1") 
-- Checking for module 'jansson'
--   Found jansson, version 2.14
-- Found Python3: /usr/bin/python3 (found version "3.11.6") found components: 
Interpreter 
-- Found python to use in qt/, shaders/ and 3party/: /usr/bin/python3
Building with Qt Positioning
-- Configuring done (1.3s)
-- Generating done (0.4s)
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
FETCHCONTENT_FULLY_DISCONNECTED


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   dh_auto_build
cd obj-x86_64-linux-gnu && make -j6 "INSTALL=install 
--strip-program=true" VERBOSE=1
make[1]: Entering directory '/<>/obj-x86_64-linux-gnu'
/usr/bin/cmake -S/<> -B/<>/obj-x86_64-linux-gnu 
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start 
/<>/obj-x86_64-linux-gnu/CMakeFiles 
/<>/obj-x86_64-linux-gnu//CMakeFiles/progress.marks
make  -f CMakeFiles/Makefile2 all
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
make  -f base/CMakeFiles/base.dir/build.make base/CMakeFiles/base.dir/depend
make  -f ge0/CMakeFiles/ge0.dir/build.make ge0/CMakeFiles/ge0.dir/depend
make  -f qt_tstfrm/CMakeFiles/qt_tstfrm.dir/build.make 
qt_tstfrm/CMakeFiles/qt_tstfrm.dir/depend
make  -f transit/CMakeFiles/transit.dir/build.make 
transit/CMakeFiles/transit.dir/depend
make  -f routing_common/CMakeFiles/routing_common.dir/build.make 

Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure

[gregor herrmann]

On Sat, 18 Nov 2023 16:21:57 -0800, Russ Allbery wrote:

> > in the light of #1055955 (perl5.38 transition bug) -- do you think
> > you can upload a fixed version (the current version plus a patch or a
> > new release) in the near future, or should I upload an NMU with your
> > upstream commit or should we just ignore docknot for the transition …
> > or something else? :)
> I've uploaded a fix;

Thank you!

> I'm so sorry for the absurd delay.  I'd meant to get
> to this months ago and kept not making time to finish it.

No worries, still well in time for the perl 5.38 transition :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1056212: ITP: sphinxcontrib-moderncmakedomain -- Sphinx domain for Modern CMake

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: sphinxcontrib-moderncmakedomain
  Version : 3.27.0
  Upstream Author : Kitware, Inc
* URL : https://github.com/scikit-build/moderncmakedomain
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx domain for Modern CMake

This is the stand-alone version of Kitware's Sphinx code to generate the
official CMake documentation, taken directly from the CMake sources.

The package will be team-maintained under the umbrella of the
Debian Python Team 
at https://salsa.debian.org/python-team/packages/sphinxcontrib-moderncmakedomain


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVZVuQACgkQ+C8H+466
LVnX1QwApgxr9rEY7qwtK9drW4aDxiSVWcXbl7beYcOdD3AHls0VXAWXK3XLmnlZ
QNebR90PtzkhvWvyehJweSYjxE0YAOe/LOYvsfJJOcpKpm8AohnyZPnPlslmaFUI
ck9j8GPJXbCEIUyApFxp/X0okDL00MsR5RuBAOVzgFmbZpJDM3ypEO3WmvGWBcZs
ZEqwQ2zyDdM8guKi4uCkvWRzOAhHgEj9m1vcudj6KXxwYhuV85V442xQo6WPtFsb
78fhVgfFgjzWBkTrzGD4kCbIVTFUD1MkzmRCOgp4QEBx95nArsVOgZrlkkrmKBsF
UV+UFaEB4hfRDQPQLME82q3Dr2+VHzDwTYCpGOOIzGHg+ulFya9LUxcy3/S/bRBn
L1jumCoWuntWTjWVaevXxoDShYX2RF/coD0fHRbQsL8oYtrWIP9JGoXJaeyxf8y2
7TpeHHhnza/RzDDDnx6pIlqHBGVKmOidn9yyaBNJjvIx0mnKiEXdSNDGgid3ozIg
l+tBHUkp
=Z45h
-END PGP SIGNATURE-

Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure

[Russ Allbery]

gregor herrmann  writes:
> On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote:
>> gregor herrmann  writes:

>>> According to https://github.com/rra/docknot/issues/6 fixed upstream
>>> (in git, not released yet).

>> Yeah, I'm sorry about the delay here.  I'm trying to get a new release
>> out shortly and if I fail at that I'll patch this in the Debian
>> package.  Please feel free to move forward with Perl and don't block on
>> this package; this is totally my own (known) problem.

> in the light of #1055955 (perl5.38 transition bug) -- do you think
> you can upload a fixed version (the current version plus a patch or a
> new release) in the near future, or should I upload an NMU with your
> upstream commit or should we just ignore docknot for the transition …
> or something else? :)

I've uploaded a fix; I'm so sorry for the absurd delay.  I'd meant to get
to this months ago and kept not making time to finish it.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

[陳侃如]

Package: tex-common
Version: 6.18
Followup-For: Bug #1051243

Dear Maintainer,

This issue is still present in current Sid.

Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.fhjAW06q
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

Detail logs attached. The tail shows

fmtutil [ERROR]: running `luatex -ini   -jobname=luatex -progname=luatex 
luatex.ini 

Versions of packages texlive-base suggests:
pn  ghostscript 
pn  gv | postscript-viewer  
ii  mupdf [pdf-viewer]  1.23.6+ds1-1~1.gbp47c8fa
pn  perl-tk 
pn  xzdec   

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-12
ii  libcairo2   1.18.0-1
ii  libfontconfig1  2.14.2-6
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-6
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-4
ii  libkpathsea62023.20230311.66589-7
ii  libmpfr64.2.1-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-2
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-7
ii  libstdc++6  13.2.0-6
ii  libsynctex2 2023.20230311.66589-7
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-7
ii  libx11-62:1.8.7-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.17-1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-9
ii  t1utils 1.41-4
ii  zlib1g  1:1.3.dfsg-2

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2023.20231007-1

Versions of packages texlive-binaries suggests:
pn  hintview   
pn  texlive-binaries-sse2  

-- no debconf information


fmtutil.aZA9kPIx.gz
Description: application/gzip

Bug#1032104:

[Timothy Pearson]

Root cause found, merge request here: 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/917

Bug#1056211: ITP: dhtd -- standalone DHT for mainline BitTorrent

[Moritz Warning]

Package: wnpp
Severity: wishlist
Owner: Moritz Warning 

* Package name: dhtd
  Version : 0.2.2
  Upstream Contact: Moritz Warning 
* URL : https://github.com/mwarning/dhtd
* License : MIT license
  Programming Lang: C
  Description : Standalone Distributed Hash Table (DHT)

  DHTd takes part in the DHT network of the mainline BitTorrent network.
  It can serve as a bootstrap node but also allows to announce and
  query hashes to serve as a P2P DNS like system, but without verification.
  A command line interface dhtd-ctl allows an easy interaction from the 
terminal.

I am looking for someone to maintain this package. Since the package has
minimal dependencies and is feature complete, minimal future work is to be 
expected.

Bug#1056210: luatex panics with zlib 1.3

[François Rozet]

Package: texlive-binaries
Version: 2023.20230311.66589-7

The luatex binary shipped with texlive is not compatible with zlib 1.3 
(zlib1g 1:1.3.dfsg-2 on Debian Sid).


$ luatex
PANIC: unprotected error in call to Lua API (zlib library version does 
not match - header: 1.2.13, library: 1.3)

Aborted
$

This bug has also been reported on the Arch Linux forum:

https://bugs.archlinux.org/task/79470

I am using Debian GNU/Linux trixie/sid (up to date) with the Linux 
6.5.0-4-amd64 kernel.


Regards,
François Rozet.

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Adrian Bunk]

On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote:
> Control: severity -1 important
> Control: block 1056183 by -1
> 
> On 11/18/23 20:18, Samuel Thibault wrote:
> 
> Hi Samuel,
> 
> > 
> > nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild 
> > against new zlib"
> > 
> 
> Thanks for filing the NMU bug.
> 
> > So a binnmu of the texlive-bin source package seems needed on all archs
> > to fix installing texlive-binaries.
> > 
> 
> I tested if recompiling solves the issue and it does. Hence I bump severity
> of the NMU bug the get a solution ASAP.

I don't see how a binNMU would solve the problem.

A proper fix would be either to:
1. patch the version check out of texlive-bin (preferred), or
2. ensure texlive-bin has package dependencies that match this runtime check

After a binNMU the migration of zlib to testing would still be 
blocked forever by the autopkgtest of packages like asymptote that
will continue to test with zlib/unstable and texlive-bin/testing.

And it also might affects users directly, without proper dependencies 
e.g. a bookworm -> trixie upgrade might end up with the following order
(among many other things happening during the upgrade):
1. zlib gets upgraded
2. the tex-common trigger runs
3. texlive-bin gets upgraded
If this is permitted by the dependencies, then step 2 must not fail.

> Hilmar

cu
Adrian

Bug#1054621: lutris: new dependencies

[Reiner Herrmann]

Control: forwarded -1 https://github.com/lutris/lutris/issues/5138

I have forwarded the issue upstream. I think they were accidentally
added to Depends, as upstream is probably not that familiar with Debian
packaging.
According to policy's description of Depends and Recommends they would
be better suited as Recommends.

Kind regards,
  Reiner

Bug#1056070: hibiscus: Please package new version

[Martin Dosch]

Thank you both!


signature.asc
Description: PGP signature

Bug#888025: gpgsm: UI asks insane, unanswerable trust questions

[Brendon Higgins]

I'm using kmail and am getting hit by this. It seems to be someone has sent me 
an email signed with some weird (internal?) certificate. What can I as a user 
even do if I *don't* trust the certificate? There is no "No, and please stop 
asking" option...

Best,
Brendon

Bug#1056209: ITP: authselect -- Configures authentication and identity sources from supported profiles

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: authselect
  Version : 1.4.3
  Upstream Contact: Pavel Březina .
* URL : https://github.com/authselect/authselect/
* License : GPL-3.0
  Programming Lang: C
  Description : Authselect is a tool to select system authentication and 
identity sources from a list of supported profiles

Authselect is designed to be a replacement for authconfig but it takes
a different approach to configure the system. Instead of letting
the administrator build the PAM stack with a tool (which may potentially
end up with a broken configuration), it would ship several tested stacks
(profiles) that solve a use-case and are well tested and supported.
At the same time, some obsolete features of authconfig are not
supported by authselect.


-- 
Regards
Sudip

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Hilmar Preuße]

Control: severity -1 important
Control: block 1056183 by -1

On 11/18/23 20:18, Samuel Thibault wrote:

Hi Samuel,



nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against new 
zlib"



Thanks for filing the NMU bug.


So a binnmu of the texlive-bin source package seems needed on all archs
to fix installing texlive-binaries.



I tested if recompiling solves the issue and it does. Hence I bump 
severity of the NMU bug the get a solution ASAP.


Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Just for the records:

There's now a fix for this at:
  https://github.com/systemd/systemd/pull/30074
(which I confirmed working)

>From my side it's not super important to have that cherry picked.
I'd hope it might still make it into 255, so for that I can easily wait
and it saves you guys some work!

Thanks,
Chris.

Bug#1056070: hibiscus: Please package new version

[tony mancill]

On Sat, Nov 18, 2023 at 09:26:13PM +0100, Jochen Sprickerhof wrote:
> Hi Tony,
> 
> * tony mancill  [2023-11-18 12:18]:
> > Since this is a team-maintained package, I prepared an update; no
> > packaging changes required.   I have uploaded it to DELAYED-5 out of
> > deference to Jochen, who has performed all of the uploads prior to now.
> > 
> > Jochen, let me know if you would like me to dcut my upload.  Otherwise,
> > I will the push the updated branches to the packaging repo.
> 
> Thanks for working on it! Did you also update hbci4java to the version used
> by hibiscus? If yes, then feel free change the delay to 0. Otherwise I can
> take care of both in the next days.

Hi Jochen,

Thank you for the pointer.  No, I didn't update hbci4java.  My upload has been 
canceled:

> > cancel hibiscus_2.10.15+dfsg-1_source.changes
> Files removed from 5-day: hibiscus_2.10.15+dfsg-1_source.changes 
> hibiscus_2.10.15+dfsg-1.dsc hibiscus_2.10.15+dfsg.orig.tar.xz 
> hibiscus_2.10.15+dfsg-1.debian.tar.xz hibiscus_2.10.15+dfsg-1_amd64.buildinfo

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1056208: mediathekview: Doesn't work properly in sway (wayland)

[Martin Dosch]

Package: mediathekview
Version: 13.2.1+ds-1
Severity: normal

Dear Maintainer,

when I started mediathekview the display was totally broken (see 
attached screenshot) when using sway (wayland).
But I found a workaround in a german forum: 
https://forum.mediathekview.de/topic/3384/anzeige-probleme-unter-linux-mit-wayland-sway

By opening it via `$ _JAVA_AWT_WM_NONREPARENTING=1 mediathekview` it 
works well. If this has no negative side effect for X users you might 
consider adding this to the .desktop starter to make mediathekview work 
also with sway.

Best regards,
Martin

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

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

Versions of packages mediathekview depends on:
ii  default-jre [java9-runtime] 2:1.17-75
ii  java-wrappers   0.4
ii  libcommons-compress-java1.24.0-1
ii  libcommons-configuration2-java  2.8.0-2
ii  libcommons-dbcp2-java   2.10.0-1
ii  libcommons-lang3-java   3.13.0-1
ii  libcommons-pool2-java   2.11.1-1
ii  libcontrolsfx-java  11.0.0-1
ii  libguava-java   32.0.1-1
ii  libjackson2-core-java   2.14.1-1
ii  libjchart2d-java3.2.2+dfsg2-3
ii  libjiconfont-font-awesome-java  4.7.0.1-1
ii  libjiconfont-java   1.0.0-2
ii  libjiconfont-swing-java 1.0.1-2
ii  libjide-oss-java3.7.6+dfsg-2
ii  liblog4j2-java  2.19.0-2
ii  libmbassador-java   1.3.1-2
ii  libmiglayout-java   11.1+ds-1
ii  libokhttp-java  3.13.1-4
ii  libopenjfx-java 11.0.11+1-3.1
ii  libslf4j-java   1.7.32-1
ii  libswingx-java  1:1.6.2-4
ii  libxz-java  1.9-1
ii  openjdk-17-jre [java9-runtime]  17.0.9+9-2

Versions of packages mediathekview recommends:
ii  flvstreamer  2.1c1-1.1
ii  mplayer  2:1.5+svn38423-2+b1
ii  mpv  0.36.0-1+b1

Versions of packages mediathekview suggests:
ii  ffmpeg  7:6.0-9+b1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1053741: systemd-journal-remote: systemd-joural-uploading killed by watchdog every 3 minutes

[Michael Biebl]

Control: tags -1 moreinfo
On Tue, 31 Oct 2023 10:36:36 +0100 Michael Biebl  wrote:

Am 10.10.23 um 04:22 schrieb Tom Cameron:

> I have also looked at the systemd issue tracker on github, and while
> there has historically be several issues with journal-upload, none of
> them seem to have been reported recently.

Could you please raise this upstream and report back with the issue number?



Any updates here?
Without further information, this issue is not really actionable.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056166: systemd-homed: `passwd` fails

[Michael Biebl]

Control: found -1 254.5-1

This is not a regression of v255, as v254 shows the same behaviour.

Marking accordingly.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056207: ITP: wcm -- Wayfire Config Manager

[Tianyu Chen]

Package: wnpp
Severity: wishlist
Owner: Tianyu Chen 
X-Debbugs-Cc: debian-de...@lists.debian.org, billchenchina2...@gmail.com

* Package name: wcm
  Version : 0.8.0
  Upstream Contact: Scott Moreau 
* URL : https://github.com/WayfireWM/wcm/
* License : MIT
  Programming Lang: C++
  Description : Wayfire Config Manager

Wayfire Config Manager is a Gtk3 application to configure wayfire. It writes
the config file that wayfire reads to update option values.

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Dirk Eddelbuettel]

I will not engage any more with debian-r. But this is now at the BTS so a
clarification may be in order. This started as I had sent an email as a
heads-up to fellow maintainers (via that mostly pointless list) informing
them that their packages would exhibit a bug following a bug in package
Matrix.

Now, net-net all I got out of this is a 'severity: serious' bug against my
own package, and a beyond-stupid situation (sadly also not a first time)
where the affected maintainer now acts like a three-year and refuses to
update his known-broken packages.

And I repeact that it was upstream (for Matrix) who asked (publically, on a R
list) for a rebuild.

Going forward, I will simply not send such courtesy emails. Life is too
short. I will let just those follow maintainers continue to waste the time of
the release managers by trying random combination of packages and then acting
surprised that breakage happens.

CRAN is well known to work exceedingly well at '@HEAD' (occasional bugs among
what are now over 20k packages notwithstanding). But some people refuse to
understand or acknowledge that and enjoy fighting fight pointless fights.  We
can all choose our own adventure, but that particular one is of no interest
to me.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1056206: graphite-web: saving graphs in dashboard is broken (only in stable version 1.1.8-2)

[Hermann Lauer]

Package: graphite-web
Version: 1.1.8-2
Severity: normal
Tags: patch

Dear Maintainer,

graphite-web in bookworm (1.1.8-2) does not allow saving dashboards due to 
missing function
htmlEncode from dashboard.js. Workaround is to install 1.1.10-1 from testing, 
where
dashboard.js contains the definition of htmlEncode.

As a note to others: js is cached in the browser for quite some time, so the
showing up of the bug was delayed

Please consider the applied patch for bookwoorm which simply adds the missing 
function.

Thanks and greetings
  Hermann

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

Kernel: Linux 6.5.2 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_TEST
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages graphite-web depends on:
ii  adduser 3.134
ii  python3 3.11.2-1+b1
ii  python3-cairo   1.20.1-5+b1
ii  python3-cairocffi   1.4.0-1
ii  python3-django  3:3.2.19-1+deb12u1
ii  python3-django-tagging  1:0.5.0-4
ii  python3-pyparsing   3.0.9-1
ii  python3-simplejson  3.18.3-1
ii  python3-six 1.16.0-4
ii  python3-tz  2022.7.1-4
ii  python3-urllib3 1.26.12-1
ii  python3-whisper 1.1.4-2.2

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
pn  graphite-carbon  
pn  libapache2-mod-wsgi-py3  
pn  python3-ldap 
pn  python3-memcache 
pn  python3-mysqldb  

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- no debconf information
--- gw/usr/share/graphite-web/static/js/dashboard.js2023-03-17 
14:24:47.0 +0100
+++ gw10/usr/share/graphite-web/static/js/dashboard.js  2023-09-21 
16:39:16.0 +0200
@@ -157,6 +157,12 @@
   return false;
 }
 
+function htmlEncode(input) {
+  return input.replace(/[^a-zA-Z0-9 ]/g, function (chr) {
+return 

Bug#897939: network-manager-strongswan: clean up legacy conffiles

[Michael Biebl]

On Sat, 05 May 2018 01:10:42 +0200 Christoph Anton Mitterer 
 wrote:

btw: I'd guess it's not just enough to clean up the conffile itself
with the appropriate tools, but one likely needs to manually rmdir:
/etc/NetworkManager/VPN
as this is neither a conffile (as it's a dir) nor owned by any other
package (at least on my system)... so dpkg will not remember about it
and it would remain forever.


I've made the directory /etc/NetworkManager/VPN owned by the 
network-manager package in the mean time and will keep this at least for 
trixie.


I.e., you simply need to deal with the removal (and cleanup) of the 
conffile  in network-manager-strongswan.


At some later point, once no package ships any conffiles in 
/etc/NetworkManager/VPN anymore, I might consider dropping this 
directory from the network-manager again and leave the cleanup of the 
directory to dpkg.



Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

[Gunnar Hjalmarsson]

Control: affects -1 ibus-table
Control: severity -1 serious
X-Debbugs-Cc: debian-input-met...@lists.debian.org

This problem prevents the ibus-table package, where tex-common is 
indirectly in Build-Depends, from building in unstable.


https://buildd.debian.org/status/logs.php?pkg=ibus-table=1.17.4-2=all

I haven't been able to reproduce the failure locally, and ibus-table 
builds successfully in Ubuntu:


https://launchpad.net/ubuntu/+source/ibus-table/1.17.4-1

I'm aware of the case where fmtutil failed under a broken locale, but 
that does reasonably not apply when building for unstable.


debian/postinst includes this line:

FMTUTIL="fmtutil --sys --strict 
--no-error-if-no-engine=luajittex,mfluajit,luajithbtex"


One thought is to replace "--strict" with "--no-strict" as a workaround 
while awaiting a proper fix. That idea is untested, though.


--
Cheers,
Gunnar Hjalmarsson

Bug#1056070: hibiscus: Please package new version

[Jochen Sprickerhof]

Hi Tony,

* tony mancill  [2023-11-18 12:18]:

Since this is a team-maintained package, I prepared an update; no
packaging changes required.   I have uploaded it to DELAYED-5 out of
deference to Jochen, who has performed all of the uploads prior to now.

Jochen, let me know if you would like me to dcut my upload.  Otherwise,
I will the push the updated branches to the packaging repo.


Thanks for working on it! Did you also update hbci4java to the version 
used by hibiscus? If yes, then feel free change the delay to 0. 
Otherwise I can take care of both in the next days.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1056141: nvenc encoder not available after installing libnvidia-encode1 and enabling ffnvcodec

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-11-17 11:20:11 -0500, Brian Bostwick wrote:
> Package: ffmpeg
> Version: 7:6.1-2
> 
> Hi in Trixie, using nvidia-driver 525.125.06-2, libnvidia-encode1
> 525.125.06-2, and ffmpeg 7:6.1-2, I can't seem to get the nvenc codec
> built into ffmpeg.
> 
> $ ffmpeg -codecs | grep 264
> H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m
> h264_qsv h264_cuvid ) (encoders: libx264 libx264rgb h264_omx h264_qsv
> h264_v4l2m2m h264_vaapi )
> 
> These are the additional enable flags I added to the debian/rules file:
> 
> --enable-nonfree \
> --enable-cuda-llvm \
> --enable-ffnvcodec
> 
> Full build configuration:
> 
>   configuration:
> --prefix=/usr
> --extra-version=9
> --toolchain=hardened
> --libdir=/usr/lib/x86_64-linux-gnu
> --incdir=/usr/include/x86_64-linux-gnu
> --arch=amd64
> --enable-gpl
> --disable-stripping
> --enable-gnutls
> --enable-ladspa
> --enable-libaom
> --enable-libass
> --enable-libbluray
> --enable-libbs2b
> --enable-libcaca
> --enable-libcdio
> --enable-libcodec2
> --enable-libdav1d
> --enable-libflite
> --enable-libfontconfig
> --enable-libfreetype
> --enable-libfribidi
> --enable-libglslang
> --enable-libgme
> --enable-libgsm
> --enable-libjack
> --enable-libmp3lame
> --enable-libmysofa
> --enable-libopenjpeg
> --enable-libopenmpt
> --enable-libopus
> --enable-libpulse
> --enable-librabbitmq
> --enable-librist
> --enable-librubberband
> --enable-libshine
> --enable-libsnappy
> --enable-libsoxr
> --enable-libspeex
> --enable-libsrt
> --enable-libssh
> --enable-libtheora
> --enable-libtwolame
> --enable-libvidstab
> --enable-libvorbis
> --enable-libvpx
> --enable-libwebp
> --enable-libx265
> --enable-libxml2
> --enable-libxvid
> --enable-libzimg
> --enable-libzmq
> --enable-libzvbi
> --enable-lv2
> --enable-omx
> --enable-openal
> --enable-opencl
> --enable-opengl
> --enable-sdl2
> --enable-nonfree
> --enable-cuda-llvm
> --enable-ffnvcodec
> --disable-sndio
> --enable-libjxl
> --enable-pocketsphinx
> --enable-librsvg
> --enable-libvpl
> --disable-libmfx
> --enable-libdc1394
> --enable-libdrm
> --enable-libiec61883
> --enable-chromaprint
> --enable-frei0r
> --enable-libsvtav1
> --enable-libx264
> --enable-libplacebo
> --enable-librav1e
> --enable-shared
> 
> After being built I just installed the ffmpeg and libavcodec debs.
> 
> $ dpkg -i': sudo dpkg -i ffmpeg_6.0-9_amd64.deb
> libavcodec60_6.0-9_amd64.deb libavcodec-extra*
> 
> I originally had the proprietary driver installed via the vendor's
> script, but it has since been removed.
> 
> My goal is to have nvenc appear as an option in OBS, which depends on
> ffmpeg to have the codec available.

It is, though:

$ ffmpeg -codecs | grep nvenc
ffmpeg version 6.1-2 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13 (Debian 13.2.0-6)
  configuration: --prefix=/usr --extra-version=2 --toolchain=hardened 
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu 
--arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa 
--enable-libaom --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d 
--enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm 
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq 
--enable-librist --enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh 
--enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis 
--enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 
--enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 
--enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 
--disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg 
--enable-libvpl --disable-libmfx --enable-libdc1394 --enable-libdrm 
--enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libsvtav1 
--enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared
  libavutil  58. 29.100 / 58. 29.100
  libavcodec 60. 31.102 / 60. 31.102
  libavformat60. 16.100 / 60. 16.100
  libavdevice60.  3.100 / 60.  3.100
  libavfilter 9. 12.100 /  9. 12.100
  libswscale  7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc57.  3.100 / 57.  3.100
 DEV.L. av1  Alliance for Open Media AV1 (decoders: libdav1d 
libaom-av1 av1 av1_cuvid av1_qsv) (encoders: libaom-av1 librav1e libsvtav1 

Bug#1056070: hibiscus: Please package new version

[tony mancill]

On Thu, Nov 16, 2023 at 06:49:11PM +0100, Martin Dosch wrote:
> Package: hibiscus
> Version: 2.10.12+dfsg-1
> Severity: wishlist
> 
> Dear Jochen,
> 
> could you please consider updating hibiscus to the current upstream 
> version?
> 
> I checked out the git repo from salsa and locally built 2.10.15 without 
> any issue so it should be easy to update the version in the debian 
> repos.

Hi,

Since this is a team-maintained package, I prepared an update; no
packaging changes required.   I have uploaded it to DELAYED-5 out of
deference to Jochen, who has performed all of the uploads prior to now.

Jochen, let me know if you would like me to dcut my upload.  Otherwise,
I will the push the updated branches to the packaging repo.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Andreas Tille]

Am Fri, Nov 17, 2023 at 12:52:29PM -0600 schrieb Dirk Eddelbuettel:
> | Anyway. Now that you made it a bug I let you drive this.  Upstream just made
> | an unrelated bugfix Matrix 1.6-3 which I just sent to unstable.
> 
> There are two known failures left which the maintainer(s) do not want to fix.

Again: Please stop blaming other maintainers for not doing what you
want.  We need some means to follow ABI changes.  In Debian we could use
something like r-matrix-abi-VERSION.  As long as you not discussing this
in a qualified wording I will not upload any package that is affected
since I see my time wasted to discuss this in the next ABI change again
and again.

You were teached by Nilesh[1] about the right way to go (BTW, thanks for
scaring away Nilesh[2].)
 
> As I have fixed my dependents of package Matrix, I continue to find it unfair
> that I am being to an open bug requiring fixes via builds in other packages
> that are not mine. So I guess this bug will stay open 'forever' or
> until those packages get normal routine updates.

You were also told that even this statement is wrong.[3]

Finger pointing to others and claiming you can't do anything is what
I call unfair.

Kind regards
Andreas.

[1] https://lists.debian.org/debian-r/2023/11/msg00049.html
[2] https://lists.debian.org/debian-r/2023/11/msg00054.html
[3] https://lists.debian.org/debian-r/2023/11/msg00044.html

-- 
http://fam-tille.de

Bug#1056143: libeval-context-perl: t/012_safe.t fails

[Niko Tyni]

On Fri, Nov 17, 2023 at 06:28:30PM +0100, gregor herrmann wrote:
> Source: libeval-context-perl
> Version: 0.09.11-5
> Severity: serious
> Tags: ftbfs trixie sid
> Justification: fails to build from source

> As noted by ci.debian.net, t/012_safe.t started to fail recently:

This seems to have been broken by libdata-treedumper-perl_0.41-1.
Downgrading to 0.40-5 makes it go away.
-- 
Niko

Bug#1056205: open-vm-tools containerInfo plugin is being installed in incorrect directory

[John Wolfe]

Package: open-vm-tools
Version: 2:12.3.x

open-vm-tools containerInfo plugin is being installed in incorrect directory

VMware's internal builds and testing of upcoming versions of open-vm-tools is 
based on the
debian packaging source seen at

 https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/


The debian/rules script contains the following related to the positioning of 
the containerInfo plugin

   # moving open-vm-tools-containerinfo files
   mkdir -p 
debian/open-vm-tools-containerinfo/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugin/containerinfo/
   mv 
debian/open-vm-tools/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugins/vmsvc/libcontainerInfo.so
 
debian/open-vm-tools-containerinfo/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugins/containerinfo/

The optional containerInfo plugin, if installed, will be run by the vmtoolsd 
service.
The libcontainerInfo.so plugin should be installed in the 
open-vm-tools/plugins/vmsvc directory as is the libserviceDiscovery.so plugin.

Please update the debian/rules file with:

   # moving open-vm-tools-containerinfo files
   mkdir -p 
debian/open-vm-tools-containerinfo/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugi/vmsvc/
   mv 
debian/open-vm-tools/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugins/vmsv/libcontainerInfo.so
 
debian/open-vm-tools-containerinfo/usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools/plugins/vmsvc/

Have filed BZ with Ubuntu 
at:https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/2043897

Thanks,
John Wolfe

Bug#1055007: network-manager: NetworkManager fails to manage pppoa adsl connection

[Michael Biebl]

Hi Denis

On Sun, 29 Oct 2023 10:36:03 +0100 Denis Prost  
wrote:




After upgrade from Debian 11 to Debian 12. pppoa management, which
worked in Debian 11 with network-manager 1.30.6-1+deb11u1, does not work
anymore with Debian 12 network-manager 1.42.4-1


Can you raise this upstream please at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thanks,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054310: Please install helper binaries into /usr/libexec

[Michael Biebl]

Am 26.10.23 um 18:07 schrieb Harald Dunkel:

Hi Michael,

thank you for the patch and your input to various bug reports about
network-manager-strongswan. I have prepared a new version on Salsa

 https://salsa.debian.org/debian/network-manager-strongswan

(not verified yet). Would you mind to take a look, esp. at the
maintscript? I haven't used this feature before.


I do not see any changes in master or a dedicated MR or branch.
Have you not yet pushed your changes?


Are there some special actions necessary about the /etc/NetworkManager/VPN
directory? AFAIU the maintscript cannot remove directories.


Correct, there is no automatic cleanup of that directory.
Personally, I wouldn't bother with cleaning that up manually.
Maybe I'll consider making this directory owned by the network-manager 
package, so it would be cleaned up by dpkg when the package is removed.


From a quick glance at debian/rules, you might consider dropping the 
obsolete configure switch --without-libnm-glib, this is no longer necessary:




 NetworkManager-strongswan-1.6.0
---

- Support for GTK 4
- Removed libnm-glib compatibility






OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Samuel Thibault]

Samuel Thibault, le sam. 18 nov. 2023 20:18:01 +0100, a ecrit:
> nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against 
> new zlib"

I forgot to mention that this should of course be made dep-wait
zlib1g-dev (>= 1:1.3.dfsg-1) 



> Hello,
> 
> Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
> texlive-base fails:
> 
> fmtutil failed. Output has been stored in
> /tmp/fmtutil.ndDMEWN5
> 
> [...]
> 
> fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini' 
> ...
> PANIC: unprotected error in call to Lua API (zlib library version does not 
> match - header: 1.2.13, library: 1.3)
> Aborted
> 
> And indeed texlive-bin checks the zlib version:
> 
> https://codesearch.debian.net/search?q=zlib+library+version+does+not+match=en
> 
> texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c
> 
> if (strncmp(version, ZLIB_VERSION, 4))
> {
> lua_pushfstring(L, "zlib library version does not match - header: %s, 
> library: %s", ZLIB_VERSION, version);
> lua_error(L);
> }
> 
> So a binnmu of the texlive-bin source package seems needed on all archs
> to fix installing texlive-binaries.
> 
> Samuel

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Samuel Thibault]

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

nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against 
new zlib"

Hello,

Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
texlive-base fails:

fmtutil failed. Output has been stored in
/tmp/fmtutil.ndDMEWN5

[...]

fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
Aborted

And indeed texlive-bin checks the zlib version:

https://codesearch.debian.net/search?q=zlib+library+version+does+not+match=en

texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c

if (strncmp(version, ZLIB_VERSION, 4))
{
lua_pushfstring(L, "zlib library version does not match - header: %s, 
library: %s", ZLIB_VERSION, version);
lua_error(L);
}

So a binnmu of the texlive-bin source package seems needed on all archs
to fix installing texlive-binaries.

Samuel

Bug#1056203: fonts-wine breaks font rendering

[Pat Suwalski]

Package: fonts-wine
Version: 8.0.1~repack-2

I just did a dist upgrade and got the change that moves the wine fonts 
into the global /usr/share/fonts path where all programs use them. This 
appears to be in response to issue #883973.


Please revert this change. These are not the real Microsoft fonts, but 
rather similar fonts created by the Wine folk. Tahoma, in particular, 
doesn't render nicely at all. It has very bad kerning and does not 
anti-alias.


Tahoma is very frequently referenced in emails and documents, and this 
change makes it really hard to read those texts, where previously there 
was a good substitution.


The correct way to install Microsoft fonts is mscorettfonts. Using 
substitutes is okay in Wine, but shouldn't affect the experience outside 
of Wine.


--Pat

Bug#1056202: src:benchmark: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Source: benchmark
Version: 1.7.1-1
Severity: serious
Control: close -1 1.8.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056201: etherape: [L10N,DE] etherape_0.9.20-2: german translation

[Christoph Brinkhaus]

Package: etherape
Version: 0.9.20-2
Severity: wishlist

Dear Maintainer,

please find attached the po file with the german translation.
It is an update to the current po template.
Please consider to apply it to the package.

Thank you very much!

Kind regards,
Christoph Brinkhaus

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

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

Versions of packages etherape depends on:
ii  etherape-data0.9.20-2
ii  libc-ares2   1.18.1-3
ii  libc62.36-9+deb12u3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgoocanvas-2.0-9   2.0.4-1+b1
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpcap0.8   1.10.3-1
ii  libpopt0 1.19+dfsg-1

etherape recommends no packages.

etherape suggests no packages.
# Translation of etherape to German
# Copyright (C) 2000 Juan Toledo .
# This file is distributed under the same license as the etherape package.
# Chris Leick , 2009-2017
# Christoph Brinkhaus , 2023
#
msgid ""
msgstr ""
"Project-Id-Version: etherape 0.9.20\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-05-16 17:05+0200\n"
"PO-Revision-Date: 2023-11-14 15:50+0100\n"
"Last-Translator: Christoph Brinkhaus \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

# https://de.wikipedia.org/wiki/Glade_(Programmierwerkzeug)
#: src/appdata.c:83
#, c-format
msgid "Could not load interface file '%s'!: %s"
msgstr "Die Schnittstellendatei konnte nicht geladen werden: %s"

#: src/datastructs.c:385
#, c-format
msgid "%s protocol not supported"
msgstr "Protokoll %s nicht unterstützt"

#: src/diagram.c:254
#, c-format
msgid ""
"Nodes: %d (on canvas: %d, shown: %u), Links: %d, Conversations: %ld, names "
"%ld, protocols %ld. Total Packets seen: %lu (in memory: %ld, on list %ld). "
"IP cache entries %ld. Canvas objs: %ld. Refreshed: %u ms"
msgstr ""
"Knoten: %d (auf Zeichenfläche: %d, angezeigt: %u), Links: %d, Dialoge:  "
"%ld, Namen %ld, Protokolle %ld. Gesamt gesehene Pakete: %lu (im Speicher: "
"%ld, auf der Liste %ld). IP-Zwischenspeichereinträge %ld. "
"Zeichenflächenobjekte: %ld. Aktualisiert: %u ms"

#: src/diagram.c:618
msgid "(Capture statistics unavailable in offline mode.)"
msgstr "(Statistiken erfassen, die im Offline-Modus nicht verfügbar sind)"

#: src/diagram.c:673
#, c-format
msgid "Bogus statspos_t (%d) pref.pcap_stats_pos"
msgstr "gefälschte statspos_t (%d) pref.pcap_stats_pos"

#: src/diagram.c:700
#, c-format
msgid "SIGUSR1 received: exporting to %s"
msgstr "SIGUSR1 empfangen: Export nach %s"

#: src/diagram.c:976
msgid "Canvas node null"
msgstr "Zeichenflächenknoten null"

#: src/diagram.c:985
#, c-format
msgid "Creating canvas_node: %s. Number of nodes %d"
msgstr "canvas_node wird erzeugt: %s. Anzahl der Knoten %d"

#: src/diagram.c:1049
msgid "Unknown value or node_size_variable"
msgstr "Wert oder node_size_variable unbekannt"

#: src/diagram.c:1686
msgid "Unknown value for link_size_variable"
msgstr "Unbekannter Wert für link_size_variable"

#: src/diagram.c:1732
#, c-format
msgid "Link main protocol: %s"
msgstr "Link-Hauptprotokoll: %s"

#: src/diagram.c:1734
msgid "Link main protocol: unknown"
msgstr "Link-Hauptprotokoll: unbekannt"

#: src/diagram.c:1797
msgid ""
"'recv': packets received; 'drop': packets dropped by OS buffering; 'ifdrop': "
"packets dropped by interface or driver."
msgstr ""
"»recv«: Pakete empfangen; »drop«: Pakete durch Betriebssystempufferung "
"verworfen; »ifdrop« Pakete durch Schnittstelle oder Treiber verworfen."

#: src/info_windows.c:110 src/info_windows.c:794 src/info_windows.c:800
#, c-format
msgid "We could not load the interface! (%s)"
msgstr "Die Schnittstelle konnte nicht geladen werden. (%s)"

#: src/info_windows.c:116
#, c-format
msgid "Cannot create widget %s from file %s!"
msgstr "Kann das Widget %s nicht aus der Datei %s erzeugen!"

#: src/info_windows.c:200
msgid "No prot_name in on_prot_info_delete_event"
msgstr "Kein prot_name in on_prot_info_delete_event"

#: src/info_windows.c:206
msgid "No prot_info_window in on_prot_info_delete_event"
msgstr "Kein prot_info_window in on_prot_info_delete_event"

#: src/info_windows.c:438 src/pref_dialog.c:486
msgid "Protocol"
msgstr "Protokoll"

#: src/info_windows.c:439
msgid "Port"
msgstr "Port"

#: src/info_windows.c:440 src/node_windows.c:224
msgid "Inst Traffic"
msgstr "Mom Verkehr"

#: src/info_windows.c:441 src/node_windows.c:225
msgid "Accum 

Bug#1056200: libstring-binary-interpolation-perl: broken package description

[Daniele Forsi]

Package: libstring-binary-interpolation-perl
Severity: important
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the example in the description of this package reads:
 my $binary = "ABCE";
which doesn't explain how to use ,thi smodule, while the original example 
contains:
 my $binary = "ABC${b01000100}E";

greetings,
Daniele

Bug#1056199: src:procdump: fails to migrate to testing for too long: FTBFS on armel, mips64el and ppc64el

[Paul Gevers]

Source: procdump
Version: 1.2-4
Severity: serious
Control: close -1 2.2-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:procdump has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel, mips64el, ppc64el, riscv64, loogn64, powerpc and ppc64 
(only the first 3 are blocking).


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056198: src:setuptools: build depends on dh-python but build conflicts with python3-setuptools

[Paul Gevers]

Source: setuptools
Version: 68.1.2-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package: it Build-Depends 
on dh-python, which Depends on python3-setuptools, but src:setuptools 
Build-Conflicts with python3-setuptools.


I notified tumbleweed on IRC and he pinged doko. Hence, I'm filing this 
bug against setuptools.


Paul

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056197: src:vim: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: vim
Version: 2:9.0.1894-1
Severity: serious
Control: close -1 2:9.0.2103-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056196: python3-onelogin-saml2: Please package new version 1.16.0

[Santiago Vila]

Package: src:python3-onelogin-saml2
Version: 1.12.0-3
Severity: important

I've recently fixed a build error related to expired certificates
used in the tests. However, I see that the current package in unstable
will FTBFS in the future:

https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python3-onelogin-saml2_1.12.0-3.rbuild.log.gz

This is from the build log:

Current time: Fri Dec 20 10:52:08 -12 2024

and I can reproduce the error by using the "libfaketime" package
in this way:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="+1y" 
dpkg-buildpackage -uc -us -b

So, before bothering upstream and telling them that the tests still fail,
I'd like to see a more recent version in unstable, then I will be able to see
if there are more things to backport for stable or not.

Thanks.

Bug#1052173: fixed upstream

[dann frazier]

tag 1052173 + patch
tag 1052173 + fixed-upstream
thanks

I found that this problem does not occur with latest upstream, so I used
bisection to identify the fix. The problem no longer occurs after
applying this fix to the existing package:

commit 124efd03f3cb9b1df819134eb7cb6683497be9b1
Author: Richard Hughes 
Date:   Wed Apr 13 14:16:02 2022 +0100

Fix a double free spotted by Coverity

Bug#1055891: transition: gdal

[Sebastiaan Couwenberg]

cmake on mips64el will also need a higher priority to unblock the 
rebuilds of several rdeps.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1056195: ITP: bashacks -- collection of useful bash functions for programmers

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: bashacks
  Version : 1.5.0
  Upstream Contact: Fernando Merces 
* URL : https://github.com/merces/bashacks
* License : GPL-3.0
  Programming Lang: (Shell Script)
  Description : collection of useful bash functions for programmers

  bashacks is an open source project under the GPL license that provides
  a set of Bash functions.
  .
  It is designed to be useful for programmers, security analysts, and
  general users who need to perform low-level operations.
  .
  The main goal of the project is to simplify tasks that would normally
  require several lines of code in Bash.
  .
  While "bashacks" doesn't contain anything entirely new, it does offer the
  advantage of providing shorter commands to perform common tasks that would
  normally be more verbose.

Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm

[Nicolas Boulenguez]

Have you seen this?
https://lists.debian.org/debian-devel/2023/08/

> I've been toying with the idea of setting up a Debian-wide system to nag
> maintainers about out-of-date, inconsistent or plain broken packaging git
> repos. This logic to diff the dsc against one built from unstable could be
> part of that effort.

Some will probably argue that you are trying to influence their
priorities, that non-git .dsc formats are obsolete, and so on.

Moreover, even if you guess the git tag and whether patches are
applied, there is probably no deterministic way to tell if .gitignore
matches the workflow of upstream, Debian or both.

For the avoidance of doubt, I would appreciate such alerts, a Debian
policy about tags and patches, and that .gitignore is only allowed for
self defense...

> Even with git what may be missing is a hook in dpkg-buildpackage to abort
> the (source) build when the worktree is unclean,

I often build with manual changes in debian/ that I want tested before
committed.

> > [...] script cleaning after the build,
> > then reporting any difference between the source and the .dsc.
> > The output is almost always either
> >  * trivial to work-around in Debian
> >(echo '*.o' > debian/clean)
> >(fixing upstream may be another story)
> >  * short enough to be easily ignored
> >(./configure),
> >  * or a real issue.

> [..] could you elaborate or show an example?

The script I am using is too lazy for public exposure.
Here are the parts unrelated with pbuilder.

# After a successful build, clean and compare the source directory
# with the contents extracted by dpkg-source.
# The diff must match debian/clean.diff if it exists, else be empty.
# Example:
# Only in ../dsc: Makefile.in
# Only in ../dsc: config.h
# Only in ../dsc: configure
# If lots of files are removed, repackaging with Files-Excluded is
# probably a better option, see uscan(1).

#!/bin/sh
set -Ceux

source=$(dpkg-parsechangelog -SSource)
version=$(dpkg-parsechangelog -SVersion)
dsc_dir=../dsc

debian/rules clean
dpkg-source -x ../$source_$version.dsc $dsc_dir
if ! (diff -qr $dsc_dir . || true) | diff -N debian/clean.diff -; then
  # Display a full diagnostic while $dsc_dir is available.
  diff -ru $dsc_dir . || true
  # When -ru is empty, -N above already reported the obsolete clean.diff.
fi
rm -fr $dsc_dir

Bug#1056194: bookworm-pu: package python3-onelogin-saml2/1.12.0-2+deb12u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: python3-onelogin-sa...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:python3-onelogin-saml2

[ Reason ]
This upload fixes Bug #1036255: FTBFS due to expired certificates in the tests

[ Impact ]
Anybody trying to build the package from source in bookworm will
get a build error.

[ Tests ]
I've verified that the package builds from source again.

[ Risks ]
Low risk. There are no real code changes, just the tests.

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

[ Changes ]
I've cherry-picked three commits from upstream repository,
required to fix the tests.

[ Other info ]
I've already uploaded the package.

Bug#941962: #941962Publish the new (Sphinx based) Developers Reference

[Holger Wansing]

I guess this bug can be closed, right?
The developers-reference (Sphinx-based) is online on www.d.o
(There are some minor issues with search and the theme, but they have separate 
bugs.)


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1

[Andreas B. Mundt]

Hi Kibi,

thank you for your comment and explanation!

On Sat, Nov 18, 2023 at 10:11:33AM +0100, Cyril Brulebois wrote:
>
> […] 
> 
> The versioning seems a little weird.
> 
> Usually:
>  - either one cherry-picks stuff on top of the stable package, and uses
>0.76+deb12u1;
>  - or one ships a rebuild of the testing/unstable into stable, and uses
>0.78~deb12u1 (adding a changelog entry on top of unstable's,
>similarly to what would be done for backports).
> 
> Glancing very briefly at the patch and the git tree, it seems like
> you're doing the latter but versioning it like the former. I'll let
> others comment as to whether that's some nitpicking that should be
> ignored, or something they'd like to see adjusted.

Ah, you are absolutely right, makes sense.  I started with a
0.76+deb12u1 package, realized that cherry-picking ended up at 0.78,
adjusted the version number … but I wasn't aware that the changelog
should also be 'reset' to the one from 0.78 (which, I agree, makes
perfectly sense).  If needed, I can provide another upload.

Thanks and best regards,

  Andi

Bug#1043419: raising missing trigger interest to serious

[Helmut Grohne]

Hi Lorenzo,

On Sat, Nov 18, 2023 at 03:26:37PM +0100, Lorenzo wrote:
> Could you please clarify how this is blocking the usrmerge transition,
> besides runit itself missing a trigger?

This is not blocking the transition. I don't see how deferring a runit
update could impact unrelated aspects. However, runit's triggers do not
work anymore. That's a serious bug and we're tracking it like that. In
tracking it like this, users can more easily see why their systems do
not work anymore.

Is there actually any issue with promoting the change from experimental
to unstable? If you lack a sponsor, I am willing to help out once to get
this fixed.

Helmut

Bug#1056193: glusterfs-client: GlusterFS SSL path changed without warning in Bookworm

[Xan Charbonnet]

Package: glusterfs-client
Version: 10.3-5
Severity: normal

Dear Maintainer,

I have a bullseye GlusterFS cluster which uses SSL/TLS.  Three machines have
a replica of the data, and an additional one merely mounts the cluster without
local storage for purposes of backing it up.

I recently upgraded the backup machine to bookworm.  Suddenly I was unable to
mount the cluster.  The key error in the logs was:

E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our
cert at /usr/lib/ssl/glusterfs.pem

/usr/lib/ssl/ is a strange path.  As far as I can tell, the correct path is
/etc/ssl/.  Creating three symlinks fixed the problem and allowed the cluster
to be mounted:
/usr/lib/ssl/glusterfs.ca -> /etc/ssl/glusterfs.ca
/usr/lib/ssl/glusterfs.pem -> /etc/ssl/glusterfs.pem
/usr/lib/ssl/glusterfs.key -> /etc/ssl/glusterfs.key

Taking another look at the apt-listchanges output for the upgrade, there is
nothing from any gluster package.  This leads me to believe that the changing
of this path was unintentional and is a bug.  Not sure what's the best thing
to do about it at this point, since fixing it would break people's existing
bookworm configurations.


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/24 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 glusterfs-client depends on:
ii  glusterfs-common  10.3-5
ii  libc6 2.36-9+deb12u3
ii  python3   3.11.2-1+b1

glusterfs-client recommends no packages.

glusterfs-client suggests no packages.

-- no debconf information

Bug#1056192: slirp4netns: allow reusing an existing tap file descriptor

[Helmut Grohne]

Package: slirp4netns
Version: 1.2.0-1
Severity: wishlist
Tags: patch upstream

Hi,

thanks for maintaining slirp4netns. I'd like to use it in a more
flexible way than it currently provides.

The usual mode of operation is that one creates a network namespace and
then launches slirp4netns outside that namespace while telling it which
namespace one is interested in via a pid or path. Then slirp4netns
creates a child that joins this namespace and creates the interface
inside. This results in the need for readiness information and the
ability for slirp4netns to join namespaces.

It would be nice if slirp4netns was able to consume an existing tap file
descriptor. The program that creates the network namespace can open
/dev/net/tun and pass the file descriptor to its supervisor in the
initial namespace. If passing this file descriptor could be passed to
slirp4netns, it could skip creating a child and just use the given one.

This approach has a few distinct advantages and disadvantages compared
to the usual way of doing things. For instance, --configure cannot work.
Also choosing the name of the interface becomes a responsibility of the
caller. On the flip side, slirp4netns no longer needs to fork nor use
any namespace syscalls. Also readiness becomes trivial, because creation
of the network interface is entirely performed by the caller.

Since patches speak louder than words, I am attaching a demo patch of
how this is supposed to work. What do you think about it?

Helmut
--- slirp4netns-1.2.1.orig/main.c
+++ slirp4netns-1.2.1/main.c
@@ -333,11 +333,11 @@
 return fd;
 }
 
-static int parent(int sock, int ready_fd, int exit_fd, const char *api_socket,
+static int parent(int tapfd, int ready_fd, int exit_fd, const char *api_socket,
   struct slirp4netns_config *cfg, pid_t target_pid)
 {
 char str[INET6_ADDRSTRLEN];
-int rc, tapfd;
+int rc;
 struct in_addr vdhcp_end = {
 #define NB_BOOTP_CLIENTS 16
 /* NB_BOOTP_CLIENTS is hard-coded to 16 in libslirp:
@@ -345,11 +345,6 @@
 .s_addr = htonl(ntohl(cfg->vdhcp_start.s_addr) + NB_BOOTP_CLIENTS - 1),
 #undef NB_BOOTP_CLIENTS
 };
-if ((tapfd = recvfd(sock)) < 0) {
-return tapfd;
-}
-fprintf(stderr, "received tapfd=%d\n", tapfd);
-close(sock);
 printf("Starting slirp\n");
 printf("* MTU: %d\n", cfg->mtu);
 printf("* Network: %s\n",
@@ -420,7 +415,7 @@
 
 static void usage(const char *argv0)
 {
-printf("Usage: %s [OPTION]... PID|PATH [TAPNAME]\n", argv0);
+printf("Usage: %s [OPTION]... PID|PATH|FD [TAPNAME]\n", argv0);
 printf("User-mode networking for unprivileged network namespaces.\n\n");
 printf("-c, --configure  bring up the interface\n");
 printf("-e, --exit-fd=FD specify the FD for terminating "
@@ -439,8 +434,8 @@
 printf("--disable-host-loopback  prohibit connecting to 127.0.0.1:* on the "
"host namespace\n");
 /* v0.4.0 */
-printf("--netns-type=TYPE 	 specify network namespace type ([path|pid], "
-   "default=%s)\n",
+printf("--netns-type=TYPE 	 specify network namespace type "
+   "([path|pid|tapfd], default=%s)\n",
DEFAULT_NETNS_TYPE);
 printf("--userns-path=PATH	 specify user namespace path\n");
 printf(
@@ -510,6 +505,7 @@
 char *macaddress; // --macaddress
 char *target_type; // --target-type
 char *bess_socket; // argv[1] (When --target-type="bess")
+int tapfd; // argv[1] (When --netns-type="tapfd")
 };
 
 static void options_init(struct options *options)
@@ -517,6 +513,7 @@
 memset(options, 0, sizeof(*options));
 options->exit_fd = options->ready_fd = -1;
 options->mtu = DEFAULT_MTU;
+options->tapfd = -1;
 }
 
 static void options_destroy(struct options *options)
@@ -806,13 +803,9 @@
 fprintf(stderr, "--target-type must be either \"netns\" or \"bess\"\n");
 goto error;
 }
-if (argc - optind < 2) {
+if (argc - optind < 1) {
 goto error;
 }
-if (argc - optind > 2) {
-// not an error, for preventing potential compatibility issue
-printf("WARNING: too many arguments\n");
-}
 if (!options->netns_type ||
 strcmp(options->netns_type, DEFAULT_NETNS_TYPE) == 0) {
 errno = 0;
@@ -821,6 +814,14 @@
 fprintf(stderr, "PID must be a positive integer\n");
 goto error;
 }
+} else if (options->netns_type &&
+   strcmp(options->netns_type, "tapfd") == 0) {
+errno = 0;
+options->tapfd = strtol(argv[optind], _e, 10);
+if (errno || *strtol_e != '\0' || options->tapfd < 0) {
+fprintf(stderr, "TAPFD must a file descriptor\n");
+goto error;
+	}
 } else {
 options->netns_path = strdup(argv[optind]);
 if (access(options->netns_path, F_OK) == -1) {
@@ -828,7 +829,21 @@
 goto error;
 }
 }
-options->tapname = 

Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators

[Otto Kekäläinen]

Source: usrmerge
Source-Version: 38
Severity: wishlist

Summary:

Please extend the Debian.README in usrmerge to explain:
- In what releases of the most popular Debian derivatives will the usrmerge
apply?
- Did any of the popular ones fork usrmerge? Does that have any
implications of Debian package maintenance?
- How should CI systems that test upgrade paths of various Debian-based
software adapt to this change?


Description:

The doc
https://salsa.debian.org/md/usrmerge/-/blob/master/debian/README.Debian
does a good job at explaining the basics of how usrmerge works, and people
can read additional justifications why doing this makes sense over at
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

I have nothing against usrmerge, but I wish there was more easily
discoverable documentation for Debian Developers and system administrators
on how to adjust whatever upgrade related systems automation they have.

Could you please extend the Debian.README in usrmerge considering that the
change is rather big and affects all Debian based systems everywhere?

I know the Debian policy states that upgrades across two Debian releases
are not officially supported, and I know it is not the responsibility for
Debian package maintainers to account for what happens in Debian
derivatives.

However it would be a nice service to users at large to explain what will
follow from usrmerge and how people best adapt to it.

For example a list of what versions of the most popular Debian derivatives
will inherit this change would be useful. Currently distrowatch.com lists
in top-10 the Debian derivatives MX Linux, Mint, Ubuntu, Pop! OS and Zorin.
This would be good general information for people to grasp how this change
will affect the Debian ecosystem at large.

The README could also explain if any of these derivatives is known to have
forked the usrmerge package and what follows to Debian Developers and
Debian sysadmins from that.

For people who already had issues while testing upgrades in CI systems etc
(or for Debian buildd itself) there was in usrmerge versions v27-37 a
workaround to use the flag file /etc/unsupported-skip-usrmerge-conversion:
https://salsa.debian.org/md/usrmerge/-/commit/380f396db19978d8bc6d7d94175a10cce5359491

This was removed in v38 along with the documentation that it existed:
https://salsa.debian.org/md/usrmerge/-/commit/458861662a0bcf4c5cf54aa6afe508ccf5b7fdbc

Thus a third thing the README could advise on is how Debian Developers and
Debian sysadmins are advised to build CI systems and test upgrade paths for
the next 10 years as what worked in the past 10 years does not apply as-is
anymore.

Thanks!

Bug#1053549: #1053549Create a Debian theme for documentation based in Sphinx (reStructuredText)

[Holger Wansing]

Hi,

I'm have no experiences regarding design or CSS or the like, but I have
created some sort of a proposal for this, using an adapted alabaster theme.

See 

The used conf.py can also be found there for reference.

While it looks good IMO on laptos, PC etc., it does not on a small 
screen like on smartphones, because the sidebar gets unvisible.

Maybe someone can help with that?




Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1056190: /sbin/upsmon: CAL flag in UPSMON never cleared, shutdown procedure will not be triggered

[Fabien]

Package: nut-client
Version: 2.8.0-7
Severity: important
File: /sbin/upsmon
X-Debbugs-Cc: fab_bw-deb...@yahoo.com

Dear Maintainer,


   * What led up to the situation?

During a power cut long enough to bring my UPS batteries to a
critical level, I noticed that my server was not shut down by
NUT as I expected.

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

An UPS is connected to the server and managed by NUT.
(daemon /sbin/upsmon = nut-monitor)
NUT is configured to switch off the server in "low battery"
state.
The UPS regularly performs a battery self-test, which is
recognized by UPSMON as a calibration.
A few days later, there was a power cut.

   * What was the outcome of this action?

During a power cut long enough to bring the battery level to a
critical threshold, UPSMON didn't initiate the shutdown
procedure because it thought the UPS was still in calibration,
which was wrong, and the server was finally abruptly power down when
the battery was drained.

   * What outcome did you expect instead?

When the battery charge level reached a threshold defined as "low
battery", UPSMON should have initiated the server shutdown procedure.


This bug is known on the github of networkupstools here :
https://github.com/networkupstools/nut/issues/2168
Bug fix here :

https://github.com/networkupstools/nut/pull/2169/commits/b606d757660b85ba9123757609e6ac70a1684cbf


Further Informations :

UPSMON detects a battery self-test as a calibration and records this
state with a flag.

However, it will never clear this flag.

During a power failure, when the battery charge level reaches "low
battery" state, the is_ups_critical function is called.

This detects the "on battery" and "low battery" states, but since the
"calibration" flag is not cleared, the function will block the rest of
the expected procedure. A log entry is created:
is_ups_critical: seems that UPS [Onduleur] is OB+LB now, but it is also
calibrating - not declaring a critical state

This behavior is easy to reproduce :

First test : (Shows that NUT is correctly configured)
- After starting the nut-monitor daemon, simulate a power failure
- The station is powered by the UPS battery
- Battery charge level becomes low
- UPSMON detects this and correctly shuts down the server

Second test : (Show the bug)
- After starting the nut-monitor daemon, simulate or wait for a battery
  self-test
- Wait for the test to be successful, so the station is powered by the
  mains
- Simulate a power failure
- The station is powered by the UPS battery
- Battery charge level becomes low
- UPSMON detects this but thinks the UPS is in calibration. A log
  entry is created, but the station will not be shut down

Third test : (Get around the problem)
- After starting the nut-monitor daemon, simulate or wait for a
  battery self-test.
- Wait for the test to be successful, so the station is powered
  by the mains.
- Restart the nut-monitor daemon (only this one)
- Simulate a power failure
- The station is powered by the UPS battery
- Battery charge level becomes low
- UPSMON detects this and correctly switches off the station


To solve the problem quickly:

Using the NUT v2.8.0 sources provided by Debian Bookworm
(apt source nut),
edit the file ./nut-2.8.0/clients/upsmon.c

Add this just after line 1678:
  if (!strstr(status, "CAL"))
clearflag(>status, ST_CAL);

see
https://github.com/networkupstools/nut/pull/2169/commits/b606d757660b85ba9123757609e6ac70a1684cbf

Thank you very much
Fabien



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

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

Versions of packages nut-client depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
ii  libupsclient6  2.8.0-7
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages nut-client recommends:
ii  bash-completion  1:2.11-6

Versions of packages nut-client suggests:
pn  nut-monitor  

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

-- no debconf information

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

Hi,

On 2023-10-30 09:46, Julien Cristau wrote:
> Hi,
> 
> On Mon, Oct  9, 2023 at 09:08:31 +0100, Jiaxun Yang wrote:
> 
> > 
> > 
> > 在2023年10月8日十月 上午11:11，Aurelien Jarno写道：
> > > On 2023-07-19 16:28, Jiaxun Yang wrote:
> > >> 
> > >> 
> > >> 在 2023/7/8 18:11, Aurelien Jarno 写道:
> > >> [...]
> > >> > Any news about that? We need to be able to run the latest stable kernel
> > >> > on the build daemon.
> > >> 
> > >> Hi all,
> > >> 
> > >> After receiving more reports on that patch I think we shoud workaround 
> > >> it in
> > >> Kernel.
> > >> 
> > >> I had posted a patch to kernel, kernel bug tracker [1].
> > >> 
> > >> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217680
> > >
> > > Any news about that? I haven't spotted any fix for this in Linus' tree
> > > nor in next.
> > 
> > Still waiting for a response from PCI folks.
> > Will resend the patch later.
> > 
> Any news on this?  It's been several months...

Gentle ping about the issue.

Thanks,
Aurelien

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

Bug#1056189: luahbtex: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)

[Preuße]

Control: severity -1 grave
Control: merge -1 1056186

On 18.11.2023 16:19, Andreas Metzler wrote:

Hi,


trying to install texlive-latex-base+texlive-plain-generic to fullfill a
build dependency resulted in:
8X--
Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
 This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.VGYt4Mud
Please include this file if you report a bug.



Rebuilding tl-binaries with the new zlib in place seems to solve the 
issue. I'll try to do an bin-NMU.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056189: luahbtex: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)

[Andreas Metzler]

On 2023-11-18 Andreas Metzler  wrote:
[...]
> /tmp/fmtutil.VGYt4Mud (attached) shows:

actually attaching now.

cu Andreas
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luahbtex with luahbtex
fmtutil: running `luahbtex -ini   -jobname=luahbtex -progname=luahbtex 
luatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
Aborted
fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/luahbtex/luahbtex.log
fmtutil [INFO]: --- remaking pdftex with pdftex
fmtutil: running `pdftex -ini   -jobname=pdftex -progname=pdftex 
-translate-file=cp227.tcx *pdfetex.ini' ...
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (INITEX)
 restricted \write18 enabled.
 (/usr/share/texlive/texmf-dist/web2c/cp227.tcx)
entering extended mode
(/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
(/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex)
(/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src
(/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
Preloading the plain format: codes, registers, parameters, fonts, more fonts,
macros, math definitions, output routines, hyphenation
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib
Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";)
(/var/lib/texmf/tex/generic/config/language.def
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended register allocation; 
Recycling: \addlanguage, \@nswer (not defined), \@sk, \b@dresponsetrue,
\b@dresponsefalse, \ch@ckforyn, \mayber@cycle, \et@xabort, \et@xbuf,
\et@xfmtsrc, \et@xfilehdr, \et@xinf, \et@xpatterns, \l@ngdefnfile, \n@xt,
\p@rse (not defined), \pr@mpt (not defined), \pr@mptloop (not defined),
\forcer@cycle, \usef@llback, \usef@llbacktrue, \usef@llbackfalse, 
Retaining: \et@xerr, \et@xinput, \et@xlibhdr, \et@xmsg, \et@xtoks, \et@xwarn,
\et@xl@@d, \et@xl@ad, \et@xload, \et@xlang, \et@xhash, \eTeX, \etexhdrchk,
\etexstatus, \module, \uselanguage, \r@tain, \r@cycle,)
(/usr/share/texlive/texmf-dist/tex/plain/config/pdftexmagfix.tex) )
Beginning to dump on file pdftex.fmt
 (preloaded format=pdftex 2023.11.18)
2925 strings of total length 43603
7961 memory locations dumped; current usage is 203&7322
1275 multiletter control sequences
\font\nullfont=nullfont
\font\tenrm=cmr10
\font\preloaded=cmr9
\font\preloaded=cmr8
\font\sevenrm=cmr7
\font\preloaded=cmr6
\font\fiverm=cmr5
\font\teni=cmmi10
\font\preloaded=cmmi9
\font\preloaded=cmmi8
\font\seveni=cmmi7
\font\preloaded=cmmi6
\font\fivei=cmmi5
\font\tensy=cmsy10
\font\preloaded=cmsy9
\font\preloaded=cmsy8
\font\sevensy=cmsy7
\font\preloaded=cmsy6
\font\fivesy=cmsy5
\font\tenex=cmex10
\font\preloaded=cmss10
\font\preloaded=cmssq8
\font\preloaded=cmssi10
\font\preloaded=cmssqi8
\font\tenbf=cmbx10
\font\preloaded=cmbx9
\font\preloaded=cmbx8
\font\sevenbf=cmbx7
\font\preloaded=cmbx6
\font\fivebf=cmbx5
\font\tentt=cmtt10
\font\preloaded=cmtt9
\font\preloaded=cmtt8
\font\preloaded=cmsltt10
\font\tensl=cmsl10
\font\preloaded=cmsl9
\font\preloaded=cmsl8
\font\tenit=cmti10
\font\preloaded=cmti9
\font\preloaded=cmti8
\font\preloaded=cmti7
\font\preloaded=cmu10
\font\preloaded=cmmib10
\font\preloaded=cmbsy10
\font\preloaded=cmcsc10
\font\preloaded=cmssbx10
\font\preloaded=cmdunh10
\font\preloaded=cmr7 at 14.51799pt
\font\preloaded=cmtt10 at 14.4pt
\font\preloaded=cmssbx10 at 14.4pt
\font\preloaded=manfnt
14787 words of font info for 50 preloaded fonts
14 hyphenation exceptions
Hyphenation trie of length 6075 has 181 ops out of 35111
  181 for language 0
0 words of pdfTeX memory
0 indirect objects
No pages of output.
Transcript written on pdftex.log.
fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/pdftex/pdftex.log
fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/pdftex.fmt installed.
fmtutil [INFO]: --- remaking tex with tex
fmtutil: running `tex -ini   -jobname=tex -progname=tex tex.ini' ...
This is TeX, Version 3.141592653 (TeX Live 2023/Debian) (INITEX)
(/usr/share/texlive/texmf-dist/tex/plain/config/tex.ini
(/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
Preloading the plain format: codes, registers, parameters, fonts, more fonts,
macros, math definitions, output routines, hyphenation
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) )
Beginning to dump on file tex.fmt
 (preloaded format=tex 

Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3

[Cyril Brulebois]

Scott Talbert  (2023-11-16):
> > Scott Talbert  (2023-11-13):
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: binnmu
> > > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
> > > Control: affects -1 + src:libalien-wxwidgets-perl
> > > 
> > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild 
> > > for wxwidgets3.2 (3.2.4+dfsg-1)"
> > 
> > This looks like a redux of #1054146, with libwx-perl also needing a
> > binNMU (after the libalien-wxwidgets-perl one)?
> 
> Yeah, I did at least file both at the same time this round though :)
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908

I was trying to suggest filing both in the same request, to have them
scheduled in one go.

In any case, actually binNMUing both packages would be nice, as we've
been lacking d-i daily builds for some days already.

(I could probably try and do that myself but “above all, do no harm”.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1056189: luahbtex: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)

[Andreas Metzler]

Package: texlive-binaries
Version: 2023.20230311.66589-7
Severity: important
Affects: tex-common

Hello,

trying to install texlive-latex-base+texlive-plain-generic to fullfill a
build dependency resulted in:
8X--
Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.VGYt4Mud
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
[...]
Errors were encountered while processing:
 tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
8X--

/tmp/fmtutil.VGYt4Mud (attached) shows:
...
fmtutil [INFO]: --- remaking luahbtex with luahbtex
fmtutil: running `luahbtex -ini   -jobname=luahbtex -progname=luahbtex 
luatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
Aborted
...

I am submitting against texlive-binaries since it contains the failing
binary.

cu Andreas

##
minimal input file


##
other files

##
 List of ls-R files

lrwxrwxrwx 1 root root 31 Oct  8 20:00 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Nov 18 15:02 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Oct  8 20:00 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Oct  8 20:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2942 Nov 18 15:02 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Apr  1  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Nov 18 15:02 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-12
ii  libcairo2   1.18.0-1
ii  libfontconfig1  2.14.2-6
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-6
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-4
ii  libkpathsea62023.20230311.66589-7
ii  libmpfr64.2.1-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-2
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-7
ii  libstdc++6  13.2.0-6
ii  libsynctex2 2023.20230311.66589-7
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-7
ii  libx11-62:1.8.7-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.17-1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-9
ii  t1utils 1.41-4
ih  tex-common  6.18
ii  zlib1g  1:1.3.dfsg-2

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2023.20231007-1

Versions of packages texlive-binaries suggests:
pn  hintview   
pn  texlive-binaries-sse2  

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-binaries is related to:
ih  tex-common6.18
ii  texlive-base  2023.20231007-1

-- no debconf information

Bug#1056188: gnutls28: CVE-2023-5981: timing side-channel inside RSA-PSK key exchange

[Salvatore Bonaccorso]

Source: gnutls28
Version: 3.8.1-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1511
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

[Andreas, just filling for having a BTS reference, realize you know
already]

The following vulnerability was published for gnutls28.

CVE-2023-5981[0]:
| timing side-channel inside RSA-PSK key exchange


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5981
https://www.cve.org/CVERecord?id=CVE-2023-5981
[1] https://gitlab.com/gnutls/gnutls/-/issues/1511
[2] https://gnutls.org/security-new.html#GNUTLS-SA-2023-10-23
[3] 
https://gitlab.com/gnutls/gnutls/-/commit/29d6298d0b04cfff970b993915db71ba3f580b6d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056186: texlive-binaries: zlib library mismatch

[Jerome BENOIT]

Hello Hilmar, thanks for your prompt reply.

To clarify things,
the message is not only irritating but also aborting:
the package tex-common cannot currently configure.

Best wishes,
Jerome

PS: I merged my report with the first report,
and I redirected the first report to texlive-binaries.

On 18/11/2023 15:28, Preuße, Hilmar wrote:

On 18.11.2023 14:57, Jerome Benoit wrote:

Hi,


Hi, the issue appeared to me within a Sid schroot environment
at postinstallation time of tex-common.
I traced it back to texlive-binaries by looking the logfile at
the fmutils stage. The issue seems to originate from the recent migration
from zlib 1.2.13 to zlib 1.3. For short, the following command-line

   $ luatex -ini -jobname=luatex -progname=luatex luatex.ini

gives

   PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
   aborted


Already reported, but on the wrong package. I'll try, whether a simple rebuild of the package 
solves the issue, but I'm afraid it won't. The message "zlib library version does not match - 
header: 1.2.13, library: 1.3" is irritating, but I know that behavior from other packages too 
(e.g. proftp). I understand this warning: "expect trouble ahead".

Hilmar


--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1056187: libde265: CVE-2023-47471

[Salvatore Bonaccorso]

Source: libde265
Version: 1.0.12-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/strukturag/libde265/issues/426
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libde265.

CVE-2023-47471[0]:
| Buffer Overflow vulnerability in strukturag libde265 v1.10.12 allows
| a local attacker to cause a denial of service via the
| slice_segment_header function in the slice.cc component.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-47471
https://www.cve.org/CVERecord?id=CVE-2023-47471
[1] https://github.com/strukturag/libde265/issues/426
[2] 
https://github.com/strukturag/libde265/commit/e36b4a1b0bafa53df47514c419d5be3e8916ebc7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055797: Likely quick and easy: KDbg Debian packaging revival

[Sebastian Pipping]

Hello again!


Just a quick note that reviving the Debian package may /not/ need much
more than…

  1. Dropping the existing patches

https://github.com/j6t/kdbg/commit/11c48e4c4aaa9365208a9d2688830e2d5aee308e

  2. Updating the package dependencies for Qt 5 and KDE 4

https://github.com/j6t/kdbg/commit/1aa87d26a432b6dffc935f69e5a67c0463a773d7

…on Debian side in practice.  At least that made the old 2.5.5-3
packaging build with Git `master`.

Pull request https://github.com/j6t/kdbg/pull/37 would be the full 
picture with more details if interested.


Asking regular users to download and install CI-built guerilla Debian
packages built by upstream CI is not ideal though, in particular because
it teaches users that installing unofficial .deb files by random third
parties using sudo is okay and safe, but with my security hat on I'd
rather want users to twice twice about that minimum.

Any chance we could get flip the live switch on official KDBG Debian
packaging?  I truly believe it can be a low-cost project, realistically.
Anyone?

Thanks and best



Sebastian

Bug#1056185: /usr/lib/python3/dist-packages/gidocgen/gir/ast.py: Debian specific multiarch detection fails when called outside of dpkg build

[Simon McVittie]

Control: tags -1 + confirmed pending

On Sat, 18 Nov 2023 at 13:40:55 +, Mario wrote:
> When running gi-docgen outside of a package (such as a test build by hand)
> it will fail with the following:
...
> NameError: name 'sysconfig' is not defined
> 
> This looks specific to a Debian patch that forgot to import sysconfig.

Oops, yes; fix in progress. A workaround until the fixed version arrives
is to do your non-packaging builds with:

export DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH)

(or use a different multiarch tuple as appropriate if cross-compiling).

smcv

Bug#1056186: texlive-binaries: zlib library mismatch

[Preuße]

On 18.11.2023 15:42, Jerome BENOIT wrote:

Hi,


To clarify things,
the message is not only irritating but also aborting:
the package tex-common cannot currently configure.

I'm aware of this: the other user reported a core dump and in our output 
an aborted message is visible. Therefore I'm afraid, that a simple 
rebuild won't solve the issue.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056183: Bug#1056186: texlive-binaries: zlib library mismatch

[Preuße]

On 18.11.2023 14:57, Jerome Benoit wrote:

Hi,


Hi, the issue appeared to me within a Sid schroot environment
at postinstallation time of tex-common.
I traced it back to texlive-binaries by looking the logfile at
the fmutils stage. The issue seems to originate from the recent migration
from zlib 1.2.13 to zlib 1.3. For short, the following command-line

   $ luatex -ini -jobname=luatex -progname=luatex luatex.ini

gives

   PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
   aborted

Already reported, but on the wrong package. I'll try, whether a simple 
rebuild of the package solves the issue, but I'm afraid it won't. The 
message "zlib library version does not match - header: 1.2.13, library: 
1.3" is irritating, but I know that behavior from other packages too 
(e.g. proftp). I understand this warning: "expect trouble ahead".


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043419: raising missing trigger interest to serious

[Lorenzo]

Hi Helmut,

On Sat, 18 Nov 2023 09:19:46 +0100
Helmut Grohne  wrote:

> Control: severity -1 serious
> 

Could you please clarify how this is blocking the usrmerge transition,
besides runit itself missing a trigger?

Lorenzo

> I am raising the bug about missing trigger interest to severity
> serious. The systemd package has now moved its units to
> /usr/lib/systemd and debhelper will also now install its units there.
> Hence, the trigger is now practically broken. I know that the bug is
> already fixed in experimental and that's great, but it still affects
> trixie and sid, so by raising it to serious, we get rid of the bug in
> trixie before too long (either via upload or autoremove).
> 
> Helmut

Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Martin-Éric Racine]

On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
 wrote:
>
> On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
>  wrote:
> >
> > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> >  wrote:
> > >
> > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > > >  wrote:
> > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > > > > Greetings,
> > > > > > >
> > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might 
> > > > > > > be a
> > > > > > > good time to re-visit Debian's choice of standard DHCP client 
> > > > > > > shipping
> > > > > > > with priority:important.
> > > > > > >
> > > > > > > I hereby propose bin:dhcpcd-base:
> > > > > > >
> > > > > > > 1) already supported by ifupdown.
> > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with 
> > > > > > > privilege separation.
> > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > > > > configure both stacks.
> > > > > > ...
> > > > > >
> > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client 
> > > > > > for
> > > > > > the moment, and I'll make the relevant changes in ifupdown as soon 
> > > > > > as I
> > > > > > can. Josué, any thoughts?
> > > > >
> > > > > 1) As someone pointed out in the thread, the reason why
> > > > > isc-dhcp-client had priority:important probably was to ensure that
> > > > > debootstrap would pull it, since debootstrap ignores Recommends and
> > > > > packages with a priority lower than standard.
> > > > >
> > > > > 2) However, as long as ifupdown explictly depends on a package, it can
> > > > > also pull dependencies with a lower priority. Right now ifupdown
> > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead.
> > > > >
> > > > > 3) At that point, swapping the priority of isc-dhcp-client and
> > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both
> > > > > could, in principle, be optional, just as long as ifupdown explicitly
> > > > > Depends on a DHCP client, and the first alternative is a real package.
> > > >
> > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if
> > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp
> > > > client installed, where all the ipv4 is handled statically, and ipv6 is
> > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the
> > > > next upgrade.
> > > >
> > > > So I'd prefer to go forward with the steps proposed by Simon, and
> > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends:
> > > > Unless there is a strong objection, I'll file the override bug report.
> > >
> > > (sorry for taking so long to come back to this)
> > >
> > > For the moment, ifupdown is still installed by the debian-installer as
> > > default network interfaces manager. And after sleeping over it, and
> > > discussing with debian fellows, I would like to call for consensus to
> > > rise Priority: Important to dhcpcd-base (as initially requested in
> > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client.
> > >
> > > This addresses two scenarios: keep some systems as small as possible
> > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp
> > > client available after installing/bootstrapping.
> > >
> > > So I would like to retitle #1038882 back as originally reported. (Sorry
> > > for going back and forth) Objections?
> > >
> > > The situation regarding the default network interfaces manager could
> > > change, even in the short term. But that could be discussed in another
> > > thread.
> >
> > No objection. Raising the priority of dhcpcd-base to important works for me.
>
> Have we reached a conclusion? Are we moving ahead with this or not?

What is the current situation?

Martin-Éric

Bug#1056160: ITS: auctex

[Preuße]

On 18.11.2023 11:51, Davide G. M. Salvetti wrote:

Hello Davide,


please, let me have some more time.  I plan to release a new version
within a fortnight.

Many thanks for fast response! I'll leave the ITS bug open, but I won't 
drive the salve process forward. In case I can help somehow, let me know.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056186: texlive-binaries: zlib library mismatch

[Jerome Benoit]

Package: texlive-binaries
Version: 2023.20230311.66589-7
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: calcu...@rezozer.net

Hi, the issue appeared to me within a Sid schroot environment 
at postinstallation time of tex-common.
I traced it back to texlive-binaries by looking the logfile at
the fmutils stage. The issue seems to originate from the recent migration
from zlib 1.2.13 to zlib 1.3. For short, the following command-line

  $ luatex -ini -jobname=luatex -progname=luatex luatex.ini

gives

  PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
  aborted

Best wishes,
Jerome


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

Kernel: Linux 6.1.0-0.deb11.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 texlive-binaries depends on:
ii  libc6   2.37-12
ii  libcairo2   1.18.0-1
ii  libfontconfig1  2.14.2-6
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-6
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-4
ii  libkpathsea62023.20230311.66589-7
ii  libmpfr64.2.1-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-2
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-7
ii  libstdc++6  13.2.0-6
ii  libsynctex2 2023.20230311.66589-7
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-7
ii  libx11-62:1.8.7-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.17-1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-9
ii  t1utils 1.41-4
ih  tex-common  6.18
ii  zlib1g  1:1.3.dfsg-2

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2023.20231007-1

Versions of packages texlive-binaries suggests:
pn  hintview   
pn  texlive-binaries-sse2  

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-binaries is related to:
ih  tex-common6.18
ii  texlive-base  2023.20231007-1

-- no debconf information

Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

[Martin-Éric Racine]

On Wed, Oct 25, 2023 at 3:35 AM Ron Murray  wrote:
> OK. Now running version 10.0.3-1. I'll let you know how it goes.

Testing now has 10.0.4-1, while unstable has 10.0.5-2. Does either one
fix the issue for you?

Martin-Éric

Bug#1056185: /usr/lib/python3/dist-packages/gidocgen/gir/ast.py: Debian specific multiarch detection fails when called outside of dpkg build

[Mario]

Package: gi-docgen
Version: 2023.1+ds-4
Severity: normal
File: /usr/lib/python3/dist-packages/gidocgen/gir/ast.py
X-Debbugs-Cc: supe...@gmail.com


When running gi-docgen outside of a package (such as a test build by hand)
it will fail with the following:

usr/bin/gi-docgen generate --quiet 
--add-include-path=/github/workspace/fwupd/bulid/docs/../libfwupd 
--config=docs/fwupd.toml --output-dir=docs/libfwupd --no-namespace-dir 
--content-dir=/github/workspace/fwupd/docs libfwupd/Fwupd-2.0.gir
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gidocgen/gidocmain.py", line 78, in run
res = options.run_func(options)
  ^
  File "/usr/lib/python3/dist-packages/gidocgen/gdgenerate.py", line 3134, in 
run
paths.extend(utils.default_search_paths())
 
  File "/usr/lib/python3/dist-packages/gidocgen/utils.py", line 826, in 
default_search_paths
multiarch = sysconfig.get_config_var('MULTIARCH')
^
NameError: name 'sysconfig' is not defined


This looks specific to a Debian patch that forgot to import sysconfig.


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

Kernel: Linux 6.5.11-300.fc39.x86_64 (SMP w/12 CPU threads; PREEMPT)
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 gi-docgen depends on:
ii  python3 3.11.4-5+b1
ii  python3-jinja2  3.1.2-1
ii  python3-markdown3.4.4-1
ii  python3-markupsafe  2.1.3-1
ii  python3-pygments2.15.1+dfsg-1
ii  python3-typogrify   1:2.0.7-3

gi-docgen recommends no packages.

gi-docgen suggests no packages.

-- no debconf information

Bug#1056065: transition: spdlog

[Sebastian Ramacher]

Hi Andrius

binNMUs for the reverse dependencies have been scheduled.

spdlog's autopkgtest fail, though:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/spdlog/39983394/log.gz

Could you please take a look?

Cheers
-- 
Sebastian Ramacher

Bug#1056184: python-ase: FTBFS: ERROR: Broken link: :git:`COPYING`: Non-existing path: ../COPYING

[Santiago Vila]

Source: python-ase
Version: 3.22.1-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During an incremental rebuild of all packages in trixie,
this package failed to build:

[...]
/<>/doc/about.rst:51: ERROR: Broken link: :git:`COPYING`: 
Non-existing path: ../COPYING
/<>/doc/about.rst:51: ERROR: Broken link: :git:`COPYING.LESSER`: 
Non-existing path: ../COPYING.LESSER
/<>/doc/ase/ase.rst:49: WARNING: download file not readable: 
/<>/doc/ase/ase-talk.pdf
/<>/doc/ase/calculators/FHI-aims.rst:110: ERROR: Broken link: 
:git:`ase/test/calculator/aims/test_H2O_aims.py`: Non-existing path: 
../ase/test/calculator/aims/test_H2O_aims.py
/<>/doc/ase/calculators/kim.rst:97: ERROR: Broken link: 
:git:`ase.calculators.kim.kim `: Non-existing path: 
../ase/calculators/kim/kim.py
/<>/doc/ase/calculators/kim.rst:97: ERROR: Broken link: 
:git:`ase.calculators.kim.kimmodel `: Non-existing path: 
../ase/calculators/kim/kimmodel.py
/<>/doc/ase/calculators/qmmm.rst:108: ERROR: Broken link: 
:git:`ase/test/forcefields/test_forceqmmm.py`: Non-existing path: 
../ase/test/forcefields/test_forceqmmm.py
/<>/doc/ase/calculators/turbomole.rst:346: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_H2.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_H2.py
/<>/doc/ase/calculators/turbomole.rst:353: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_h3o2m.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_h3o2m.py
/<>/doc/ase/calculators/turbomole.rst:360: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_au13.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_au13.py
/<>/doc/ase/calculators/turbomole.rst:368: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_optimizer.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_optimizer.py
/<>/doc/ase/calculators/turbomole.rst:373: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_h2o.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_h2o.py
/<>/doc/ase/calculators/turbomole.rst:385: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_qmmm.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_qmmm.py
/<>/doc/ase/calculators/turbomole.rst:415: ERROR: Broken link: 
:git:`ase/test/calculator/turbomole/test_turbomole_2h2o.py`: Non-existing path: 
../ase/test/calculator/turbomole/test_turbomole_2h2o.py

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx/ext/extlinks.py", line 108, in 
role
title = caption % part
^~
TypeError: not all arguments converted during string formatting
The full traceback has been saved in /tmp/sphinx-err-ytvbet8_.log, if you want 
to report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
make[1]: *** [debian/rules:45: override_dh_sphinxdoc] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Full build log available here, where it also fails:

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/python-ase.html

Thanks.

Bug#1055891: transition: gdal

[Sebastiaan Couwenberg]

grass is now also built & installed on all release architectures.

libgdal-grass & qgis can be rebuilt.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER

[Rene Engelhard]

tag 1056104 + wonffix
thanks

Hi,

Am 17.11.23 um 18:30 schrieb Rene Engelhard:

So it would boil down to

rene@frodo:~/LibreOffice/git/master/debian$ git diff rules
diff --git a/rules b/rules
index e7152c60..ed7a8157 100755
--- a/rules
+++ b/rules
@@ -2247,6 +2247,7 @@ config_host.mk:
     MARIADBCONFIG=$(MARIADBCONFIG) \
     FIREBIRD_CFLAGS=$(FIREBIRD_CFLAGS) 
FIREBIRD_LIBS=$(FIREBIRD_LIBS) \

     ./autogen.sh $(CONFIGURE_FLAGS)
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


  build:
     $(CURDIR)/debian/rules build-arch
@@ -2270,6 +2271,7 @@ ifeq "$(BUILD_NOGUI_PACKAGES)" "y"
     --without-doxygen --without-javadoc \
     --with-galleries=no --with-theme="$(DEFAULT_IMAGE)" \
     --disable-gui --disable-introspection --disable-qt5 
--disable-kf5
+   sed -i "s/ENABLE_WASM_STRIP_PINGUSER 
0/ENABLE_WASM_STRIP_PINGUSER 1/" config_host/config_wasm_strip.h


     PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) 
ARCH_FLAGS=$(ARCH_FLAGS) TMP=`mktemp -q -d` $(MAKE) build-non-l10n-only


That is actually not enough, one also needs to add a similar line for 
config_host.mk to be more complete and disable the affected lib.


sed -i 
"s/ENABLE_WASM_STRIP_PINGUSER=$$/ENABLE_WASM_STRIP_PINGUSER=TRUE/" 
config_host.mk


But AFAICS both of this also affects the "Tip of the day", so I am even 
more relucatant to actually set this..


Regards,

Rene




I am not sure this is worthwile.


  Thanks for considering.


Not for oldstable ;-)


Regards,


Rene

Bug#1056177: librust-tikv-jemalloc-ctl-dev: depends on missing packages

[Andreas Henriksson]

Hello Jonas,

On Sat, Nov 18, 2023 at 10:31:56AM +0100, Jonas Smedegaard wrote:
> Package: librust-tikv-jemalloc-ctl-dev
> Version: 0.5.4-1
> Severity: grave
> Justification: renders package unusable
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Depends on packages librust-tikv-jemalloc-sys-0.5+default-dev and
> librust-tikv-jemalloc-sys-0.5+disable-initial-exec-tls-dev that are
> missing in Debian.

tikv-jemalloc-sys is currently stuck in NEW (since a month, wonder if
there's a reason for it taking so long?).

Looks like this problem should resolve itself once it's accepted.

Regards,
Andreas Henriksson

Bug#1056183: texlive-luatex: lualatex exits immediately due to new zlib

[Nick Black (Public gmail account)]

Package: texlive-luatex
Version: 2023.20231007-1
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I recently updated zlib1g:amd64 (1:1.2.13.dfsg-3, 1:1.3.dfsg-2) in unstable.

lualatex immediately stopped working, with the error:

[schwarzgerat](0) $ lualatex
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
Aborted (core dumped)
[schwarzgerat](134) $

Should just need a rebuild, but perhaps this (unnecessary?) check ought be
removed? Isn't this what SOVERSIONs are for?


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2496 2023-11-10 04:56 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 17:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2023-08-28 14:30 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2023-10-08 16:00 /usr/share/texmf/web2c/fmtutil.cnf 
-> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2023-10-08 16:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5289 2023-11-10 04:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2016-02-22 09:54 mktex.cnf
-rw-r--r-- 1 root root 475 2023-08-28 14:30 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.5.9nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-luatex depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  lmodern   2.005-1
ii  tex-common6.18
ii  texlive-base  2023.20231007-1
ii  texlive-binaries  2023.20230311.66589-7

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-luatex is related to:
ii  tex-common6.18
ii  texlive-binaries  2023.20230311.66589-7

-- no debconf information

Bug#1055101: Remove moreinfo tag

[Tobias Frost]

Control: tags -1 moreinfo

Hi Daniel,

thanks for working on the package, appreciating the progress!

I've enabled CI for the package on salsa, in case you're wondering about
that.

Let me continue on the review, as said, the last one was only a short
review.

- lintian 
W: libapache2-mod-authn-otp source: timewarp-standards-version (2022-05-05 
< 2022-12-17)

(You need to touch the date on d/changelog… hint: dch -r "" )

I: libapache2-mod-authn-otp: hardening-no-bindnow [usr/bin/genotpurl]
I: libapache2-mod-authn-otp: hardening-no-bindnow [usr/bin/otptool]

This could be false positives, please review whether this is true or a
false positive, e.g some compiler flags are not passed appropiatly.
(There's a wiki page on wiki.d.o about hardening:
https://wiki.debian.org/Hardening)

Update: CI revealed that this are indeed missing compiler flags.
I also see that in configure.ac CFLAGS are replaced, not ammended.

- d/copyright is incomplete / inaccurate.
  d/copyright needs to reflect what the code says, and must be "verbatim".
  For example, You write "2009-", the "-" is incorrectly, a correct span
  needs to have a target. In the case of this source (but I did only
  grep on it), it seems that it should be 2009 only.
  - Please make sure every license is covered. For example, base32.c has a
  different license and copyright holder.

- upstream tarball differs in hash.
  
  probably a pristine-tar issue, if you re-generated the tarball from
  there. Please use the tarball retrived from upstream:

sha256 sums:
c2c41cd3404d1d9560e38a92d1afc70751d3d569978e8b4fe7e4a53b5e806033  
upstream/1.1.10.tar.gz
9151b4ee47680ef21ba89b66bb45a4b49c5d5a33cf12562507d6405e3d61f480  
mentors/libapache2-mod-authn-otp_1.1.10.orig.tar.gz

- (not required to be fixed for this upload)
The package does not cross-compile. It would be nice if that could be
fixed.

- There is a warning emitted by the compiler that indicates that there
  might be a buffer overflow. Please investigate and patch if required.
  (I did not investigate the context of the usage of snprintf e.g in
  motp.c, but this might well have security impact.)


-- 
Cheers,
tobi

On Fri, Nov 17, 2023 at 07:03:30PM +, Daniel Fancsali wrote:
> Control: tag - moreinfo
> 
> Thanks for the review Tobias.
> 
> Well, that happens if you put something on the back-burner for some time. ;)
> 
> I do apologise...
> 
> All should be fixed now.
> 
> Cheers,
> Daniel
> 


signature.asc
Description: PGP signature

Bug#1056182: python-nvchecker: "nvchecker" spelled wrong ("nvchekcer") in package description

[Beatrice Torracca]

Package: python-nvchecker
Severity: minor

Hi,

in the first paragraph of the package description of python3-nvchecker and 
python-nvchecker-doc, "nvchecker" is spelled wrong ("nvchekcer").

Thanks,

beatrice

Bug#1056181: RFP: denote -- simple note-taking tool for Emacs

[Dhavan Vaidya]

Package: wnpp
Severity: wishlist
Owner: Dhavan Vaidya 

* Package name: elpa-denote
  Version : 2.1.0
  Upstream Author : Protesilaos Stavrou 
* URL : https://git.sr.ht/~protesilaos/denote
* License : GNU GPLV3
  Programming Lang: elisp
  Description : Denote is a simple note-taking tool for Emacs.

Denote is a simple note-taking tool for Emacs. It is based on the idea
that notes should follow a predictable and descriptive file-naming
scheme. The file name must offer a clear indication of what the note is
about, without reference to any other metadata. Denote basically
streamlines the creation of such files while providing facilities to
link between them.

Denote's file-naming scheme is not limited to "notes". It can be used
for all types of file, including those that are not editable in Emacs,
such as videos. Naming files in a consistent way makes their filtering
and retrieval considerably easier. Denote provides relevant facilities
to rename files, regardless of file type.

Bug#1056180: rust-ryu: please update to v1.0.9

[Jonas Smedegaard]

Source: rust-ryu
Version: 1.0.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.0.9.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVYhiIACgkQLHwxRsGg
ASHZcRAAokclMDNIHNTR63BX2N0Sw/dq2AuTcs3UwikQ/lL/3q2awfzZhd/PGwFj
ljdH8+xV18yPdzaBEp8tvckEYQmnl+pYrO6ekzxtGltk/xBGlVQl7IdszGJHwIwr
fQMToMGiL0KvXIiWkaLDb8kUI7qMPzKcYQaTkHZntST5E+WhtyK4GkPCnYecxsqJ
YiSN0Icy8jLnlzHtlq6GNRXw+Dq9lPbXvUv1tBV47DMtAjoep1hgJvd+XJlM0q8j
CQwaN65DC7o2gM5qfBHWssJXW1tyunULAIYrwYPWRaGbVcO62y2Q8KbbIh6h4LMQ
ojrpmcAiqrXTsdZItD4z1s78mxSClt+2LH9CVH+NZPgR4z7m7BBPTSQ6shrbZnkU
szmq0LOCREkoFORISLAeFHqdp3rpjBkPG3CVMo+brrAgmoXsV2z2YXtwnXEGEiOo
o1P+fcu9vLdijJEznoevL+13WLGo5emDZgMTWmrD1TKW6ckyrFyV7xFxt3kIYKzZ
4wiNdX95ewYMzw0teMZdkxPRZk3fUhdq0fvABLN+GPVtCxodjnwnrAVvUveh/9Cs
S9IAWJQ1FXG7GNpZ0QxyM2puxuth3HC7pjAI7uX+u2xML5iX4KnNXhKNi9vHm24A
wxPRAhRTeu7U1EnXZ5oDxEvjvsGlYQLHQduRX11cPZ4EETNG2lo=
=vJnl
-END PGP SIGNATURE-

Bug#1056178: rust-bytemuck: please update to v0.12.3

[Jonas Smedegaard]

Source: rust-bytemuck
Version: 1.12.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.12.3.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVYhZIACgkQLHwxRsGg
ASGsOg/+LcowW9+UpOrNtfIn7cecFZvXt5DI1v2I6uQ7qzo2HGMIPANw9f2as4Na
Ia5mnY50OShMx+3A+HIKNpvXXJEmqeM3YhM5ar8ihAETxdbP317cF16zx98hQs9Q
2tjtJfpkX7fmsJlP2FYTOMKuFvVqV4TfPfBhAaOPXPnn0AmQQtqTm6jZOoHWs2k9
yWgvPWOUWu4FwrVqTM91pNsAUSgFx7wDPxWa5Kr90hD9DUvkNUVNhpWuKW4eb73p
TPp6UzD3JevLe0DJyL+NCnuktbu1bTK9Aaus7q3xlvieYHmjrE5uWOHANevwCd4c
MMTk1k58N754SqQuGYzCJlebgkAmc8lkERJ+Cjlkp5buZGY2y1YFMVzn8xcJ6qrp
iZNxZwpeXuGlkxC9aDpYoGQxIElBMbZkKO/GuFadPcbzyiiFOSPsWegHuUDE+tIc
1W5qpwF79BFaBABOhloRw/ROqviUnn9JxhyrTnHS9oQApBq7+UXobThY70bpmqmN
qkK0sbd3sM7oRFPeyzVZWkQ2vl0FTM2lYMGCNlqRNrrnC3edUtKm7Kl1Xdv+jZs1
Ewkgu8XGG2R4oiDf+ut2Fpzhnpm0UwpD8ZCspkIg6zANZiwK7Dso5U1BMHa3SQ2a
ZBaSLqk5Em7OEFQkdi2afdneerKUgsRRH46cdvgoKS18hU2/Icc=
=eIYS
-END PGP SIGNATURE-

Bug#1056179: rust-pkg-config: please update to v0.3.26

[Jonas Smedegaard]

Source: rust-pkg-config
Version: 0.3.25-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.3.26.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVYheMACgkQLHwxRsGg
ASFzkg//QplNmN8h6r1N+OzqhRAz7L/cCnlBS3XKXluLz4u7uOkszunHraF9NWXo
JExmfvmEra+1SPfEx5Q/em+QE7E+2n/gzQfpRoJ/CDhmfv5pLo1q8WeWHy1mvOAV
3lESB63wFqUxCt4RyyC9hvrJH+VKDF9hZ6wdDvqfex0eijvD26d/Q2c8CixmRwYi
gyd3kdnDHgS976RTHcsMmRiqVrT7AMwtSUfLNQvs3BPpfjKMutQxa+5I81hkvd4/
sAtCQHMoztGPbEbLJ/ZKPKHGYYgtDn9yKI69mbtcli6ObY99ogADrGdpOjBfrvMn
Gr95WLJECk+IHaTMHw8AweUSRsy/ugGeb61g127FbqK8Wo+kI0Nnq0yb5IzPesDL
8pOHsnjE80TimrxLSuPTV3/vEBR/8jZYvK3W6CWCxJ5rlKyeSsTt+EdwJfm/rlXH
oibHYWcE+W70XztgB6z5F0/IM5eF1MTn+SSDT5LoIaI2+hXZIc9vH8/0EUyLiI1a
Llv8sYhyy7yDnG1YHgsqxL43pK7zFYzwciFEjbWMStqGE4e1+3NgKqsSS9itv6Qa
+VGfp62ROE8AAsM7ix99MLUn8LGjkgeL9dsytnzG7ZIeeFJAvbBPg9Sbqu11h/7Z
dOxq2GeJmZ05ekhMf7Mb9Nf6s2MEKakCrumVoQUDNNBG3Y+t6YY=
=qBnb
-END PGP SIGNATURE-

Bug#1056177: librust-tikv-jemalloc-ctl-dev: depends on missing packages

[Jonas Smedegaard]

Package: librust-tikv-jemalloc-ctl-dev
Version: 0.5.4-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Depends on packages librust-tikv-jemalloc-sys-0.5+default-dev and
librust-tikv-jemalloc-sys-0.5+disable-initial-exec-tls-dev that are
missing in Debian.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVYhIgACgkQLHwxRsGg
ASFjNg//cqyOhnOtJOazDOwLT/Ix+Xc1/kmpB4K7uRe1VjPh9s2p62AgGD8jgNhM
LzsDnRvU6LXcYekRNfSUyTxEsU7A0L8xcw+hkgS2daY67PEnWI1HYltLJt//Ncq0
O8Ee8nNZ8ZZfIKoL241851jMO6awFvsrsRQ9ukKuKq//S7pz4y798s68QjoGISrT
XSjPLRGVGenDzLdLAa4VaqSR7FAo9gVaTWW/n5h93vChHmDgrls03LXDbZsCbp7v
y20BslCFnzRBcYX+QhC5OItrmDgq11yvLb4F8ZU000n46Dxu15ASbyZruCvnrNv5
jqWb/1bkaEOPKD0AqX9yilNJArzmvf8zQSWTmAPZurDKJVsM505pLQ3UWdEl1W2i
KxXhcp6whujtyBbAHqjistGFdmERc9nXrFZ2ZPrUbkNIbFcO4N+D5ZbZbYg6s8V1
UrHITbW9SgYdd+K2L8ohzQ44Y6avgGlY1Ks2XBok6hKXRCHgTph/WQ2gII1oNmwx
kxicT5WBfJ+c6Py3sOp2vWBmSDxAu1gaYEGLIEF815ZNst7FNqqiBCGWZHRv7rcc
rlpP8HmBV74KgBkuQh+ntTAeoOb647HIOeF7ZkDK5Rqw9yjm9X9N0iIh6QAoaZMD
6W/YJeDm8oeMU4btskDUIinZJidQNkzNNGgUtsSu5Ofz/OSz7zY=
=h8JL
-END PGP SIGNATURE-

Bug#1056176: insserv: please support DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Source: insserv
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: werdah...@riseup.net

Hi,

when creating chroots for architectures that are in the process of being
bootstrapped without yet having emulation support, it is not possible to run
maintainer scripts inside the foreign architecture chroot as the tools they
call cannot be executed. The solution to that problem is to run maintainer
scripts from the chroot directory without doing a chroot call first and instead
use the $DPKG_ROOT environment variable to communicate the location of the
chroot directory that the tools called by the maintainer script should operate
on. By default, for normal installations, that environment variable is set, but
empty. For more information see:
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

Support for this mode was already added to all packages in the essential set,
apt, systemd-sysv as well as build-essential. I'm now trying to add
support to the packages required to set up a system using sysv-init.
Having support DPKG_ROOT support for another init system than systemd is
useful to create chroots for architectures or kernels (like GNU Hurd)
that do not have systemd support.

Attached patch changes the insserv postinst so that if the $DPKG_ROOT
environment variable is not empty, the insserv tool is called with a bunch of
options which let it operate on the files inside the directory stored in
$DPKG_ROOT instead of /. Please review the patch to make sure that the insserv
command line arguments that the patch passes indeed make sense in this
scenario.

We tested it in our CI environment and it produces a bit-by-bit
identical chroot with DPKG_ROOT compared to a normal installation.

https://salsa.debian.org/helmutg/dpkg-root-demo/

Since the DPKG_ROOT variable is empty on normal installations, the patch
should have no effect in the normal case.

Thanks!

cheers, josch


diff -Nru insserv-1.24.0/debian/postinst insserv-1.24.0/debian/postinst
--- insserv-1.24.0/debian/postinst  2022-02-22 11:31:29.0 +0100
+++ insserv-1.24.0/debian/postinst  2023-11-17 01:55:47.0 +0100
@@ -7,5 +7,16 @@
 # fix up the rc?.d priorities from the dumb update-rc.d fallback (which uses
 # priority 01 for everything).
 if [ "$1" = "configure" ] && [ -z "$2" ]; then
-insserv || true
+if [ -z "$DPKG_ROOT" ] ; then
+# normal operation
+insserv || true
+else
+# in chrootless installation, provide the path to the chroot
+insserv \
+--path "$DPKG_ROOT/etc/init.d" \
+--override "$DPKG_ROOT/etc/insserv/overrides/" \
+--insserv-dir "$DPKG_ROOT/etc/init.d/" \
+--config "$DPKG_ROOT/etc/insserv.conf" \
+|| true
+fi
 fi

Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1

[Cyril Brulebois]

Hi Andreas,

And thanks for keeping an eye on netboot-assistant.

Andreas B. Mundt  (2023-11-18):
> +di-netboot-assistant (0.78~deb12u1) bookworm; urgency=medium
> +
> +  * Fixes for bookworm live iso image inclusion.
> +  * Update/add/fix preseed examples.  Thanks to Holger Wansing.
> +
> + -- Andreas B. Mundt   Sun, 18 Jun 2023 09:11:47 +0200
> +
>  di-netboot-assistant (0.76) unstable; urgency=medium

The versioning seems a little weird.

Usually:
 - either one cherry-picks stuff on top of the stable package, and uses
   0.76+deb12u1;
 - or one ships a rebuild of the testing/unstable into stable, and uses
   0.78~deb12u1 (adding a changelog entry on top of unstable's,
   similarly to what would be done for backports).

Glancing very briefly at the patch and the git tree, it seems like
you're doing the latter but versioning it like the former. I'll let
others comment as to whether that's some nitpicking that should be
ignored, or something they'd like to see adjusted.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1056174: librocprim-tests: SortKeysOver4G fails due to insufficient memory

[Cordell Bloor]

Package: librocprim-tests
Version: 5.5.1-2
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

RocprimDeviceRadixSort.SortKeysOver4G fails when executed on GPUs with
8 GB of memory or less [1]. To ensure that tests are useful on a wide
variety of hardware, the appropriate behaviour when a device has
insufficient memory to run the test is to mark it as SKIPPED rather
than marking it as FAILED.

The failing test output can be found in the CI logs [1] and it looks
like this:

[==] Running 145 tests from 37 test suites.
[--] Global test environment set-up.
[--] 1 test from RocprimDeviceRadixSort
[ RUN  ] RocprimDeviceRadixSort.SortKeysOver4G
KFD does not support xnack mode query.
ROCr must assume xnack is disabled.
test/rocprim/../../test/rocprim/test_device_radix_sort.hpp:710: Failure
Failed
HIP error 2: hipErrorOutOfMemory
Google Test trace:
test/rocprim/../../test/rocprim/test_device_radix_sort.hpp:696: with 
device_id = 0

Sincerely,
Cory Bloor

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/r/rocprim/210/log.gz

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
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 librocprim-tests depends on:
ii  libamdhip64-5  5.2.3-13
ii  libc6  2.37-12
ii  libgcc-s1  13.2.0-5
ii  libstdc++6 13.2.0-5

librocprim-tests recommends no packages.

librocprim-tests suggests no packages.

-- no debconf information

Bug#1056173: librocsparse0-tests: CBSRMV test failure on gfx1030

[Cordell Bloor]

Package: librocsparse0-tests
Version: 5.5.1-2
Severity: minor
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

There is a test failing with gfx1030 on the CI:

[ RUN  ] 
quick/bsrmv.level2/f32_c_500_842_1_1_n1_n0p5_row_2_NT_0b_rand_t2
clients/common/rocsparse_check.cpp:287: Failure
The difference between std::imag(A[i + j * LDA]) and std::imag(B[i + j * 
LDB]) is 5.7220458984375e-06, which exceeds std::imag(compare_val), where
std::imag(A[i + j * LDA]) evaluates to -0.00034707784652709961,
std::imag(B[i + j * LDB]) evaluates to -0.00034135580062866211, and
std::imag(compare_val) evaluates to 1.1920928955078125e-06.
131s
clients/common/rocsparse_check.cpp:287: Failure
The difference between std::imag(A[i + j * LDA]) and std::imag(B[i + j * 
LDB]) is 5.7220458984375e-06, which exceeds std::imag(compare_val), where
std::imag(A[i + j * LDA]) evaluates to -0.00034707784652709961,
std::imag(B[i + j * LDB]) evaluates to -0.00034135580062866211, and
std::imag(compare_val) evaluates to 1.1920928955078125e-06.
131s
[  FAILED  ] 
quick/bsrmv.level2/f32_c_500_842_1_1_n1_n0p5_row_2_NT_0b_rand_t2, where 
GetParam() = { function: "bsrmv", index_type_I: "i32", index_type_J: "i32", 
a_type: "f32_c", b_type: "f32_c", c_type: "f32_c", x_type: "f32_c", y_type: 
"f32_c", compute_type: "f32_c", transA: "NT", transB: "NT", baseA: "0b", baseB: 
"0b", baseC: "0b", baseD: "0b", M: 500, N: 842, K: -1, nnz: -1, block_dim: 2, 
row_block_dimA: 2, col_block_dimA: 2, row_block_dimB: 2, col_block_dimB: 2, 
dim_x: 1, dim_y: 1, dim_z: 1, ll: -2, l: -1, u: 1, uu: 2, alpha: 1.0, alphai: 
1.0, beta: -1.0, betai: -0.5, threshold: 1.0, percentage: 0.0, action: "num", 
part: "auto", matrix_type: "general", diag: "ND", uplo: "L", storage: 
"unsorted", analysis_policy: "reuse", solve_policy: "auto", direction: "row", 
order: "col", format: "coo", itilu0_alg: "async_inplace", sddmm_alg: "default", 
spmv_alg: "default", spsv_alg: "default", spitsv_alg: "default", spsm_alg: 
"default", spmm_alg: "default", spgemm_alg: "default", sparse_to_dense_alg: 
"default", dense_to_sparse_alg: "default", gtsv_interleaved_alg: "default", 
gpsv_interleaved_alg: "default", matrix: "rand", matrix_init_kind: "default", 
file: "*", algo: 0, numeric_boost: 0, boost_tol: 0.0, boost_val: 1.0, 
boost_vali: 0.0, tolm: 1.0, graph_test: false, name: "bsrmv", category: 
"quick", hardware: "all", unit_check: 1, timing: 0, iters: 10, denseld: -1, 
batch_count: -1, batch_count_A: -1, batch_count_B: -1, batch_count_C: -1, 
batch_stride: -1 }
 (5 ms)

It is difficult to be sure whether this is an indication of a real
problem or merely a test that is not numerically robust enough.

Sincerely,
Cory Bloor

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
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 librocsparse0-tests depends on:
ii  libamdhip64-5 5.2.3-13
ii  libc6 2.37-12
ii  libgcc-s1 13.2.0-5
ii  librocsparse0 5.5.1-2
ii  librocsparse0-tests-data  5.5.1-2
ii  libstdc++613.2.0-5

librocsparse0-tests recommends no packages.

librocsparse0-tests suggests no packages.

-- no debconf information

Bug#1056172: librocprim-tests: Test failures when gfx1030 code is run on gfx1031 hardware

[Cordell Bloor]

Package: librocprim-tests
Version: 5.5.1-2
Severity: important
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

In ROCm 5.5, the rocprim library added functionality that branched on
the detected GPU hardware to select the appropriate implementation of
the library functionality. This does not account for the possibility
of executing code compiled for gfx1030 on gfx103{1,2,3,4,5,6} hardware, so the
lookup fails and incorrect results are produced.

This problem be observed seen in the CI results for rocprim on gfx1031 [1],
gfx1032 [2], and gfx1034 [3]. This is also probably the cause for
rocsparse failures in prune_dense2csr_by_percentage on those architectures 
[4][5][6].

Sincerely,
Cory Bloor

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1031/r/rocprim/1154/log.gz
[2]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1032/r/rocprim/832/log.gz
[3]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/r/rocprim/210/log.gz
[4]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1031/r/rocsparse/1156/log.gz
[5]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1032/r/rocsparse/834/log.gz
[6]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1034/r/rocsparse/213/log.gz

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
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 librocprim-tests depends on:
ii  libamdhip64-5  5.2.3-13
ii  libc6  2.37-12
ii  libgcc-s1  13.2.0-5
ii  libstdc++6 13.2.0-5

librocprim-tests recommends no packages.

librocprim-tests suggests no packages.

-- no debconf information

Bug#1043419: raising missing trigger interest to serious

[Helmut Grohne]

Control: severity -1 serious

I am raising the bug about missing trigger interest to severity serious. The
systemd package has now moved its units to /usr/lib/systemd and debhelper will
also now install its units there. Hence, the trigger is now practically broken.
I know that the bug is already fixed in experimental and that's great, but it
still affects trixie and sid, so by raising it to serious, we get rid of the
bug in trixie before too long (either via upload or autoremove).

Helmut