Bug#1055509: diversions of /sbin/halt and friends

[Daniel Baumann]

On 12/22/23 12:30, Helmut Grohne wrote:

I am happy with all of these changes moving to
unstable and trixie.


applied and uploaded both p-l-metapackages and bfh-metapackages to unstable.


Thanks for your patience.


thank you for all your work and help!

Regards,
Daniel

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Paul Gevers]

Source: apt
Version: 2.7.6
Severity: serious
Control: close -1 2.7.7
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:apt has been trying to migrate for 31 days 
[2]. Hence, I am filing this bug. The version in unstable fails its own 
autopkgtest on armhf.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059351: swiftlang: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: swiftlang
Version: 5.6.3
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for swiftlang
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
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the swiftlang package.
# Helge Kreutzmann , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: swiftlang 5.6.3\n"
"Report-Msgid-Bugs-To: swiftl...@packages.debian.org\n"
"POT-Creation-Date: 2022-09-01 07:11-0700\n"
"PO-Revision-Date: 2023-12-20 18:57+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"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Would you like to create the recommended symbolic link /usr/bin/swift?"
msgstr ""
"Möchten Sie den empfohlenen symbolischen Link /usr/bin/swift erstellen?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"There is a binary \"swift\" provided by package \"python3-swiftclient\" that "
"predates swiftlang and its binaries. If you do not plan to make use of the "
"\"python3-swiftclient\" package then creating this symbolic link allows the "
"Swift programming language to work as intended with the command \"swift\" "
"available in your PATH. Without this link you cannot use the REPL and must "
"compile with the \"swiftc\" command."
msgstr ""
"Es gibt ein durch das Paket »python3-swiftclient« bereitgestelltes Programm "
"»swift«, dass älter als Swiftlang und seine Programme ist. Falls Sie nicht "
"vorhaben, das Paket »python3-swiftclient« zu verwenden, ermöglicht es dieser "
"symbolische Link, dass die Programmiersprache Swift wie vorgesehen mit dem in "
"Ihrem Pfad verfügbaren Programm »swift« funktioniert. Ohne diesen Link "
"können Sie REPL nicht verwenden und müssen mit dem Befehl »swiftc« "
"kompilieren."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"If you choose not to create this link now you can always create it later by "
"linking /usr/libexec/swift/bin/swift to /usr/bin/swift."
msgstr ""
"Falls Sie sich entscheiden, diesen Link nicht jetzt zu erstellen, können Sie "
"ihn später durch Verlinken von /usr/libexec/swift/bin/swift auf /usr/bin/"
"swift erstellen."

#. Type: note
#. Description
#: ../templates:2001
msgid "/usr/bin/swift already exists"
msgstr "/usr/bin/swift existiert bereits"

#. Type: note
#. Description
#: ../templates:2001
msgid ""
"Found an exiting /usr/bin/swift! This was probably previously installed by "
"the python3-swiftclient package. This will prevent you from calling the "
"Swift REPL with the command \"swift\" and you will need to compile with the "
"\"swiftc\" command."
msgstr ""
"Ein bestehendes /usr/bin/swift wurde gefunden! Es wurde wahrscheinlich "
"früher von dem Paket python3-swiftclient installiert. Dies wird verhindern, "
"dass Sie das Swift REPL mit dem Befehl »swift« aufrufen und Sie müssen mit "
"dem Befehl »swiftc« übersetzen."

Bug#1053000: RFS: golang-github-google-gnostic-models/0.6.8-1 [ITP] -- Protocol buffer models for gnostic

[Nilesh Patra]

On Fri, Dec 22, 2023 at 12:49:34PM +0100, Nicolas Schier wrote:
> thanks a lot for your review!  I fixed all four points (and updated the
> debian/watch version) so lintian is now completely satisfied.
> 
> The corresponding fixup commit is pushed to
> 
>   
> https://salsa.debian.org/go-team/packages/golang-github-google-gnostic-models.git

Uploaded to NEW. Thanks for contributing!

> (TIL: I should always push 'UNRELEASED' to the git repos as long as the
> package is not completely reviewed and accepted.)

Yep!

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1059350: debian-keyring: missing update since 2023.09.24

[Kentaro HAYASHI]

Package: debian-keyring
X-Debbugs-Cc: ken...@xdump.org
Version: 2023.09.24
Severity: normal

Dear Maintainer,

* What led up to the situation?

debian-keyring package has not updated for a while.
(last update was debian-keyring 2023.09.24)

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

I've checked the recent activity on salsa.d.o

https://salsa.debian.org/debian-keyring/keyring/-/commits/master?ref_type=heads

It seems that tagged but not released yet.


* What was the outcome of this action?

Even though refreshed key was sent to keyring.debian.org,
 it was not reflected.
There is a case that contained key may be expired.

If there is no release in a long term, it will cause
delay of uploading package for affected DD.

Could you release newer version of debian-keyring?

* What outcome did you expect instead?

N/A.



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

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

debian-keyring depends on no packages.

Versions of packages debian-keyring recommends:
ii  gnupg  2.2.40-1.1

debian-keyring suggests no packages.

-- no debconf information

Bug#1059349: deal.ii ftbfs on ppc64el (with boost1.83)

[Matthias Klose]

Package: src:deal.ii
Version: 9.5.1-1
Severity: serious
Tags: sid trixie
X-Debbugs-CC: debian-powe...@lists.debian.org, Debian Boost Team 




[...]
[ 41%] Building CXX object 
source/dofs/CMakeFiles/object_dofs_debug.dir/number_cache.cc.o
cd /<>/obj-powerpc64le-linux-gnu/source/dofs && 
/usr/bin/c++ -DDEBUG 
-I/<>/obj-powerpc64le-linux-gnu/source/dofs 
-I/<>/source/dofs 
-I/<>/obj-powerpc64le-linux-gnu/include 
-I/<>/include -isystem 
/usr/lib/powerpc64le-linux-gnu/openmpi/include -isystem 
/usr/lib/powerpc64le-linux-gnu/openmpi/include/openmpi -isystem 
/usr/include/petsc -isystem /usr/include/trilinos -isystem 
/usr/include/hdf5/openmpi -isystem /usr/include/scotch -isystem 
/usr/include/suitesparse -isystem /usr/include/opencascade -isystem 
/usr/include/slepc -std=c++17 -fPIC -pedantic -Wall -Wextra 
-Wmissing-braces -Woverloaded-virtual -Wpointer-arith -Wsign-compare 
-Wsuggest-override -Wswitch -Wsynth -Wwrite-strings -Wno-placement-new 
-Wno-deprecated-declarations -Wno-literal-suffix -Wno-psabi 
-Wno-class-memaccess -Wno-unused-local-typedefs -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 
-Wno-nonnull-compare -Wno-address -O0 -ggdb 
-Wa,--compress-debug-sections -MD -MT 
source/dofs/CMakeFiles/object_dofs_debug.dir/number_cache.cc.o -MF 
CMakeFiles/object_dofs_debug.dir/number_cache.cc.o.d -o 
CMakeFiles/object_dofs_debug.dir/number_cache.cc.o -c 
/<>/source/dofs/number_cache.cc
In file included from 
/usr/include/boost/math/special_functions/detail/round_fwd.hpp:12,
 from 
/usr/include/boost/math/special_functions/math_fwd.hpp:29,
 from 
/usr/include/boost/math/special_functions/legendre.hpp:16,
 from 
/<>/include/deal.II/base/std_cxx17/cmath.h:32,

 from /<>/source/base/function_lib.cc:20:
/usr/include/boost/math/tools/promotion.hpp: In instantiation of ‘struct 
boost::math::tools::promote_argsfloat, float>’:
/usr/include/boost/math/tools/promotion.hpp:272:13:   required by 
substitution of ‘templateT5, class T6> using boost::math::tools::promote_args_t = typename 
boost::math::tools::promote_args::type [with T1 = long double; T2 = 
float; T3 = float; T4 = float; T5 = float; T6 = float]’
/usr/include/boost/math/special_functions/legendre.hpp:247:4:   required 
by substitution of ‘template 
boost::math::tools::promote_args_t boost::math::legendre_p(int, T) 
[with T = long double]’
/<>/include/deal.II/base/std_cxx17/cmath.h:99:35: 
required from here
/usr/include/boost/math/tools/promotion.hpp:267:27: error: static 
assertion failed: Sorry, but this platform does not have sufficient long 
double support for the special functions to be reliably implemented.
  267 |  static_assert((0 == std::is_samedouble>::value), "Sorry, but this platform does not have sufficient long 
double support for the special functions to be reliably implemented.");
  | 
~~~^~
/usr/include/boost/math/tools/promotion.hpp:267:27: note: the comparison 
reduces to ‘(0 == 1)’
/usr/include/boost/math/tools/promotion.hpp: In instantiation of ‘struct 
boost::math::tools::promote_argsfloat, float, float>’:
/usr/include/boost/math/tools/promotion.hpp:272:13:   required by 
substitution of ‘templateT5, class T6> using boost::math::tools::promote_args_t = typename 
boost::math::tools::promote_args::type [with T1 = long double; T2 = long 
double; T3 = long double; T4 = float; T5 = float; T6 = float]’
/usr/include/boost/math/special_functions/legendre.hpp:28:4:   required 
by substitution of ‘template 
boost::math::tools::promote_args_t 
boost::math::legendre_next(unsigned int, T1, T2, T3) [with T1 = long 
double; T2 = long double; T3 = long double]’
/usr/include/boost/math/special_functions/legendre.hpp:69:53:   required 
from ‘T boost::math::detail::legendre_imp(unsigned int, T, const 
Policy&, bool) [with T = long double; Policy = 
boost::math::policies::policyboost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy, 
boost::math::policies::default_policy>]’
/usr/include/boost/math/special_functions/legendre.hpp:228:88: 
required from ‘typename 
std::enable_if::value, typename 
boost::math::tools::promote_args::type>::type 
boost::math::legendre_p(int, T, const Policy&) [with T = long double; 
Policy = policies::policypolicies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy>; typename 
std::enable_if::value, typename 

Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo

[Nilesh Patra]

On Fri, Dec 22, 2023 at 06:03:11AM +0100, Nicolas Schier wrote:
> On Thu, Dec 21, 2023 at 11:01:23PM +0530 Nilesh Patra wrote:
> > On Wed, Dec 20, 2023 at 09:49:48AM +0100, Nicolas Schier wrote:
> > > On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote:
> > > ah, I forgot to mention that 'uscan' does choose the "correct" upstream 
> > > version
> > > tag automatically:
> > > [...]
> > > > Can someone please remove the protected branch 'upstream' as well as the
> > > > upstream tag 'upstream/1.25.0_alpha0'?
> > > > 
> > > > (Or remove the whole repo to allow re-creating it?)
> > 
> > Do you still want the repo to be pruned or remove the upstream branch?
> 
> yes, please.

Pruned the repo. HTH

> > > > [1]: 
> > > > https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1

[M. Zhou]

On Thu, 2023-12-21 at 21:48 +, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Thu, Dec 21, 2023 at 10:06:23PM +0100, Salvatore Bonaccorso wrote:
> > Can you as well add  a bug closer for #1057455?
> 
> And a brief description of what the vulnerability actually is, please. You
> can go ahead with those changes.

Thanks. I added the missing information as follows, and will upload it shortly.


---
diff --git a/debian/changelog b/debian/changelog
index 0c1065b..3f18ea1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,10 @@
 fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium
 
-  * Cherry-pick upstream fix for CVE-2023-49284.
+  * Cherry-pick upstream fix for CVE-2023-49284. (Closes: #1057455)
+fish shell uses certain Unicode non-characters internally for marking
+wildcards and expansions. It will incorrectly allow these markers to be
+read on command substitution output, rather than transforming them into
+a safe internal representation.
 
  -- Mo Zhou   Thu, 21 Dec 2023 14:47:56 -0500
 
diff --git a/debian/patches/CVE-2023-49284.patch 
b/debian/patches/CVE-2023-49284.patch
index a6fb924..5830277 100644
--- a/debian/patches/CVE-2023-49284.patch
+++ b/debian/patches/CVE-2023-49284.patch
@@ -4,6 +4,16 @@ Description: fixes CVE-2023-49284
  The corresponding fix can be found at
  
https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14
  This patch is rebased from the upstream fix.
+ .
+ fish shell uses certain Unicode non-characters internally for marking
+ wildcards and expansions. It will incorrectly allow these markers to be read
+ on command substitution output, rather than transforming them into a safe
+ internal representation.
+ .
+ While this may cause unexpected behavior with direct input (for example, echo
+ \UFDD2HOME has the same output as echo $HOME), this may become a minor 
security
+ problem if the output is being fed from an external program into a command
+ substitution where this output may not be expected.

Bug#1059348: UDD: import/display data from piuparts about dpkg alternatives

[Paul Wise]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd

piuparts is extracting data about dpkg alternatives for every package
it tests. It would be nice to have the data imported into UDD and
the results presented in a CGI on the UDD website.

https://piuparts.debian.org/for-manpages.d.o/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1022718: O: ghostscript -- interpreter for the PostScript language and for PDF

[Steven Robbins]

retitle 1022718 'ITA: ghostscript -- interpreter for the PostScript language 
and for PDF'
owner  1022718 s...@debian.org
done 1036869


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

Bug#1056643: RFS: gtklock/2.1.0-1 [ITP] -- GTK-based lockscreen for wayland

[Maytham Alsudany]

Hi Matthias,

On Wed, 2023-12-13 at 23:29 +0100, Matthias Geiger wrote:
> copyright looks good now, good work. Minor nitpick: Section should be 
> x11 since it's a sway-related package.

Done.


Kind regards,
Maytham


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

Bug#1059347: flashrom doesn't know its own version

[Jonathan Neuschäfer]

Package: flashrom
Version: 1.3.0-2.1
Severity: minor

I don't know if it's due to an upstream bug, or a problem in the Debian
packaging, but flashrom fails to report its own version when asked with
--version:

> $ flashrom --version
> flashrom unknown on Linux 6.5.0-4-amd64 (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
> 
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).



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

Kernel: Linux 6.5.0-4-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 flashrom depends on:
ii  libc6 2.37-12
ii  libftdi1-21.5-6+b3
ii  libjaylink0   0.3.1-1
ii  libpci3   1:3.10.0-2
ii  libusb-1.0-0  2:1.0.26-1

flashrom recommends no packages.

flashrom suggests no packages.

-- debconf-show failed

Bug#1059336: ITP: node-html5-qrcode -- qr-code and bar-code scanning library for the web

[Yadd]

On 12/22/23 22:58, Georges Khaznadar wrote:

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

* Package name: node-html5-qrcode
   Version : 2.3.8
   Upstream Contact: https://github.com/mebjas/html5-qrcode/issues
* URL : https://github.com/mebjas/html5-qrcode
* License : Apache-2.0, GPL2
   Programming Lang: nodejs, typescript
   Description : qr-code and bar-code scanning library for the web

  Use this lightweight library to easily / quickly integrate QR code,
  bar code, and other common code scanning capabilities to your web
  application.

So far, debian is missing a package to scan qrcodes and barcodes from
a web page. I intend to maintain this package as a dependency for a
future package SLM, school library management, which I am developping
actively. This latter package allows students to find and recognize
books inside a library by scanning a few qr-codes.

The package node-html5-qrcode is uploaded to
https://salsa.debian.org/georgesk/node-html5-qrcode.git


Hi,

your debian/rules uses npm to build instead of launching direct commands 
but the worst is that you call "npm install" which imports files from 
Internet, this is not compliant with policy.


Cheers,
Yadd

Bug#1053334: galera-4: FTBFS because of expired certificates

[Otto Kekäläinen]

Sure, this will be fixed (automatically) with uploading latest upstream
minor release as stable update, and I intend to do it in coming 1-2 weeks.

Bug#1052740: graphite2: FTBFS: graph_legend.dot:1: error: Problems running dot: exit code=1, command='dot', arguments='"/<>/build/doc/doxygen/html/graph_legend.dot" -Tpng -o "/<

[Bastian Germann]

graph_legend.dot should have quotes around the font name references.
This is probably a doxygen bug. A workaround would be removing doxygen from 
Build-Depends
and the two doxgen output files from debian/libgraphite2-doc.docs

Bug#1059346: Grub install dummy failed arm64

[TarotApprentice]

Package: installation-reportsVersion: 12.0
Machine is a Gigabyte R272 Ampere Altra. Trying to install bookworm. Machine 
was running bullseye previously. Only storage in the machine is an m2 nvme 
drive. Using the netinst installer written to a USB thumb drive. Machine boots 
into Debian installer, install proceeds as normal until we get to the 
bootloader. It fails with a “grub install dummy” failed message. Nvme drive was 
partitioned with all files in one drive, no encryption.
Not sure where to look after I get this error. The installer offers an option 
to save debug logs but the only removable media I have at that point is the 
thumb drive.
A google search suggests that using a USB 2 port for the thumb drive might 
work. It doesn’t make any difference.
Where to look for the real error message rather than the installer pop up 
message?
MarkJ

Bug#1059345: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2023d

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.47-1+2023d to bullseye.
It includes the new tzdata release as a quilt patch.

Manually stripped down debdiff attached.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWGMpdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgY9jw/+IcD4/fkUGMcuy63JbEYHnHPtHA1Tci8bHYnyYef/aY6/KxDuAqcJHAbM
UGUgS09njELipkV21V+U/9SGrV9AhUia+2EneuMNZFTb+wCuTQGNm6C1Uo7WYJmw
1L1pHmsrlV3ShOZkjYmQODeIJfCyjYNQAcIGkrSMAIO1eK1xMVWuL7J64aWnHTnV
Be5ib3LaArz1caA7aas5WLE5sh9c0htZYTkceNXCiPjeNUJFG9YZAjyCTyBeMbsk
H+V29YyjksiOHW03lQdlOa/HulB6sGYzkEWNIzr0GfIYgpGlLOYSNnGiFY5YC2Ji
ePea3z01VyxYYlSehEGpdG2g33FcQwFzaY991g3Ey0zvSJ62dtre75w9kbU/dIEf
lxHKiZU/2qv2YUKN4hggt8Fjccz6oK4U/4uZB/O/MfP8GxoAEb7Udrllihjx/+xV
FiejEQmm+OSJJrFzDlmAmqYCk4AkP/gWuiZyaJ9otwtMnq1DaLdiw4wpazXrvRr4
OAdfR/rb2h+yZE0+idxmgg903eTFEwCIAx+hCVlulk+m2L2OY8q7i0wQhPDR4H9z
AAADq8m8ro/iLCNKST979NyceTBErjn9aNrzXZwi27VmI5ZNFnvxlv5gEtYqTA0W
3p7mRGZUXJy3U0zza05VKmK5iXOpKp8nUcfHZHVhdYg8mzXNpYw=
=lgAZ
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2023-03-29 
20:21:49.0 +0200
+++ libdatetime-timezone-perl-2.47/debian/changelog 2023-12-23 
01:50:44.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.47-1+2023d) bullseye; urgency=medium
+
+  * Update data to Olson database version 2023d.
+This update contains contemporary changes for Antarctica and Greenland.
+
+ -- gregor herrmann   Sat, 23 Dec 2023 01:50:44 +0100
+
 libdatetime-timezone-perl (1:2.47-1+2023c) bullseye; urgency=medium
 
   * Update data to Olson database version 2023c.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2023d 
libdatetime-timezone-perl-2.47/debian/patches/olson-2023d
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2023d   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2023d   2023-12-23 
01:50:44.0 +0100
@@ -0,0 +1,7146 @@
+Description: Update to Olson DB 2023d
+Origin: vendor
+Author: gregor herrmann 
+Reviewed-by: gregor herrmann 
+Last-Update: 2023-12-23
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2023c
++# Generated from debian/tzdata/africa.  Olson data version 2023d
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023c'}
++sub olson_version {'2023d'}
+ 
+ sub has_dst_changes {0}
+ 
+--- /dev/null
 b/lib/DateTime/TimeZone/Antarctica/Vostok.pm
+@@ -0,0 +1,86 @@
++# This file is auto-generated by the Perl DateTime Suite time zone
++# code generator (0.08) This code generator comes with the
++# DateTime::TimeZone module distribution in the tools/ directory
++
++#
++# Generated from debian/tzdata/antarctica.  Olson data version 2023d
++#
++# Do not edit this file directly.
++#
++package DateTime::TimeZone::Antarctica::Vostok;
++
++use strict;
++use warnings;
++use namespace::autoclean;
++
++our $VERSION = '2.47';
++
++use Class::Singleton 1.03;
++use DateTime::TimeZone;
++use DateTime::TimeZone::OlsonDB;
++
++@DateTime::TimeZone::Antarctica::Vostok::ISA = ( 'Class::Singleton', 
'DateTime::TimeZone' );
++
++my $spans =
++[
++[
++DateTime::TimeZone::NEG_INFINITY, #utc_start
++61755609600, #  utc_end 1957-12-16 00:00:00 (Mon)
++DateTime::TimeZone::NEG_INFINITY, #  local_start
++61755609600, #local_end 1957-12-16 00:00:00 (Mon)
++0,
++0,
++'-00',
++],
++[
++61755609600, #utc_start 1957-12-16 00:00:00 (Mon)
++62895718800, #  utc_end 1994-01-31 17:00:00 (Mon)
++61755634800, #  local_start 1957-12-16 07:00:00 (Mon)
++62895744000, #local_end 1994-02-01 00:00:00 (Tue)
++25200,
++0,
++'+07',
++],
++[
++62895718800, #utc_start 1994-01-31 17:00:00 (Mon)
++62919331200, #  utc_end 1994-11-01 00:00:00 (Tue)
++62895718800, #  local_start 1994-01-31 17:00:00 (Mon)
++62919331200, #local_end 1994-11-01 00:00:00 (Tue)
++0,
++0,
++'-00',
++],
++[
++62919331200, #utc_start 1994-11-01 00:00:00 (Tue)
++63838522800, #  utc_end 2023-12-17 19:00:00 (Sun)
++62919356400, #  local_start 1994-11-01 07:00:00 (Tue)
++63838548000, #local_end 2023-12-18 02:00:00 (Mon)
++25200,
++0,
++'+07',
++],
++[
++63838522800, #utc_start 2023-12-17 19:00:00 (Sun)
++DateTime::TimeZone::INFINITY, #  

Bug#1059344: bookworm-pu: package libdatetime-timezone-perl/1:2.60-1+2023d

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.60-1+2023d to bookworm.
As usual, it contains the tzdata data 2023d as a quilt patch.

Manually stripped down debdiff attached.



Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWGK3tfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaueA/7BufaCNIYWZfeI5Unp8avYsvGkU9BSOc/1nl7T80D6s/kwn/QXFPnqze5
f9JL59YGiq7ALJ1vQK1TewCWKx6OsjbexVVTRIpjMNXL1QqPkVcJwhkZTOmhkHGu
xGG7MPw6Rr4UlG4NxV0Rbny6KSF0PCasoDEyd9GzqSARKupNvyPFxkFDyt7oZ/x4
5cvbI0RhOYTR8sm2Hg/ws+7YWbL735brv1E4+vMozV5jXXiljynT1GaQB03kk+dx
pdueZSzRftrelYxI1kM8nji3GtVAzG4gcx7C+PMMbXNE5XPyGt/klCUGRkJCX5rS
/2usevQdAsSv04v1wMQK8Fce56+J2wig5KP423UIX5AvtANIF3VJUuFYQKVv+Uo/
I5awNmuSqbs0zOPi4z72zn4+oS7tIdU6ABWK+SFuaxbH6dslyVL+nzVMmfmjeEFF
oFQawN88lyf7wcLdfCbhiTYlBFTrmrUbKUbGFuOD6oGTfbmhz+zl27VNjj2MOf2M
KYKDCNSccTpVzl34rOOXlQJQUb+Q66PbcYkkghNAY9LChgoUFw7BPR/2dkj52gQA
Ltat77yQWp386jrX7FquhejUMVmRP9qcx1EVuLO10DExKAXdc/vEjrt2UIfmXfHa
91xgevUJGyArw7LIyBcOvc8TkoXzadKLNSxx4VU3d9ecmIk453o=
=dLDF
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.60/debian/changelog 
libdatetime-timezone-perl-2.60/debian/changelog
--- libdatetime-timezone-perl-2.60/debian/changelog 2023-03-29 
19:46:25.0 +0200
+++ libdatetime-timezone-perl-2.60/debian/changelog 2023-12-23 
01:27:56.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.60-1+2023d) bookworm; urgency=medium
+
+  * Update data to Olson database version 2023d.
+This update contains contemporary changes for Antarctica and Greenland.
+
+ -- gregor herrmann   Sat, 23 Dec 2023 01:27:56 +0100
+
 libdatetime-timezone-perl (1:2.60-1+2023c) unstable; urgency=medium
 
   * Import upstream version 2.60.
diff -Nru libdatetime-timezone-perl-2.60/debian/patches/olson-2023d 
libdatetime-timezone-perl-2.60/debian/patches/olson-2023d
--- libdatetime-timezone-perl-2.60/debian/patches/olson-2023d   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.60/debian/patches/olson-2023d   2023-12-23 
01:27:56.0 +0100
@@ -0,0 +1,7155 @@
+Description: Update to Olson DB 2023d
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2023-12-23
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from /tmp/DzE_ngvtVe/africa.  Olson data version 2023c
++# Generated from debian/tzdata/africa.  Olson data version 2023d
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023c'}
++sub olson_version {'2023d'}
+ 
+ sub has_dst_changes {0}
+ 
+--- /dev/null
 b/lib/DateTime/TimeZone/Antarctica/Vostok.pm
+@@ -0,0 +1,86 @@
++# This file is auto-generated by the Perl DateTime Suite time zone
++# code generator (0.08) This code generator comes with the
++# DateTime::TimeZone module distribution in the tools/ directory
++
++#
++# Generated from debian/tzdata/antarctica.  Olson data version 2023d
++#
++# Do not edit this file directly.
++#
++package DateTime::TimeZone::Antarctica::Vostok;
++
++use strict;
++use warnings;
++use namespace::autoclean;
++
++our $VERSION = '2.60';
++
++use Class::Singleton 1.03;
++use DateTime::TimeZone;
++use DateTime::TimeZone::OlsonDB;
++
++@DateTime::TimeZone::Antarctica::Vostok::ISA = ( 'Class::Singleton', 
'DateTime::TimeZone' );
++
++my $spans =
++[
++[
++DateTime::TimeZone::NEG_INFINITY, #utc_start
++61755609600, #  utc_end 1957-12-16 00:00:00 (Mon)
++DateTime::TimeZone::NEG_INFINITY, #  local_start
++61755609600, #local_end 1957-12-16 00:00:00 (Mon)
++0,
++0,
++'-00',
++],
++[
++61755609600, #utc_start 1957-12-16 00:00:00 (Mon)
++62895718800, #  utc_end 1994-01-31 17:00:00 (Mon)
++61755634800, #  local_start 1957-12-16 07:00:00 (Mon)
++62895744000, #local_end 1994-02-01 00:00:00 (Tue)
++25200,
++0,
++'+07',
++],
++[
++62895718800, #utc_start 1994-01-31 17:00:00 (Mon)
++62919331200, #  utc_end 1994-11-01 00:00:00 (Tue)
++62895718800, #  local_start 1994-01-31 17:00:00 (Mon)
++62919331200, #local_end 1994-11-01 00:00:00 (Tue)
++0,
++0,
++'-00',
++],
++[
++62919331200, #utc_start 1994-11-01 00:00:00 (Tue)
++63838522800, #  utc_end 2023-12-17 19:00:00 (Sun)
++62919356400, #  local_start 1994-11-01 07:00:00 (Tue)
++63838548000, #local_end 2023-12-18 02:00:00 (Mon)
++25200,
++0,
++'+07',
++],
++[
++63838522800, #utc_start 2023-12-17 19:00:00 (Sun)
++DateTime::TimeZone::INFINITY, #  utc_end
++63838540800, #  local_start 

Bug#1041311: marked as done (jool: please drop superfluous B-D: dkms)

[Alberto Leiva]

Sorry, Andreas. As mentioned in the other bug, I struggle to notice
these bug reports among the Debian notifications.

Removing dkms from Build-Depends results in a Lintian error:

E: jool source: missing-build-dependency-for-dh_-command dh_dkms => dkms
N:
E: missing-build-dependency-for-dh_-command
N:
N:   The source package appears to be using a dh_ command but doesn't build
N:   depend on the package that actually provides it. If it uses it, it
N:   must build depend on it.
N:
N:   Severity: error
N:
N:   Check: debhelper

I have not deleted dh-sequence-dkms from the Build-Depends.

Any advice?

On Tue, Jul 18, 2023 at 11:11 AM Debian Bug Tracking System
 wrote:
>
> Your message dated Tue, 18 Jul 2023 17:06:11 +
> with message-id 
> and subject line Bug#1041311: fixed in netplan.io 0.106.1-6
> has caused the Debian Bug report #1041311,
> regarding jool: please drop superfluous B-D: dkms
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 1041311: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041311
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Andreas Beckmann 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 17 Jul 2023 12:17:57 +0200
> Subject: jool: please drop superfluous B-D: dkms
> Source: jool
> Version: 4.1.10-1
> Severity: minor
>
> Hi,
>
> src:jool has a superfluous B-D on dkms. Everything that is needed comes
> with dh-sequence-dkms.
>
>
> Andreas
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1041311-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 18 Jul 2023 17:06:11 +
> Subject: Bug#1041311: fixed in netplan.io 0.106.1-6
> Source: netplan.io
> Source-Version: 0.106.1-6
> Done: Lukas Märdian 
>
> We believe that the bug you reported is fixed in the latest version of
> netplan.io, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1041...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Lukas Märdian  (supplier of updated netplan.io package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 18 Jul 2023 17:35:49 +0200
> Source: netplan.io
> Built-For-Profiles: noudeb
> Architecture: source
> Version: 0.106.1-6
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Netplan Maintainers 
> Changed-By: Lukas Märdian 
> Closes: 1041311
> Changes:
>  netplan.io (0.106.1-6) unstable; urgency=medium
>  .
>* Fix ethernets,vlans,scenarios autopkgtests on systemd 254, Closes: 
> #1041311
> Checksums-Sha1:
>  5866e1cafec487762ff29d221293b6b174bbd065 2747 netplan.io_0.106.1-6.dsc
>  60732dc8da053041526f01d6883a5bd3c431510b 29552 
> netplan.io_0.106.1-6.debian.tar.xz
>  ec27beebf6043915662c115e9d289f12a9a306bf 12131 
> netplan.io_0.106.1-6_source.buildinfo
> Checksums-Sha256:
>  84e233657f8b23136e8a3c3b41dce79783c6a1145b4169f4da5b941f78385016 2747 
> netplan.io_0.106.1-6.dsc
>  a82a2fc8194abbb47d1958b6d7fb86a6b6daee45fa126f096d47ef93de5d0ee5 29552 
> netplan.io_0.106.1-6.debian.tar.xz
>  4323c40f0ee19bb4746466422a0afb8632f8bf2df745cc0a5fa05d58d4389f46 12131 
> netplan.io_0.106.1-6_source.buildinfo
> Files:
>  2989b821aa41a6ca3f2c6512e5c0a61f 2747 net optional netplan.io_0.106.1-6.dsc
>  a8644d161b561b112cdda3cc1155a6ca 29552 net optional 
> netplan.io_0.106.1-6.debian.tar.xz
>  c198db04b372c3a6e1765cf496ec7a39 12131 net optional 
> netplan.io_0.106.1-6_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEE496GmCL5m2y8NfJ5v322IrMDrIsFAmS2tysACgkQv322IrMD
> rIvJzRAArnu7hzJcVUDQ+pWbZXg08MhfETdpBk2T76ovfj3emymjEnXxHZfHZ9J2
> k0AnNRTlzNKs3Q0MGEI1ZnxAee6QUsG+KUc5UsG0BZZw67QzGkHq+pnAYs+sa5H4
> NTJVJ1WMjRdjrraUZVuyNwpYTM5OtXN2VKAHGQ4mF/25QFyBW2a0NnH1rUspfuJJ
> i6Qh2/FXv5vq7im6x6Hn10ziM/N19EnmtsX0z7aJ5MGm5khuQdW+VX7QGzFrc/EO
> stZJPdZyoiBXmXIKXm+yQlYY8KRnFngK3FWpu3IhzYBKSz/rjyb3R5SX4cuYTNy6
> zbFJWCZO8ZWrd23hGJ2VF4cd6SpObSAmcbFMYVqM3fdIwAY7KnlXdvamRasfOW5U
> gdnNUnXTHYE/rH/eDQy5F3Hg4vdiiDEU08KWVsdlwPC7od+CPY4F8rIY8TK0PDuR
> jU7HcrzzC8A5kZAikXwemRwlbQjbZFIxbntZPb+hqFkBz1i/O2H1PAZNypAcvMh4
> 

Bug#1057703: Please stop build-depending on mime-support

[Alberto Leiva]

Sorry; I struggle to notice these bug reports among the Debian notifications.

Thank you; I will have this fixed by version 4.1.11, which should be
released tomorrow at the latest.

On Tue, Dec 12, 2023 at 8:29 AM Charles Plessy  wrote:
>
> Le Thu, Dec 07, 2023 at 08:14:30PM +0900, Charles Plessy a écrit :
> >
> > Please either drop the build-depend on mime-support or replace it by
> > media-types.
> >
> > If you are busy I can offer to NMU your package.  I would like to remove
> > mime-support from the archive.
>
> Dear Alberto,
>
> unless you object, I intend to upload the fix to DELAYED/8 soon.
>
> Have a nice day,
>
> Charles

Bug#1042299: libfirefox-marionette-perl: FTBFS: tests fail

[gregor herrmann]

Control: block -1 with 1059343 

On Fri, 22 Dec 2023 20:35:57 +0100, Santiago Vila wrote:

> Hi. I found this bug while rebuilding all packages in bookworm:
> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/libfirefox-marionette-perl.html
> I'm fixing the metadata since it's a FTBFS bug.
> Would be possible to fix it in bookworm, please?

Thanks for the heads-up.

I've uploaded a fixed package to bookworm and raised a pu bug against
release.debian.org.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1059343: bookworm-pu: package libfirefox-marionette-perl/1.35-1+deb12u1

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libfirefox-marionette-p...@packages.debian.org
Control: affects -1 + src:libfirefox-marionette-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libfirefox-marionette-perl/1.35-1+deb12u1 to bookworm.

Compared to 1.35-1 it contains one small patch, taken from an
upstream commit which is in the 1.36 release, which adjusts the
Firefox Capabilities handling to Firefox 112+.

This upload fixes the FTBFS bug #1042299.

Upstream bug report: https://github.com/david-dick/firefox-marionette/issues/21
Related firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1819029
Upstream commit (= patch): 
https://github.com/david-dick/firefox-marionette/commit/1e8785004852e561c8b7a98701bc82fb7a537ffd

Full debdiff attached.


Thanks in advance,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWGF1VfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb3DhAAw0+ye42GcRoBBymTiCrJR6TzCxT1SI0gwBnC6bTczNkv5yg8sEYAlXMe
NpG4RRNG77x6oqBB95yXt/USUCMZdgjlpJcgqZrK3NiZ3QLuMC+erghsToWSCL6S
WqRy4DHJPx4xsOenGsyVIgMqQzxtlkg1wsr93vjI5ToL1fAppki3QZuN/ovXl7wU
p6yb/aoTXaW1jn7ZN7FbLBe6KNC1Vl6NX5JNuCR0iihBxXZDQTLoZDle60s/7Hjc
TZpuSK7KTwhW2f3Rg8kYvuuA4VlX8x2uVuGb4q7ptvUTHWlSdKjRcPeMKLOcb9NQ
h3YFhhSxS1Cofn0sX8Rz67yfnYkVnY+QEJZESueEIyhgp0NDpWMoiVqSeiOWyjXy
kBYIIupb6eaPKSVnCd0Cbqbf9IuTeotP6YukS9xIdAZRwaPu4dEYIVH52i+U4oXT
ZoX/Pe6GruG+4UFrP/Elo5VSSxuHFhM3Z8tfa2OMGUd47KfehbZFbikAH+2uX1/v
9n5liqIMwTJl3rJBfSMYPKSZFukICnvFiqwIP44uTG6WYgHaQwUUcLmzMQyPXTFO
8zZSU5EFqG8jEjp9j/z6IxzVI5VtRI+cU7UIc0ZHkcMtsdVBVkIXel60lfetynsg
2XxuUt5g+10f1KJAmGWIOgixc/8JMPz88XpLhI1OpycG5NpL1cg=
=bm57
-END PGP SIGNATURE-
diff -Nru libfirefox-marionette-perl-1.35/debian/changelog 
libfirefox-marionette-perl-1.35/debian/changelog
--- libfirefox-marionette-perl-1.35/debian/changelog2023-01-30 
20:40:55.0 +0100
+++ libfirefox-marionette-perl-1.35/debian/changelog2023-12-22 
23:49:39.0 +0100
@@ -1,3 +1,12 @@
+libfirefox-marionette-perl (1.35-1+deb12u1) bookworm; urgency=medium
+
+  * Add patch 0001-Fixes-to-capabilities-for-Firefox-112.-Looks-
+related.patch: "Fixes to capabilities for Firefox 112."
+(This is upstream commit 1e87850, included in the 1.36 release.)
+Closes: #1042299
+
+ -- gregor herrmann   Fri, 22 Dec 2023 23:49:39 +0100
+
 libfirefox-marionette-perl (1.35-1) unstable; urgency=medium
 
   * Import upstream version 1.35.
diff -Nru 
libfirefox-marionette-perl-1.35/debian/patches/0001-Fixes-to-capabilities-for-Firefox-112.-Looks-related.patch
 
libfirefox-marionette-perl-1.35/debian/patches/0001-Fixes-to-capabilities-for-Firefox-112.-Looks-related.patch
--- 
libfirefox-marionette-perl-1.35/debian/patches/0001-Fixes-to-capabilities-for-Firefox-112.-Looks-related.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libfirefox-marionette-perl-1.35/debian/patches/0001-Fixes-to-capabilities-for-Firefox-112.-Looks-related.patch
  2023-12-22 23:49:39.0 +0100
@@ -0,0 +1,39 @@
+From 1e8785004852e561c8b7a98701bc82fb7a537ffd Mon Sep 17 00:00:00 2001
+From: David Dick 
+Date: Sat, 29 Apr 2023 13:37:28 +1000
+Subject: [PATCH] Fixes to capabilities for Firefox 112.  Looks related to
+ https://bugzilla.mozilla.org/show_bug.cgi?id=1819029. Thanks to toreau for
+ the bug report in GH#21
+
+Bugs-Debian: https://bugs.debian.org/1042299
+
+---
+ lib/Firefox/Marionette.pm | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/lib/Firefox/Marionette.pm b/lib/Firefox/Marionette.pm
+index 2d10d85..6b8440b 100644
+--- a/lib/Firefox/Marionette.pm
 b/lib/Firefox/Marionette.pm
+@@ -7670,8 +7670,16 @@ sub capabilities {
+ );
+ my $response = $self->_get_response($message_id);
+ if ( $self->marionette_protocol() == _MARIONETTE_PROTOCOL_VERSION_3() ) {
+-return $self->_create_capabilities(
+-$response->result()->{capabilities} );
++if (   ( $response->result()->{value} )
++&& ( $response->result()->{value}->{capabilities} ) )
++{
++return $self->_create_capabilities(
++$response->result()->{value}->{capabilities} );
++}
++else {
++return $self->_create_capabilities(
++$response->result()->{capabilities} );
++}
+ }
+ else {
+ return $self->_create_capabilities( $response->result()->{value} );
+-- 
+2.43.0
+
diff -Nru libfirefox-marionette-perl-1.35/debian/patches/series 
libfirefox-marionette-perl-1.35/debian/patches/series
--- libfirefox-marionette-perl-1.35/debian/patches/series   2023-01-30 
20:40:55.0 +0100
+++ libfirefox-marionette-perl-1.35/debian/patches/series   2023-12-22 
23:49:39.0 +0100
@@ -1 +1,2 @@
 no-network.patch

Bug#1058701: pm-utils: unauthorised and uncommunicated removal

[Ian Jackson]

Thorsten Alteholz writes ("Re: pm-utils: unauthorised and uncommunicated 
removal"):
> On Thu, 21 Dec 2023, Ian Jackson wrote:
> > I intend to re-upload the last version shortly (and reopen all the
> > bug reports).
> 
> Yes, please do so.

Thanks.  This has now been done.

I chose to *not* fix anything about the package now (not even the
wrong VCS fields, for example) in order to simplify review.

The diff against the version previously in sid, and currently in
testing, is attached.

Regards,
Ian.

diff --git a/debian/changelog b/debian/changelog
index 9dd8325..7469392 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pm-utils (1.4.1-20) unstable; urgency=medium
+
+  * No-change upload to reintroduce to sid following erroneous
+removal (#1058701).
+
+ -- Ian Jackson   Fri, 22 Dec 2023 22:26:26 
+
+
 pm-utils (1.4.1-19) unstable; urgency=medium
 
   * No-change upload to make myself the maintainer.  I intend to perhaps

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1059266: error: cannot verify inline signature

[Guillem Jover]

Hi!

On Fri, 2023-12-22 at 19:37:16 +0100, Aurelien Jarno wrote:
> On 2023-12-22 19:23, Aurelien Jarno wrote:
> > This also causes issues on the riscv64 build daemons running sid:
> > 
> > | dupload exit status 9/0
> > | Removed  to reupload later.
> > | 
> > | Complete output from dupload:
> > | 
> > | dupload note: no announcement will be sent.
> > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 
> > 22 18:06:16 2023 UTC
> > | gpgv:using RSA key 
> > 670D3AC041E218107D0DE6F9339F749981589F2F
> > | gpgv: Can't check signature: No public key
> > | openpgp-check: error: cannot verify inline signature for 
> > emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature 
> > found
> > | 
> > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed 
> > for emmax_0~beta.20100307-4_riscv64-buildd.changes

Ouch, ok.

> > On 2023-12-22 12:16, Guillem Jover wrote:
> > > Just to understand what is going wrong, I assume you don't have the
> > > debian-keyring package installed (where the signing certificate could
> > > be found in the debian-keyring.gpg keyring), nor the certificate for
> > > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?
> > 
> > For debian build daemons, it is not expected to have the keys in the
> > debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
> > exist.
> > 
> > > But gpg has it in its certificate store?
> > 
> > Yes:
> > 
> > buildd@rv-manda-01:~/.gnupg$ gpg -K
> > /home/buildd/.gnupg/pubring.kbx
> > ---
> > sec   rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
> >   670D3AC041E218107D0DE6F9339F749981589F2F
> > uid  [  ultime ] buildd autosigning key rv-manda-01 
> > 
> 
> It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg,
> not from ~/.gnupg/trustedkeys.gpg.

The trustedkeys.gpg is a keyring used mainly by gpgv (gpg does not use
it by default, except that the dpkg code will feed it as an additional
keyring if it is found.

I'll prepare an upload right away and force the code to use gpg for
now (as it was used before the recent upload, instead of trying gpgv,
sqop, pgpainless-cli, or sq), until I've devised a better migration
plan, or implemented enough configuration options for people to switch
or use other OpenPGP backends when desired.

Thanks,
Guillem

Bug#1059342: live-build: Can we please install net-tools?

[Dima Kogan]

Package: live-build
Severity: normal
Hi. This is a feature request. Can we please include net-tools in the
set of packages we ship with debian-live? It is small, and would make
many people's lives easier. I personally use this as a rescue disk, and
configuring the network is a common need for such an application. And
like many, I prefer the older net-tools tools.

Thanks.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (500, 'unstable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel

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

Bug#1059341: gir1.2-cscreensaver-1.0: contains 900K of GIR XML which shouldn't usually be necessary on end user systems

[Simon McVittie]

Package: gir1.2-cscreensaver-1.0
Version: 5.8.1-2
Severity: normal
X-Debbugs-Cc: gobject-introspect...@packages.debian.org

In addition to the binary typelib (about 50K), gir1.2-cscreensaver-1.0
contains GIR XML (about 900K). This is not right for the conventional
way to package GObject-Introspection modules, and is probably a waste of
space on end-user systems.

Typelib files are normally used by bindings for dynamic languages like
Python (PyGI), JavaScript (gjs, cjs, seed) or Perl
(Glib::Object::Introspection), as an equivalent of a C/C++ shared library.
If I understand correctly, cinnamon-screensaver is mostly written in Python,
and uses C code from libcscreensaver0 via gir1.2-cscreensaver-1.0 and PyGI.

GIR XML is normally used by bindings for static languages like C++, Rust
or Haskell, and are closer to an equivalent of C/C++ header files. They
contain a superset of the information in the equivalent typelib file,
in a less efficient but easier-to-parse encoding. I suspect that
cinnamon-screensaver doesn't actually need this.

On #1057391, Fabio Fantoni wrote:
> user testing cinnamon 6 on sid spotted -dev package in
> gir1.2-cscreensaver-1.0 actually not present, so I suppose added from recent
> dh_girepository changes. upstream have all in libcscreensaver0, so I created
> at least gir1.2-cscreensaver-1.0 in 5.4.1-2 to solve the policy issue (I not
> tried to do a PR for upstream now) but I put also gir file in it instead
> create -dev package for only it. I must create gir1.2-cscreensaver-1.0-dev
> with gir and all needed -dev deps or is possible remove the -dev deps?

If I'm understanding the question correctly, the right answer depends
on whether this is a public or private library.

I see that the way src:cinnamon-screensaver packages its shared library
libcscreensaver0 seems to be a mixture of public and private library,
which might indicate some confusion about its role. Is this library
private to src:cinnamon-screensaver and not intended to be used by other
packages? Or is it a public library that can be used by third-party
software, like GTK or libsoup? Or is there some more complicated situation?

If it's a private library
=

One option is to say that it's a private library, like the libgc.so
that is part of src:gnome-characters.

If it's this, then:

- the shared library should be in a non-default library path, like maybe
  /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
  (gnome-characters uses /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/)
  and the main executable should use the LD_LIBRARY_PATH environment
  variable, a DT_RUNPATH ELF header (gcc -Wl,-rpath), or
  g_irepository_prepend_library_path() to load it

- the typelib should also be in a non-default location, like maybe
  /usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-screensaver/
  (gnome-characters uses
  /usr/lib/${DEB_HOST_MULTIARCH}/org.gnome.Characters/girepository-1.0/),
  and the main executable should use the GI_TYPELIB_PATH environment
  variable or g_irepository_prepend_search_path() to load it

- it's correct for the C/C++ header files not to be installed

- the GIR XML should either not be installed, or be installed in a
  non-default location, like maybe /usr/share/cinnamon-screensaver/

- everything can be in one large binary package

- it's probably unnecessary to run dh_girepository, because everything
  is in one large binary package anyway - although you will want to depend
  on gir1.2-gtk-3.0, either via dh_girepository or directly

src:gnome-characters seems to be a good example of this setup.

If it's a public library


Another option is to say that it's a public library, like the libcheese.so.*
and libcheese-gtk.so.* that are part of src:cheese.

If it's this, then:

- the shared library should continue to be in
  /usr/lib/${DEB_HOST_MULTIARCH}/ in a libcscreensaver0 binary package

- the typelib should continue to be in
  /usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0/ in a
  gir1.2-cscreensaver-1.0 binary package

- the C/C++ header files should be installed in a new -dev package,
  probably libcscreensaver-dev, so that other C/C++ code can link to the
  library

- the GIR XML should continue to be in /usr/share/gir-1.0/ but should be
  moved into the new -dev package, which should have Depends: ${gir:Depends}
  and Provides: ${gir:Provides}

- multiple, separate binary packages will be needed

- dh_girepository should be used

src:flatpak is a good example of this setup.

If it's something more complicated
==

If there's some more complicated situation, like the forks of Clutter and
Cogl in src:mutter and src:muffin, then please explain, and I or other
members of the GNOME team can try to come up with a recommendation.

Thanks,
smcv

Bug#1058701: pm-utils: unauthorised and uncommunicated removal

[gregor herrmann]

On Thu, 21 Dec 2023 21:57:33 -0500, Paul R. Tagliamonte wrote:

Thanks for your thoughtful response. And I share your conclusion:

> This specific situation seems unfortunate. I have every confidence the
> maintainers involved will collaborate in a good faith effort to move
> the distro forward.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1057391: cinnamon and private GIR XML

[Simon McVittie]

Here is an attempt at a more comprehensive answer to your questions about
correct handling of Cinnamon's private typelibs and private GIR XML.

The first thing I should say is that the GObject-Introspection mini-policy
(file:///usr/share/doc/gobject-introspection/policy.txt.gz) was written for
the common case of public libraries, typelibs and GIR XML, for example GTK
or libsoup:

- libraries in /usr/lib/MULTIARCH/
- typelibs in /usr/lib/MULTIARCH/girepository-1.0
- GIR XML in /usr/share/gir-1.0 or /usr/lib/MULTIARCH/gir-1.0

Tools like dh_girepository and Lintian are also set up for that common
case, and it's entirely possible that they are not always doing the right
thing for private libraries, typelibs and GIR XML. Not many packages use
private typelibs or GIR XML, and it's probably mostly only GNOME and
Cinnamon that do this, so it's up to the GNOME and Cinnamon maintainers to
figure out how private libraries with typelibs and GIR XML ought to work.

I am not a Cinnamon user or developer, but if I understand the Cinnamon
packages directly, src:cinnamon contains private libraries, typelibs and
GIR XML, similar to src:gnome-shell.

When installing private libraries that are only intended to be used
within a group of closely cooperating packages, you don't necessarily
have to follow all of the same policies that you would need to follow
for a public library like GTK or libsoup, as long as the setup that
ends up in the packages you have built still works correctly within your
closed ecosystem.

For instance, in GNOME we have some private libraries built by src:mutter
and src:gnome-shell, which are used by GNOME Shell, Budgie and GNOME
Shell extensions, but should not be accessed by anything outside that
ecosystem. If I understand correctly, Cinnamon has muffin (a fork of
mutter) and cinnamon itself (a fork of gnome-shell) which have a similar
relationship; but perhaps the Cinnamon ecosystem is even simpler than
GNOME's, because GNOME has extensions and I don't think Cinnamon does?

I think libmuffin-dev also probably should not be installing its GIR
XML into /usr/share/gir-1.0, because most (all?) of muffin's GIR XML
consists of forks of other projects (Clutter, Cogl, Metacity) and it
seems confusing to have GIR XML in the public search path that is named
something like "Clutter" but is actually a private fork of a better-known
library. src:mutter puts its GIR XML in /usr/lib/MULTIARCH/mutter-12,
which is the same directory as the private typelibs and the private
shared libraries. I think it would make sense for muffin to do the
equivalent, by putting its GIR XML into /usr/lib/MULTIARCH/muffin.

On Sat, 09 Dec 2023 at 21:12:03 +0100, Fabio Fantoni wrote:
> Thanks for all informations, I did some changes in git, moved gir files in
> /usr/share/cinnamon

I see that you are also now running dh_girepository as:

dh_girepository ... /usr/share/cinnamon

Was that so that when dh_girepository looks at
/usr/lib/MULTIARCH/cinnamon/{St-1.0,Cinnamon-0.1}.typelib, it will be able
to find their corresponding GIR XML in
/usr/share/cinnamon/{St-1.0,Cinnamon-0.1}.gir?

Or is there some other reason that you needed to tell dh_girepository about
this private directory?

src:gnome-shell doesn't actually run dh_girepository at all (although
src:mutter does). I'm not sure whether src:gnome-shell or src:cinnamon
is the one that is being more correct here. Ideally dh_girepository would
"do the right thing" for both public and private libraries, but it isn't
100% clear to me what the right thing *is* in this case.

> the package for the split should be cinnamon-dev, with only gir I thinked
> gir1.2-cinnamon-0.1-dev, what is correct and/or best?

Let me go back a few steps from there:

- Is there anything else in Debian that is going to use this GIR XML
  programmatically?

- If something else in Debian wanted to load libcinnamon.so or libst.so,
  are there C/C++ headers that it would be able to use to access those
  libraries? GIR XML is analogous to C/C++ headers, so if these libraries
  are "private enough" that you wouldn't want third-party code to be able
  to #include their headers, you probably also don't want third-party code
  to be loading their interface descriptions from GIR XML either?

- Do you *want* a separate -dev package? Or are you just suggesting this
  because dh_girepository suggests a dependency cinnamon -> libmuffin-dev,
  which you actively don't want?

- Is there anything else installed by src:cinnamon that conceptually
  "belongs" in a -dev package, and is not needed by end users? Like for
  example C/C++ header files that I've missed, or perhaps developer-only
  tools?

It isn't completely obvious to me why either GNOME Shell or Cinnamon
installs its GIR XML at all - I can't immediately think of any situation
where it would be useful, except perhaps to a GNOME Shell or Cinnamon
developer who is already building the relevant project from source and
could equally well just look at the .gir file in 

Bug#1058768: [Debian-med-packaging] Bug#1058768: cyvcf2: ftbfs and autopkgtest regression with htslib 1.19

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2023-12-21:
> I have *not* tested cyvcf2 with htslib 1.19 from experimental thus not
> closing this bug.  However it builds nicely with htslib 1.18 now and
> thus I uploaded to close cython3-legacy related bug #1056799.

You did good not closing, I quickly checked the new upstream
version but it still failed to build with the newer htslib 1.19
on my end.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1059340: libstdc++6:riscv64: stream output for NaN is optimization-dependent

[Benjamin Barenblat]

Control: user debian-ri...@lists.debian.org
Control: usertag 1059340 + riscv64

Just to be clear, I've only observed this behavior on riscv64.

Bug#1059340: libstdc++6:riscv64: stream output for NaN is optimization-dependent

[Benjamin Barenblat]

Package: libstdc++6
Version: 13.2.0-9

Streaming a negative NaN float produces "-nan" with g++ -O0 and "nan"
with g++ -O1 or above:

$ cat >mwe.cc < // Copyright 2023 Google LLC
> // SPDX-License-Identifier: Apache-2.0
> 
> #include 
> #include 
> 
> int main() { std::cerr << std::bit_cast(0xfff8) << '\n'; }
> EOF
$ g++ -std=c++20 -O0 mwe.cc && ./a.out
nan
$ g++ -std=c++20 -O1 mwe.cc && ./a.out
-nan
$ clang++ -std=c++20 -O0 mwe.cc && ./a.out
nan
$ clang++ -std=c++20 -O1 mwe.cc && ./a.out
-nan

For comparison, on amd64, this program always produces "-nan",
regardless of optimization level.

Tested with g++-13 13.2.0-9 and clang-16 1:16.0.6-19.

Bug#1059339: nv-codec-headers: Version mismatch with nvidia-driver package

[Tim H.]

Source: nv-codec-headers
Version: 12.1.14.0-1
Severity: important

Dear Maintainer,

After I updated FFmpeg to version 7:6.1-5 hardware accelerated encoding
via h264_nvenc stopped working.

FFmpeg reports:
Driver does not support the required nvenc API version. Required: 12.1
Found: 12.0

[1] states that the minimum required nvidia driver version to support
nvenc 12.1 is 530.41.03 or higher. Yet the most recent version
available in trixie is currently 525.147.05-1.

I managed to compile FFmpeg against an older version (12.0.16.1) of the
headers which fixed the bug for me. Please note that my graphics card
is quite old (NVIDIA Corporation GM206 [GeForce GTX 960]), so I'm not
sure if this bug affects people with more up to date cards.

~ Tim

[1]: 
https://docs.nvidia.com/video-technologies/video-codec-sdk/12.1/read-me/index.html


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

Kernel: Linux 6.1.68-1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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: sysvinit (via /sbin/init)

Bug#1059338: Update database config for 15.9 -> 16.0 upgrade (current config is deprecated)

[Pirate Praveen]

Package: gitlab
Version: 16.4.4+ds1-1
severity: important

Currently gitlab shows a warning during installation

  ██ ██  █  ██  ███    ██ ██ ███    ██  ██ 
  ██ ██ ██   ██ ██   ██    ██ ██    ██ ██  
  ██  █  ██ ███ ██  ██ ██  ██ ██ ██ ██  ██ ██   ███ 
  ██ ███ ██ ██   ██ ██   ██ ██  ██ ██ ██ ██  ██ ██ ██    ██ 
   ███ ███  ██   ██ ██   ██ ██    ██ ██     ██  

**
  Your database has a single connection, and single connections were
  deprecated in GitLab 15.9 
https://docs.gitlab.com/ee/update/deprecations.html#single-dat

abase-connection-is-deprecated.

  Please add a :ci section to your database, following these instructions:

https://docs.gitlab.com/ee/install/installation.html#configure-gitlab-db-settings.
**

We should follow the instructions to update the configuration.

Bug#999975: rdup: depends on obsolete pcre3 library

[Yavor Doganov]

Control: tags -1 + patch

Please find attached a patch -- build-tested after adding -Wno-error
to CFLAGS due to #941101.
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/75
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2023-12-22
---

--- rdup-1.1.15.orig/configure.ac
+++ rdup-1.1.15/configure.ac
@@ -62,26 +62,28 @@
 if test "$with_libpcre_includes" != "no"; then
CFLAGS="${CFLAGS} -I${with_libpcre_includes}"
 else
-   CFLAGS="${CFLAGS} `pcre-config --cflags`"
+   CFLAGS="${CFLAGS} `pcre2-config --cflags`"
 fi
 
 if test "$with_libpcre_libraries" != "no"; then
LIBS="${LIBS} -L${with_libpcre_libraries}"
 else
-   LIBS="${LIBS} `pcre-config --libs`"
+   LIBS="${LIBS} `pcre2-config --libs8`"
 fi
 
 # PCRE configuration (required)
 # Verify that we have the headers
 PCRE_H=""
-AC_CHECK_HEADERS(pcre.h,, PCRE_H="no")
+AC_CHECK_HEADERS([pcre2.h], [], [PCRE_H="no"], [[
+#define PCRE2_CODE_UNIT_WIDTH 8
+]])
 if test "$PCRE_H" = "no"; then
AC_MSG_ERROR([** No pcre library found.])
 fi
 
 # Verify that we have the library
 PCRE_L=""
-AC_CHECK_LIB(pcre, pcre_compile, ,PCRE_L="no")
+AC_CHECK_LIB([pcre2-8], [pcre2_compile_8], [], [PCRE_L="no"])
 if test "$PCRE_L" = "no"; then
AC_MSG_ERROR([** No pcre library found.])
 fi
--- rdup-1.1.15.orig/gfunc.c
+++ rdup-1.1.15/gfunc.c
@@ -7,7 +7,8 @@
 
 #include "rdup.h"
 #include "protocol.h"
-#include 
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include 
 #ifdef HAVE_LIBNETTLE
 #include 
 #else
@@ -622,20 +623,26 @@
 gboolean gfunc_regexp(GSList * l, char *n, size_t len)
 {
GSList *k;
-   pcre *P;
-   int ovector[REG_VECTOR];
+   pcre2_code *P;
+   pcre2_match_data *md;
 
+   md = pcre2_match_data_create(REG_VECTOR, NULL);
for (k = g_slist_nth(l, 0); k; k = k->next) {
-   if (sig != 0)
+   if (sig != 0) {
+   pcre2_match_data_free(md);
signal_abort(sig);
+   }
 
-   P = (pcre *) k->data;
+   P = (pcre2_code *) k->data;
/* pcre_exec errors are all < 0, so >= 0 is some kind
 * of success
 */
-   if (pcre_exec(P, NULL, n, len, 0, 0, ovector, REG_VECTOR) >= 0)
+   if (pcre2_match(P, (PCRE2_SPTR)n, len, 0, 0, md, NULL) >= 0) {
+   pcre2_match_data_free(md);
return TRUE;
+   }
}
+   pcre2_match_data_free(md);
return FALSE;
 }
 
--- rdup-1.1.15.orig/regexp.c
+++ rdup-1.1.15/regexp.c
@@ -6,7 +6,8 @@
  */
 
 #include "rdup.h"
-#include 
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include 
 
 GSList *pregex_list = NULL;
 
@@ -18,15 +19,16 @@
 {
FILE *fp;
char *buf;
-   const char *errbuf;
-   int erroff;
+   PCRE2_UCHAR errbuf[120];
+   PCRE2_SIZE erroff;
+   int err;
char delim;
gpointer d;
size_t l;
size_t s;
size_t re_length;
ssize_t j;
-   pcre *P;
+   pcre2_code *P;
 
if ((fp = fopen(file, "r")) == NULL) {
msg(_("Could not open '%s\': %s"), file, strerror(errno));
@@ -45,18 +47,20 @@
/* buf[j - 1] holds the delimeter */
buf[j - 1] = '\0';
 
-   if ((P = pcre_compile(buf, 0, , , NULL)) == NULL) 
{
+   if ((P = pcre2_compile((PCRE2_SPTR)buf, strlen(buf), 0, , 
, NULL)) == NULL) {
/* error */
fclose(fp);
+   pcre2_get_error_message(err, errbuf, sizeof(errbuf));
msg(_
-   ("Corrupt regular expression line: %zd, column %d: 
%s"),
+   ("Corrupt regular expression line: %zd, column %zu: 
%s"),
l, erroff, errbuf);
g_free(buf);
return FALSE;
} else {
-   pcre_fullinfo(P, NULL, PCRE_INFO_SIZE, _length);
+   pcre2_pattern_info(P, PCRE2_INFO_SIZE, _length);
d = g_malloc(re_length);
d = memcpy(d, P, re_length);
+   pcre2_code_free(P);
pregex_list = g_slist_append(pregex_list, d);
}
l++;

Bug#958682: node-jsonld: Remove dependency to node-request

[Pirate Praveen]

On Sun, 29 Oct 2023 21:37:08 +0100 Jonas Smedegaard  wrote:

Yes, I still want to work on node-jsonld - I will make time to look at
this soon...


yarnpkg 4.0.2 was recently uploaded to unstable, so this and 
node-matrix-js-sdk are the only remaining reverse dependencies for 
node-request. We have an ack from its maintainer to remove it 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958692#42 so this is 
the only real blocker remaining to remove node-request.

Bug#1056792: bitshuffle: ftbfs with cython 3.0.x

[PICCA Frederic-Emmanuel]

It seems to me that the FTBFS was not due to cython 3.x but related to this bug

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

now that this bug is solved, can you re run the build for bitshuffle ?

Frederic

Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[Julian Andres Klode]

On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: si...@josefsson.org
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: apt-verify
>   Version : 2.0
>   Upstream Contact: Simon Josefsson 
> * URL : https://gitlab.com/debdistutils/apt-verify
> * License : AGPLv3+
>   Programming Lang: Shell script
>   Description : extend apt's gpgv-based verification mechanism
> 
> Apt-verify extends apt to call all tools in /etc/verify.d/ instead of
> always only calling gpgv, to verify apt archive integrity and
> authenticity.  A symbolic link in /etc/verify.d/gpgv is installed by
> default to provide full backwards compatibility.


David already said a lot of good things but let me extend on that:

- apt-key use is slated for removal no later than Feb 29th.
- apt signature verification should not involve shell scripts
  (hence the removal in the first place)
- apt-verify looks like it's an apt tool and is easy to confuse
  with apt-sign, apt's openpgp replacement, and what will likely
  be the name of the method verifying apt-ed25519 signatures,
  'verify'

In closing let me say I consider overriding APT's signature verification
to be RC-buggy and would immediately file an RC bug should that package
be accepted.

-- The road forward, signature verification and sandboxing concerns

I do not think we currently have a way to move forward with signature
verification hooks due to issues with the download sandbox. If we want
to come up with solutions to plug in additional verification steps, we
first need to

1) finish the sandboxing to move verification of files outside the
   sandbox, or writes from the download and decompressor steps into
   a deeper sandbox

   Essentially my consideration is to replace the entire acquire stack
   with a new event-based stack that's easier to reason about because at
   this point the interactions between the classes we have are
   unreasonable and not understandable.

2) figure out how we can integrate additional verification steps
   with well known security properties that ensure reliability of
   the sandbox. We don't just want to run arbitrary hooks in the
   sandbox (or as root really).

3) figure out a protocol for this. My goal is to adopt varlink in
   APT for IPC to provide a daemon for APT as well as to replace
   custom IPC protocols we currently have like the various classic
   hooks, the JSON hooks, and the acquire protocol.

   Then it would be nice to be able to say "hook in after
   'org.debian.apt.verify' and do additional things".

This will probably take until 2030 or so if I'm the only one working on
it but that's the position that we should aim for rather than blindly
hooking in things where they're not expected or creating hooks that we
don't know how they will work in the final design.

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

Bug#1042299: libfirefox-marionette-perl: FTBFS: tests fail

[Santiago Vila]

tags 1042299 - trixie sid
tags 1042299 + bookworm
thanks

Hi. I found this bug while rebuilding all packages in bookworm:

https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/libfirefox-marionette-perl.html

I'm fixing the metadata since it's a FTBFS bug.
Would be possible to fix it in bookworm, please?

Thanks.

Bug#1059061: libssh: CVE-2023-6004

[Salvatore Bonaccorso]

Hi Martin,

On Fri, Dec 22, 2023 at 04:39:46PM +0100, Martin Pitt wrote:
> Hello Salvatore,
> 
> Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > > However, the fix for CVE-2023-6004 caused a regression:
> > > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > > I will monitor this, and include the fix in the security upload once it is
> > > available (or presumably they'll do a 0.10.7). So if it's alright with 
> > > you,
> > > I'll delay the stable-security update for a few days.
> >
> > Rigth, it's not that pressing that we get updates out, so let's
> > monitor this, have 0.10.7 uploaded and exposed as well then to
> > unstable for a while and then look at bookworm-security. Btw, we will
> > as well need bullseye-security.
> 
> Ack. The fix landed upstream, and they said they won't do a 0.10.7 
> immediately,
> so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole cockpit
> integration test suite at it (which exercises libssh pretty thoroughly via
> cockpit-ssh), and it is happy.
> 
> I'll let that simmer for a few days to let it go into testing, and prepare the
> security updates soon.

Thanks, that sounds good.

Regards,
Salvatore

Bug#1056671: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056671: fixed in emmax 0~beta.20100307-4)

[Andreas Tille]

Hi Sébastien,

Am Fri, Dec 22, 2023 at 07:01:49PM +0100 schrieb Sébastien Villemot:
> Unfortunately the updated package won’t build on some architectures
> (notably armel), because you put libopenblas-dev as a first alternative
> in Build-Depends, and libopenblas-dev is not available on all archs.
> One should put libblas-dev as the first alternative.

Thanks a lot for the initial patch and this hint which I just uploaded.

Kind regards 
   Andreas.

-- 
http://fam-tille.de

Bug#1053334: galera-4: FTBFS because of expired certificates

[Santiago Vila]

retitle 1053334 galera-4: FTBFS in bookworm because of expired SSL certificates
found 1053334 26.4.13-1
severity 1053334 serious
tags 1053334 bookworm
thanks

Hello.

I found about this bug during a rebuild of all packages in bookworm.

Could you please fix this in bookworm as well?
Packages in stable must build in stable.

(I would be willing to help if required).

Thanks.

Bug#1059337: RM: node-request-capture-har -- ROM; wrapper around deprecated node-request

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: node-request-capture-...@packages.debian.org
Control: affects -1 + src:node-request-capture-har
Control: block 1002901 by -1

Affected by rc bug #1002901 (yarnpkg no longer depend on this library 
from version 4.0.2 in unstable).

Bug#1058863: libqwt-qt5-dev: invalid conversion from ‘int’ to ‘QwtPlotLayout::Option’

[Gudjon I. Gudjonsson]

Hi Yadd

I could not find ovito in Debian. Are you packaging it?
If so, can you please provide me a link?

Qwt version 6.2.0 is in experimental and I would like to get it into 
unstable ASAP but it will unfortunately take some time.

Regards
Gudjon

Bug#1059336: ITP: node-html5-qrcode -- qr-code and bar-code scanning library for the web

[Georges Khaznadar]

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

* Package name: node-html5-qrcode
  Version : 2.3.8
  Upstream Contact: https://github.com/mebjas/html5-qrcode/issues
* URL : https://github.com/mebjas/html5-qrcode
* License : Apache-2.0, GPL2
  Programming Lang: nodejs, typescript
  Description : qr-code and bar-code scanning library for the web

 Use this lightweight library to easily / quickly integrate QR code,
 bar code, and other common code scanning capabilities to your web
 application.

So far, debian is missing a package to scan qrcodes and barcodes from
a web page. I intend to maintain this package as a dependency for a
future package SLM, school library management, which I am developping
actively. This latter package allows students to find and recognize
books inside a library by scanning a few qr-codes.

The package node-html5-qrcode is uploaded to
https://salsa.debian.org/georgesk/node-html5-qrcode.git

Bug#1059286: cacti: CVE-2023-46490

[Paul Gevers]

Hi,

On 22-12-2023 13:17, Moritz Mühlenhoff wrote:

There's also a reference for
https://github.com/Cacti/cacti/security/advisories/GHSA-f4r3-53jr-654c
but it's noin-public for two months now, might be worth checking with
upstream for the status.


Upstream confirmed they are working on an official release.

They referred me to these (haven't checked myself, just forwarding for 
info):


https://github.com/Cacti/cacti/commit/58a980f335980ab57659420053d89d4e721ae3fc
https://github.com/Cacti/cacti/commit/73d9a60e24d6d826e6343b94d833b48c28b68643

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059266: error: cannot verify inline signature

[Aurelien Jarno]

On 2023-12-22 19:23, Aurelien Jarno wrote:
> control: reopen -1
> 
> Hi,
> 
> On 2023-12-22 12:16, Guillem Jover wrote:
> > Hi!
> > 
> > On Fri, 2023-12-22 at 10:53:18 +0100, Christian Marillat wrote:
> > > Package: dupload
> > > Version: 2.10.4
> > > Severity: grave
> > 
> > > This version fail to check a signature. Work fine with 2.10.3
> > > 
> > > ,
> > > | $ debrelease 
> > > | dupload note: no announcement will be sent.
> > > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri 
> > > Dec 22 10:50:05 2023 CET
> > > | gpgv:using RSA key 
> > > A401FF99368FA1F98152DE755C808C2B65558117
> > > | gpgv:issuer "maril...@deb-multimedia.org"
> > > | gpgv: Can't check signature: No public key
> > > | openpgp-check: error: cannot verify inline signature for 
> > > ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found
> > > | 
> > > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed 
> > > for ../gerbera-dmo_1.12.1-dmo5_amd64.changes
> > > `
> 
> This also causes issues on the riscv64 build daemons running sid:
> 
> | dupload exit status 9/0
> | Removed  to reupload later.
> | 
> | Complete output from dupload:
> | 
> | dupload note: no announcement will be sent.
> | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 
> 18:06:16 2023 UTC
> | gpgv:using RSA key 670D3AC041E218107D0DE6F9339F749981589F2F
> | gpgv: Can't check signature: No public key
> | openpgp-check: error: cannot verify inline signature for 
> emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature found
> | 
> | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for 
> emmax_0~beta.20100307-4_riscv64-buildd.changes
> 
> > Just to understand what is going wrong, I assume you don't have the
> > debian-keyring package installed (where the signing certificate could
> > be found in the debian-keyring.gpg keyring), nor the certificate for
> > A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?
> 
> For debian build daemons, it is not expected to have the keys in the
> debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
> exist.
> 
> > But gpg has it in its certificate store?
> 
> Yes:
> 
> buildd@rv-manda-01:~/.gnupg$ gpg -K
> /home/buildd/.gnupg/pubring.kbx
> ---
> sec   rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
>   670D3AC041E218107D0DE6F9339F749981589F2F
> uid  [  ultime ] buildd autosigning key rv-manda-01 
> 

It seems the decision to trust the key comes from ~/.gnupg/trustdb.gpg,
not from ~/.gnupg/trustedkeys.gpg.

Cheers
Aurelien

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

Bug#1059266: error: cannot verify inline signature

[Aurelien Jarno]

control: reopen -1

Hi,

On 2023-12-22 12:16, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2023-12-22 at 10:53:18 +0100, Christian Marillat wrote:
> > Package: dupload
> > Version: 2.10.4
> > Severity: grave
> 
> > This version fail to check a signature. Work fine with 2.10.3
> > 
> > ,
> > | $ debrelease 
> > | dupload note: no announcement will be sent.
> > | Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 
> > 22 10:50:05 2023 CET
> > | gpgv:using RSA key 
> > A401FF99368FA1F98152DE755C808C2B65558117
> > | gpgv:issuer "maril...@deb-multimedia.org"
> > | gpgv: Can't check signature: No public key
> > | openpgp-check: error: cannot verify inline signature for 
> > ../gerbera-dmo_1.12.1-dmo5_amd64.changes: no acceptable signature found
> > | 
> > | dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed 
> > for ../gerbera-dmo_1.12.1-dmo5_amd64.changes
> > `

This also causes issues on the riscv64 build daemons running sid:

| dupload exit status 9/0
| Removed  to reupload later.
| 
| Complete output from dupload:
| 
| dupload note: no announcement will be sent.
| Checking OpenPGP signatures before upload...gpgv: Signature made Fri Dec 22 
18:06:16 2023 UTC
| gpgv:using RSA key 670D3AC041E218107D0DE6F9339F749981589F2F
| gpgv: Can't check signature: No public key
| openpgp-check: error: cannot verify inline signature for 
emmax_0~beta.20100307-4_riscv64-buildd.changes: no acceptable signature found
| 
| dupload: error: Pre-upload '/usr/share/dupload/openpgp-check %1' failed for 
emmax_0~beta.20100307-4_riscv64-buildd.changes

> Just to understand what is going wrong, I assume you don't have the
> debian-keyring package installed (where the signing certificate could
> be found in the debian-keyring.gpg keyring), nor the certificate for
> A401FF99368FA1F98152DE755C808C2B65558117 in ~/.gnupg/trustedkeys.gpg?

For debian build daemons, it is not expected to have the keys in the
debian-keyring.gpg file. The file ~/.gnupg/trustedkeys.gpg does not
exist.

> But gpg has it in its certificate store?

Yes:

buildd@rv-manda-01:~/.gnupg$ gpg -K
/home/buildd/.gnupg/pubring.kbx
---
sec   rsa4096 2023-12-08 [SC] [expire : 2024-12-07]
  670D3AC041E218107D0DE6F9339F749981589F2F
uid  [  ultime ] buildd autosigning key rv-manda-01 


Thanks
Aurelien

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

Bug#1055024: cryptsetup-initramfs changes crypttab entries order when generating initramfs

[Marc Haber]

On Sun, Oct 29, 2023 at 03:10:18PM +0100, Nicolas Melot wrote:
> This is a repost of the same bug report I submitted to Ubuntu maintainers on
> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/2031499 and that
> seems to have been left as is. I am now hitting the same issue on Debian
> Bookworm.

I have exactly the same problem with a setup where another crypt device
needs to be unlocked BEFORE the root file system because the other crypt
device holds part of the key.

And I came to the same solution independently.

Hence, this is not a totally exotic use case at least, since two users
came even to the same solution.

After taking a step back I also find the solution quite elegant: It
preserves the order of the crypt devices as given by the local admin, it
just adds the devices that the local admin didn't specify while the
system knows a device is needed. The admin has the option of taking
the complete crypttab in their own hands transparently.

Please consider implementing this.

Greetings
Marc

Bug#983291: [Pkg-fonts-devel] Bug#983291: Default font: Transition from DejaVu to Noto

[Jonas Smedegaard]

Quoting dr. ir. Tjeerd J. Pinkert (2023-12-22 17:48:09)
> Dear Fabian, List,
> 
> thanks for packaging fonts for Debian.
> 
> On Mon, 18 Sep 2023 13:28:36 +0200 Fabian Greffrath  
> wrote:
> > > If I recall it correctly, the primary suggestion in that bug report
> > > is to split fonts-noto-core into an LCG and an "other" package.
> > 
> > I have created a MR to implement this:
> > 
> > https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1
> > 
> >  - Fabian
> 
> I was also struggling with the extensive font list issue. I managed to 
> deinstall the font today to get rid of the annoyance. Of course, I am 
> now also rid of a set of type faces.
> 
> Why are there so many language specific font files in the package?

You might find upstrem answer to this question relevant.

If you reinstall fonts-noto-core and less, you can do this:

  zless /usr/share/doc/fonts-noto-core/FAQ.md.gz

...and then read the topic near the bottom by the title "Could you
provide a single font file that covers every language (or at least as
many scripts as possible)?"


 - 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#1056671: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056671: fixed in emmax 0~beta.20100307-4)

[Sébastien Villemot]

Thanks Andreas for uploading a fixed package.

Unfortunately the updated package won’t build on some architectures
(notably armel), because you put libopenblas-dev as a first alternative
in Build-Depends, and libopenblas-dev is not available on all archs.
One should put libblas-dev as the first alternative.

Best,

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



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

Bug#1030223: gobject-introspection mini-policy: separate GIR XML from -dev package to make cross-compilation possible?

[Simon McVittie]

On Wed, 01 Feb 2023 at 10:39:30 +, Simon McVittie wrote:
> I think this would require changes to dependent packages if they make
> use of the GIR XML (because build-depending on libflatpak-dev would
> no longer be enough, and it would also be necessary to build-depend on
> gir1.2-flatpak-1.0-dev  or similar). If so, this would have to
> be done on a package-by-package basis, with dependent packages changed
> before their dependency. A migration path would be to add
> Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) on libflatpak-dev.

The dh_girepository in gobject-introspection (>= 1.78.1-3~) generates a
${gir:Provides} substvar for any package that contains public GIR XML,
partially automating this. For example, libflatpak-dev_1.14.5-1+b1 has
Provides: gir1.2-flatpak-1.0-dev (= 1.14.5-1+b1).

To make this work, a sourceful change is still necessary, to add

Depends: ${gir:Depends}
Provides: ${gir:Provides}

to every package that ships GIR XML in the public directories:
/usr/share/gir-1.0/*.gir or /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0/*.gir.

We also want packages that ship public typelibs
(/usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0/*.typelib or legacy
/usr/lib/girepository-1.0/*.typelib) to have Depends: ${gir:Depends}.

We also want packages that ship public typelibs that do not match the
package's name to have Provides: ${gir:Provides}. For example,
gir1.2-flatpak-1.0 doesn't need this, because the only typelib it contains
is Flatpak-1.0.gir; but gir1.2-gtk-4.0 *does* need this, because in
addition to Gtk-4.0.typelib, it also contains Gdk-4.0.typelib and others.

The dh_girepository in gobject-introspection (>= 1.78.1-3~) also emits
warnings suggesting that (for example) src:libadwaita-1 should have a
Build-Depends on gir1.2-gtk-4.0-dev, if the Build-Depends isn't already
present and the -dev package already has the necessary Provides. This
will let us get those Build-Depends into place gradually.

It is not fully clear to me how much of this is applicable to private
typelibs or GIR XML, shipped in private locations (for example by mutter,
gnome-shell, muffin, cinnamon and cinnamon-screensaver). There is some
discussion of this on #1057391.

> A side benefit of this would be that we could separate out the GIR XML
> that is provided by src:gobject-introspection (#859013) into one or more
> similar gir1.2-*-dev packages.

I intend to do this next time gobject-introspection goes through NEW, or
as part of the first upload of GLib 2.79.x, whichever is sooner.
(GLib 2.79.x is going to take over responsibility for GLib-2.0.typelib etc.
and GLib-2.0.gir etc. from gobject-introspection.)

On Mon, 17 Apr 2023 at 21:54:23 +0200, Helmut Grohne wrote:
> Let me propose another alternative. Rather than
> have gir1.2-flatpak-1.0-dev be a real binary package, we can provide it
> as a virtual one from libflatpak-dev. The mini-policy would then have to
> be updated such that using the gir files requires depending on a
> gir*-dev package and that a dependency on the regular lib*-dev package
> is insufficient. When enabling the nogir profile, the virtual package is
> removed thus no interface is broken. This variant still breaks
> reproducibility of course.

I would prefer not to be 100% relying on this, because I'd prefer for
build-profiles to be "safe" (no functional changes to package content,
and ideally fully reproducible); but it would be a useful stopgap to
avoid having the NEW queue block forward progress.

> In your second mail, you propose storing pre-built gir files in debian/.

I think I mentioned when talking to Helmut in person that I wasn't
proposing storing pre-built GIR files, only the intermediate "dump" files
that are one of the inputs to generating a GIR file. The workflow goes
like this:

- gcc compiles C headers/source into a shared library

- g-ir-scanner produces GIR XML by:
- parsing C headers/source
- generating a temporary file with a list of GObject types learned
  from the C headers/source
- compiling a "dumper" binary linked to the shared library
- running the "dumper" binary with the list of GObject types as input
- parsing the output of the "dumper" binary, which includes things
  that in general can only be known at runtime, like all of a GObject
  type's signals, properties and ancestors

- g-ir-compiler compiles GIR XML into a binary typelib

The GIR XML is a combination of information parsed directly from the C
headers and source (I'd estimate 80%), and information from the output
of the "dumper" binary (I'd estimate 20%).

What I was proposing storing pre-built in debian/ is the input to the
"dumper" binary (list of GObject types), and the corresponding output
(each type's list of signals and so on). This is vaguely analogous
to storing a .symbols file, but not a prebuilt shared or static library.

> I dislike this proposal, because it poses continuous extra effort for
> maintainers. We already struggle with symbols files and 

Bug#1059335: librandombytes-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/librandombytes.a

[Helmut Grohne]

Package: librandombytes-dev
Version: 0~20230919-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libnacl-dev

librandombytes-dev has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/librandombytes.a is contained in the
packages
 * libnacl-dev/20110221-12 as present in bookworm
 * librandombytes-dev/0~20230919-3 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1058937: /usr-move: Do we support upgrades without apt?

[Helmut Grohne]

Hi Matthew,

On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote:
> On 21/12/2023 09:41, Helmut Grohne wrote:
> 
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?

Let me thank David for clarifying what "using apt" means in exactly the
way I intended it.

As a result, I think the only "no" reply, I've seen thus far is from
Matthew here.

> I incline towards "no"; if an upgrade has failed part-way (as does happen),
> people may then reasonably use dpkg directly to try and un-wedge the upgrade
> (e.g. to try and configure some part-installed packages, or try installing
> some already-downloaded packages).

I incline to agreeing with the scenario you depict. This can reasonably
happen. I also think that David made a good case for it being unlikely
to manage oneself into the buggy situation that way. And then the
consequence is that you lost some possibly important files. If you ended
up fiddling with dpkg in a failed upgrade, would it be too much to ask
for running dpkg --verify? In the event you see missing files, you may
reinstall affected packages and thus have cured the symptoms for your
installation.

Say we extended release-notes saying that you should dpkg --verify after
the upgrade and more so if you happened to use dpkg directly in the
process and review the output. Would that address your concern?

> It may be that the mitigations necessary are worse than the risk, but I
> think the behaviour as described in #1058937 is definitely buggy.

I hope we all agree this is buggy. That's not the question. The question
at hand is whether this is a bug worth fixing or mitigating. We face a
lot of bugs in Debian and assign different severities. Here, the
preliminary analysis assigned a rc-severity which generally means it is
worth fixing. That's the thing I'm questioning here.

Also keep in mind that probably the majority of bullseye -> bookworm
upgrades have been performed already. In all those upgrades, nobody ran
into the issue and reported it. As David pointed out, it was encountered
by actively trying to make it break. It's the silent kind of failure, so
it may just have happened without people noticing.

Maybe we can all run dpkg --verify on our installations (in particular
those upgraded to bookworm or later) and report if they show anything
suspicious. Then we can better quantify how likely these issues happen
in practice.

I note that dpkg --verify does not currently work with --path-exclude.
I'm not sure whether that's a bug. Being a user of --path-exclude, I
note that I ran dpkg --verify on 5 very different systems and didn't
spot unusual things. This is anecdotal evidence and cannot prove the
absence of problems though. I'd be very keen to see at least one user
reporting such problems in a real upgrade rather than me trying to find
problems.

Helmut

Bug#1059171: firefox-esr: Firefox freezes after upgrade from 115.5 to 115.6.0esr-1~deb12u1

[Pierre Aussaguel]

Le 20/12/2023 à 23:10, Mike Hommey a écrit :

Which process specifically is using the CPU?


The process is firefox-esr



Does it happen if you use 115.6.0esr from upstream[1]?

1.https://archive.mozilla.org/pub/firefox/releases/115.6.0esr/linux-x86_64/en-US/firefox-115.6.0esr.tar.bz2


Yes.

I also tried to downgrade to the previous version, but the problem is 
still there.
It seems that the profile has been somehow damaged during the update 
process.


I managed to use a backup to get the important files I needed and use 
them into a newly created profile.

Bug#1058701: pm-utils: unauthorised and uncommunicated removal

[Ian Jackson]

Hi.  Thanks for your nice email.

Thorsten Alteholz writes ("Re: pm-utils: unauthorised and uncommunicated 
removal"):
> this is sad. The RM bug appeared on the tracker page of the package, in 
> your packages overview, on the ftpmaster removals page (or on the bug 
> page). It was also sent to debian-bugs-dist@lists.debian.org.

Right.  But none of those places actually email the maintainer.

> Where would have been a better place to draw your attention to it?

I think ideally the process would have involved a bug against the
package.  I appreciate that that's not always convenient.

Would it be possible and sensible to improve your tooling to warn you,
or require additional configuration, when you're removing a package
from sid that is still in testing ?  I think that would be an unusual
case.  (But that's just a guess; maybe I'm wrong about how unusual it
is.)  (And apparently this is quite rare and maybe this bug isn't the
right place to discuss such an improvement.)

> Hmm, the standards version is 3.9.7, the VCS URLs point to a no longer 
> existing repository, the last upload was in 2019. This looks rather like 
> an abandoned package. But of course, your mileage may vary

Yes.  I can see how you would think that.  Updating the package to
improve the metadata etc. didn't seem a priority.

For the record, I think your action was perfectly understandable; you
normally don't need to consider whether a removal request is the
result of ill will or conflict.  And, I very much appreciate all the
hard work you do with the day to day of ftpmaster.  It is difficult
for me to express my thanks for that strongly enough.  I understand
that a person who does a lot of work will make the occasional mistake,
too.

I should probably have said all this in my last mail.

> > I intend to re-upload the last version shortly (and reopen all the
> > bug reports).
> 
> Yes, please do so.

Thanks.  That'll probably happen later today.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[David Kalnischkies]

On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote:
> * Package name: apt-verify

It is bad enough that apt-* is a free for all name grab outside of the
Debian archive, I would very much prefer if we would not encourage it
inside Debian at least…

Especially as this has zero mentions on deity@ and declares itself
a hack that you now want to ship with next stable even through it is
utterly unsupportable for Debian as at least I, as an APT developer,
am unwilling to declare the apt::key::gpgvcommand option a supported
interface & I don't see who else would step up…

I added this completely undocumented option in apt-key in 2015 in the
process of supporting gpgv2, so that our tests could be run against
gpgv, gpgv1 and gpgv2. As we no longer have such a need, that option
could disappear any second.

apt-key itself is heavily deprecated and might disappear in the future.
That it is used by libapt currently is also an implementation detail
(again, of the gpg2 supporting kind) we are unwilling to declare
a supported interface and could be changed any second.

I can't give you an exact time line, but I think Julian even already
wrote some PoC code for libapt, so that the parts from apt-key it
secretly reuses will no longer be needed. Its definitely on the (long)
todo list and has some likelihood of being done before trixie releases.
(And that is ignoring if calling gpgv will even remain the only option).


So, in summary, while no such thing as a VETO formally exists for ITPs,
I intend this mail to be as close to a VETO as possible – by the power
of our dear super cow.


In terms of what this actually does: I haven't looked too closely, but
it seem like you want libapt code not to just call its gpgv-method,
but to also (optionally) call a bunch of other methods before and/or
after it, which all have to approve before we can proceed. Certainly not
the easiest thing in the world to implement, but not that hard either…
after all, we have support for client-merged pdiffs (which isn't used
much nowadays, as Debian moved to server-merged pdiffs years ago) which
are downloaded in parallel and wait on each other before proceeding.
So, not rocket-science. It would also solve a bunch of problems you
already have ("it is currently not known how to find out which apt
repository (apt URL) was used") and the many you will have as soon as
you have actual users (I see e.g. apt-canary downloading files) that
you can solve only by being a proper part of the acquire process, not
by attaching yourself with duck tape and hot glue to its underbelly.
Especially not if you want this to be a security feature…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1059334: python-bytecode fails it's autopkg tests

[Matthias Klose]

Package: src:python-bytecode
Version: 0.15.1-2
Severity: serious
Tags: sid trixie

python-bytecode fails it's autopkg tests:

[...]
57s autopkgtest [00:42:21]: test pybuild-autopkgtest: pybuild-autopkgtest
 57s autopkgtest [00:42:21]: test pybuild-autopkgtest: 
[---

 57s dh before-pybuild-autopkgtest --buildsystem=pybuild
 58s dh: error: Unknown sequence before-pybuild-autopkgtest (choose 
from: binary binary-arch binary-indep build build-arch build-indep clean 
install install-arch install-indep)

 58s make: *** [debian/rules:13: before-pybuild-autopkgtest] Error 25
 58s pybuild-autopkgtest: error: /tmp/B_QXjozyWg/run 
before-pybuild-autopkgtest returned exit code 2
 58s autopkgtest [00:42:22]: test pybuild-autopkgtest: 
---]

 58s pybuild-autopkgtest  FAIL non-zero exit status 25

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Moritz Muehlenhoff]

On Fri, Dec 22, 2023 at 05:47:20PM +0100, Jérémy Lal wrote:
> Le jeu. 21 déc. 2023 à 23:30, Jérémy Lal  a écrit :
> 
> >
> >
> > Le jeu. 21 déc. 2023 à 20:34, Moritz Mühlenhoff  a écrit :
> >
> >> Am Thu, Dec 21, 2023 at 11:29:12AM +0100 schrieb Jérémy Lal:
> >> > Le jeu. 21 déc. 2023 à 10:54, Moritz Muehlenhoff  a
> >> écrit :
> >> >
> >> > > On Thu, Dec 21, 2023 at 06:43:35AM +0100, Salvatore Bonaccorso wrote:
> >> > > > Hi,
> >> > > >
> >> > > > [CC'ing node-undici uploader]
> >> > >
> >> >
> >> > [CC-ing the good email address for node-undici uploader]
> >> >
> >> > Attached is a debdiff for a node-undici update (which backports what has
> >> > been done in testing).
> >>
> >> Looks good to me, please build with -sa (since it's the first upload
> >> to bookworm-security) and upload to security-master.
> >>
> >
> > Note that nodejs 18.19.0 doesn't need this node-undici version to be built,
> > only typescript consumers need it (when rebuilding packages in bookworm,
> > or when simply using a typescript compiler in bookworm).

Ack!

> nodejs (18.19.0+dfsg-6~deb11u1) is ready and built with -sa.

The bookworm branch looks good, but the version is wrong, Bookworm was the
12th Debian release, so this should be 18.19.0+dfsg-6~deb12u1 instead.

With that change, please upload to security-master.

Cheers,
Moritz

Bug#1000014: mydumper: depends on obsolete pcre3 library

[Yavor Doganov]

Control: tags -1 + patch

Please find attached a patch; build-tested only.
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/114
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2023-12-22
---

--- mydumper-0.10.1.orig/cmake/modules/FindPCRE.cmake
+++ mydumper-0.10.1/cmake/modules/FindPCRE.cmake
@@ -11,10 +11,10 @@
 # For details see the accompanying COPYING-CMAKE-SCRIPTS file.
 
 
-if (PCRE_INCLUDE_DIR AND PCRE_PCREPOSIX_LIBRARY AND PCRE_PCRE_LIBRARY)
+if (PCRE_INCLUDE_DIR AND PCRE_PCRE_LIBRARY)
   # Already in cache, be silent
   set(PCRE_FIND_QUIETLY TRUE)
-endif (PCRE_INCLUDE_DIR AND PCRE_PCREPOSIX_LIBRARY AND PCRE_PCRE_LIBRARY)
+endif (PCRE_INCLUDE_DIR AND PCRE_PCRE_LIBRARY)
 
 
 if (NOT WIN32)
@@ -22,24 +22,22 @@
   # in the FIND_PATH() and FIND_LIBRARY() calls
   find_package(PkgConfig)
 
-  pkg_check_modules(PC_PCRE REQUIRED libpcre)
+  pkg_check_modules(PC_PCRE REQUIRED libpcre2-8)
 
   set(PCRE_DEFINITIONS ${PC_PCRE_CFLAGS_OTHER})
 
 endif (NOT WIN32)
 
-find_path(PCRE_INCLUDE_DIR pcre.h 
+find_path(PCRE_INCLUDE_DIR pcre2.h
   HINTS ${PC_PCRE_INCLUDEDIR} ${PC_PCRE_INCLUDE_DIRS} 
-  PATH_SUFFIXES pcre)
+  )
 
-find_library(PCRE_PCRE_LIBRARY NAMES pcre HINTS ${PC_PCRE_LIBDIR} 
${PC_PCRE_LIBRARY_DIRS})
-
-find_library(PCRE_PCREPOSIX_LIBRARY NAMES pcreposix HINTS ${PC_PCRE_LIBDIR} 
${PC_PCRE_LIBRARY_DIRS})
+find_library(PCRE_PCRE_LIBRARY NAMES pcre2-8 HINTS ${PC_PCRE_LIBDIR} 
${PC_PCRE_LIBRARY_DIRS})
 
 include(FindPackageHandleStandardArgs)
-find_package_handle_standard_args(PCRE DEFAULT_MSG PCRE_INCLUDE_DIR 
PCRE_PCRE_LIBRARY PCRE_PCREPOSIX_LIBRARY )
+find_package_handle_standard_args(PCRE DEFAULT_MSG PCRE_INCLUDE_DIR 
PCRE_PCRE_LIBRARY )
 
-set(PCRE_LIBRARIES ${PCRE_PCRE_LIBRARY} ${PCRE_PCREPOSIX_LIBRARY})
+set(PCRE_LIBRARIES ${PCRE_PCRE_LIBRARY})
 
-mark_as_advanced(PCRE_INCLUDE_DIR PCRE_LIBRARIES PCRE_PCREPOSIX_LIBRARY 
PCRE_PCRE_LIBRARY)
+mark_as_advanced(PCRE_INCLUDE_DIR PCRE_LIBRARIES PCRE_PCRE_LIBRARY)
 
--- mydumper-0.10.1.orig/mydumper.c
+++ mydumper-0.10.1/mydumper.c
@@ -36,7 +36,8 @@
 #include 
 #include 
 #include 
-#include 
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include 
 #include 
 #include 
 #include "config.h"
@@ -387,26 +388,31 @@
 
 gboolean check_regex(char *database, char *table) {
   /* This is not going to be used in threads */
-  static pcre *re = NULL;
+  static pcre2_code *re = NULL;
+  pcre2_match_data *md;
   int rc;
-  int ovector[9] = {0};
-  const char *error;
-  int erroroffset;
+  PCRE2_UCHAR error[120];
+  int err;
+  PCRE2_SIZE erroroffset;
 
   char *p;
 
   /* Let's compile the RE before we do anything */
   if (!re) {
-re = pcre_compile(regexstring, PCRE_CASELESS | PCRE_MULTILINE, ,
-  , NULL);
+re = pcre2_compile((PCRE2_SPTR)regexstring, strlen(regexstring),
+   PCRE2_CASELESS | PCRE2_MULTILINE,
+   , , NULL);
 if (!re) {
+  pcre2_get_error_message(err, error, sizeof(error));
   g_critical("Regular expression fail: %s", error);
   exit(EXIT_FAILURE);
 }
   }
 
   p = g_strdup_printf("%s.%s", database, table);
-  rc = pcre_exec(re, NULL, p, strlen(p), 0, 0, ovector, 9);
+  md = pcre2_match_data_create(9, NULL);
+  rc = pcre2_match(re, (PCRE2_SPTR)p, strlen(p), 0, 0, md, NULL);
+  pcre2_match_data_free(md);
   g_free(p);
 
   return (rc > 0) ? TRUE : FALSE;
--- mydumper-0.10.1.orig/server_detect.c
+++ mydumper-0.10.1/server_detect.c
@@ -15,73 +15,96 @@
 Authors:Andrew Hutchings, SkySQL (andrew at skysql dot com)
 */
 
-#include 
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include 
 #include 
 #include 
 #include "server_detect.h"
 
 int detect_server(MYSQL *conn) {
-  pcre *re = NULL;
-  const char *error;
-  int erroroffset;
-  int ovector[9] = {0};
+  pcre2_code *re = NULL;
+  pcre2_match_data *md;
+  PCRE2_UCHAR error[120];
+  PCRE2_SIZE erroroffset;
+  int err;
   int rc;
   const char *db_version = mysql_get_server_info(conn);
 
   // debug the version
   g_message("Server version reported as: %s", db_version);
 
-  re = pcre_compile(DETECT_TIDB_REGEX, 0, , , NULL);
+  re = pcre2_compile((PCRE2_SPTR)DETECT_TIDB_REGEX, PCRE2_ZERO_TERMINATED,
+ 0, , , NULL);
   if (!re) {
+pcre2_get_error_message(err, error, sizeof(error));
 g_critical("Regular expression fail: %s", error);
 exit(EXIT_FAILURE);
   }
 
-  rc = pcre_exec(re, NULL, db_version, strlen(db_version), 0, 0, ovector, 9);
-  pcre_free(re);
+  md = pcre2_match_data_create(9, NULL);
+  rc = pcre2_match(re, (PCRE2_SPTR)db_version, strlen(db_version),
+   0, 0, md, NULL);
+  pcre2_code_free(re);
 
   if (rc > 0) {
+pcre2_match_data_free(md);
 return SERVER_TYPE_TIDB;
   }
 
-  re = pcre_compile(DETECT_MYSQL_REGEX, 0, , , NULL);
+  re = pcre2_compile((PCRE2_SPTR)DETECT_MYSQL_REGEX, PCRE2_ZERO_TERMINATED,
+ 0, , , NULL);
   if (!re) {
+pcre2_get_error_message(err, error, sizeof(error));
 

Bug#1059329: cinnamon-desktop-environment: dependency on noto-font installs too many fonts, fontlist exploded.

[dr. ir. Tjeerd J. Pinkert]

Dear Fabio,

thanks for the quick reply. OK, so that is one issue less... then please 
close this bug?


I also made a reply to the fonts-noto main package. Both the exploding 
fontlist and difficult deinstallation are discussed there in threads:

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

Splitting out the Noto font in many language dependent files seems to be 
not so handy somehow... Unicode was invented to circumvent that issue...

However, the noto-core package still has many fonts installed.

Best regards,


Tjeerd Pinkert

On 12/22/23 17:06, Fabio Fantoni wrote:
Hi, this was already reported by other people and fixed in 5.8.0 (that 
is in unstable/testing) moving fonts-noto from deps to recommends.


I was thinking if it might be useful to further reduce the default 
installation (with recommended) by replacing fonts-noto with 
fonts-noto-core, but I don't know how much the fonts of the other 
packages recommended by fonts-noto are used.

Bug#983291: Default font: Transition from DejaVu to Noto

[dr. ir. Tjeerd J. Pinkert]

Dear Fabian, List,

thanks for packaging fonts for Debian.

On Mon, 18 Sep 2023 13:28:36 +0200 Fabian Greffrath  
wrote:

> If I recall it correctly, the primary suggestion in that bug report
> is to split fonts-noto-core into an LCG and an "other" package.

I have created a MR to implement this:

https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1

 - Fabian


I was also struggling with the extensive font list issue. I managed to 
deinstall the font today to get rid of the annoyance. Of course, I am 
now also rid of a set of type faces.


Why are there so many language specific font files in the package? I'm 
not the most knowledgeable person in this field, but, is it not the idea 
of a unicode font to be capable to include all languages in a single 
font file for one font style / typeface? Then the list of Noto fonts 
would slink to only the various styles available (20 or so?).


- Are there technical boundaries that prevent this other than file size?
- Would this be something to discuss with upstream how to tackle this?

I would guess not only Debian faces these problems with Noto?

Another thought would be to split the package out super fine grained, 
and make the font installation depend on the language selection of the 
users? That would be a lot of work though. I guess there is not an easy 
solution, but people are struggling with this font as can be seen by the 
various bug reports mentioned in this thread. Especially the fact that a 
huge list of fonts is generated by the way the files are structured.


The issue will become harder when more software starts to depend on 
Noto, I had both cinnamon and texlive dependencies. Even only the noto 
core was too much for my taste...


Best regards,


Tjeerd Pinkert

Bug#1059333: mirage: Please disable LTO

[Sudip Mukherjee]

Source: mirage
Version: 0.11.1-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

Please disable LTO for the issue at 
https://gitlab.com/thomasross/mirage/-/issues/24.

The attached patch will disable LTO.

--  
Regars
Sudip
diff --git a/debian/rules b/debian/rules
index 18bed59..a0d5054 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ export DH_VERBOSE = 1
 export PYBUILD_NAME=mirage
 export PYBUILD_DISABLE=test
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
 
 %:
 	dh "$@" --with python3 --buildsystem=pybuild

Bug#1059332: bridge-utils: Using tokenized interface identifiers with bridge-utils ifupdown via /etc/network/interfaces fails

[Oliver Freyermuth]

Package: bridge-utils
Version: 1.7.1-1
Severity: normal

Issue
=
Using "ip token", a command to specify a fixed Interface ID for IPv6 
addressing, fails with bridges in Debian Bookworm, as the token needs to be set in 
between interface creation and taking the interface up.
/lib/bridge-utils/ifupdown.sh currently does not allow to hook into that stage.

Using the following interface config:

auto br0
iface br0 inet dhcp
 bridge_ports enp1s0
 bridge_hw 12:34:56:78:90:12
iface br0 inet6 manual
 pre-up ip token set ::192.168.1.35 dev br0

causes the system to end up with the usual EUI-64 based global IPv6 addresses 
in addition to the token-based addresses.
The kernel then keeps the EUI-64 based addresses in addition to the wanted 
token-based addresses until they expire, at which point only the tokized 
interface identifiers keep being used.


Workaround
==
As a "hack", the following workaround configuration can be used:

auto br0
iface br0 inet dhcp
 pre-up brctl addbr br0
 pre-up ip link set dev br0 address 12:34:56:78:90:12
 pre-up ip token set ::192.168.1.35 dev br0
 bridge_ports enp1s0
 bridge_hw 00:1e:06:45:2e:fa
iface br0 inet6 manual

This causes the "ip token" command to apply between interface creation and 
taking the interface up, which works as expected (i.e. the system only has global 
addresses based on the token).
Of course, any required feature dealt with in /lib/bridge-utils/ifupdown.sh in 
between interface creation and taking the interface up needs to be replicated 
manually via pre-up.


Proposed fix

Adding the lines:

  if [ "$IF_BRIDGE_TOKEN" ]
  then
ip token set $IF_BRIDGE_TOKEN dev $IFACE
  fi

right before:

  # We activate the bridge
  ip link set dev $IFACE up

in /lib/bridge-utils/ifupdown.sh and using the interface config:

auto br0
iface br0 inet dhcp
 bridge_ports enp1s0
 bridge_hw 12:34:56:78:90:12
 bridge_token ::192.168.1.35

fixes the problem. However, this necessarily introduces a dependency on iproute2 (i.e. it should 
probably be a "recommends", existence of "/sbin/ip" might be necessary to 
check, documentation needs to be adapted).

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Jérémy Lal]

Le jeu. 21 déc. 2023 à 23:30, Jérémy Lal  a écrit :

>
>
> Le jeu. 21 déc. 2023 à 20:34, Moritz Mühlenhoff  a écrit :
>
>> Am Thu, Dec 21, 2023 at 11:29:12AM +0100 schrieb Jérémy Lal:
>> > Le jeu. 21 déc. 2023 à 10:54, Moritz Muehlenhoff  a
>> écrit :
>> >
>> > > On Thu, Dec 21, 2023 at 06:43:35AM +0100, Salvatore Bonaccorso wrote:
>> > > > Hi,
>> > > >
>> > > > [CC'ing node-undici uploader]
>> > >
>> >
>> > [CC-ing the good email address for node-undici uploader]
>> >
>> > Attached is a debdiff for a node-undici update (which backports what has
>> > been done in testing).
>>
>> Looks good to me, please build with -sa (since it's the first upload
>> to bookworm-security) and upload to security-master.
>>
>
> Note that nodejs 18.19.0 doesn't need this node-undici version to be built,
> only typescript consumers need it (when rebuilding packages in bookworm,
> or when simply using a typescript compiler in bookworm).
>

nodejs (18.19.0+dfsg-6~deb11u1) is ready and built with -sa.

Jérémy

Bug#1058928: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2

[Guilhem Moulin]

Control: tag -1 - moreinfo

Hi,

On Thu, 21 Dec 2023 at 21:59:40 +, Jonathan Wiltshire wrote:
> On Mon, Dec 18, 2023 at 02:10:20PM +0100, Guilhem Moulin wrote:
>> [ Reason ]
>>
>> 1. cryptsetup-suspend 2:2.6.1-4~deb12u1 was found incompatible with
>> systemd 254.1-3 and later, in particular with systemd/bookworm-backports.
>>
>> 2. cryptsetup-initramfs 2:2.6.1-4~deb12u2 dos not support kernel
>> shipping compressed modules under MODULES=dep, as is done by default
>> with linux 6.6 (currently in Debian experimental).
>
> Aren't these problems better sorted out in the relevant suites, e.g. with
> Breaks? It seems an unnecessary change in stable when stable isn't actually
> broken.

It's correct that stable isn't broken at the moment, but some users also
build their own kernels, and we can't warn about the incompatibilty
there; they just won't be able to boot when these 3 conditions are
satisfied:

 1. Linux is configured with CONFIG_MODULE_COMPRESS_* (Debian currently
does that in experimental only but the setting is also available in
<6.0);
 2. initramfs.conf(5) sets MODULES=dep; and
 3. There is a device to be unlocked at initramfs stage (for instance
the root FS).

Moreover the issue stands in the way of kernel maintainers enabling
CONFIG_MODULE_COMPRESS_* in stable should that be needed or desired
in some point release.  (Compressed modules are already suported in
Bookworm's initramfs-tools, but currently not in cryptsetup-initramfs.)

The other issue I see with ‘Breaks: cryptsetup-initramfs (<< 2:2.6.1-6~)’
without having a recent enough cryptsetup-initramfs available is that
apt will hapilly suggest to remove cryptsetup-initramfs.  That too would
yield an unbootable system whenever there is any device to be unlocked
at initramfs stage.

Note that the proposed change is a no-op with Bookworm's current kernel
and systemd.  It just adds forward compatibility in the same way
initramfs-tools did.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1055509: diversions of /sbin/halt and friends

[Helmut Grohne]

On Fri, Dec 22, 2023 at 12:30:04PM +0100, Helmut Grohne wrote:
> My patch for progress-linux-container and bfh-container fails to remove
> /usr/lib/container on package removal. This probably breaks piuparts. I
> am attaching a followup patch. This defect is unrelated to the /usr-move
> as far as I can tell.

Chris kindly made me aware that I forgot to attach patches.

Helmut
diff --minimal -Nru bfh-metapackages-20211009/debian/bfh-container.postrm 
bfh-metapackages-20211009/debian/bfh-container.postrm
--- bfh-metapackages-20211009/debian/bfh-container.postrm   2023-12-20 
11:10:47.0 +0100
+++ bfh-metapackages-20211009/debian/bfh-container.postrm   2023-12-22 
11:29:03.0 +0100
@@ -13,6 +13,13 @@
do
dpkg-divert --package bfh-container --quiet --remove 
--rename --divert "/usr/lib/container/divert/${FILE}.orig" "/usr/sbin/${FILE}"
done
+
+   if test -d /usr/lib/container; then
+   if test -d /usr/lib/container/divert; then
+   rmdir --ignore-fail-on-non-empty 
/usr/lib/container/divert
+   fi
+   rmdir --ignore-fail-on-non-empty /usr/lib/container
+   fi
;;
 
purge|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
diff --minimal -Nru bfh-metapackages-20211009/debian/bfh-container.preinst 
bfh-metapackages-20211009/debian/bfh-container.preinst
--- bfh-metapackages-20211009/debian/bfh-container.preinst  2023-12-20 
11:10:47.0 +0100
+++ bfh-metapackages-20211009/debian/bfh-container.preinst  2023-12-22 
11:26:27.0 +0100
@@ -4,7 +4,7 @@
 
 case "${1}" in
install|upgrade)
-   mkdir -p /lib/container/divert
+   mkdir -p /usr/lib/container/divert
 
for FILE in halt poweroff reboot shutdown coldreboot
do
diff --minimal -Nru bfh-metapackages-20211009/debian/changelog 
bfh-metapackages-20211009/debian/changelog
--- bfh-metapackages-20211009/debian/changelog  2023-12-20 11:12:25.0 
+0100
+++ bfh-metapackages-20211009/debian/changelog  2023-12-22 11:29:03.0 
+0100
@@ -1,3 +1,10 @@
+bfh-metapackages (20211009-22.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Delete /usr/lib/container/divert on package removal.
+
+ -- Helmut Grohne   Fri, 22 Dec 2023 11:29:03 +0100
+
 bfh-metapackages (20211009-22) experimental; urgency=medium
 
   * Uploading to experimental.
diff --minimal -Nru progress-linux-metapackages-20221002/debian/changelog 
progress-linux-metapackages-20221002/debian/changelog
--- progress-linux-metapackages-20221002/debian/changelog   2023-12-20 
11:26:39.0 +0100
+++ progress-linux-metapackages-20221002/debian/changelog   2023-12-22 
11:44:44.0 +0100
@@ -1,3 +1,10 @@
+progress-linux-metapackages (20221002-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Delete /usr/lib/container/divert on package removal.
+
+ -- Helmut Grohne   Fri, 22 Dec 2023 11:44:44 +0100
+
 progress-linux-metapackages (20221002-11) experimental; urgency=medium
 
   * Uploading to experimental.
diff --minimal -Nru 
progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
progress-linux-metapackages-20221002/debian/progress-linux-container.postrm
--- progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
2023-12-20 11:25:47.0 +0100
+++ progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
2023-12-22 11:44:43.0 +0100
@@ -13,6 +13,13 @@
do
dpkg-divert --package progress-linux-container --quiet 
--remove --rename --divert "/usr/lib/container/divert/${FILE}.orig" 
"/usr/sbin/${FILE}"
done
+
+   if test -d /usr/lib/container; then
+   if test -d /usr/lib/container/divert; then
+   rmdir --ignore-fail-on-non-empty 
/usr/lib/container/divert
+   fi
+   rmdir --ignore-fail-on-non-empty /usr/lib/container
+   fi
;;
 
purge|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
diff --minimal -Nru 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
--- 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
2023-12-20 11:26:29.0 +0100
+++ 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
2023-12-22 11:44:08.0 +0100
@@ -4,7 +4,7 @@
 
 case "${1}" in
install|upgrade)
-   mkdir -p /lib/container/divert
+   mkdir -p /usr/lib/container/divert
 
for FILE in halt poweroff reboot shutdown coldreboot
do

Bug#1059329: cinnamon-desktop-environment: dependency on noto-font installs too many fonts, fontlist exploded.

[Fabio Fantoni]

Hi, this was already reported by other people and fixed in 5.8.0 (that 
is in unstable/testing) moving fonts-noto from deps to recommends.


I was thinking if it might be useful to further reduce the default 
installation (with recommended) by replacing fonts-noto with 
fonts-noto-core, but I don't know how much the fonts of the other 
packages recommended by fonts-noto are used.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17

[Holger Levsen]

On Thu, Dec 21, 2023 at 08:59:31PM +, Jonathan Wiltshire wrote:
> > I've updated this update request for adding 3 more lines to
> > security-support-ended.deb11 (and updating d/changelog)
> Please go ahead.

thanks, uploaded.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

First they ignore you, then they laugh at you, and then it's too late.
Don't look up!


signature.asc
Description: PGP signature

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Salvatore Bonaccorso]

Source: spip
Version: 4.1.12+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: fixed -1 4.1.13+dfsg-1
Control: found -1 4.1.9+dfsg-1+deb12u2
Control: found -1 3.2.11-3+deb11u9

Filling a bug for tracking (as otherwise beeing a unspecified TEMP
entry), as the issue has no CVE: 4.1.13 fixes an issue:

   * fix: les modèles insérés dans un texte héritent automatiquement du
 contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
 variables envoyées par l'utilisateur

https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/

Regards,
Salvatore

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Hello Salvatore,

Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > However, the fix for CVE-2023-6004 caused a regression:
> > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > I will monitor this, and include the fix in the security upload once it is
> > available (or presumably they'll do a 0.10.7). So if it's alright with you,
> > I'll delay the stable-security update for a few days.
>
> Rigth, it's not that pressing that we get updates out, so let's
> monitor this, have 0.10.7 uploaded and exposed as well then to
> unstable for a while and then look at bookworm-security. Btw, we will
> as well need bullseye-security.

Ack. The fix landed upstream, and they said they won't do a 0.10.7 immediately,
so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole cockpit
integration test suite at it (which exercises libssh pretty thoroughly via
cockpit-ssh), and it is happy.

I'll let that simmer for a few days to let it go into testing, and prepare the
security updates soon.

Martin

Bug#1059330: transition: shapelib

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: shape...@packages.debian.org
Control: affects -1 + src:shapelib
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-shapelib.html

Shapelib 1.6.0 bumps the SONAME requiring a transition.

All rdeps built successfully with the new version as summarized below.


Transition: shapelib

 libshp2 (1.5.0-3+b1) -> libshp4 (1.6.0~rc1-1~exp1)

The status of the most recent rebuilds is as follows.

 cyrus-imapd  (3.8.1-1)   OK
 glgrib   (1.0-3) OK
 gpsbabel (1.9.0+ds-2)OK
 gpsmanshp(1.2.3-6)   OK
 grads(3:2.2.1-5) OK
 libgeo-shapelib-perl (0.22-6)OK
 libterralib  (4.3.0+dfsg.2-12.1) OK
 marble   (4:22.12.3-2)   OK
 plplot   (5.15.0+dfsg2-6)OK
 therion  (6.1.8-2)   OK
 tilemaker(2.4.0-1)   OK

 gnudatalanguage  (1.0.3-1)   OK
 scamp(2.10.0-2)  OK
 xastir   (2.2.0-1)   OK


Kind Regards,

Bas

Bug#1059329: cinnamon-desktop-environment: dependency on noto-font installs too many fonts, fontlist exploded.

[T. J. Pinkert]

Package: cinnamon-desktop-environment
Version: 5.6.0
Severity: whishlist
X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl

Dear Maintainer,

to have several desktop environments available on my computer, I installed the
cinnamon desktop environment.
This package has a hard dependency on the noto-font package. Latter package
contains fonts for all unicode languages, and it is thus not a bad idea to have
that installed per-see.
But since there are for every language about 10 to 20 fonts installed, the
fontlist on my computer "exploded".
This is a hussle as font selection should not be cumbersome, but usefull.
Scrolling along a list of hundreds of noto fonts to come to the next usefull
font is clearly not.

When I tried to deinstall the noto-font, the dependency on this package tried
to deinstall also part of the cinnamon desktop.
I could work around it though, by manually selecting all packages that were to
be deinstalled. However must this be?

For me the question is, is the dependency on the noto-font really necessary? Or
is it a nice to have?
Could the noto-font be a recommended package? That would allow easier
deinstallation when wanted.

Another solution could be to separate the noto-font out into a much finer
selection of font packages, such that only those for installed languages are
installed.
I do understand that native speakers of, say, thai, may want the thai part of
the noto-font, but we "westerners" do typically not need that part of this huge
font base.

I hope some thoughts on this will help to make Debian better.

Best regards,


Tjeerd Pinkert


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

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

Versions of packages cinnamon-desktop-environment depends on:
ii  atril [pdf-viewer]   1.26.0-2+b1
ii  cinnamon-core5.6.0
ii  eog  43.2-1
ii  evince [pdf-viewer]  43.1-2+b1
ii  fonts-liberation 1:1.07.4-11
pn  fonts-noto   
ii  gnome-calculator 1:43.0.1-2
ii  gnome-screenshot 41.0-2
ii  gnome-text-editor43.2-1
ii  gv [pdf-viewer]  1:3.7.4-2+b1
ii  xdg-user-dirs-gtk0.11-1

Versions of packages cinnamon-desktop-environment recommends:
ii  blueman  2.3.5-2+b1
ii  brasero  3.12.3-2
ii  bsd-mailx [mail-reader]  8.1.2-0.20220412cvs-1
ii  cheese   43.0-1
ii  chromium [www-browser]   120.0.6099.129-1~deb12u1
ii  cups 2.4.2-3+deb12u5
ii  deja-dup 44.0-2
ii  evolution [mail-reader]  3.46.4-2
ii  firefox-esr [www-browser]115.6.0esr-1~deb12u1
ii  gdebi0.9.5.7+nmu6
ii  gnome-characters 43.1-1+deb12u1
ii  gnome-disk-utility   43.0-1
ii  gnome-font-viewer43.0-1
ii  gnome-games  1:43+1
ii  gnome-logs   43.0-1
ii  gnome-software   43.5-1~deb12u1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-system-monitor 42.0-2
ii  gnote43.1-1
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  hexchat  2.16.1-1+b3
ii  libreoffice-calc 4:7.4.7-1+deb12u1
ii  libreoffice-gnome4:7.4.7-1+deb12u1
ii  libreoffice-impress  4:7.4.7-1+deb12u1
ii  libreoffice-writer   4:7.4.7-1+deb12u1
ii  lynx [www-browser]   2.9.0dev.12-1
ii  mate-themes  3.22.23-1
ii  mpv  0.35.1-4
ii  orca 43.1-1
ii  pidgin   2.14.12-1
ii  remmina  1.4.29+dfsg-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  smplayer 22.7.0~ds0-1
ii  sound-juicer 3.38.0-2.1
ii  sound-theme-freedesktop  0.8-2
ii  synaptic 0.91.3
ii  system-config-printer1.5.18-1
ii  thunderbird [mail-reader]1:115.6.0-1~deb12u1
ii  totem43.0-2
ii  transmission-gtk 3.00-2.1+deb12u1
pn  vino | x2goserver
ii  vlc  3.0.20-0+deb12u1
ii  yelp 42.2-1
ii  zenity   3.44.0-1

Versions of packages cinnamon-desktop-environment suggests:
pn  gedit-plugins   
ii  gimp

Bug#1059326: Workaround

[Sébastien Delafond]

In case someone out there is stuck real bad with this bug in bookworm,
here's a very nasty workaround for which I of course decline all
responsibility:

  $ mkdir /usr/share/fonts/type1/gsfonts
  $ ln -sf /usr/share/fonts/X11/Type1/C059-Roman.pfb 
/usr/share/fonts/type1/gsfonts/n021003l.pfb

Cheers,

-- 
Seb

Bug#1059328: ITP: trml2pdf -- implementation of RML (Report Markup Language) from ReportLab

[Georges Khaznadar]

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

* Package name: trml2pdf
  Version : 0.6
  Upstream Contact: Roman Lyashov 
* URL : https://github.com/romanlv/trml2pdf
* License : LGPL2+
  Programming Lang: Python3
  Description : translation of RML (Report Markup Language) from ReportLab,
to PDF

 trml2pdf is a translator which converts high level XML markup into
 PDF documents. RML (Report Markup Language) describes the precise
 layout of a printed document, and trml2pdf converts this to a
 finished document in one step.
 .
 This package installs the library for Python 3.


trml2pdf enhances the package python3-reportlab, which I maintain.
It is uploaded at https://salsa.debian.org/georgesk/trml2pdf.git

Bug#1059326: fixed in 4.0.8-1

[Sébastien Delafond]

Control: fixed 1059326 4.0.8-1

The earliest fixed version is most likely between 4.0.4-7 and 4.0.4-11.

Cheers,

-- 
Seb

Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate

[Simon McVittie]

On Fri, 22 Dec 2023 at 03:23:21 +0100, Olivier Mehani wrote:
> GDM3 doesn't seem to be able to start a Wayland session (nor a fallback Xorg 
> session, but I'm less concerned about this, and this seems to be a 
> separate permission issue).

That's a valid bug, let's leave your report open for that.

If neither Wayland nor Xorg works, that would suggest (to me, at least)
that this is a lower-level issue, indeed perhaps involving permissions
as you say.

> This seems to be related to 
> org.freedesktop.systemd1 failing to activate (and triggering the 
> fallback to Xorg).

I don't think this is necessarily the root cause, though.

> The smoking gun implicating org.freedesktop.systemd1 is
> 
>   déc. 22 03:17:17 desktop gdm-launch-environment][28769]: 
> pam_unix(gdm-launch-environment:session): session opened for user 
> Debian-gdm(uid=113) by (uid=0)
>   déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: 
> dbus-daemon[28792]: [session uid=113 pid=28792] Activating service 
> name='org.freedesktop.systemd1' requested by ':1.0' (uid=113 pid=28785 
> comm="/usr/libexec/gdm-wayland-session dbus-run-session ")
>   déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: 
> dbus-daemon[28792]: [session uid=113 pid=28792] Activated service 
> 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited 
> with status 1

Even though it looks bad at first glance, this could actually be fine. gdm
can run more than one "greeter" (login prompt) under the same uid, so it
intentionally avoids the mechanism that would normally result in having
one `dbus-daemon --session` per uid. Instead, it uses dbus-run-session(1)
to launch one `dbus-daemon --session` per greeter.

The result is that gdm-wayland-session tries to contact `systemd --user`,
which fails with exit status 1, because
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service
contains:

Exec=/bin/false

(it is not possible to start a `systemd --user` when already inside a
session that does not already have one).

I get similar messages on a fully-working system, in this case a virtual
machine running bookworm and GNOME, without anything being obviously broken:

Dec 22 14:38:53 d12gnome /usr/libexec/gdm-wayland-session[691]: 
dbus-daemon[691]: [session uid=113 pid=691] Activating
 service name='org.freedesktop.systemd1' requested by ':1.10' (uid=113 pid=851 
comm="/usr/libexec/gsd-sharing")
Dec 22 14:38:53 d12gnome /usr/libexec/gdm-wayland-session[691]: 
dbus-daemon[691]: [session uid=113 pid=691] Activated service 
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with 
status 1
Dec 22 14:38:53 d12gnome gsd-sharing[851]: Failed to StopUnit service: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.freedesktop.systemd1 exited with status 1
Dec 22 14:38:53 d12gnome gsd-sharing[851]: Failed to StopUnit service: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.freedesktop.systemd1 exited with status 1
Dec 22 14:38:53 d12gnome gnome-shell[727]: Error looking up permission: 
GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation
Dec 22 14:38:53 d12gnome org.gnome.Shell.desktop[783]: Failed to initialize 
glamor, falling back to sw
Dec 22 14:38:53 d12gnome /usr/libexec/gdm-wayland-session[691]: 
dbus-daemon[691]: [session uid=113 pid=691] Activating service 
name='org.gtk.vfs.Daemon' requested by ':1.25' (uid=113 pid=885 
comm="ibus-daemon --panel disable")

So I think you might need to look elsewhere for the root cause of the gdm
session not starting successfully.

smcv

Bug#1057750: ciso: Please update to ciso 1.0.2

[Aaron Rainbolt]

Sorry for the late reply.

I'd be happy to co-maintain ciso. Thanks!

The patch was taken from upstream, so I'm not sure why you're getting 
failures. I'll take a closer look hopefully in the near future. Perhaps 
the ciso packaging you have on your system has changes that aren't in 
the archive already?


Thanks for your help!

On 12/11/23 06:53, Gürkan Myczko wrote:

Hi Aaron

On 08.12.2023 00:36, Aaron Rainbolt wrote:
Debdiff prepared and attached. Please review this whenever you get a 
chance and tell me if there's anything I can do better. Thanks!


Thank you for the patch. Would it be possible to upstream this?
https://github.com/jamie/ciso

If upstream doesn't accept your patches, would you be willing to fork 
and continue?


debian/changelog, your entries look fine, would you like to be 
co-maintainer or not?


I didn't take a look at why it failed with ciso.c and ciso.h yet, but 
here's the output:

$ patch -p1 < ../update.patch
patching file README.markdown
patching file ciso.c
Hunk #1 FAILED at 22.
Hunk #2 succeeded at 32 (offset 1 line).
Hunk #3 succeeded at 44 (offset 1 line).
Hunk #4 succeeded at 81 (offset 1 line).
Hunk #5 succeeded at 118 (offset 1 line).
Hunk #6 succeeded at 139 (offset 1 line).
Hunk #7 succeeded at 238 (offset 1 line).
Hunk #8 succeeded at 251 (offset 1 line).
Hunk #9 succeeded at 280 (offset 1 line).
Hunk #10 succeeded at 307 (offset 1 line).
Hunk #11 succeeded at 402 (offset 1 line).
1 out of 11 hunks FAILED -- saving rejects to file ciso.c.rej
patching file ciso.h
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file ciso.h.rej
patching file debian/changelog
patching file debian/control
patching file debian/copyright
patching file debian/patches/01_mem_alloc_failure_amd64.patch
patching file debian/patches/series
patching file debian/patches/usage-syntax
patching file debian/upstream/metadata
patching file debian/watch


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3

Bug#1053873: cronie: Crond with high load after 19-01-2038

[Lin Qigang]

Control: tags 1053873 = wontfix

I hope Debian will find all 32bit problems in the new versions, because 
there will be more people want to use it.
We have a world wide problem in 2038. All old unix (like) systems will 
fail because the signed value of unix will cause programs in all layers 
to fail, starting with the kernel and c-library..

I have tested with vxworks which is the only systems that works after 2038.
Debian is the only version that still supports newer kernel versions 
on x86 machines. Certain programs require specific old java versions for 
their program to run after 2038. And there will be many more problems.
Solving these issues must be done soon before knowledge of the 
application is unavailable at the time of the wrap in 2038.


Can you help me with a debian version that works?
You could also pass on this information.


This is the year 2038 problem for 32-bit architectures. Debian has 
release goals for fixing or working around this issue for most 32-bit 
architectures, but based on Debian's wiki, i386 will not be 
transitioning time_t for 64-bit time [1].


[1] https://wiki.debian.org/ReleaseGoals/64bit-time

Best,

--
Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059326: python3-reportlab: Can't set standard fonts

[Sebastien Delafond]

Package: python3-reportlab
Version: 3.6.12-1
Severity: normal

Control: notfound -1 4.0.8-1
Control: found -1 3.6.12-1 

This is the same type of issue as archived bug
https://bugs.debian.org/1029683, and I'm filing this new one to make
it clear python3-reportlab in bookworm is affected.

Here's a short reproducer :

  from reportlab.graphics.barcode import createBarcodeDrawing
  barcode = createBarcodeDrawing('QR',value='test')
  barcode.asString('png')

And the associated error :

,
| Warn: Can't find .pfb for face 'Times-Roman'
| Traceback (most recent call last):
|   File "/opt/test-reportlab-bug.py", line 7, in 
| barcode.asString('png')
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/shapes.py",
|   line 807, in asString
| return renderPM.drawToString(self,
| fmt=format,showBoundary=getattr(self,'showBorder',
|
^^
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 696, in drawToString
| drawToFile(d,s,fmt=fmt, dpi=dpi, bg=bg,
| configPIL=configPIL,backend=backend)
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 691, in drawToFile
| c = drawToPMCanvas(d, dpi=dpi, bg=bg, configPIL=configPIL,
| showBoundary=showBoundary,backend=backend)
| 
^
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 677, in drawToPMCanvas
| draw(d, c, 0, 0, showBoundary=showBoundary)
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 66, in draw
| R.draw(renderScaledDrawing(drawing), canvas, x, y,
| showBoundary=showBoundary)
|   File
|   "/usr/lib/python3/dist-packages/reportlab/graphics/renderbase.py",
|   line 185, in draw
| self.initState(x,y)  #this is the push()
| ^^^
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 113, in initState
| self.applyState()
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 107, in applyState
| self._canvas.setFont(s['fontName'], s['fontSize'])
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py",
|   line 405, in setFont
| _setFont(self._gs,fontName,fontSize)
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/utils.py",
|   line 42, in setFont
| _errorDump(fontName,fontSize)
|   File "/usr/lib/python3/dist-packages/reportlab/graphics/utils.py",
|   line 29, in _errorDump
| rl_exec(code,dict(RenderPMError=RenderPMError))
|   File "", line 1, in 
`

Cheers,

-- 
Seb

Bug#1059325: bash: printf does not recognise numeric constants with explicit base 10

[Francesco Potortì]

Package: bash
Version: 5.2.21-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ bash --version
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ echo $((10#08))
8

pot@pot:~$ printf %d\\n 10#08
bash: printf: 10#08: invalid number
10

This is clearly a bug: printf should print no error, and just print 8 followed 
by newline.  However, this only happens on one of my two boxes with Debian 
testing.  The other one does not exhibit the bug, and printf just prints 8 
followed by newline.

I tried with bash --login --noprofile, but nothing changes.

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it
(gate 20, 1st floor, room C71) ISPIN:  https://ieee-jispin.org/


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 bash depends on:
ii  base-files   13
ii  debianutils  5.14
ii  libc62.37-12
ii  libtinfo66.4+20231209-1

Versions of packages bash recommends:
ii  bash-completion  1:2.11-8

Versions of packages bash suggests:
ii  bash-doc  5.2.21-2

-- Configuration Files:
/etc/bash.bashrc changed:
[ -z "$PS1" ] && return
shopt -s checkwinsize
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi
if [ -x /usr/lib/command-not-found -o -x 
/usr/share/command-not-found/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
   /usr/lib/command-not-found -- "$1"
   return $?
elif [ -x /usr/share/command-not-found/command-not-found ]; then
   /usr/share/command-not-found/command-not-found -- "$1"
   return $?
else
   printf "%s: command not found\n" "$1" >&2
   return 127
fi
}
fi
alias ls='ls --color=auto '
set -o emacs
eval "$(lessfile)"


-- no debconf information

Bug#1056681: build-depends on atlas, which is obsolete and scheduled for removal

[Sébastien Villemot]

Control: tags -1 + patch

Hi Andreas,

Le mercredi 29 novembre 2023 à 11:53 +0100, Andreas Tille a écrit :
> Control: tags -1 help
> 
> [Ritika Ramani in CC to inform that Debian tries to get rid of Atlas
>  which also affects phast. see https://bugs.debian.org/1056681]
> 
> Hi,
> 
> I tried to replace clapack by LAPACKE.  Unfortunately this is not a
> drop-in replacement.  As you can see in the raw(! normal log is to
> long!) build log on Salsa[1] when seeking for the string
>   too few arguments to function
> you see
> 
> ...
> phast_eigen.c: In function 'mat_diagonalize':
> phast_eigen.c:62:3: error: too few arguments to function 'dgeev_'
>62 |   dgeev_(, , , tmp, , wr, wi, vl,
>   |   ^~
> In file included from /usr/include/lapack.h:11,
>  from 
> /builds/med-team/phast/debian/output/source_dir/src/../include/phast/external_libs.h:43,
>  from 
> /builds/med-team/phast/debian/output/source_dir/src/../include/phast/vector.h:19,
>  from 
> /builds/med-team/phast/debian/output/source_dir/src/../include/phast/matrix.h:18,
>  from 
> /builds/med-team/phast/debian/output/source_dir/src/../include/phast/eigen.h:18,
>  from phast_eigen.c:18:
> /usr/include/lapack.h:1828:6: note: declared here
>  1828 | void LAPACK_dgeev_base(
>   |  ^
> phast_eigen.c: In function 'mat_eigenvals':
> phast_eigen.c:199:3: error: too few arguments to function 'dgeev_'
>   199 |   dgeev_(, , , tmp, , wr, wi, NULL,
>   |   ^~
> ...

Actually we had already completed the migration away from the old
CLAPACK in clapack.patch.

Only a minor cleanup was still needed to remove ATLAS. I opened a merge
request that seems to do the job:

 https://salsa.debian.org/med-team/phast/-/merge_requests/1

Best,

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



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

Bug#942274: uscan: handling several levels of http links

[P. J. McDermott]

On Sun, 13 Oct 2019 18:36:51 +0200 Samuel Thibault  wrote:
> Package: devscripts
> Version: 2.19.6
> Severity: wishlist
> 
> Hello,
> 
> For the hwloc package, there is on single webpage that references all
> releases.
> 
[...]
> 
> But this doesn't seem supported. Am I missing something or is handling
> several levels of http links not supported?

I've run into this with the 7kaa-music package:
https://salsa.debian.org/games-team/7kaa-music

Upstream lists versions at:
https://www.7kfans.com/download/
That page links to pages such as:
https://www.7kfans.com/download/v2.15.6.html
And those pages link to the tar archive:
https://www.7kfans.com/downloads/7kaa-music-2.15.tar.bz2

So I need uscan to somehow recurse from the main download page to the
latest version's page to find the tar archive link.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1059324: subversion: "svn revert -R" signals reverted files with no changes

[Vincent Lefevre]

Package: subversion
Version: 1.14.2-5+b1
Severity: important

I get the following:

qaa% svn st
M   config.dat
M   dpkg-l
M   grub.cfg
M   mutt-v
M   postconf
M   selections
M   version.out
qaa% svn pl -v etc/apache2/mods-available/dnssd.conf
Properties on 'etc/apache2/mods-available/dnssd.conf':
  source
qaa:/etc/apache2/mods-available/dnssd.conf
  svn:mime-type
text/plain
qaa% svn diff etc/apache2/mods-available/dnssd.conf
qaa% svn revert -R .
Reverted 'selections'
Reverted 'version.out'
Reverted 'postconf'
Reverted 'etc/apache2/conf-available/javascript-common.conf'
Reverted 'etc/apache2/mods-available/dnssd.load'
Reverted 'etc/apache2/mods-available/dnssd.conf'
Reverted 'mutt-v'
Reverted 'config.dat'
Reverted 'grub.cfg'
Reverted 'dpkg-l'
qaa% svn pl -v etc/apache2/mods-available/dnssd.conf
Properties on 'etc/apache2/mods-available/dnssd.conf':
  source
qaa:/etc/apache2/mods-available/dnssd.conf
  svn:mime-type
text/plain
qaa% 

I don't see why etc/apache2/mods-available/dnssd.conf is signaled
as reverted. Is there some data corruption somewhere?

This seems reproducible.

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 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 subversion depends on:
ii  libapr1  1.7.2-3
ii  libaprutil1  1.6.3-1
ii  libc62.37-13
ii  libsvn1  1.14.2-5+b1

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util  
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
ii  subversion-tools1.14.2-5+b1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1059323: mount.cifs fails to mount a share which smbclient can access all right

[Alain Knaff]

Package: cifs-utils
Version: 2:7.0-2

We have one share here which can be opened by smbclient, but not mounted
using mount.cifs:

smbclient -A ~alain/.smbcredentials-admin //work03.gouv.etat.lu/aev
=> succeeds

# mount.cifs -o credentials=/home/alain/.smbcredentials-admin 
//work03.gouv.etat.lu/aev  /media/windows/work03
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log 
messages (dmesg)

kernel log shows:

2023-12-22T11:58:37.212890+01:00 alainpc kernel: [10807.375685] CIFS: 
fs/smb/client/fs_context.c: CIFS: parsing cifs mount option 'source'
2023-12-22T11:58:37.212910+01:00 alainpc kernel: [10807.375702] CIFS: 
fs/smb/client/fs_context.c: CIFS: parsing cifs mount option 'ip'
2023-12-22T11:58:37.212913+01:00 alainpc kernel: [10807.375710] CIFS: 
fs/smb/client/fs_context.c: CIFS: parsing cifs mount option 'unc'
2023-12-22T11:58:37.212914+01:00 alainpc kernel: [10807.375715] CIFS: 
fs/smb/client/fs_context.c: CIFS: parsing cifs mount option 'user'
2023-12-22T11:58:37.212916+01:00 alainpc kernel: [10807.375720] CIFS: 
fs/smb/client/fs_context.c: CIFS: parsing cifs mount option 'pass'
2023-12-22T11:58:37.212917+01:00 alainpc kernel: [10807.375726] CIFS: 
fs/smb/client/cifsfs.c: Devname: \\work03.gouv.etat.lu\aev flags: 0
2023-12-22T11:58:37.212919+01:00 alainpc kernel: [10807.375733] CIFS: 
fs/smb/client/connect.c: Username: xx_admin
2023-12-22T11:58:37.212921+01:00 alainpc kernel: [10807.375736] CIFS: 
fs/smb/client/connect.c: file mode: 0755  dir mode: 0755
2023-12-22T11:58:37.212924+01:00 alainpc kernel: [10807.375743] CIFS: 
fs/smb/client/connect.c: VFS: in mount_get_conns as Xid: 79 with uid: 0
2023-12-22T11:58:37.212926+01:00 alainpc kernel: [10807.375748] CIFS: 
fs/smb/client/connect.c: UNC: \\work03.gouv.etat.lu\aev
2023-12-22T11:58:37.212928+01:00 alainpc kernel: [10807.375756] CIFS: 
fs/smb/client/connect.c: generic_ip_connect: connecting to 148.110.208.152:445
2023-12-22T11:58:37.212959+01:00 alainpc kernel: [10807.375774] CIFS: 
fs/smb/client/connect.c: Socket created
2023-12-22T11:58:37.212962+01:00 alainpc kernel: [10807.375777] CIFS: 
fs/smb/client/connect.c: sndbuf 16384 rcvbuf 131072 rcvtimeo 0x6d6
2023-12-22T11:58:37.232875+01:00 alainpc kernel: [10807.396428] CIFS: 
fs/smb/client/connect.c: cifs_get_tcp_session: next dns resolution scheduled 
for 600 seconds in the future
2023-12-22T11:58:37.232893+01:00 alainpc kernel: [10807.396441] CIFS: 
fs/smb/client/connect.c: VFS: in cifs_get_smb_ses as Xid: 80 with uid: 0
2023-12-22T11:58:37.232896+01:00 alainpc kernel: [10807.396447] CIFS: 
fs/smb/client/connect.c: Existing smb sess not found
2023-12-22T11:58:37.232897+01:00 alainpc kernel: [10807.396455] CIFS: 
fs/smb/client/smb2pdu.c: Negotiate protocol
2023-12-22T11:58:37.232899+01:00 alainpc kernel: [10807.396467] CIFS: 
fs/smb/client/transport.c: wait_for_free_credits: remove 1 credits total=0
2023-12-22T11:58:37.232901+01:00 alainpc kernel: [10807.396484] CIFS: 
fs/smb/client/connect.c: Demultiplex PID: 13815
2023-12-22T11:58:37.232903+01:00 alainpc kernel: [10807.396494] CIFS: 
fs/smb/client/transport.c: Sending smb: smb_len=252
2023-12-22T11:58:37.252865+01:00 alainpc kernel: [10807.418048] CIFS: 
fs/smb/client/connect.c: RFC1002 header 0x134
2023-12-22T11:58:37.252887+01:00 alainpc kernel: [10807.418071] CIFS: 
fs/smb/client/smb2misc.c: SMB2 data length 114 offset 128
2023-12-22T11:58:37.252889+01:00 alainpc kernel: [10807.418076] CIFS: 
fs/smb/client/smb2misc.c: SMB2 len 242
2023-12-22T11:58:37.252892+01:00 alainpc kernel: [10807.418079] CIFS: 
fs/smb/client/smb2misc.c: length of negcontexts 60 pad 6
2023-12-22T11:58:37.252894+01:00 alainpc kernel: [10807.418086] CIFS: 
fs/smb/client/smb2ops.c: smb2_add_credits: added 1 credits total=1
2023-12-22T11:58:37.252895+01:00 alainpc kernel: [10807.418177] CIFS: 
fs/smb/client/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=64
2023-12-22T11:58:37.252897+01:00 alainpc kernel: [10807.418199] CIFS: 
fs/smb/client/misc.c: Null buffer passed to cifs_small_buf_release
2023-12-22T11:58:37.252899+01:00 alainpc kernel: [10807.418205] CIFS: 
fs/smb/client/smb2pdu.c: mode 0x3
2023-12-22T11:58:37.252902+01:00 alainpc kernel: [10807.418208] CIFS: 
fs/smb/client/smb2pdu.c: negotiated smb3.1.1 dialect
2023-12-22T11:58:37.252904+01:00 alainpc kernel: [10807.418218] CIFS: 
fs/smb/client/smb2pdu.c: decoding 2 negotiate contexts
2023-12-22T11:58:37.252907+01:00 alainpc kernel: [10807.418221] CIFS: 
fs/smb/client/smb2pdu.c: decode SMB3.11 encryption neg context of len 4
2023-12-22T11:58:37.252909+01:00 alainpc kernel: [10807.418224] CIFS: 
fs/smb/client/smb2pdu.c: SMB311 cipher type:2
2023-12-22T11:58:37.252910+01:00 alainpc kernel: [10807.418229] CIFS: 
fs/smb/client/connect.c: cifs_setup_session: channel connect bitmap: 0x1
2023-12-22T11:58:37.252931+01:00 alainpc kernel: [10807.418234] CIFS: 
fs/smb/client/connect.c: Security Mode: 0x3 Capabilities: 0x30005f TimeAdjust: 0

Bug#1059321: ITP: pylabels -- python library for creating PDFs to print sheets of labels

[Georges Khaznadar]

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

* Package name: pylabels
  Version : 1.2.1
  Upstream Contact: Blair Bonnett 
* URL : https://pypi.org/project/pylabels/
* License : GPL-3+
  Programming Lang: Python3
  Description : python library for creating PDFs to print sheets of labels

 pylabels uses the ReportLab PDF toolkit to produce the PDF.
 .
 Basically, the user creates a set of specifications of the label
 sizes etc, writes a callback function which does the actual drawing,
 and gives these two items to a Sheet object. Items are then added to
 the sheet using the add_label() method (or add_labels() to add all
 items from an iterable).

Pylabel enhances python3-reportlab since it makes easier for an author to
design label sheets. I already maintain the package python-reportlab, and I use
often features from pylabels.

This package is uploaded to https://salsa.debian.org/georgesk/pylabels.git

Bug#1059322: zfs-linux: CVE-2013-20001

[Moritz Mühlenhoff]

Source: zfs-linux
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for zfs-linux.

CVE-2013-20001[0]:
| An issue was discovered in OpenZFS through 2.0.3. When an NFS share
| is exported to IPv6 addresses via the sharenfs feature, there is a
| silent failure to parse the IPv6 address data, and access is allowed
| to everyone. IPv6 restrictions from the configuration are not
| applied.

https://github.com/openzfs/zfs/commit/6cb5e1e7591da20af3a15793e022345a73e40fb7 
(zfs-2.2.0-rc1)

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059320: libitext5-java: CVE-2021-37819

[Moritz Mühlenhoff]

Source: libitext5-java
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for PDfReader, which is
embedded in libitext5-java.

CVE-2021-37819[0]:
| PDF Labs pdftk-java v3.2.3 was discovered to contain an infinite
| loop via the component /text/pdf/PdfReader.java.

https://gitlab.com/pdftk-java/pdftk/-/merge_requests/21
https://gitlab.com/pdftk-java/pdftk/-/commit/75deacdf5c46fd4eefb310c784eb9dfdc7b9fdc9
 (v3.3.0)
https://gitlab.com/pdftk-java/pdftk/-/commit/9b0cbb76c8434a8505f02ada02a94263dcae9247
 (v3.3.0)

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059319: libitext1-java: CVE-2021-37819

[Moritz Mühlenhoff]

Source: libitext1-java
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for PdfReader, which is
embedded in libitext1-java.

CVE-2021-37819[0]:
| PDF Labs pdftk-java v3.2.3 was discovered to contain an infinite
| loop via the component /text/pdf/PdfReader.java.

https://gitlab.com/pdftk-java/pdftk/-/merge_requests/21
https://gitlab.com/pdftk-java/pdftk/-/commit/75deacdf5c46fd4eefb310c784eb9dfdc7b9fdc9
 (v3.3.0)
https://gitlab.com/pdftk-java/pdftk/-/commit/9b0cbb76c8434a8505f02ada02a94263dcae9247
 (v3.3.0)

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059318: libitext-java: CVE-2021-37819

[Moritz Mühlenhoff]

Source: libitext-java
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for PdfReader, which
is embedded by libitext-java.

CVE-2021-37819[0]:
| PDF Labs pdftk-java v3.2.3 was discovered to contain an infinite
| loop via the component /text/pdf/PdfReader.java.

https://gitlab.com/pdftk-java/pdftk/-/merge_requests/21
https://gitlab.com/pdftk-java/pdftk/-/commit/75deacdf5c46fd4eefb310c784eb9dfdc7b9fdc9
 (v3.3.0)
https://gitlab.com/pdftk-java/pdftk/-/commit/9b0cbb76c8434a8505f02ada02a94263dcae9247
 (v3.3.0)


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059317: r-cran-jsonlite: CVE-2023-33460

[Moritz Mühlenhoff]

Source: r-cran-jsonlite
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for yajl, which is embedded
by r-cran-jsonlite:

CVE-2023-33460[0]:
| There's a memory leak in yajl 2.1.0 with use of yajl_tree_parse
| function. which will cause out-of-memory in server and cause crash.

https://github.com/lloyd/yajl/issues/250

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059316: epics-base: CVE-2023-33460

[Moritz Mühlenhoff]

Source: epics-base
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for yajl, which is
embedded by epics-base:

CVE-2023-33460[0]:
| There's a memory leak in yajl 2.1.0 with use of yajl_tree_parse
| function. which will cause out-of-memory in server and cause crash.

https://github.com/lloyd/yajl/issues/250


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Moritz Mühlenhoff]

Source: tinyxml
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,
https://www.forescout.com/resources/sierra21-vulnerabilities
mentions three security issues in Tinyxml:

CVE-2023-34194[0]:
| StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in
| TinyXML through 2.6.2 has a reachable assertion (and application
| exit) via a crafted XML document with a '\0' located after
| whitespace.


CVE-2023-40462[1]:
| The ACEManager component of ALEOS 4.16 and earlier does not
| perform input sanitization during authentication, which could
| potentially result in a Denial of Service (DoS) condition for
| ACEManager without impairing other router functions. ACEManager
| recovers from the DoS condition by restarting within ten seconds of
| becoming unavailable.


CVE-2023-40458[2]:
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability
| in Sierra Wireless, Inc ALEOS could potentially allow a remote
| attacker to trigger a  Denial of Service (DoS) condition for
| ACEManager without impairing  other router functions. This condition
| is cleared by restarting the  device.


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-34194
https://www.cve.org/CVERecord?id=CVE-2023-34194
[1] https://security-tracker.debian.org/tracker/CVE-2023-40462
https://www.cve.org/CVERecord?id=CVE-2023-40462
[2] https://security-tracker.debian.org/tracker/CVE-2023-40458
https://www.cve.org/CVERecord?id=CVE-2023-40458

Please adjust the affected versions in the BTS as needed.

Bug#1059314: imagemagick-6.q16: please update "Suggests: imagemagick-doc" to imagemagick-6-doc

[Vincent Lefevre]

Package: imagemagick-6.q16
Version: 8:6.9.12.98+dfsg1-4
Severity: serious

The imagemagick-doc package is not longer built and has been replaced
by imagemagick-6-doc. So the "Suggests" should be updated.

Note that the current Suggests can prevent installations/upgrades if
suggested packages are installed by default, e.g. with --install-suggests
or APT::Install-Suggests set to true.

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
compare:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
convert:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
composite:  ImageMagick 6.9.12-98 Q16 x86_64 18038 
https://legacy.imagemagick.org
conjure:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
display:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
identify:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
import:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
mogrify:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
montage:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org
stream:  ImageMagick 6.9.12-98 Q16 x86_64 18038 https://legacy.imagemagick.org

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 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 imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.37-13
ii  libmagickcore-6.q16-7  8:6.9.12.98+dfsg1-4
ii  libmagickwand-6.q16-7  8:6.9.12.98+dfsg1-4

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  10.02.1~dfsg-1
ii  libmagickcore-6.q16-7-extra  8:6.9.12.98+dfsg1-4
ii  netpbm   2:11.04.05-2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.4.7-1
ii  curl 8.5.0-1
pn  enscript 
pn  ffmpeg   
ii  fig2dev [transfig]   1:3.2.9-3
ii  gimp 2.10.36-2
ii  gnuplot-qt [gnuplot] 5.4.4+dfsg1-2+b2
pn  grads
ii  graphviz 2.42.2-7+b3
ii  groff-base   1.23.0-3
pn  hp2xx
pn  html2ps  
pn  imagemagick-doc  
pn  libraw-bin   
ii  libwmf-bin   0.2.13-1.1
pn  mplayer  
pn  povray   
pn  radiance 
ii  sane-utils   1.2.1-7
ii  texlive-binaries [texlive-base-bin]  2023.20230311.66589-8
ii  xdg-utils1.1.3-4.1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1059313: libxml-security-java: CVE-2023-44483

[Moritz Mühlenhoff]

Source: libxml-security-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libxml-security-java.

CVE-2023-44483[0]:
| All versions of Apache Santuario - XML Security for Java prior to
| 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable
| to an issue where a private key may be disclosed in log files when
| generating an XML Signature and logging with debug level is
| enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4,
| or 3.0.3, which fixes this issue.

https://www.openwall.com/lists/oss-security/2023/10/20/5
https://lists.apache.org/thread/vmqbp9mfxtrf0kmbnnmbn3h9j6dr9q55
https://santuario.apache.org/secadv.data/CVE-2023-44483.txt.asc


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059312: libcrypto++: CVE-2023-50981

[Moritz Mühlenhoff]

Source: libcrypto++
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcrypto++.

CVE-2023-50981[0]:
| ModularSquareRoot in Crypto++ (aka cryptopp) through 8.9.0 allows
| attackers to cause a denial of service (infinite loop) via crafted
| DER public-key data associated with squared odd numbers, such as the
| square of 268995137513890432434389773128616504853.

https://github.com/weidai11/cryptopp/issues/1249


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059311: libcrypto++: CVE-2023-50980

[Moritz Mühlenhoff]

Source: libcrypto++
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcrypto++.

CVE-2023-50980[0]:
| gf2n.cpp in Crypto++ (aka cryptopp) through 8.9.0 allows attackers
| to cause a denial of service (application crash) via DER public-key
| data for an F(2^m) curve, if the degree of each term in the
| polynomial is not strictly decreasing.

https://github.com/weidai11/cryptopp/issues/1248

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059310: libcrypto++: CVE-2023-50979

[Moritz Mühlenhoff]

Source: libcrypto++
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcrypto++.

CVE-2023-50979[0]:
| Crypto++ (aka cryptopp) through 8.9.0 has a Marvin side channel
| during decryption with PKCS#1 v1.5 padding.

https://github.com/weidai11/cryptopp/issues/1247


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059309: libcrypto++: CVE-2022-48570

[Moritz Mühlenhoff]

Source: libcrypto++
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcrypto++.

CVE-2022-48570[0]:
| Crypto++ through 8.4 contains a timing side channel in ECDSA
| signature generation. Function FixedSizeAllocatorWithCleanup could
| write to memory outside of the allocation if the allocated memory
| was not 16-byte aligned. NOTE: this issue exists because the
| CVE-2019-14318 fix was intentionally removed for functionality
| reasons.

https://github.com/weidai11/cryptopp/issues/992


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

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

[Moritz Mühlenhoff]

Source: python-cryptography
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for python-cryptography.

CVE-2023-50782[0]:
Bleichenbacher timing oracle attack against RSA decryption - incomplete fix for 
CVE-2020-25659

https://github.com/pyca/cryptography/issues/9785
https://people.redhat.com/~hkario/marvin/


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1059307: ring: CVE-2023-38703

[Moritz Mühlenhoff]

Source: ring
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for pjsig, which is
bundled in ring:

CVE-2023-38703[0]:
| PJSIP is a free and open source multimedia communication library
| written in C with high level API in C, C++, Java, C#, and Python
| languages. SRTP is a higher level media transport which is stacked
| upon a lower level media transport such as UDP and ICE. Currently a
| higher level transport is not synchronized with its lower level
| transport that may introduce use-after-free issue. This
| vulnerability affects applications that have SRTP capability
| (`PJMEDIA_HAS_SRTP` is set) and use underlying media transport other
| than UDP. This vulnerability’s impact may range from unexpected
| application termination to control flow hijack/memory corruption.
| The patch is available as a commit in the master branch.

https://github.com/pjsip/pjproject/security/advisories/GHSA-f76w-fh7c-pc66
https://github.com/pjsip/pjproject/commit/6dc9b8c181aff39845f02b4626e0812820d4ef0d
 (2.14)

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.