Bug#1063830: libtorrent-rasterbar2.0: libtorrent does not handle case sensitive torrents

[axet]

Package: libtorrent-rasterbar2.0
Version: 2.0.8-1+b1
Severity: normal

Dear Maintainer,

qbittorrent failed to save / resume torrent with duplicate filenames (case 
sensitive) with following error:

13.02.2024 09:50 - Failed to restore torrent. Files were probably moved or 
storage isn't accessible. Torrent: "TheException". Reason: "TheException fast 
resume rejected. 
file_stat(/media/axet/1TB/Games/TheException/TheException/readme.1.txt): 
mismatching file size"

 1) create torrent with "ReadMe.txt" and "readme.txt" in the same folder.
 2) restart app.

No patch yet. Upstream issue:

https://github.com/arvidn/libtorrent/issues/7607

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

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

Versions of packages libtorrent-rasterbar2.0 depends on:
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libssl3 3.0.11-1~deb12u2
ii  libstdc++6  12.2.0-14

libtorrent-rasterbar2.0 recommends no packages.

libtorrent-rasterbar2.0 suggests no packages.

-- no debconf information

Bug#1063831: qbittorrent 4.5.2 unable to load big torrent files

[axet]

Package: qbittorrent
Version: 4.5.2-3+deb12u1
Severity: normal

Dear Maintainer,

qbittorrent 4.5.2 faild to load 20MB torrent files due to bencode max
memory size.

Issue described in here:

https://github.com/qbittorrent/qBittorrent/issues/20403

Patch available from link above. Value of 1000 came from 
src/base/bittorrent/torrentinfo.cpp

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

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

Versions of packages qbittorrent depends on:
ii  libc62.36-9+deb12u4
ii  libgcc-s112.2.0-14
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5network5   5.15.8+dfsg-11
ii  libqt5sql5   5.15.8+dfsg-11
ii  libqt5sql5-sqlite5.15.8+dfsg-11
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libqt5xml5   5.15.8+dfsg-11
ii  libssl3  3.0.11-1~deb12u2
ii  libstdc++6   12.2.0-14
ii  libtorrent-rasterbar2.0  2.0.8-1+b1
ii  zlib1g   1:1.2.13.dfsg-1

qbittorrent recommends no packages.

qbittorrent suggests no packages.

-- no debconf information

Bug#1063769: Segfault on latest stable nftables package on Bullseye

[Jordi MORILLO]

It's a duplicated of case 
#1063690 so you can 
close this case.
Best regards

Bug#1063725: xkb-data: keymap alias 'dvorak' no longer available

[Timo Aaltonen]

Michael Gold kirjoitti 11.2.2024 klo 21.31:

Package: xkb-data
Version: 2.41-1

Dear Maintainer,

I noticed a "setxkbmap dvorak" command, run by my X session scripts,
starting giving an error with the latest xkb-data:
Error loading new keyboard description

It started after upgrading the following 4 packages together:
console-setup:amd64 (1.223, 1.226)
console-setup-linux:amd64 (1.223, 1.226)
xkb-data:amd64 (2.38-2, 2.41-1),
keyboard-configuration:amd64 (1.223, 1.226)
(The xkb-data changes look the most substantial, which is why I've filed
against that package.)

My keyboard layout was still as expected, but downgrading those packages
to the versions from 'testing' eliminated the error.

Here's the output of "setxkbmap -verbose 10 -print dvorak" with 2.38-2:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)"   };
xkb_types { include "complete"};
xkb_compat{ include "complete"};
xkb_symbols   { include 
"pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)"  };
xkb_geometry  { include "pc(pc105)"   };
};

And with 2.41-1:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)"   };
xkb_types { include "complete"};
xkb_compat{ include "complete"};
xkb_symbols   { include 
"pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)"  };
xkb_geometry  { include "pc(pc105)"   };
};

The contents of /etc/default/keyboard:
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="dvorak"
XKBOPTIONS="ctrl:swapcaps"

BACKSPACE="guess"

My X session was configured to run this command at startup:
setxkbmap -option 'ctrl:swapcaps' -option 'compose:menu' dvorak

After looking at the above output, I changed "dvorak" to "us(dvorak)" in
the command, and it worked without error.

It's not clear whether support for just "dvorak" was dropped on purpose,
but I don't recall seeing any deprecation warnings about it, and don't
see any relevant Debian changelog or "NEWS" entry.

- Michael


Hi,

This was likely due to

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/470ad2cd8fea84d7210377161d86b31999bb5ea6

I'll add a NEWS entry for this too.


--
Timo Aaltonen
Kernel Enablement
Canonical Ltd.

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Martin Steigerwald]

Martin Steigerwald - 13.02.24, 00:24:35 CET:
> This breaks compiling my own kernel with:
> 
> time eatmydata make -j16 bindeb-pkg LOCALVERSION=-t14

Work-around:

[…]etc/apt/preferences.d% cat kmod 
Explanation: Bug #1063804: FTBFS: depmod: FATAL: could not search modules: No 
such file or directory
Package: kmod libkmod2
Pin: version *
Pin-Priority: -3

Install kmod and libkmod2 31-1 from snapshot.debian.org.

Best,
-- 
Martin

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Salvatore Bonaccorso]

Hi Andreas,

On Mon, Feb 12, 2024 at 12:37:44AM +0100, Andreas Beckmann wrote:
> On 11/02/2024 21.36, Salvatore Bonaccorso wrote:
> > If I can add a comment: I (but note I'm not wearing a
> > nvidia-graphics-drivers maintainer hat) would support that, as there
> > are enough people affected by this. This is quite unfortunate and I'm
> > open to hear ideas how we can try to avoid such fallouts.
> 
> I was aware of the bug (#1062932) but not of the fact a point release was
> upcoming. Even if I had been aware of the point release I'm not sure if I
> had realized the impact of this bug to make me yell ;-)
> Perhaps once point release dates have been choosen, this could be announced
> to d-d-a@ as well.
> I'm not following debian-release@ ... -ENOTIME
> 
> > As you know we are strictly following upstream stable series (and
> > trying our best to keep an eye on as well regression reports upstream,
> > but OOT modules are not explicitly tested, so neither the nvidia ones)
> 
> Are autopkgtests being run for proposed-updates? That should have shown the
> issue.

Yes there are in fact autopkgtests being run, so this should have been
catched (and at least decided what to do, i.e. not release 6.1.76-1,
nod ideal, or deal during the still allowed window with the nvidia
drivers as well). But to be very honest: I did miss this regression
report on the overview page. At least according to Paul on IRC the
test should have been run.

> It was unfortunate that this upstream backported change appeared in
> proposed-updates first and in sid only a few days later. And the
> metapackages from linux-signed-amd64 are still depending on the version
> before this change was introduced ... so I only could reproduce the issue
> (and verify fixes) manually. (The module build test done during the package
> build did not use the regressing headers.)

Right, 6.6.15 upload to unstable had a couple of issues, first failing
to build the arch:all packages then the linux-signed-amd64 were
waiting to be processed, and once that happened, we have now a FTBFS
due to interaction with a new kmod upload (Filled #1063804). It is not
that usual that otherwise we would have that change in bookworm
(queued in proposed-updates) before we had a similar change in
unstable (or experimental).

> Then I had to spent quite some time verifying that the issue only happened
> on amd64 and since the 460 series (despite of ppc64el having even more calls
> to pfn_valid() dating back to the 418 series).

I would like to thank you again for the time you invested here to deal
with that issue!

> Andreas
> 
> PS: @Salvatore: Looking forward to see some linux 6.8 packages in
> experimental s.t. I can throw them in my module build chroot to see what
> breaks next :-) Or do you already have some early build available somewhere
> while experimental is still preparing 6.7?

We have to move 6.7.y next to unstable. But I'm not completely sure if
we are there yet, need to ask Bastian Blank about the plan. After that
experimental is freed we can go aehad with 6.8.y for experimental, but
there are yet no packages to test with :(

Regards,
Salvatore

Bug#1059308: python-cryptography: CVE-2023-50782

[Jérémy Lal]

Shouldn't this be assigned to openssl ?

Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1

[Dylan Aïssi]

Control: tag -1 patch

> While doing a rebuild of some node packages in Bookworm, it appears several
> packages (at least ~ 50 pkgs) no longer build with nodejs 
> 18.19.0+dfsg-6~deb12u1
> (from bookworm-security repo) while they still successfully build with nodejs
> 18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the
> same error:
> error TS2307: Cannot find module 'undici-types' or its corresponding
> type declarations.

A fix for this issue has been proposed:
 https://salsa.debian.org/js-team/node-undici/-/merge_requests/2/

Thanks Ryan!

Best regards,
Dylan

Bug#1063771: Please update to version 42, needed for new dnspython

[Jérémy Lal]

Will do, but right now there are a bunch of rust dependencies that need to
be upgraded.

Bug#1063832: mailman3: Wrong database scheme for postgresql not resolved for stable

[Paolo Miotto]

Package: mailman3
Version: 3.3.8-2~deb12u1
Severity: important

Dear Maintainer,

this bug is related to bug #1040708, where an issue with database scheme for
postgresql was resolved in package version mailman3/3.3.8-3.

That version never landed in stable, despite the bug was tagged bookworm
(actual stable), so using mailman3 with postgres doesn't work out of the
box in stable/bookworm, as the service refuses to start.

I don't know if this is related with a transition occurring with mailman3
packages, but I think it is worth to leave the version 3.3.8-3 to reach
the stable repository.

Thanks


Paolo

Bug#1063475: RM: lazarus -- NVIU; Newer version is available

[peter green]

retitle 1063475 RM: lazarus 2.2.6+dfsg2-2 -- NVIU; Newer version is available



lazarus| 2.2.6+dfsg2-2 | unstable   | source, all
lazarus| 3.0+dfsg1-7   | unstable   | source, all


To clarify, this is a request to remove the outdated lazarus packages that are
still hanging around, not to remove lazarus completely.

Looking at the cruft report it seems that the packages are still hanging round
because some  formerly arch all packages became arch specific and this is
confusing dak's dependency checks.

Bug#1032008: mpich FTBFS on ppc64

[Adrian Bunk]

On Sun, Feb 26, 2023 at 04:00:12PM +0200, Adrian Bunk wrote:
> Source: mpich
> Version: 4.0.1-1
> Severity: important
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=mpich&arch=ppc64
> 
> ...
> checking for ucp/api/ucp.h... no
> configure: error: --with-ucx is given but not found
> 
> 
> This is due to the following in debian/rules:
> 
> UCX_ARCH:= amd64  ppc64el arm64
> ...
> ifneq (,$(findstring  $(DEB_HOST_ARCH),$(UCX_ARCH)))
> DEVICE:= --with-device=ch4:ucx
>   UCX:= --with-ucx=/usr
>   #PMIX:=  --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2
> endif
> 
> 
> The problem is that "ppc64" is a substring of "ppc64el".
> 
> "filter" instead of "findstring" fixes the problem.

Alastair, could you include this change in the next upload?

Thanks
Adrian

Bug#1063752: custodian: Inappriate maintainer address

[Drew Parsons]

Source: custodian
Followup-For: Bug #1063752
X-Debbugs-Cc: Debichem Team 
Control: reassign 1063752 lists.debian.org
Control: affects 1063752 src:custodian

Scott Kitterman reported that lists.alioth.debian.org is bouncing
emails from debian official addresses (ftpmas...@ftp-master.debian.org
in this case, processing packages for the Debichem team with Maintainer
address debichem-de...@lists.alioth.debian.org)

Scott filed the bug against src:custodian, but the bug must be in the
mailing list daemon, so I'm reassigning the bug to lists.debian.org

Bug#1063675: nvidia-graphics-drivers 525.147.05-6~deb12u1 flagged for acceptance

[Patrick ZAJDA]

Le 13/02/2024 à 00:58, Jonathan Wiltshire a écrit :

It will be released in bookworm at the next point release, and all being
well earlier than that via bookworm-updates.

Testing of the packages through proposed-updates before then is
appreciated, as always.



Thanks.

FYI I've tested with proposed-updates (with some pining to only update 
NVIDIA related) and was able to update to 6.1.0-18 then reboot successfully.


--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063833: mpich: ftbfs in sid due to newer slurm-wlm

[Gianfranco Costamagna]

Source: mpich
Version: 4.1.2-2
Severity: serious
tags: patch

Hello, the package now FTBFS due to newer slurm-wlm

see e.g. 
https://buildd.debian.org/status/fetch.php?pkg=mpich&arch=i386&ver=4.1.2-2%2Bb3&stamp=1707819996&raw=0

  | ^~~~
./modules/mpl/include/mpl_atomic_c11.h:102:1: note: in expansion of macro 
‘MPLI_ATOMIC_DECL_FUNC_VAL’
  102 | MPLI_ATOMIC_DECL_FUNC_VAL(int64_t, int64, atomic_int_fast64_t, 
int_fast64_t)
  | ^
lib/tools/bootstrap/external/slurm_query_node_list.c: In function 
‘list_to_nodes’:
lib/tools/bootstrap/external/slurm_query_node_list.c:29:16: error: storage size 
of ‘hostlist’ isn’t known
   29 | hostlist_t hostlist;
  |^~~~
make[5]: *** [Makefile:1350: 
lib/tools/bootstrap/external/slurm_query_node_list.lo] Error 1

cherry-picking upstream fix 
https://github.com/pmodels/mpich/commit/7a28682a805acfe84a4ea7b41cea079696407398
is enough to make the build succeed.

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062932: Confirm, Bookworm still broken

[Patrick ZAJDA]

Le 13/02/2024 à 08:55, Kate Korsaro a écrit :

Hi guys,
tried an update this morning and it still broken for Bookworm.
It is not available in bookworm-updates yet, only in 
bookworm-proposed-updates then should be available in bookworm-updates 
later.

See Bug#1063675 for more information.
--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063772: postfix-mysql upgrade add map in dynamicmaps.cf after postfix restart

[Vincent Caron]

Hello,

I have exactly the same problem with Debian 11 (for at least the last 3
Postfix upgrades). I am using Postfix with MySQL and PCRE maps.

Bug#1063237: tmux: crash when pasting into dead pane

[Romain Francoise]

Fix merged upstream:

https://github.com/tmux/tmux/commit/4bdb855020d266ea0a480a53e13c806fcaad9b45

And tmux 3.4 is also out, so it'll be part of that upload.

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

Bug#1061063: armhf: h5py's tests expose unaligned memory accesses during the build

[Graham Inggs]

Control: severity -1 important
Control: tags -1 + patch

hickle has been auto-removed from testing due to #1060804.
I'm lowering the severity so that h5py can migrate.

Bug#1063834: displayfont man page: "showfont (no such manpage?)"

[Jakub Wilk]

Package: console-cyrillic
Version: 0.9-17.2
Severity: minor

The SEE ALSO section of the displayfont(1) manual page says:

   showfont (no such manpage?)

But it does exist:

   $ dpkg -S showfont.1
   x11-xfs-utils: /usr/share/man/man1/showfont.1.gz

--
Jakub Wilk

Bug#1058959: python-quantities: please removed old suggestion for python3-unittest2

[James Addison]

Followup-For: Bug #1058959
Control: forwarded -1 
https://salsa.debian.org/science-team/python-quantities/-/merge_requests/1

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

[Per Lundberg]

For reference, this patch was merged into mainline JDK in 
https://github.com/openjdk/jdk/pull/17628, and will be part of the upcoming JDK 
23 release. (The patch that was merged there is basically the same as in 
https://salsa.debian.org/openjdk-team/openjdk/-/blob/2aebf9c2fb202cf3648cbeda9d96d8b29650e79f/debian/patches/8307977-proposed.diff,
 but with some comments modified).

Best regards,
Per

From: Per Lundberg 
Sent: Monday, January 29, 2024 10:17
To: 1034...@bugs.debian.org <1034...@bugs.debian.org>; d...@ubuntu.com 

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

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

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

Best regards,
Per


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

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

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

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

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


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

Bug#1034601:

[Per Lundberg]

For reference, this was fixed in openjdk-11 (11.0.22+7-2) because of this 
patch: 
https://salsa.debian.org/openjdk-team/openjdk/-/blob/2aebf9c2fb202cf3648cbeda9d96d8b29650e79f/debian/patches/8307977-proposed.diff.
 I think it would make sense to apply the same patch could to openjdk-17 as 
well, so we can get this bug closed.

(The bug has been fixed upstream as part of 
https://github.com/openjdk/jdk/pull/17628, but the fix is not yet backported to 
JDK 17 in upstream)

Bug#1063835: roundcube: When upgrading from roundcube 1.4.15+dfsg.1-1~deb11u2 to 1.6.5+dfsg-1~deb12u1 error "table roundcube.filestore does not exist" is thrown, not handled

[Andrew Gallagher]

Package: roundcube
Version: 1.6.5+dfsg-1~deb12u1
Severity: important

When upgrading roundcube to the latest version, the mariadb schema upgrade 
fails due to a missing table "roundcube.filestore".
This table apparently never existed, however this did not seem to cause any 
noticeable issues before the upgrade.

It appears therefore that the schema migration makes too many assumptions about 
the state of the current database,
and so does not handle the missing (but apparently optianal) table gracefully. 
Missing tables should be created if they do not exist..



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

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

Versions of packages roundcube depends on:
ii  dpkg1.21.22
ih  roundcube-core  1.6.5+dfsg-1~deb12u1

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.19
ii  debconf [debconf-2.0]   1.5.77
ii  dpkg1.21.22
ii  libjs-bootstrap44.5.2+dfsg1-8~deb11u1
ii  libjs-codemirror5.59.2+~cs0.23.109-1
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-minicolors 2.2.6+dfsg-4
ii  libjs-jquery-ui 1.12.1+dfsg-8+deb11u1
ii  libjs-jstimezonedetect  1.0.6-5
ii  libmagic1   1:5.39-3+deb11u1
ii  php 2:7.4+76
ii  php-auth-sasl   1.1.0-1
ii  php-common  2:76
ii  php-guzzlehttp-guzzle   7.4.5-1
ii  php-intl2:7.4+76
ii  php-mail-mime   1.10.10-1
ii  php-masterminds-html5   2.7.4+dfsg-2
ii  php-mbstring2:7.4+76
ii  php-net-sieve   1.4.6-1
ii  php-net-smtp1.10.1-1
ii  php-pear1:1.10.12+submodules+notgz+20210212-1
ii  php7.4 [php]7.4.33-1+deb11u4
ii  php7.4-cli [php-cli]7.4.33-1+deb11u4
ii  php7.4-intl [php-intl]  7.4.33-1+deb11u4
ii  php7.4-json [php-json]  7.4.33-1+deb11u4
ii  php7.4-mbstring [php-mbstring]  7.4.33-1+deb11u4
ii  roundcube-mysql 1.6.5+dfsg-1~deb12u1
ii  ucf 3.0043

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi] 2.4.57-2
pn  php-enchant 
ii  php-gd  2:7.4+76
ii  php7.4-gd [php-gd]  7.4.33-1+deb11u4
pn  roundcube-skin-classic  
pn  roundcube-skin-larry

Versions of packages roundcube-core suggests:
pn  php-bacon-qr-code   
pn  php-bjeavons-zxcvbn-php 
pn  php-crypt-gpg   
pn  php-net-ldap3   
pn  php-roundcube-rtf-html-php  
iu  roundcube-plugins   1.6.5+dfsg-1~deb12u1

-- debconf information:
  roundcube/mysql/admin-pass: (password omitted)
  roundcube/mysql/app-pass: (password omitted)
  roundcube/app-password-confirm: (password omitted)
  roundcube/password-confirm: (password omitted)
  roundcube/internal/skip-preseed: false
  roundcube/internal/reconfiguring: false
  roundcube/mysql/authplugin: default
  roundcube/database-type: mysql
  roundcube/db/app-user: roundcube@localhost
  roundcube/remote/port:
  roundcube/missing-db-package-error: abort
  roundcube/hosts:
  roundcube/db/dbname: roundcube
  roundcube/remote/newhost:
  roundcube/language: en_US
  roundcube/purge: false
  roundcube/dbconfig-remove: true
  roundcube/remove-error: abort
  roundcube/restart-webserver: true
  roundcube/dbconfig-upgrade: true
  roundcube/mysql/admin-user: debian-sys-maint
  roundcube/upgrade-error: abort
  roundcube/dbconfig-reinstall: false
  roundcube/passwords-do-not-match:
  roundcube/install-error: abort
  roundcube/remote/host: localhost
  roundcube/upgrade-backup: true
  roundcube/mysql/method: Unix socket
  roundcube/reconfigure-webserver: apache2, lighttpd
  roundcube/dbconfig-install: true

debian-bugs-dist@lists.debian.org

[Greg Wooledge]

Package: coreutils
Version: 9.1-1
Severity: minor
Tags: upstream

The info page for shred includes this example code:

 i=$(mktemp)
 exec 3<>"$i"
 rm -- "$i"
 echo "Hello, world" >&3
 shred - >&3
 exec 3>-

The last line is incorrect.  It should be "exec 3>&-" which closes file
descriptor 3.  As written, the example code creates or truncates a
file literally named "-" instead.

This same error appears on
https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html
(as of today) so I believe it's an upstream bug.

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u4
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1063838: tmux: new upstream released: tmux 3.4

[Yukiharu YABUKI]

Package: tmux
Version: 3.3a-5
Severity: wishlist
X-Debbugs-Cc: yyab...@debian.org

Dear Maintainer,

As you might know tmux 3.4 released.

You can see https://github.com/tmux/tmux/releases/tag/3.4

And I relaized This release has SIXEL feature.

If you enable '--enable-sixel', I'd happy to use the feature.

Best Resgards
Yukiharu.

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

Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 tmux depends on:
ii  libc62.37-15
ii  libevent-core-2.1-7  2.1.12-stable-8
ii  libtinfo66.4+20240113-1
ii  libutempter0 1.2.1-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#1063838: tmux: new upstream released: tmux 3.4

[Romain Francoise]

Hi,

Yes, I am aware of it and will update the package later today, in sid.

On Tue, Feb 13, 2024 at 1:33 PM Yukiharu YABUKI  wrote:
> If you enable '--enable-sixel', I'd happy to use the feature.

If you want to try it, the tmux package in experimental is very close
to 3.4 and has had Sixel enabled for a few months already.

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

Bug#1063839: lwm: fixed bugs, lintian clean, cross compiles, please review

[Nicholas Bamber]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: debian-cr...@lists.debian.org, s...@debian.org, 
np.bam...@gmail.com

I have forked  lwm so that my work can be reviewed: 
https://salsa.debian.org/npbamber/lwm
If this is approved please grant me permission so I can keep the repository up 
to date.

I am happy with my work here, but I can list somethings potential sponsors 
might appreciate
being pointed out:

#920091 - adoption: I have been through the Debian induction process about a 
decade ago. So I
know what packaging involves even if I have things to learn or relearn. My life 
is more 
stable now than then, so I am not going to take on long term commitments I 
can't handle.  I
will review packages before trying to adopt them. If I don't feel
comfortable with this commitment I will just do a QA upload, not touch the 
package
or perhaps even discuss removal of a package.

#1031650 - I fixed the trivial typo. However I strongly believe a minimalist 
window manager should
strongly advertise how to start an xterm as it can be hard to get started 
otherwise. So
I made this clear in the control description.

#1051010 - I have done what I feel most appropriate here. The first part 
(systemd environment) is 
easy to test. The second part - portals - are a bit harder. My journey there is 
documented on the
bug report. If this is not adequate I need some advice.

Cross compilation: I had to undertake radical surgery here. The general 
strategy was to start
with upstream's backup makefile and make it as debhelper compliant as possible. 
However
on the opertaing table the patient went through numerous crises. Like flags not 
being passed
onto the compiler (notably dropping hardening.) I checked the old build logs 
against the new
build logs. There were decisions to be made. I was biased to caution but I 
sought
strategiclaly not to get in debhelper's way. All these issues are now resolved. 
It was quite
hard to know how to describe this in the changelog.

Lintian: the only overrides are because upstream is inactive and I see no point 
in contacting them.

Rules-Requires-Root: It clearly does not require root to build and I have 
marked it as such.
However the Lintian explanation for this warning is a little bit scary. I did 
try it both before
and after making the change and the only diffoscope difference appeared to be 
an 8 
year difference in certain timestamps. I found this pretty odd.

I really appreciate any time and effort you can put into this.

Nicholas

Bug#1063840: RFS: python-airspeed/0.6.0-1 -- Python template engine

[MOESSBAUER, Felix]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-airspeed":

 * Package name : python-airspeed
   Version  : 0.6.0-1
   Upstream contact : Steve Purcell 
 * URL  : https://github.com/purcell/airspeed
 * License  : BSD-2-Clause
 * Vcs  :
https://salsa.debian.org/python-team/packages/python-airspeed
   Section  : python

The source builds the following binary packages:

  python3-airspeed - Python template engine

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

  https://mentors.debian.net/package/python-airspeed/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-airspeed/python-airspeed_0.6.0-1.dsc

Changes since the last upload:

 python-airspeed (0.6.0-1) unstable; urgency=medium
 .
   * fix package short description
   * update debian standards version to 4.6.2
   * add multi-arch specifier
   * execute tests with unittest
   * New upstream version 0.6.0

Regards,

-- 
Siemens AG, Technology
Linux Expert Center

Bug#1063835: roundcube: When upgrading from roundcube 1.4.15+dfsg.1-1~deb11u2 to 1.6.5+dfsg-1~deb12u1 error "table roundcube.filestore does not exist" is thrown, not handled

[Guilhem Moulin]

Control: reassign -1 roundcube-mysql
Control: tag - 1 unreproducible

On Tue, 13 Feb 2024 at 11:47:12 +, Andrew Gallagher via 
Pkg-roundcube-maintainers wrote:
> When upgrading roundcube to the latest version, the mariadb schema
> upgrade fails due to a missing table "roundcube.filestore".
> This table apparently never existed, however this did not seem to
> cause any noticeable issues before the upgrade.

It definitely is part of the schema and should have been created when
you installed roundcube-mysql ≥1.4.1-1 or upgraded from <1.4.  Piuparts
doesn't croak either.

> It appears therefore that the schema migration makes too many assumptions 
> about the state of the current database,
> and so does not handle the missing (but apparently optianal) table
> gracefully. Missing tables should be created if they do not exist..

Schema upgrades come from upstream so that would be a (wishlist)
upstream bug.  When using roundcube-{mysql,pgsql,sqlite3} I think it's
reasonable to assume the schema version based on the roundcube version
alone.  dbconfig has no way to guess if/how the database has been
manually tampered with, and I'm not sure a more robust migration is even
doable reliably as it's not only about table creation but also indices,
foreign keys, types and constraints on columns etc.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1063841: jami quits after left mouse click on system tray icon

[Anonymous 648]

Package: jami
Version: 20230206.0~ds2-1.1
Severity: normal
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

0) I use AwesomeWM window manager
1) Run jami. Now jami icon appears on WM system tray
2) Move window focus to jami window
3) Left click jami icon in sys tray
4) jami just quits without any warning

Expected behaviour: jami continuous to work


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

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

Versions of packages jami depends on:
ii  jami-daemon 20230206.0~ds2-1.1
ii  libc6   2.36-9+deb12u4
ii  libgcc-s1   12.2.0-14
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.6-2
ii  libnm0  1.42.4-1
ii  libnotify4  0.8.1-1
ii  libqrencode44.1.1-1
ii  libqt6core5compat6  6.4.2-1
ii  libqt6core6 6.4.2+dfsg-10
ii  libqt6dbus6 6.4.2+dfsg-10
ii  libqt6gui6  6.4.2+dfsg-10
ii  libqt6multimedia6   6.4.2-5
ii  libqt6network6  6.4.2+dfsg-10
ii  libqt6positioning6  6.4.2-1
ii  libqt6qml6  6.4.2+dfsg-1
ii  libqt6quick66.4.2+dfsg-1
ii  libqt6sql6  6.4.2+dfsg-10
ii  libqt6sql6-sqlite   6.4.2+dfsg-10
ii  libqt6svg6  6.4.2-2
ii  libqt6widgets6  6.4.2+dfsg-10
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2+deb12u2
ii  libxcb1 1.15-1
ii  qml6-module-qt-labs-platform6.4.2+dfsg-1
ii  qml6-module-qt-labs-qmlmodels   6.4.2+dfsg-1
ii  qml6-module-qt5compat-graphicaleffects  6.4.2-1
ii  qml6-module-qtmultimedia6.4.2-5
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg-1
ii  qml6-module-qtquick 6.4.2+dfsg-1
ii  qml6-module-qtquick-controls6.4.2+dfsg-1
ii  qml6-module-qtquick-dialogs 6.4.2+dfsg-1
ii  qml6-module-qtquick-layouts 6.4.2+dfsg-1
ii  qml6-module-qtquick-shapes  6.4.2+dfsg-1
ii  qml6-module-qtquick-templates   6.4.2+dfsg-1
ii  qml6-module-qtquick-window  6.4.2+dfsg-1
ii  qml6-module-qtquick3d-spatialaudio  6.4.2-5

jami recommends no packages.

jami suggests no packages.

-- no debconf information

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

[Bert]

Package: openssh-server
Version: 1:9.2p1-2+deb12u2
Severity: important
Tags: ipv6
X-Debbugs-Cc: b...@rptbgd.firenzee.com

Dear Maintainer,

I configured SSH with a static IPv6 ListenAddress.
During bootup, SSH tries to start before the IPv6 address has been fully bound 
to the host (ie during duplicate address detection)
This results in SSH failing to start with "Cannot bind any address" and a 
return code of 255.
The systemd unit file for ssh contains "RestartPreventExitStatus=255" which 
causes it to give up when it encounters this error.
In a cloud environment this is a critical failure as it renders the host 
inaccessible.
The same thing occurs if the static IPv6 address is assigned a different way 
(eg via SLAAC or DHCPv6)
If you remove this line, systemd tries again and succeeds once the address has 
been bound to the host. I generally also add "StartSec=15s" to prevent it 
trying too frequently.
This manual change is not persistent, as it gets overwritten next time you 
update the package.

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

Kernel: Linux 6.1.0-10-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9+deb12u4
ii  libcom-err21.47.0-2
ii  libcrypt1  1:4.4.33-2
ii  libgssapi-krb5-2   1.20.1-2+deb12u1
ii  libkrb5-3  1.20.1-2+deb12u1
ii  libpam-modules 1.5.2-6+deb12u1
ii  libpam-runtime 1.5.2-6+deb12u1
ii  libpam0g   1.5.2-6+deb12u1
ii  libselinux13.4-1+b6
ii  libssl33.0.11-1~deb12u2
ii  libsystemd0252.22-1~deb12u1
ii  libwrap0   7.6.q-32
ii  openssh-client 1:9.2p1-2+deb12u2
ii  openssh-sftp-server1:9.2p1-2+deb12u2
ii  procps 2:4.0.2-3
ii  runit-helper   2.15.2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  252.22-1~deb12u1
pn  ncurses-term 
pn  xauth

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: true
  openssh-server/password-authentication: false

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

[Colin Watson]

On Tue, Feb 13, 2024 at 01:13:17PM +, Bert wrote:
> I configured SSH with a static IPv6 ListenAddress.
> During bootup, SSH tries to start before the IPv6 address has been fully 
> bound to the host (ie during duplicate address detection)
> This results in SSH failing to start with "Cannot bind any address" and a 
> return code of 255.
> The systemd unit file for ssh contains "RestartPreventExitStatus=255" which 
> causes it to give up when it encounters this error.
> In a cloud environment this is a critical failure as it renders the host 
> inaccessible.
> The same thing occurs if the static IPv6 address is assigned a different way 
> (eg via SLAAC or DHCPv6)
> If you remove this line, systemd tries again and succeeds once the address 
> has been bound to the host. I generally also add "StartSec=15s" to prevent it 
> trying too frequently.
> This manual change is not persistent, as it gets overwritten next time you 
> update the package.

I suggest that in such unusual configurations you should use the After=
directive in the [Unit] section to ensure that ssh.service doesn't start
until the relevant other systemd unit has been started.  You can do this
in a way that persists across upgrades using a drop-in unit; see "man
systemd.unit" or use "systemctl edit ssh.service".

However, a simpler solution might well be to remove ListenAddress and
instead use firewall rules to restrict incoming SSH connections to only
the desired address(es), as is recommended in README.Debian.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1059223: Workaround for rustc toolchain bug

[Mate Kukri]

Hello,

We have a similar issue in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2049904

To me this seems like a rust linking issue, the same C library
compiled with cc, then linked against a C stub program links just fine
for me.

In comparison rustc tries to be annoyingly clever and calls `cc` to
link with `-nodefaultlibs` and tries to manually provide all the
required libraries, which makes it fail.

The direct cause of the error is a library ordering issue, `-lc`
should always come after all C static libs and object files in a link
command, but it does not.

It seems that meson doesn't pass `-Clink-arg=-lc` to `rustc` at all by
default (which it probably shouldn't need to), and it's rustc itself
that emits `-lc` at the wrong location.

A workaround is as follows:
```
dep_libc = declare_dependency(link_args : '-lc')

l = static_library(
  'c_accessing_zlib',
  'c_accessing_zlib.c',
  dependencies: [dep_zlib, dep_libc],
)
```

It is rather unweildly to read, but here's an example of an offending
link invocation by rustc:
```
LC_ALL="C" 
PATH="/usr/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
VSLANG="1033" "cc" "/tmp/rustcqxuAcC/symbols.o"
"prog.p/prog.prog.3a9e8efe5d7989d1-cgu.0.rcgu.o"
"prog.p/prog.2valzr4aprd78wdd.rcgu.o" "-Wl,--as-needed" "-L" "." "-L"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-3f505df5bf7b6973.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-f7bbfb2a4f0106ba.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-799d4aa6228550fd.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-817c1781430e6007.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-ad8936af23d8ece8.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-fa9ccab1157705c6.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-0f0344f8af442a24.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-f1d03073262366fd.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-d2b728fe429f73fd.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-78f4eeade0e7b3f3.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-386abc7d4431b549.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-f2fbe97df215d47a.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1b9c021e2652ca95.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-a31e7b8703ef1917.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-67315dfc1c311b62.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-6f13ad92e9ef28f1.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-4647df6db5bfc191.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-7ca28360f44e13c1.rlib"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-bda26fded9d4fbc7.rlib"
"-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl"
"-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L"
"/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "prog"
"-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
"libc_accessing_zlib.a" "-lz"
```

Which was produced by the following rustc invocation:
```
rustc -C linker=cc --color=always -C debug-assertions=yes -C
overflow-checks=no --crate-type bin -g --crate-name prog --emit
dep-info=prog.d --emit link=prog --out-dir prog.p -C metadata=prog@exe
-Clink-arg=libc_accessing_zlib.a -Clink-arg=-lz -L. ../prog.rs
```

As a note, same issue repros on the latest nightly rustc also.

Fixing rustc instead of meson is the real solution, but I don't think
this should be holding up meson migrating, as such I am attaching a
workaround patch similar to the one I have proposed for Ubuntu.

Mate Kukri
diff -Nru meson-1.3.1/debian/changelog meson-1.3.1/debian/changelog
--- meson-1.3.1/debian/changelog	2023-12-26 17:31:01.0 +
+++ meson-1.3.1/debian/changelog	2024-02-13 14:32:10.0 +
@@ -1,3 +1,11 @@
+meson (1.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/lp2049904-workaround.patch: Add workaround for rustc emitting link
+flags in the wrong order (LP: #2049904) (#1059223)
+
+ -- Mate Kukri   Tue, 13 Feb 2024 14:32:10 +
+
 meson (1.3.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru meson-1.3.1/debian/control meson-1.3.1/debian/control
--- meson-1.3.1/debian/control	2023-12-11 19:52:05.0 +
+++ meson-1.3.1/debian/control	2024-02-13 13:23:33.0 +
@@ -1,5 +1,6 @@
 Source: meson
-Maintainer: Jussi Pakkanen 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Jussi Pakkanen 
 Section: devel
 Priority: optional
 Standards-Version: 4.6.2
diff -Nru meson-1.3.1/debian/patches/lp2049904-workaround.patch meson-1.3.1/debian/patches/lp2049904-workar

Bug#1063843: python3-electrum: Upgrade to Electrum 4.5.2 from 4.4.6 causes installation of texlive packages

[Hernán Cabañas]

Package: python3-electrum
Version: 4.5.2+dfsg-1
Severity: normal
X-Debbugs-Cc: hcaban...@gmail.com

The new version of python3-electrum (4.5.2) recommends texlive-fonts-extra, 
which 
depends on texlive-base. All in all, installing (or upgrading) Electrum 
normally 
would install 2.3GB of packages that are not needed.

I deferred the upgrade, the following information is for python3-electrum 4.4.6.

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

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

Versions of packages python3-electrum depends on:
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-jquery-ui-theme-ui-lightness  1.12.1+dfsg-1.1
ii  libsecp256k1-1  0.2.0-2
ii  node-qrcode-generator   1.4.4+dfsg-3
ii  python3 3.11.6-1
ii  python3-aiohttp 3.9.1-1
ii  python3-aiohttp-socks   0.8.4-1
ii  python3-aiorpcx 0.22.1-2
ii  python3-attr23.2.0-1
ii  python3-bitstring   4.1.4-1
ii  python3-certifi 2023.11.17-1
ii  python3-cryptography41.0.7-3
ii  python3-dnspython   2.5.0-1
ii  python3-protobuf3.21.12-8+b1
ii  python3-qrcode  7.4.2-4

Versions of packages python3-electrum recommends:
ii  fonts-dejavu-core  2.37-8

Versions of packages python3-electrum suggests:
pn  python3-btchip  
pn  python3-trezor  

-- no debconf information

Bug#1063844: iptables-persistent: In the flush_rules() function for IPv4 and IPv6, write a message when user-defined chains are found.

[Gabor Zsoldos]

Package: iptables-persistent
Version: 1.0.20
Severity: normal

Dear Maintainer,

When using user-defined chains in iptables, the netfilter-persistent flush 
command will write a message for each matching chain name like this:
iptables: Bad built-in chain name.

I suggest changing this regular expression in the flush_rules function of the 
15-ip4tables and 25-ip6tables scripts:
s/^:([A-Z]+).*/\1/p

to this:
s/^:([A-Z]+) [A-Z]+ .*/\1/p

This regular expression only captures the embedded chains, excluding 
user-defined chains, in the iptables-save output text.

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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to hu_HU.UTF8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables-persistent depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  iptables   1.8.9-2
ii  netfilter-persistent   1.0.20

iptables-persistent recommends no packages.

iptables-persistent suggests no packages.

-- debconf information excluded

Bug#1063845: unbound: Package 1.19.1 to fix CVE-2023-50387 and CVE-2023-50868

[Diederik de Haas]

Source: unbound
Version: 1.18.0-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Today 2 remote exploitable High Severity CVE's were published and
unbound has released version 1.19.1 to fix those.

Relevant links:
https://fosstodon.org/@nlnetlabs/111924266007688683
https://nlnetlabs.nl/news/2024/Feb/13/unbound-1.19.1-released/
https://kb.isc.org/docs/cve-2023-50387
https://kb.isc.org/docs/cve-2023-50868

I think a Release Critical Severity is more appropriate, but none of
the (by reportbug) presented options were applicable. It seems reportbug
then changed it to 'normal', which I manually changed to 'important'.

Fixing this bug would also fix bug #1051817, #1051818 and #1056631.

Link: https://bugs.debian.org/1051817
Link: https://bugs.debian.org/1051818
Link: https://bugs.debian.org/1056631

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZcuATAAKCRDXblvOeH7b
buedAP0QEqqGjjN4ZP8nu+WdKqrUWupLtsaN6FqEyNOd5OSp3QD/Wfh/sE5azFqf
99HKnBGhNVhrnxlNYIPlEjIns5pVDQs=
=thcd
-END PGP SIGNATURE-

Bug#1060995: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2)

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir

Bug#1063846: kwartz-client: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: kwartz-client
Version: 3.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kwartz-client's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


kwartz-client_3.0-2_pt.po.gz
Description: application/gzip

Bug#1063847: minissdpd: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: minissdpd
Version: 1.6.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for minissdpd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


minissdpd_1.6.0-2_pt.po.gz
Description: application/gzip

Bug#1063142: tiny-initramfs: diff for NMU version 0.1-5.1

[Tobias Frost]

Control: tags 1063142 + pending


Dear maintainer,

I've sponsore an NMU, prepared by Victor Westerhuis, for tiny-initramfs
(versioned as 0.1-5.1) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.

Regards.

diff -Nru tiny-initramfs-0.1/debian/changelog tiny-initramfs-0.1/debian/changelog
--- tiny-initramfs-0.1/debian/changelog	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/changelog	2024-02-11 11:48:39.0 +0100
@@ -1,3 +1,10 @@
+tiny-initramfs (0.1-5.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Decompress kernel modules included in initramfs. (Closes: #1063142)
+
+ -- Victor Westerhuis   Sun, 11 Feb 2024 11:48:39 +0100
+
 tiny-initramfs (0.1-5) unstable; urgency=medium
 
   [ Free Ekanayaka ]
diff -Nru tiny-initramfs-0.1/debian/control tiny-initramfs-0.1/debian/control
--- tiny-initramfs-0.1/debian/control	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/control	2024-02-05 11:33:39.0 +0100
@@ -24,7 +24,7 @@
 Package: tiny-initramfs-core
 Architecture: linux-any
 Multi-Arch: foreign
-Depends: cpio, ${shlibs:Depends}, ${misc:Depends}
+Depends: cpio, xz-utils, ${shlibs:Depends}, ${misc:Depends}
 Built-Using: ${Built-Using}
 Description: Minimalistic initramfs implementation (core tools)
  A very minimalistic initramfs implementation for booting Linux
diff -Nru tiny-initramfs-0.1/debian/extra/functions tiny-initramfs-0.1/debian/extra/functions
--- tiny-initramfs-0.1/debian/extra/functions	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/extra/functions	2024-02-05 11:33:39.0 +0100
@@ -208,9 +208,18 @@
   fi
   /sbin/modprobe --all --ignore-install --set-version="${VERSION}" --quiet --show-depends "$@" | \
 awk '$1 == "insmod" { print; }' | while read dummy_type mod_file mod_options ; do
-mod_name=${mod_file##*/}
+mod_name=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\1/')
+mod_compression=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\2/')
 if ! grep -q ^/"${mod_name}" "${initramfs_dir}/modules" ; then
-  cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  if [ "$mod_compression" = .xz ] ; then
+xzcat "${mod_file}" > "${initramfs_dir}/${mod_name}"
+  elif [ -z "$mod_compression" ] ; then
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  else
+echo "$0: WARNING: unable to determine compression for modules while adding modules" >&2
+echo "YOUR SYSTEM MIGHT NOT BOOT WITH THIS INITRAMFS." >&2
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  fi
   printf "%s\n" "/${mod_name}${mod_options:+ $mod_options}" >> "${initramfs_dir}/modules"
 fi
   done


signature.asc
Description: PGP signature

Bug#1063704: RFS: tiny-initramfs/0.1-5.1 [NMU] [RC] -- Minimalistic initramfs implementation (automation)

[Tobias Frost]

Hi Victor,

uploaded to DELAYED/5 and sent the nmudiff to the package.

Thanks for your contributions to Debian!

Cheers,
-- 
tobi

On Sun, Feb 11, 2024 at 12:10:48PM +0100, Victor Westerhuis wrote:
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-Cc: christ...@iwakd.de
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear mentors,
> 
> I am looking for a sponsor for "tiny-initramfs". The current version of
> the package is unusable with kernel packages with version 6.6.3-1~exp1
> or greater, because it does not support compressed modules. This NMU
> contains a targeted fix to enable support for XZ compressed modules.
> 
> I opened bug #1063142 6 days ago, so far without response from Christian
> Seiler, the maintainer. According to
> https://contributors.debian.org/contributor/chris_se/ Christian has not
> been active in Debian since 2021. That's why I decided to propose this
> NMU.
> 
> The below VCS URL is no longer active. The packaging was already
> imported in Salsa at https://salsa.debian.org/debian/tiny-initramfs and
> I'm testing some bigger packaging changes in my fork at
> https://salsa.debian.org/viccie30/tiny-initramfs.
> 
>  * Package name : tiny-initramfs
>Version  : 0.1-5.1
>Upstream contact : Christian Seiler 
>  * URL  : https://github.com/chris-se/tiny-initramfs/
>  * License  : GPL-2+, GPL-3+
>  * Vcs  : 
> https://anonscm.debian.org/cgit/collab-maint/tiny-initramfs.git
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   tiny-initramfs - Minimalistic initramfs implementation (automation)
>   tiny-initramfs-core - Minimalistic initramfs implementation (core tools)
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/tiny-initramfs/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/t/tiny-initramfs/tiny-initramfs_0.1-5.1.dsc
> 
> Changes since the last upload:
> 
>  tiny-initramfs (0.1-5.1) unstable; urgency=high
>  .
>* Non-maintainer upload.
>* Decompress kernel modules included in initramfs. (Closes: #1063142)
> 
> - --
> Vriendelijke groet, Kind regards,
> 
> Victor Westerhuis
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXIqzgTHHZpY3RvckB3
> ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+3QGD/90vFeAtsjTVWxw/W88+KV9WWp5HS4S
> t380m73WMciSqK8tA94xiem+6kwVkgTr5VeKvNPKBiRhlhkXVAJiqoVmg9xTY7oh
> bmOb9vghXCQ81+KINiE9gkBzYHdeTF+OLalN0Vjwn1R1yvQFNgi7uB/bArfR4qv8
> ytFzoqwFYURfuyVV5H+l5xhOl0q1BsNeShGQQGIhtH6rDvNhBdHIN6CAXMHkwIV8
> E1SAxVTvK2oSW7tU6wCYlwG2pXmPsFxRwjDE1l4gL3mjm0yRbfjMP8h9e7AfKVSf
> 9GD88xrNGPxsKGFgEfCkm4ndzoF3JqypIjpI8Xw8Zm/OHnrVobxAI84zvJB1tCeX
> fOYmO3HHOPzNDecJ6idWGddjXdjuQDGepbT/ZJ3qzxIPaCCPBMkGLrkmfM+sb1eg
> voRhYA36Fen1sM75rBbEx6b+tWhnb8b/lVmVHI553FhQoo+Off0/vaQGzVKf+AEw
> O5hU6e8BpPaAB8XyLYpehm1+fhO4MMf6jDhK+a7kFeHugPNL92GbnKKcbR5yVcoU
> TqlXYyU1rULqALU8fozYIm/pfZm9iPrCxe23Cj3ziJ0cRBteOe8L9FV+pzr8F5Q2
> 72JIYsJ3Q24tLVuLVyFzYVyR2Yp778+bz6bcj+b0C1mY9HmbnkaVrc0/q/R/KVMb
> 01fIJEX7ZkkTAg==
> =cfoH
> -END PGP SIGNATURE-
> 

Bug#770331: graphite-web: aliasByNode() gets upset by 'odd' characters in data paths

[Alexandre Rossi]

Version: 1.0.2+debian-1

Hi,

This seems to have been fixed in upstream commit:


https://github.com/graphite-project/graphite-web/commit/b71f0e01b7b8b90f8124fabcc591c1f77e04ffc3

And released in 1.0.0 (from what I can see in the changelog).

Feel free to reopen if I'm mistaken.

Thanks,

Alex

Bug#1063849: RM: monasca-api\ -- ROM; unmaintained

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove


Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Monasca is unmaintained and inactive. Let's remove it from Debian.

That's 2 source packages:
- monasca-api
- monasca-common

Cheers,

Thomas Goirand (zigo)

Bug#1063850: RM: freezer -- ROM; unmaintained

[Thomas Goirand]

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


As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Freezer is inactive and unmaintained. Please remove it from Debian.

That's 2 source packages:
- freezer
- freezer-api

Cheers,

Thomas Goirand (zigo)

Bug#1063848: RM: sahara -- ROM; unmaintained upstream

[Thomas Goirand]

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

Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Sahara is inactive and unmaintained. Let's remove it from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1059223: Workaround for rustc toolchain bug

[Mate Kukri]

Unfortunately this patch was rather optimistic, there are 7 or so more
tests failing similarly, so more is needed to workaround this.

On Tue, Feb 13, 2024 at 2:33 PM Mate Kukri  wrote:
>
> Hello,
>
> We have a similar issue in Ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2049904
>
> To me this seems like a rust linking issue, the same C library
> compiled with cc, then linked against a C stub program links just fine
> for me.
>
> In comparison rustc tries to be annoyingly clever and calls `cc` to
> link with `-nodefaultlibs` and tries to manually provide all the
> required libraries, which makes it fail.
>
> The direct cause of the error is a library ordering issue, `-lc`
> should always come after all C static libs and object files in a link
> command, but it does not.
>
> It seems that meson doesn't pass `-Clink-arg=-lc` to `rustc` at all by
> default (which it probably shouldn't need to), and it's rustc itself
> that emits `-lc` at the wrong location.
>
> A workaround is as follows:
> ```
> dep_libc = declare_dependency(link_args : '-lc')
>
> l = static_library(
>   'c_accessing_zlib',
>   'c_accessing_zlib.c',
>   dependencies: [dep_zlib, dep_libc],
> )
> ```
>
> It is rather unweildly to read, but here's an example of an offending
> link invocation by rustc:
> ```
> LC_ALL="C" 
> PATH="/usr/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> VSLANG="1033" "cc" "/tmp/rustcqxuAcC/symbols.o"
> "prog.p/prog.prog.3a9e8efe5d7989d1-cgu.0.rcgu.o"
> "prog.p/prog.2valzr4aprd78wdd.rcgu.o" "-Wl,--as-needed" "-L" "." "-L"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-3f505df5bf7b6973.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-f7bbfb2a4f0106ba.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-799d4aa6228550fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-817c1781430e6007.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-ad8936af23d8ece8.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-fa9ccab1157705c6.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-0f0344f8af442a24.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-f1d03073262366fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-d2b728fe429f73fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-78f4eeade0e7b3f3.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-386abc7d4431b549.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-f2fbe97df215d47a.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1b9c021e2652ca95.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-a31e7b8703ef1917.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-67315dfc1c311b62.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-6f13ad92e9ef28f1.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-4647df6db5bfc191.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-7ca28360f44e13c1.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-bda26fded9d4fbc7.rlib"
> "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl"
> "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "prog"
> "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
> "libc_accessing_zlib.a" "-lz"
> ```
>
> Which was produced by the following rustc invocation:
> ```
> rustc -C linker=cc --color=always -C debug-assertions=yes -C
> overflow-checks=no --crate-type bin -g --crate-name prog --emit
> dep-info=prog.d --emit link=prog --out-dir prog.p -C metadata=prog@exe
> -Clink-arg=libc_accessing_zlib.a -Clink-arg=-lz -L. ../prog.rs
> ```
>
> As a note, same issue repros on the latest nightly rustc also.
>
> Fixing rustc instead of meson is the real solution, but I don't think
> this should be holding up meson migrating, as such I am attaching a
> workaround patch similar to the one I have proposed for Ubuntu.
>
> Mate Kukri

Bug#1063701: Fixed it

[kritomas]

After installing libstdc++-14-dev, it fixed itself, on both clang++, and
clang++ built from upstream.

Bug#1063851: libxml++2.6: Newer version exists in the 2.x branch

[Guillermo Frontera]

Package: libxml++2.6-2v5
Version: 2.40.1-3build3
Severity: wishlist
File: libxml++2.6
X-Debbugs-Cc: gfrontera@gmail.com

Dear Maintainer,

The libxml++ project moved to GitHub (as announced here: 
https://mail.gnome.org/archives/libxmlplusplus-list/2020-January/msg0.html).
 However, the tracker (https://tracker.debian.org/pkg/libxml++2.6) is still 
monitoring the old repository.

Since then, several new versions have been released in the 2.x branch, the 
latest being 2.42.3 (whereas the latest tracked version is 2.40.1). The latest 
version is available at 
https://github.com/libxmlplusplus/libxmlplusplus/releases/tag/2.42.3.

Please, update the Debian Package Tracker with the latest homepage and Git repo 
and provide a packaged version with the latest version of the library in the 
2.x branch.

Homepage: https://libxmlplusplus.github.io/libxmlplusplus/
Git repo: https://github.com/libxmlplusplus/libxmlplusplus

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

Kernel: Linux 6.5.0-17-generic (SMP w/18 CPU threads; PREEMPT)
Locale: LANG=Default.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
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 libxml++2.6-2v5:amd64 depends on:
ii  libc6  2.35-0ubuntu3.6
ii  libgcc-s1  12.3.0-1ubuntu1~22.04
ii  libglibmm-2.4-1v5  2.66.2-2
ii  libstdc++6 12.3.0-1ubuntu1~22.04
ii  libxml22.9.13+dfsg-1ubuntu0.3

libxml++2.6-2v5:amd64 recommends no packages.

libxml++2.6-2v5:amd64 suggests no packages.

-- debconf information excluded

Bug#1063852: pdns-recursor: crafted DNSSEC records in a zone can lead to a denial of service in Recursor (CVE-2023-50387 CVE-2023-50868)

[Salvatore Bonaccorso]

Source: pdns-recursor
Version: 4.9.2-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for pdns-recursor.

CVE-2023-50387[0] and CVE-2023-50868[1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-50387
https://www.cve.org/CVERecord?id=CVE-2023-50387
[1] https://security-tracker.debian.org/tracker/CVE-2023-50868
https://www.cve.org/CVERecord?id=CVE-2023-50868
[2] 
https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6-4-9-3-5-0-2-released

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1058890: new try

[Dr . André Desgualdo Pereira]

Adding "intel_iommu=off" to kernel boot does NOT change anything. 

Bug#1063853: RM: wims-moodle -- ROM; this package works only wil moodle version 2

[Georges Khaznadar]

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

Hello, please remove the package wims-moodle, which works only with Moodle
version 2.
So, it may have some interest for people using oldstable or oldoldstable, but
it is
definetely useless for people using stable, testing or unstable.

Moodle 2.9 was released in year 2015, and does not support PHP7.0
Moodle 3.1 (LTS) was released in year 2016.

Now, the features of wims-moodle can be provided by the current package wims-
lti which I maintain.

Best regards,   Georges.

Bug#1063854: RM: senlin -- ROM; unmaintained

[Thomas Goirand]

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


Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Senlin is unmaintained and inactive. Let's remove it from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1063558: pgpainless 1.6.6 is available

[Daniel Kahn Gillmor]

On Mon 2024-02-12 11:18:59 -0500, Jérôme Charaoui wrote:
> On Fri, 09 Feb 2024 10:19:59 -0500 Daniel Kahn Gillmor 
>  wrote:
>> Package: src:pgpainless
>> Version: 1.6.5-1
>> Severity: wishlist
>> 
>> pgpainless 1.6.6 is available upstream.  it would be great to have it in
>> debian.
>
> According to my reading of the changes since 1.6.5, it's basically a 
> no-op for the Debian package:
>
> https://github.com/pgpainless/pgpainless/compare/1.6.5...1.6.6
>
> Is there a compelling reason to upgrade it nonetheless?

ah, i think you're right that this might not be worth the effort.

Sorry for the noise, i'm closing the bug report :)

--dkg


signature.asc
Description: PGP signature

Bug#1063855: RM: jsdoc-toolkit -- ROM; jsdoc-toolkit is obsolete, superseded by node-jsdoc2

[Georges Khaznadar]

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

Please remove jsdoc-toolkit from unstable and testing.

I used to maintain jsdoc-toolkit, as a build-dependency of the package
jsxgraph, which I will keep maintaining. jsdoc-toolkit was a javascript source
interpreted by a java-based engine. Now, it is superseded by the package node-
jsdoc2
which I uploaded to Debian, which is quite the same javascript source,
interpreted
by nodeJs.

So, jsdoc-toolkit is no longer useful for current developers.

Best regards,   Georges.

Bug#1063856: hdf5: new upstream release

[Drew Parsons]

Source: hdf5
Version: 1.10.10+repack-3
Severity: normal
X-Debbugs-Cc: debian-scie...@lists.debian.org

What our situation with our hdf5 package version?

We're currently using hdf5 1.10.10,
but 1.12.2 has been available in experimental for some time,
and upsteam has released 1.14.3.

Should we be upgrading now to hdft 1.14 (or 1.12)?

There's no current urgency, but I'm worried some bitrot might set in
as upstream developers focus on using the more recent HDF5 releases.

Drew

Bug#1061794: crmsh fails its autopkg tests with Python 3.12

[Florent 'Skia' Jacquet]

Hi,

Those two patches should fix autopkgtest.

The importlib one shouldn't be a problem.

The looseversion one, otoh, requires a bit more attention. LooseVersion 
was part of distutils, and got removed with Python 3.12, but there 
doesn't seem to be any replacement anywhere in the standard library.

There are basically two solutions here for now:
  * use that patch since setuptools is already packaged and provide a 
working implementation of LooseVersion. It's still in a `._distutils` 
module, which doesn't make it appear as being officially part of the 
API, meaning it could break eventually if it gets removed from here too.
  * make another patch that would make use of the `looseversion` 
package [1], that is currently not packaged in Debian, but should 
probably be the safer way forward, since the only purpose of that 
package is to provide that API. I haven't yet started the work of 
packaging that `looseversion` module, and don't know if that's the right 
path forward.


Obviously, this also depends on what solution upstream will take to 
support Python 3.12. I've already opened an issue here: 
https://github.com/ClusterLabs/crmsh/issues/1324


I also have that branch that passes autopkgtests locally: 
https://git.launchpad.net/~hyask/ubuntu/+source/crmsh/log/


[1]: https://github.com/effigies/looseversion



Skiadiff --git a/test/unittests/test_utils.py b/test/unittests/test_utils.py
index 77fd14b0b67d..900e8528143a 100644
--- a/test/unittests/test_utils.py
+++ b/test/unittests/test_utils.py
@@ -7,7 +7,7 @@ from __future__ import unicode_literals
 import os
 import socket
 import re
-import imp
+import importlib
 import subprocess
 import unittest
 import pytest
@@ -24,7 +24,7 @@ def setup_function():
 utils._ip_for_cloud = None
 # Mock memoize method and reload the module under test later with imp
 mock.patch('crmsh.utils.memoize', lambda x: x).start()
-imp.reload(utils)
+importlib.reload(utils)
 
 
 @mock.patch("crmsh.utils.get_stdout_stderr")
diff --git a/crmsh/ra.py b/crmsh/ra.py
index 6060ec7a3fd5..fcadc860aa5f 100644
--- a/crmsh/ra.py
+++ b/crmsh/ra.py
@@ -49,15 +49,15 @@ def crm_resource(opts):
 
 @utils.memoize
 def can_use_lrmadmin():
-from distutils import version
+from setuptools._distutils.version import LooseVersion
 # after this glue release all users can get meta-data and
 # similar from lrmd
 minimum_glue = "1.0.10"
 _rc, glue_ver = get_stdout("%s -v" % lrmadmin_prog, stderr_on=False)
 if not glue_ver:  # lrmadmin probably not found
 return False
-v_min = version.LooseVersion(minimum_glue)
-v_this = version.LooseVersion(glue_ver)
+v_min = LooseVersion(minimum_glue)
+v_this = LooseVersion(glue_ver)
 if v_this < v_min:
 return False
 if userdir.getuser() not in ("root", config.path.crm_daemon_user):
diff --git a/crmsh/utils.py b/crmsh/utils.py
index 51ff5b326d56..40c74a9019b5 100644
--- a/crmsh/utils.py
+++ b/crmsh/utils.py
@@ -34,7 +34,7 @@ from . import userdir
 from . import constants
 from . import options
 from . import term
-from distutils.version import LooseVersion
+from setuptools._distutils.version import LooseVersion
 from .constants import SSH_OPTION
 from . import log
 
diff --git a/debian/control b/debian/control
index 8fe560e13935..ea924b952335 100644
--- a/debian/control
+++ b/debian/control
@@ -40,6 +40,7 @@ Depends:
  python3-lxml,
  python3-packaging,
  python3-parallax,
+ python3-setuptools,
  python3-yaml
 Recommends: pacemaker (>= 1.1.12)
 Replaces: pacemaker (<< 1.1.12)

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries
will go to linux-firmware.git and then where do those go?


My (current) thinking is to have 2 categories:
- AMD CPU related
- AMD GPU/graphics related


Current products only put the IPU/NPU in APU chips, but who is to stay;
those might end up in SoCs without graphics in the future too.


I think it's important to facilitate people having f.e. the following combos:
- Intel CPU with AMD GPU
- AMD CPU with Nvidia GPU
- AMD CPU with AMD GPU (discrete or integrated)

Preferably without having to install 100s of MB of firmware files of which 95%
the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786)


You don't currently split up the AMD APU integrated graphics and dGPU, 
and I doing this is a bad idea as it's possible to reuse IP versions on 
APU and dGPU hardware.  If they are the same then they would use the 
same firmware binaries.


For reference on the size:

$ du -sh amdgpu
60M amdgpu

$ du -sh du -sh amdtee/
20K amdtee/

$ du -sh amd-ucode/
112Kamd-ucode/

$ du -sh amd
268Kamd

These aren't yet upstream, but so you can see the size:

$ du -sh amdnpu/
3.3Mamdnpu/




How would you feel about making a master "amd" metapackage that pulls
them all?  You can split as you see fit then and people who want the
'easy button' can just install that package.


I'm not much of a fan of such metapackages. I think it mostly indicates that
the purpose of the various packages isn't clear, so let's install all of them.
Clarifying the purpose better is a better solution imo.
I'm aware others feel different: https://bugs.debian.org/522415

I prefer to keep that discussion out of this bug though, feel free to open a
new bug for that if you do want it.


I think your suggestion to combine all the non graphics related binaries 
to a single package and all graphics related binaries to another is fine.

Bug#1063858: False disk set size in README.(html|txt), and a few minor corrections

[Kevin Price]

Package: debian-cd
X-Debbugs-Cc: J.A. Bezemer , Steve
McIntyre 
Version: 3.2.1
Severity: minor

Dear maintainers, dear Steve[1]:

In the official current stable (12.5) images, the /README.(html|txt)
files (see att.) seem to miscount the total number of disks in each set.
For instance, in debian-12.5.0-amd64-DLBD-2.iso, section "About This
Disc" says: "[...]this disc is number 2 of a set of 1 discs"

1. This is obviously false, not only in the DLBD images.

While we're at it, could we tidy up the generating script in a few more
minor details, without separate bug reports maybe?

2. Aforementioned sentence's full stop is awkwardly misplaced in the
html (line-break in-between), and it's missing in the txt.

3. I was not quite certain about the version number to file this bug
against, so I took a look at the XHTML header for sth. like 'meta
name="generator"'. Wouldn't that be helpful to include?

4. The html claims to be "XHTML 1.0 Strict", but fails to validate
against https://validator.w3.org/ . AFAICT, that's only due to errors in
the section "Last-Minute Notes":

4.a. The "" beginning with "This is an official release" lacks a
closing "".

4.b. Where it says "https://bugs.debian.org/";>bugs.debian.org" it should
respectively say "a", "href", and "/a" instead.

5. The html header defines the language to be "English". Maybe "en"
would be more preferable?

Please let me know how I could be of any further assistance in resolving
these issues.

[1] FWIW, See also
https://lists.debian.org/debian-user/2024/01/msg00796.html , and please
accept my apology for being slow to file this bug.

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_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 debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

HTH, cheers
-- 
Kevin Price   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

 (HTML version in README.html)

  Welcome to the exciting world of
  Debian GNU/Linux

   This is one disc in a set containing the Debian GNU/Linux distribution.
   Debian is a very extensive collection of software. But it is more. It
   is a complete Operating System (OS) for your computer. And it is free
   (as in "freedom").

   CONTENTS:
 * Introduction
 * About This Disc
 * Installing
 * Last-Minute Notes
 * Installing software using Apt
 * CD/DVD Manufacturers
 * More Information
 * Browse This Disc

Introduction


   An operating system is the set of basic programs and utilities that
   make your computer run. At the core of an operating system is the
   kernel. The kernel is the most fundamental program on the computer,
   which does all the basic housekeeping and lets you start other
   programs. Debian is kernel independent. It currently uses either the
   Linux or FreeBSD kernel. Most of the basic operating system tools come
   from the GNU project; hence the name GNU/Linux.

   Debian is available for various kinds of computers ("architectures").
   Check the ports page for more information.

   Read more at:

 https://www.debian.org/intro/about

About This Disc
===

   This disc is labeled

   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

 

Bug#1063857: github-backup: commit messages don't end with newline

[Jakub Wilk]

Package: github-backup
Version: 1.20200721-2+b1

Commit messages created by github-backup don't end with newline:

   $ git clone -q https://github.com/jwilk/cowproxy

   $ cd cowproxy

   $ github-backup --no-forks
   Gathering metadata for https://github.com/jwilk/cowproxy.git ...

   $ git cat-file commit github && echo '<-- no newline here'
   tree e4fe2ef1f08a9145c7234e0fab086a9c12781eab
   parent 9d6d276c144804c026ac35195b6adddb764c4a35
   author Jakub Wilk  1707842905 +0100
   committer Jakub Wilk  1707842905 +0100

   github-backup<-- no newline here

This is unlike commit messages created by "git commit":

   $ git cat-file commit HEAD && echo '^-- yay'
   tree 91b21d2098618e30ec4c87eef0e3ed505f281f53
   parent 6eae506db2f48cb85ffd959e2cb2385a0a87e948
   author Jakub Wilk  1706350373 +0100
   committer Jakub Wilk  1706350373 +0100

   CI: upgrade actions/cache to v4.
   ^-- yay


-- System Information:
Architecture: i386

Versions of packages github-backup depends on:
ii  libc6  2.36-9+deb12u4
ii  libdouble-conversion3  3.2.1-1
ii  libffi83.4.4-1
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libstdc++6 12.2.0-14
ii  zlib1g 1:1.2.13.dfsg-1
ii  git1:2.39.2-1.1

--
Jakub Wilk

Bug#1063856: hdf5: new upstream release

[Drew Parsons]

Source: hdf5
Followup-For: Bug #1063856

For further context, HDF upstream no longer supports hdf5 1.10, nor
hdf5 1.12 (i.e. no more releases will be made in these series)

see
https://github.com/HDFGroup/hdf5#release-schedule
https://github.com/h5py/h5py/issues/2312
https://forum.hdfgroup.org/t/release-of-hdf5-1-12-3-library-and-tools-newsletter-200/11924

hdf5 1.14 supports the REST VOL API, which may improve cloud computing
performance.
see https://github.com/HDFGroup/vol-rest
https://github.com/h5py/h5py/issues/2316

Bug#1061802: Did Python 3.12 developers honestly broke special regexp sequences? (Was: hatop fails its autopkg tests with Python 3.12)

[Andreas Tille]

Hi,

I was constantly shaking my had above bug #1061802 featuring
Syntaxwarnings like

SyntaxWarning: invalid escape sequence '\.'
573s   CLI_INPUT_RE = re.compile('[a-zA-Z0-9_:\.\-\+; /#%]')
573s /tmp/autopkgtest.G4v4eK/autopkgtest_tmp/hatop.py:215: 
SyntaxWarning: invalid escape sequence '\s'
573s   'software_name':re.compile('^Name:\s*(?P\S+)'),

which is even in contrast with Regular expression operations
documentation for Python3.12[1] where

\s
For Unicode (str) patterns:
Matches Unicode whitespace characters (which includes [ \t\n\r\f\v], and also 
many other characters, for example the non-breaking spaces mandated by 
typography rules in many languages).

Matches [ \t\n\r\f\v] if the ASCII flag is used.

For 8-bit (bytes) patterns:
Matches characters considered whitespace in the ASCII character set; this is 
equivalent to [ \t\n\r\f\v].


remains what I know \s is meaning in regular expressions.  (I admit '\.'
is unusual inside [] and I think just '.' is appropriate here.)  I tried
simple things like


$ python3.12
Python 3.12.2 (main, Feb  7 2024, 20:47:03) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> software_name = re.compile('^Name:\s*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'
>>> software_name = re.compile('^Name:[\s\t\n]*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'


which makes me scratching my head what else we should write
for "any kind of space" now in Python3.12.

Kind regards
   Andreas.

[1] https://docs.python.org/3/library/re.html

-- 
http://fam-tille.de

Bug#1063719: More analysis and improved patch

[George Robbert]

Hey,

Just like with the previous bug (#1026927), it looks like there's more
to this one.  Trying the patch on several more systems I run into the
same symptoms on some.  Again, these have the same symptoms but
differing causes (full patch included).  What I found was:


On an intel system, where uCode/AMD.pm was run before uCode/Intel.pm

intel_sys1# needrestart -b 
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
string at /usr/sbin/needrestart line 940.
NEEDRESTART-UCCUR: 
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP: 

But we don't get the 'Use of uninitialized value' when run as
`needrestart -b -v`.  The issue here is that nr_ucode_check keeps
going after the "eval ...  ${pkg}::nr_ucode_check_real..." fails
unless $debug is set.  Thus, without $debug, thi saves off the
unintialized values from AMD.pm as "the good ones", so we get the
error.

On a VM running with an AMD processor but without package
amd64-microcode, and also directly on an AMD system with a processor new enough
that it does not have a microcode version lin amd64-microcode, I get
the following identical results.

amd_vm1# needrestart -b
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0xa0011d1
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP:


amd_sys3# needrestart -b
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0x6006705
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP: 

This comes from AMD.pm not setting $ucode_vars{"AVAIL"} if it doesn't
find any matching available versions.  compare_ucode_versions()
handles, this as expected, but leaves $ucode_vars{"AVAIL"} unset to
cause problems later when run with -b.


The attached patch fixes includes the previous patch and also fixes
these 2 issues.

Hope this helps,
George

--- /tmp/uCode.pm.dist  2024-02-13 09:20:29.236867717 -0700
+++ /usr/share/perl5/NeedRestart/uCode.pm   2024-02-13 09:33:23.099742955 
-0700
@@ -152,10 +152,15 @@
 
 # call ucode modules
 foreach my $pkg (@PKGS) {
+   eval "${pkg}::nr_ucode_init();";
+   if ( $@ ) {
+   print STDERR $@ if ($debug);
+   next;
+   }
 my @nvars;
 eval "\@nvars = ${pkg}::nr_ucode_check_real(\$debug, \$ui, 
\$processors{\$pid});";
-if ( $@ && $debug ) {
-print STDERR $@;
+if ( $@ ) {
+   print STDERR $@ if ($debug);
 $ui->progress_step;
 next;
 }
@@ -174,6 +179,10 @@
 
 $ui->progress_fin;
 
+if ( $state == NRM_CURRENT && ! grep ( ( $_ eq "AVAIL"), @vars ) ) {
+   push(@vars, "AVAIL", "unavailable");
+}
+
 return ( $state, @vars );
 }
 

Bug#1063859: git: commit msg without trailing \n breaks "git log --grep"ing for notes

[Jakub Wilk]

Package: git
Version: 1:2.39.2-1.1

Let's create a commit with a message that doesn't end with newline¹, and 
attach a note to it:


   $ commit=$(printf 'foo' | git commit-tree 
4b825dc642cb6eb9a060e54bf8d69288fbee4904)
   $ git notes add -m bar $commit
   $ git log $commit --grep bar
   commit e0e2391bad1644f1dd580c0d5d6c5b58addf2870
   Author: Jakub Wilk 
   Date:   2024-02-13 18:00:51 +0100

   foo

   Notes:
   bar

So far so good, but if you anchor the regex, the commit can no longer be 
found:


   $ git log $commit --grep ^bar
   [nothing]

Apparently that's because git concatenates the commit message and the 
note without inserting newline between them:


   $ git log $commit --grep ^foobar
   commit e0e2391bad1644f1dd580c0d5d6c5b58addf2870
   Author: Jakub Wilk 
   Date:   2024-02-13 18:00:51 +0100

   foo

   Notes:
   bar



¹ See also bug #1063857 "github-backup: commit messages don't end with 
newline".



-- System Information:
Architecture: i386

Versions of packages git depends on:
ii  libc62.36-9+deb12u4
ii  libcurl3-gnutls  7.88.1-10+deb12u5
ii  libexpat12.5.0-1
ii  libpcre2-8-0 10.42-1
ii  zlib1g   1:1.2.13.dfsg-1
ii  perl 5.36.0-7+deb12u1
ii  liberror-perl0.17029-2
ii  git-man  1:2.39.2-1.1

--
Jakub Wilk

Bug#1063857: github-backup: commit messages don't end with newline

[Jakub Wilk]

* Jakub Wilk , 2024-02-13 18:00:

Commit messages created by github-backup don't end with newline


... which breaks git-log a bit:
#1063859 "git: commit msg without trailing \n breaks 'git log --grep'ing 
for notes"


--
Jakub Wilk

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Jeffrey Walton]

This issue is likely Debian Bug #62572. Also see
.

(Thanks Wesley).

Bug#1063860: minissdpd: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: minissdpd
Version: 1.6.0-2
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for minissdpd
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# German translation of Debconf template for minissdpd
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the minissdpd package.
# Helge Kreutzmann , 2018, 2019, 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: minissdpd 1.6.0-2\n"
"Report-Msgid-Bugs-To: miniss...@packages.debian.org\n"
"POT-Creation-Date: 2024-02-08 14:45+0800\n"
"PO-Revision-Date: 2024-02-13 18:59+0100\n"
"Last-Translator: Helge Kreutzmann \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"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid "MiniSSDP daemon configuration"
msgstr "Konfiguration des MiniSSDP-Daemons"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"The MiniSSDP daemon is being installed (perhaps as a dependency for UPnP "
"support) but will not function correctly until it is configured."
msgstr ""
"Der MiniSSDP-Daemon wird installiert (vielleicht als eine Abhängigkeit zur "
"UPnP-Unterstützung), wird aber nicht korrekt funktionieren, bis er "
"konfiguriert wurde."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"MiniSSDP is a daemon used by MiniUPnPc to speed up device discovery. For "
"security reasons, no out-of-box default configuration can be provided, so it "
"requires manual configuration."
msgstr ""
"MiniSSDP ist ein von MiniUPnPc verwandter Daemon, um die Geräteerkennung zu "
"beschleunigen. Aus Sicherheitsgründen kann keine Standardkonfiguration "
"bereitgestellt werden, daher wird eine manuelle Konfiguration benötigt."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"Alternatively you can simply override the recommendation and remove "
"MiniSSDP, or leave it unconfigured - it won't work, but MiniUPnPc (and UPnP "
"applications) will still function properly despite some performance loss."
msgstr ""
"Alternativ können Sie auch einfach die Empfehlung außer Kraft setzen und "
"MiniSSDP entfernen oder es unkonfiguriert lassen. Es wird nicht "
"funktionieren, aber MiniUPnPc (und UPnP-Anwendungen) werden weiterhin, wenn "
"auch mit Leistungsverlusten, korrekt funktionieren."

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid "Start the MiniSSDP daemon automatically?"
msgstr "Den MiniSSDP-Daemon automatisch starten?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid ""
"Choose this option if the MiniSSDP daemon should start automatically, now "
"and at boot time."
msgstr ""
"Wählen Sie diese Option, falls der Daemon MiniSSDP jetzt und zum "
"Systemstartzeitpunkt automatisch starten soll."

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid "Interfaces to listen on for UPnP queries:"
msgstr "Schnittstellen, an denen auf UPnP-Anfragen gewartet werden soll:"

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"The MiniSSDP daemon will listen for requests on those interfaces, and drop "
"all queries that do not come from the local network. Please enter the LAN "
"interfaces that it should listen on, separated by space."
msgstr ""
"Der MiniSSDP-Daemon wird auf diesen Schnittstellen auf Anfragen warten und "
"alle Anfragen verwerfen, die nicht vom lokalen Netzwerk stammen. Bitte geben "
"Sie die LAN-Schnittstellen ein, an denen auf Anfragen gewartet werden soll. "
"Trennen Sie die Einträge durch Leerzeichen."

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid "Enable IPv6 listening?"
msgstr "Auf IPv6-Anfragen warten?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid ""
"Please specify whether the MiniSSDP daemon should listen for IPv6 queries."
msgstr ""
"Bitte geben Sie an, ob der MiniSSDP-Daemon auf IPv6-Anfragen warten soll."

#~ msgid ""
#~ "Interface names are highly preferred, and required if you plan to enable "
#~ "IPv6 port forwarding."
#~ msgstr ""
#~ "Schnittstellennamen werden nachdrücklich bevorzugt. Falls Sie vorhaben, "
#~ "eine IPv6-Portweiterleitung zu aktivieren, sind dieser erforderlich."

#~ msgid ""
#~ "If you see this message but never manually install MiniSSDP, then most "
#~ "probably this package is automatically pulled as a recommendation for "
#~ "libminiupnpc, which is the UPnP support library for many applications."
#~ msgstr ""
#~ "Falls Sie diese Nachricht sehen aber MiniSSDP niemals manuell installiert "
#~ "haben, dann wird das Paket höchstwahrscheinlich als Empfehlung für "
#~ "libminiupnpc automatisch he

Bug#1063861: RFS: astro/0.25.1-1 [ITP] -- Gemini web browser using shell script

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name       : astro
   Version                : 0.25.1-1
   Upstream contact : Brian Mayer 
* URL                          : https://github.com/blmayer/astro
* License                : Expat
* Vcs                            : 
https://salsa.debian.org/akashdoppalapudi/astro

   Section                     : net

The source builds the following binary packages:

astro - Gemini web browser using shell script

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/astro/astro_0.25.1-1.dsc


Changes for the initial release:

astro (0.25.1-1) unstable; urgency=medium
.
* Initial release. (Closes: #1036734)

Regards,

Akash Doppalapudi



OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053757: migration from sqlite to postgresql 15 failed

[Harald Dunkel]

Hi Thomas,

sorry for the late response. Somehow this went out of focus.

I have backported your 2.5.0 package too bookworm. After running
the new xca the sqlite db was updated, next I exported it using
sqlite3, but on importing it psql complained about the first line
in the dump file again:

ERROR:  syntax error at or near "PRAGMA"
LINE 1: PRAGMA foreign_keys=OFF;
^
BEGIN
CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
:


Finally (after about 400 lines) it failed with a syntax error:

:
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
ERROR:  syntax error at or near ")"
LINE 1: ...0190307103908Z',replace('obsolete\n','\n',char(10)),2507,1);
 ^
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
:

I am not sure if xca is to blame here. The complete line looks like this:


INSERT INTO items 
VALUES(399,'old_strongSwan_IPsec_client',5,5,'20190307103908Z',replace('obsolete\n','\n',char(10)),2507,1);

There are tons of lines with

replace('sometext\n','\n',char(10))

I wonder how these newlines came into the database at all?


Regards

Harri

Bug#1063862: npm2deb fails when self.json['bin'] is not a list -- [patch provided]

[Georges Khaznadar]

Package: npm2deb
Version: 0.3.0-12
Severity: normal
Tags: patch

Dear Maintainer,

When I try to run:
   npm2deb create @babel/parser
the command fails:
   ...
   File "/usr/lib/python3/dist-packages/npm2deb/__init__.py", line 260, in
create_links
orig = _os.path.normpath(self.json['bin'][script])
 
  TypeError: string indices must be integers, not 'str'

The reason of this error is that:
   self.json['bin'] == './bin/babel-parser.js'
in this particular case.

Here is a patch which restores the expected behavior:

-8<-
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
 links = []
 dest = self.debian_dest
 if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
 if len(links) > 0:
 content = '\n'.join(links)
 utils.create_debian_file('links', content)
-8<-

Best regards,  Georges.


-- System Information:
Debian Release: trixie/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads)
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 npm2deb depends on:
ii  devscripts2.23.7
ii  node-github-url-from-git  1.5.0+~1.5.1-1
ii  npm   9.2.0~ds1-2
ii  python3   3.11.6-1
ii  python3-apt   2.7.5
ii  python3-dateutil  2.8.2-3

npm2deb recommends no packages.

npm2deb suggests no packages.

-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 75564f7..da54cd4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+npm2deb (0.3.0-12.1) unstable; urgency=medium
+
+  * NMU: fix an issue when self.json['bin'] is not a list.
+
+ -- Georges Khaznadar   Tue, 13 Feb 2024 18:57:29 +0100
+
 npm2deb (0.3.0-12) unstable; urgency=medium
 
   * Update standards version to 4.6.1, no changes needed.
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
 links = []
 dest = self.debian_dest
 if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
 if len(links) > 0:
 content = '\n'.join(links)
 utils.create_debian_file('links', content)

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Wesley Schwengle]

Small update on the previous message.

It's the same as Debian #1055694, which is upstream bug

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1053757: Info received (migration from sqlite to postgresql 15 failed)

[Harald Dunkel]

PS: I have replaced all "char(10)" and "char(13)" in the sqlite dump file
by "'.'". Finally I could import the database dump in postgresql (15) and
use it in xca.

There is no visible advantage, though. xca is as slow as for using sqlite.
I had hoped for a speed improvement.


Regards

Harri

Bug#1063863: tracker-miner-fs: lot of 'Could not get file handle for' log messages

[Patrice Duroux]

Package: tracker-miner-fs
Version: 3.4.6-3
Severity: minor

Dear Maintainer,

Looking at journalctl, I have a lot of messages like the following:

tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Musique':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Images':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Vidéos':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications': Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications/wine': Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications/anbox': Opération non supportée

(sorry for the French)

Each message seems to be related to a directory file.
Is that expected?

Regards,
Patrice


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

Kernel: Linux 6.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 tracker-miner-fs depends on:
ii  init-system-helpers  1.66
ii  libc62.37-15
ii  libglib2.0-0 2.78.3-2
ii  libgstreamer1.0-01.22.9-1+b1
ii  libtracker-sparql-3.0-0  3.4.2-3
ii  libupower-glib3  1.90.2-8
ii  procps   2:4.0.4-4
ii  tracker  3.4.2-3
ii  tracker-extract  3.4.6-3

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1

[Jérémy Lal]

Le ven. 9 févr. 2024 à 14:33, Dylan Aïssi  a écrit :

> Source: node-undici
> Version:  5.15.0+dfsg1+~cs20.10.9.3-1+deb12u3
> Severity: serious
> Tags: bookworm
> Usertags: apertis-ftbfs
> Justification: FTBFS
>
> Hello,
>
> While doing a rebuild of some node packages in Bookworm, it appears several
> packages (at least ~ 50 pkgs) no longer build with nodejs
> 18.19.0+dfsg-6~deb12u1
> (from bookworm-security repo) while they still successfully build with
> nodejs
> 18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the
> same error:
> error TS2307: Cannot find module 'undici-types' or its corresponding
> type declarations.
>
> Since, I am not sure which package need to be fixed (nodejs, node-undici or
> all of them), I fill this bug against the package referred by the error
> message,
> please reassign to the relevent package.


The latest nodejs (security | branch) update needs node-undici to export
its own "undici-types".
It seems that it doesn't, and that's probably my mistake.

Once that is fixed, three other packages need their test suites to be fixed
and uploaded to stable-proposed-updates.

> > > node-zx is a regression in the test suite only, fixed there:
> > https://salsa.debian.org/js-team/node
-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2

> > > node-v8-compile-cache is a regression in the test suite only, fixed
> > there:
> > https://salsa.debian.org/js-team/node
-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc

> > > node-babel7 is a regression in the test suite, fixed there:
> > https://salsa.debian.org/js-team/node
-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Source: mediawiki2latex
Version: 8.0-1
Severity: serious
Control: close -1 8.7-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:mediawiki2latex has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version can't be 
installed on armel, mips64el and s390x while the package builds on those 
architectures.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063865: src:tailspin: unsatisfied build dependency in testing: librust-terminal-size-0.2+default-dev

[Paul Gevers]

Source: tailspin
Version: 2.0.0+dfsg-1
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's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063866: ddcci-dkms: failed to compile DKMS module for linux 6.5.0

[Jeff Becker (probably not evil)]

Package: ddcci-dkms
Version: 0.4.2-4
Severity: important

Dear Maintainer,

after trying to install package via apt it reports that the DKMS module could
not be compilled, giving the following output:

root@desu:~# apt install ddcci-dkms
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
ddcci-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/21.7 kB of archives.
After this operation, 95.2 kB of additional disk space will be used.
Selecting previously unselected package ddcci-dkms.
(Reading database ... 1401185 files and directories currently installed.)
Preparing to unpack .../ddcci-dkms_0.4.2-4_all.deb ...
Unpacking ddcci-dkms (0.4.2-4) ...
Setting up ddcci-dkms (0.4.2-4) ...
Loading new ddcci-0.4.2 DKMS files...
Building for 6.5.0-0.deb12.4-amd64
Building initial module for 6.5.0-0.deb12.4-amd64
Error! Bad return status for module build on kernel: 6.5.0-0.deb12.4-amd64
(x86_64)
Consult /var/lib/dkms/ddcci/0.4.2/build/make.log for more information.
dpkg: error processing package ddcci-dkms (--configure):
installed ddcci-dkms package post-installation script subprocess returned error
exit status 10
Errors were encountered while processing:
ddcci-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)


contents of make.log is include as an attached file.


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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/24 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages ddcci-dkms depends on:
ii  dkms  3.0.10-8+deb12u1

ddcci-dkms recommends no packages.

ddcci-dkms suggests no packages.

-- no debconf information
DKMS make.log for ddcci-0.4.2 for kernel 6.5.0-0.deb12.4-amd64 (x86_64)
Tue Feb 13 14:32:20 EST 2024
make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build'
make -C "ddcci"
make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make -C "/lib/modules/6.5.0-0.deb12.4-amd64/build" 
M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules
make[2]: Entering directory '/usr/src/linux-headers-6.5.0-0.deb12.4-amd64'
  CC [M]  /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:34: error: macro 
"DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
   42 | static DEFINE_SEMAPHORE(core_lock);
  |  ^
In file included from 
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/fs.h:25,
 from /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:19:
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/semaphore.h:34: 
note: macro "DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  | 
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:8: error: type defaults to 
‘int’ in declaration of ‘DEFINE_SEMAPHORE’ [-Werror=implicit-int]
   42 | static DEFINE_SEMAPHORE(core_lock);
  |^~~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: In function 
‘ddcci_device_release’:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: error: ‘core_lock’ 
undeclared (first use in this function); did you mean ‘file_lock’?
 1002 | down(&core_lock);
  |   ^
  |   file_lock
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: note: each undeclared 
identifier is reported only once for each function it appears in
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: At top level:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: error: initialization of 
‘int (*)(const struct device *, struct kobj_uevent_env *)’ from incompatible 
pointer type ‘int (*)(struct device *, struct kobj_uevent_env *)’ 
[-Werror=incompatible-pointer-types]
 1053 | .uevent = ddcci_device_uevent,
  |   ^~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: note: (near 
initialization for ‘ddcci_device_type.uevent’)
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: error: initialization of 
‘char * (*)(const struct device *, umode_t *, kuid_t *, kgid_t *)’ {aka ‘char * 
(*)(const struct device *, short unsigned int *, kuid_t *, kgid_t *)’} from 
incompatible pointer type ‘char * (*)(struct device *, umode_t *, kuid_t *, 
kgid_t *)’ {aka ‘char * (*)(struct device *, short unsigned int *, kuid_t *, 
kgid_t *)’} [-Werror=incompatible-pointer-types]
 1056 | .devnode= ddcci_devnode
  |   ^
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: note: (near 
initialization for ‘ddcci_device_type.devnode’)
/var/lib/dkms/ddcci/

Bug#1063867: engrampa: Depends on non-free package

[cacin]

Source: engrampa
Version: 1.26.2-2
Severity: serious
Tags: patch
Justification: Policy 2.2.1

Dear Maintainer,

the commit fixing #1063564 introduced a direct Depends on 7zip-rar,
which is in the non-free area.

It should have been Depends: on 7zip and then Suggests: for 7zip-rar

Patch attached.
---
 debian/control | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0dba580..4641fda 100644
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,6 @@ Depends: bzip2 (>= 1.0.1),
  engrampa-common (= ${source:Version}),
  gzip (>= 1.3.2),
  7zip,
- 7zip-rar,
  tar (>= 1.13.25),
  ${misc:Depends},
  ${shlibs:Depends},
@@ -52,7 +51,7 @@ Suggests: arj,
   sharutils,
   unace,
   unalz,
-  unar | unrar | p7zip-rar,
+  unar | unrar | 7zip-rar,
   zoo,
 Breaks: engrampa-common (<< 1.8.0),
 Description: archive manager for MATE
-- 

Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`

[Jonas Smedegaard]

Control: reassign -1 librust-eyre-dev
Control: retitle -1 librust-eyre-dev: fails to builds its source
Control: affects -1 tailspin

Quoting Sebastian Ramacher (2024-02-09 21:04:28)
> https://buildd.debian.org/status/fetch.php?pkg=tailspin&arch=amd64&ver=3.0.0%2Bdfsg-1&stamp=1706195420&raw=0
> 
>  Running 
> `/<>/target/release/build/eyre-15058028a1ebd405/build-script-build`
> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait `Error`
> [eyre 0.6.8]   --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9
> [eyre 0.6.8]|
> [eyre 0.6.8] 19 | / fn backtrace(&self) -> Option<&Backtrace> {
> [eyre 0.6.8] 20 | | let backtrace = Backtrace::capture();
> [eyre 0.6.8] 21 | | match backtrace.status() {
> [eyre 0.6.8] 22 | | BacktraceStatus::Captured | 
> BacktraceStatus::Disabled | _ => {}
> [eyre 0.6.8] 23 | | }
> [eyre 0.6.8] 24 | | unimplemented!()
> [eyre 0.6.8] 25 | | }
> [eyre 0.6.8]| |_^ not a member of trait `Error`
> [eyre 0.6.8] 
> [eyre 0.6.8] error[E0554]: `#![feature]` may not be used on the stable 
> release channel
> [eyre 0.6.8]  --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:2:16
> [eyre 0.6.8]   |
> [eyre 0.6.8] 2 | #![feature(backtrace)]
> [eyre 0.6.8]   |^
> [eyre 0.6.8] 
> [eyre 0.6.8] warning: the feature `backtrace` has been stable since 1.65.0 
> and no longer requires an attribute to enable
> [eyre 0.6.8]  --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:2:16
> [eyre 0.6.8]   |
> [eyre 0.6.8] 2 | #![feature(backtrace)]
> [eyre 0.6.8]   |^
> [eyre 0.6.8]   |
> [eyre 0.6.8]   = note: `#[warn(stable_features)]` on by default
> [eyre 0.6.8] 
> [eyre 0.6.8] error: aborting due to 2 previous errors; 1 warning emitted
> [eyre 0.6.8] 
> [eyre 0.6.8] Some errors have detailed explanations: E0407, E0554.
> [eyre 0.6.8] For more information about an error, try `rustc --explain E0407`.
> [eyre 0.6.8] cargo:rustc-cfg=track_caller

The above seems like a failure not in tailspin but in librust-eyre-dev.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Diederik de Haas]

On Tuesday, 13 February 2024 17:59:55 CET Mario Limonciello wrote:
> > I think it's important to facilitate people having f.e. the following
> > combos: 
> > - Intel CPU with AMD GPU
> > - AMD CPU with Nvidia GPU
> > - AMD CPU with AMD GPU (discrete or integrated)
> > 
> > Preferably without having to install 100s of MB of firmware files of which
> > 95% the user doesn't actually need. (See f.e.
> > https://bugs.debian.org/1057786)
> You don't currently split up the AMD APU integrated graphics and dGPU,
> and I doing this is a bad idea as it's possible to reuse IP versions on
> APU and dGPU hardware.  If they are the same then they would use the
> same firmware binaries.

I have/had no plan to make a split for iGPU and dGPU, both would need to 
install the `firmware-amd-graphics` package.

For the 3 scenario's above:
- `intel-microcode` + `firmware-amd-graphics`
- `amd64-microcode` + `firmware-nvidia`*
- `amd64-microcode` + `firmware-amd-graphics`

AMD APU's would fall into scenario 3.

*) If my MR gets accepted, otherwise `firmware-misc-nonfree`

> For reference on the size:
> 
> $ du -sh amdgpu
> 60M amdgpu
> 
> $ du -sh du -sh amdtee/
> 20K amdtee/
> 
> $ du -sh amd-ucode/
> 112Kamd-ucode/
> 
> $ du -sh amd
> 268Kamd

What I want(ed) to prevent is that for scenario 2, the user should NOT have to 
install the `firmware-amd-graphics` package to get the amdtee firmware.

> These aren't yet upstream, but so you can see the size:
> 
> $ du -sh amdnpu/
> 3.3Mamdnpu/

And that seems like a future candidate too for amd64-microcode package.

> I think your suggestion to combine all the non graphics related binaries
> to a single package and all graphics related binaries to another is fine.

Excellent, then I think we're all in agreement :)

I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and Henrique 
can add those files to the amd64-microcode package.

Cheers,
  Diederik

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

Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++

[Christian Kastner]

Hi Petter,

On 2024-02-13 08:36, Petter Reinholdtsen wrote:
> I tried building the CPU edition on one machine and run it on another,
> and experienced illegal instruction exceptions.  I suspect this mean one
> need to be careful when selecting build profile to ensure it work on all
> supported Debian platforms.

yeah, that was my conclusion from my first experiments as well.

This is a problem though, since one key point of llama.cpp is to make
best use of the current hardware. If we'd target some 15-year-old amd64
lowest common denominator, we'd go against that.

In my first experiments, I've also had problems with ROCm builds on
hosts without a GPU.

I have yet to investigate if/how capabilities can be generally enabled,
and use determined at runtime.

Another issue that stable is clearly the wrong distribution for this.
This is a project that is continuously gaining new features, so we'd
need to stable-updates.

> I would be happy to help getting this up and running.  Please let me
> know when you have published a git repo with the packaging rules.

I'll push a first draft soon, though it will definitely not be
upload-ready for the above reasons.

Best,
Christian

Bug#1063868: O: xsecurelock -- X11 screen lock utility with the primary goal of security

[Markus Teich]

Package: wnpp
Severity: normal

Bug#1010279: python-iso8601: please make the build reproducible

[James Addison]

Followup-For: Bug #1010279
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: block -1 1056291
Control: close -1

Based on recent reproducible build testing history[1] of this package, and for
Debian versions after the fix for #1056291 became available (excludes both
bookworm, and builds prior to 2023-12-04 or so), I'm confident that the package
is building reproducibly, so I think we can close this.

(note: the failures that _have_ occurred recently when build-testing on
bookworm illustrate the same dot-dir pollution that we saw previously:
unexpected packaging of .hypothesis and .pytest_cache directories)

Adding a bug-blocker relationship for historical tracking purposes and closing
this bug.

[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-iso8601.html

Bug#1063869: pytest-cookies: Please package new upstream release 0.7.0

[Boyuan Yang]

Source: pytest-cookies
Version: 0.4.0-2
Tags: sid trixie
Control: block -1 by 1040040
Severity: normal
X-Debbugs-CC: ber...@debian.org

Please package new version of pytest-cookies (v0.7.0). Thanks!

The packaging of new version requires packaging the new version of
python-cookiecutter ( https://bugs.debian.org/1040040 ).

Regards,
Boyuan Yang


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

Bug#1026381: python-django-health-check: please make the build reproducible

[James Addison]

Followup-For: Bug #1026381
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: block -1 1057432
Control: close -1

Based on recent reproducible build testing history[1] of this package, and for
Debian versions after the fix for #1057432 became available (excludes both
bookworm, and builds prior to 2023-12-04 or so), I'm confident that the package
is building reproducibly, so I think we can close this.

Adding a bug-blocker relationship for historical tracking purposes and closing
this bug.

[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-health-check.html

Bug#1063870: fail2ban: upgrade warning: SyntaxWarning: invalid escape sequence

[Paul Gevers]

Package: fail2ban
Version: 1.0.2-3
Severity: important

During an upgrade of fail2ban I noticed this in the apt output:

Setting up fail2ban (1.0.2-3) ...
Installing new version of config file 
/etc/fail2ban/jail.d/defaults-debian.conf ...
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:224: 
SyntaxWarning: invalid escape sequence '\s'  "1490349000 test 
failed.dns.ch", "^\s*test \S+"
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:435: 
SyntaxWarning: invalid escape sequence '\S'   '^'+prefix+'User 
\S+ not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:443: 
SyntaxWarning: invalid escape sequence '\S'   '^'+prefix+'User 
\S+ not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:444: 
SyntaxWarning: invalid escape sequence '\d'   '^'+prefix+'Received 
disconnect from  port \d+'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:451: 
SyntaxWarning: invalid escape sequence '\s'   _test_variants('common', 
prefix="\s*\S+ sshd\[\d+\]:\s+")
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:537: 
SyntaxWarning: invalid escape sequence '\[' 
'common[prefregex="^svc\[\d+\] connect 
.+$"'
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1375: 
SyntaxWarning: invalid escape sequence '\s'   "`{ nft -a list chain inet 
f2b-table f2b-chain | grep -oP 
'@addr-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1378: 
SyntaxWarning: invalid escape sequence '\s'
   "`{ nft -a list chain inet f2b-table f2b-chain | grep -oP 
'@addr6-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1421: 
SyntaxWarning: invalid escape sequence '\s'
   "`{ nft -a list chain inet f2b-table f2b-chain | grep -oP 
'@addr-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1424: 
SyntaxWarning: invalid escape sequence '\s'   "`{ nft -a list chain inet 
f2b-table f2b-chain | grep -oP 
'@addr6-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063871: ITP: r-cran-areal -- GNU R areal weighted interpolation

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-areal -- GNU R areal weighted interpolation
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-areal
  Version : 0.1.8
  Upstream Author : Christopher Prener,
* URL : https://cran.r-project.org/package=areal
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R areal weighted interpolation
 A pipeable, transparent implementation of areal weighted interpolation
 with support for interpolating multiple variables in a single function call.
 These tools provide a full-featured workflow for validation and estimation
 that fits into both modern data management (e.g. tidyverse) and spatial
 data (e.g. sf) frameworks.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-areal

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Ansgar]

On Sat, 6 Jan 2024 19:38:42 -0800 Steve Langasek wrote:
> - dpkg will be uploaded to experimental with 64-bit time_t in the
default
>   flags

As far as I understand this approach will break any consumer on a
library whose ABI changes to to the ABI changes introduced here unless
the consumer is built with the flags from `dpkg-buildflags` (which
would now define the ABI).

In particular users could no longer just invoke `gcc` alone, but would
have to also rely on `dpkg-buildflags` for any software they built on
their own using runtime libraries shipped by Debian. It would work in
some cases (multi-ABI libraries like libc6 or libraries not affected by
the ABI change), but it is not reliable.

Do we want this? It must at least be documented, probably in Debian
Policy and GCC.

This was asked on debian-devel@ multiple times, but there was no answer
so far.

Ansgar

Bug#1063872: RM: prayer -- RoQA; Dead Upstream; Unmaintained; Incompatible with Tidy 5.8

[Boyuan Yang]

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

Dear Debian FTP Masters,

Please remove package prayer ( https://tracker.debian.org/pkg/prayer )
from Debian archive.

As discussed in https://bugs.debian.org/1010066 , its upstream has been dead
since 201x, and it is incompatible with the upcoming tidy-html5 5.8.x. In 2022,
the Debian package maintainer (in CC list) states that it is not used anymore
and unmaintained since then. It missed the last Debian stable release. Package
prayer also has a low popcon value (< 10).

Thanks,
Boyuan Yang


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

Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled

[Boyuan Yang]

notfound 1052129 20230628-1
tags 1052129 - sid
close 1052129
thanks

Obviously the Testing migration is fixed. Now closing this bug accordingly.

Thanks,
Boyuan Yang


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

Bug#1063873: Building a reverse dependency of the guava-testlib artifact fails

[Pierre Gruet]

Source: guava-libraries
Version: 32.0.1-1
Severity: important

Dear Maintainer,

When one tries to use the com.google.guava:guava-testlib:debian artifact in a
Maven pom.xml file, during the build one gets the error

[ERROR] Failed to execute goal on project myProject: Could not resolve 
dependencies for project myGroup:myProject:jar:myVersion: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.guava:guava:bundle:debian has not been downloaded from it before. -> 
[Help 1]

because the pom of guava-testlib looks for com.google.guava:guava with the
"bundle" type. I trust we should ship com.google.guava:guava with the "jar"
packaging type instead of "bundle", this is more accurate and compliant with
Debian-Java practices.

For instance I believe the enclosed patch allows one to package guava-libraries
with "jar" artifacts instead of "bundle". Yet I did not try to build the rdeps.

Best,

-- 
Pierre
--- a/guava-testlib/pom.xml
+++ b/guava-testlib/pom.xml
@@ -34,7 +34,6 @@
   ${project.groupId}
   guava
   ${project.version}
-  bundle
 
 
   junit
--- a/guava/pom.xml
+++ b/guava/pom.xml
@@ -8,7 +8,7 @@
 32.0.1-jre
   
   guava
-  bundle
+  jar
   Guava: Google Core Libraries for Java
   https://github.com/google/guava
   

Bug#1060932: doublecmd: FTBFS: make[1]: *** [debian/rules:16: override_dh_install] Error 2

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir


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

Bug#1061009: winff: FTBFS: make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 2

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir


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

Bug#1063874: m2crypto: Testsuite fails with OpenSSL 3.2

[Sebastian Andrzej Siewior]

Package: m2crypto
Version: 0.40.1-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2

OpenSSL had an optimisation for PKCS7_verify() where it kept the memory
BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for
verify fails because the memory BIO "ended".

The attached patch fixes the issue.

Sebastian
>From 08308043d7ce8bb645996c8cb29655a23ead43a4 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Tue, 13 Feb 2024 17:47:22 +0100
Subject: [PATCH] test/smime: Rewind BIO before repeadetly invoking verify.

OpenSSL had an optimisation for PKCS7_verify() where it kept the memory
BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for
verify fails because the memory BIO "ended".

Rewind the BIO before invoking verify again on the same data.

Signed-off-by: Sebastian Andrzej Siewior 
---
 tests/test_smime.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/test_smime.py b/tests/test_smime.py
index 6014315353824..1fe7e954fcb89 100644
--- a/tests/test_smime.py
+++ b/tests/test_smime.py
@@ -162,10 +162,12 @@ from tests import unittest
 with self.assertRaises(SMIME.PKCS7_Error):
 s.verify(p7, data)
 
+data.seek(0)
 st.set_verify_cb(verify_cb_dummy_function)
 v = s.verify(p7, data)
 self.assertEqual(v, self.cleartext)
 
+data.seek(0)
 st.set_verify_cb()
 v = s.verify(p7, data)
 self.assertEqual(v, self.cleartext)
-- 
2.43.0

Bug#1063875: mkdocs-material: Missing library dependency "paginate"

[Boyuan Yang]

Package: mkdocs-material
Version: 9.4.0-1
Severity: important

Dear Debian mkdocs-material maintainer,

Package "paginate" exists in requirements.txt and source code,
however current Debian package does not depends on this package.
It is not packaged in Debian yet.

Thanks,
Boyuan Yang


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

Bug#1062057: updated analysis results (ABI is unaffected)

[Adrien Nader]

Hi,

I just ran the analysis again: the ABI was dumped without requiring
any quirk. After diff, the result is that the ABI is not affected by
either time_t or LFS. :) 

I don't publish results after every update as that would be overwhelming
but I should do so by friday evening.

-- 
Adrien

Bug#1063876: xfsdump: move files from / to /usr (DEP17)

[Helmut Grohne]

Package: xfsdump
Version: 3.1.11-0.1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. After moving, we get rid of negative effects of
aliasing. xfsdump is involved, because it installs two utils to aliased
locations. I am sending a patch, because xfsdump cannot be automatically
converted using dh-sequence-movetousr. Note that this patch must not be
uploaded to bookworm-backports or earlier as it would violate the file
move moratorium there.

Helmut
diff --minimal -Nru xfsdump-3.1.11/debian/changelog 
xfsdump-3.1.11/debian/changelog
--- xfsdump-3.1.11/debian/changelog 2022-10-16 21:44:56.0 +0200
+++ xfsdump-3.1.11/debian/changelog 2024-02-13 14:12:03.0 +0100
@@ -1,3 +1,10 @@
+xfsdump (3.1.11-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move aliased xfs tools to /usr (DEP17). (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 13 Feb 2024 14:12:03 +0100
+
 xfsdump (3.1.11-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff --minimal -Nru xfsdump-3.1.11/debian/rules xfsdump-3.1.11/debian/rules
--- xfsdump-3.1.11/debian/rules 2022-10-16 21:44:56.0 +0200
+++ xfsdump-3.1.11/debian/rules 2024-02-13 14:12:03.0 +0100
@@ -27,7 +27,7 @@
@echo "== dpkg-buildpackage: configure" 1>&2
$(checkdir)
dh_autotools-dev_updateconfig
-   $(options) $(MAKE) include/config.h
+   $(options) $(MAKE) include/config.h 
LOCAL_CONFIGURE_OPTIONS='--exec-prefix=/nondefault --sbindir=/usr/sbin'
touch .census
 
 clean:

Bug#1063877: squid FTCBFS: fails detecting kerberos due to AC_RUN_IFELSE

[Helmut Grohne]

Source: squid
Version: 6.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

squid fails to cross build from source, because it pessimistically uses
AC_RUN_IFELSE, therefore concludes that kerberos is unavailable and then
causes a compiler error due to an untested code path. I've reviewed the
uses of AC_RUN_IFELSE and a number of them do not actually benefit from
running code (while others do). I'm attaching a patch that converts some
of the AC_RUN_IFELSE to AC_LINK_IFELSE and these happen to be enough to
make squid cross buildable (though the cross build still turns of some
features compared to a native build unless one provides more cache
variables externally). What do you think about the attached conversion?

Helmut
--- squid-6.6.orig/acinclude/krb5.m4
+++ squid-6.6/acinclude/krb5.m4
@@ -33,7 +33,7 @@
   AC_CACHE_CHECK([for broken Heimdal krb5.h],squid_cv_broken_heimdal_krb5_h, [
 SQUID_STATE_SAVE(squid_krb5_heimdal_test)
 CPPFLAGS="-I${srcdir:-.} $CPPFLAGS"
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include 
 int
 main(void)
@@ -45,7 +45,7 @@
 return 0;
 }
 ]])], [ squid_cv_broken_heimdal_krb5_h=no ], [
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define HAVE_BROKEN_HEIMDAL_KRB5_H  1
 #include "compat/krb5.h"
 int
@@ -130,7 +130,7 @@
 dnl checks that gssapi is ok, and sets squid_cv_working_gssapi accordingly
 AC_DEFUN([SQUID_CHECK_WORKING_GSSAPI], [
   AC_CACHE_CHECK([for working gssapi], squid_cv_working_gssapi, [
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #if USE_HEIMDAL_KRB5
 #if HAVE_GSSAPI_GSSAPI_H
 #include 
@@ -231,7 +231,7 @@
   AC_CACHE_CHECK([for working krb5], squid_cv_working_krb5, [
 SQUID_STATE_SAVE(squid_krb5_test)
 CPPFLAGS="-I${srcdir:-.} $CPPFLAGS"
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include "compat/krb5.h"
 int
 main(void)

Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

[Helmut Grohne]

Package: di-utils
Version: 1.148
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + dpkg
Tags: patch
Forwarded: 
https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/11
X-Debbugs-Cc: b...@debian.org, f...@debian.org

Hi,

Raphael kindly pointed me at this Kali Linux bug report:
https://bugs.kali.org/view.php?id=8628
In there, we can see (among other things):

| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename

Due to this harmless warning, we learn that /sbin/start-stop-daemon is
being diverted, but dpkg now installs it as /usr/sbin/start-stop-daemon.
We are effectively faced with what DEP17 P3 calls an ineffective
diversion. We later see:

| Feb 8 22:07:08 grub-installer: dpkg: warning: 'start-stop-daemon' not found 
in PATH or not executable
| Feb 8 22:07:08 grub-installer: dpkg: error: 1 expected program not found in 
PATH or not executable
| Feb 8 22:07:08 grub-installer: Note: root's PATH should usually contain 
/usr/local/sbin, /u
| Feb 8 22:07:08 grub-installer: sr/sbin and /sbin

Raphael kindly pointed at chroot-setup.sh from di-utils. There
/sbin/start-stop-daemon is diverted with --rename. Since it is installed
as /usr/sbin/start-stop-daemon, this diversion (and its rename) does not
take any effect. When it is undiverted, the /sbin/start-stop-daemon (and
since the chroot is /usr-merged also /usr/sbin/start-stop-daemon) is
deleted and then undiverted with --rename, but there is no
/sbin/start-stop-daemon.REAL, because that diversion ended up being
ineffective. Therefore, nothing is moved back and we lost
/sbin/start-stop-daemon (and /usr/sbin-start-stop-daemon).

I've prepared a patch that duplicates diversions as needed and filed it
in the linked merge request on salsa. I've attempted testing this, but
debian-installer still FTBFS in unstable. Holger told me that Fil and
openqa.debian.net would be somehow able to test MRs on salsa. Fil, can
you help here?

I also see that https://openqa.debian.net/ has recent successes. dpkg
migrated to trixie about two weeks ago. I would have expected that this
breaks an d-i. Do you have an explanation for why jobs still pass?

Raphael, can you link this bug to the Kali bug?

Helmut

Bug#1060256: Please enable the Rust parts

[Steinar H. Gunderson]

On Tue, Feb 06, 2024 at 11:55:55AM +0200, Faidon Liambotis wrote:
>> Still required.
> I uploaded that last week, currently sitting in NEW.

Now that this is through NEW, I uploaded an NMU to DELAYED/7-day.
I see that this package is in LowThresholdNmu, but given that it
adds an epoch, I'm giving everyone a week to speak up if they feel
this is wrong :-)

The package can be found at

  https://storage.sesse.net/bcachefs-tools/

and the git repository I built from at

  https://git.sesse.net/?p=bcachefs-tools-debian

I used (with upstream being github.com/koverstreet/bcachefs-tools)

  gbp buildpackage --git-upstream-tree=upstream/master

and then built with pbuilder. I've tested that this works fine with bcachefs
as root device on my workstation (which also has some patches for multi-device
root; see #1060256).

Thanks to Faidon for paving the way here :-)

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