Bug#1061213: [Pkg-opencl-devel] Bug#1061213: Please upgrade to llvm-toolchain-17

[Timo Aaltonen]

Sylvestre Ledru kirjoitti 20.1.2024 klo 23.03:

Source: intel-graphics-compiler
Severity: important

Dear Maintainer,

As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -17.

This package depends on 14.

Thanks,
Sylvestre


according to upstream, 14 is the current one they support

https://github.com/intel/intel-graphics-compiler/projects/5


and the latest version doesn't even build with llvm 16, let alone 17.


--
t

Bug#1061468: gloo: attempts to build on unsupported 32 bit systems

[Paul Wise]

On Wed, 2024-01-24 at 23:59 +, Dan Bungert wrote:

> I suggest adjusting the control file to reflect this state so that
> builds are only attempted on 64 bit systems. Something like this
> should work.

The right way to do this is to Build-Depend: architecture-is-64-bit, so 
that when new 64-bit architectures are introduced no changes are needed.
This is a virtual package that gets provided by the binary package called
architecture-properties on the architectures that are 64-bit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1061479: mk-origtargz: support lz compression

[Andrius Merkys]

Package: devscripts
Version: 2.23.7
Severity: wishlist

Dear Maintainers,

I am maintaining ocrad package which recently has switched to shipping 
its tarballs compressed with lz (ocrad-0.29.tar.lz). 'tar.lz' files are 
identified by 'file' as 'application/x-lzip' and seamlessly extracted by 
'tar'. However, 'tar_regex' in 
/usr/share/perl5/Devscripts/MkOrigtargz/Config.pm does not allow 
'tar.lz', albeit it includes 'tlz'. If renamed to 'tlz', the archive is 
again refused to be processed as '%mime2comp' in 
/usr/share/perl5/Devscripts/Compression.pm does not contain 
'application/x-lzip'. I tried adding 'application/x-lzip' to 
'%mime2comp', but then ran into "uscan: error: tar is not a supported 
compression" error and gave up.


Could you please give a look at implementing support for lz compression 
in mk-origtargz?


Best wishes,
Andrius

Bug#1060973: Reduce severity since it is not reproducible

[Andreas Tille]

Control: severity -1 important

Bug#1061296: syncthing version is treated as beta

[Simon Frei]

On 22/01/2024 11:44, Thomas Butz wrote:

Syncthing treats versions with a "-" as beta builds:
I think it's anything after the semver-like part that some pattern 
doesn't recognize.

This might have unintended consequences.
It most definitely does - it enabled deadlock detection (was removed 
recently) and usage-reporting.


I thought that was fixed a while ago and when building in debian, you 
pass `-version not. That's the way to go though for the best experience/expected 
behaviour: Full debian version for the package and upstream version for 
the build script.

Bug#1055329: Offer of support/assistance

[Jeremy Davis]

Hi Alexandre,

My name is Jeremy and I'd like to offer you my support and assistance in 
your efforts to package and maintain AdminerEvo if that's of any use to you?


FWIW I am a core developer in a Debian derivative project named TurnKey 
Linux[1][2].


[1] https://wiki.debian.org/Derivatives/Census/TurnKeyLinux
[2] https://www.turnkeylinux.org/

We currently use Adminer (as packaged by you) in many of our "software 
appliances" - e.g. our LAMP appliance[3].


[3] https://www.turnkeylinux.org/lamp

I only just realised that upstream seems to have abandoned it and I 
finally managed to find my way here...


For background and context, as part of my role in TurnKey, I maintain an 
apt repo[4] for our custom packages.


[4] http://archive.turnkeylinux.org/

I'm certainly no packaging expert and have never been involved in formal 
Debian packaging before. My plan has always been to get more involved in 
Debian packaging and perhaps even bring some of our custom packages into 
Debian too. Unfortunately, I've never made the time (we're a small team 
with 100+ appliances)...


I must admit that my packaging knowledge is quite adhoc, with lots of 
gaps I am sure. Also, maintaining our own repo (and never being involved 
with official Debian packages) means that I probably have some bad 
practices...


Helping an experienced maintainer with a single package such as this, 
seems like a good way to learn the ropes and contribute something back 
directly to Debian.


So if you are open to and/or desire some assistance, I'd be glad to help 
(and learn a bit...). If not, that's fine too.


Take care and thanks for your contributions to Debian.

Warm Regards,
Jeremy


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Rene Engelhard]

tag 1020482 + pending
thanks

Am 24.01.24 um 23:44 schrieb Soren Stoutner:

Control: tags -1 + patch


I submitted an MR at:


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/-/merge_requests/6
 




Merged (and uploaded after fixing the changelog)

Regards,

Rene

Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package

[Jeremy Davis]

Dear Alexandre (adminer maintainer),

As per Ondřej's note below, with regards to MySQL support, from a glance 
through the source code (adminer/drivers/mysql.inc.php) it seems that 
adminer should depend on php-mysql (real metapackage) OR php-mysqli 
(virtual package provided by real phpX.Y-mysql package - i.e. currently 
php8.2-mysql).


On 25/1/24 16:05, Ondřej Surý wrote:

The extension package provide names of the extensions actually provided by the 
said package. “mysql” extension has been removed from PHP a quite a while ago 
and is not provided by php8.2-mysql package. (Similar situation can be found in 
php8.2-xml package.)

This needs to be fixed in the adminer, so it actually depends on an extension 
it actually uses.

Ondrej
--
Ondřej Surý (He/Him)



Please find a patch attached to resolve this issue - #1061469. Hopefully 
I got it right?


If you would prefer me to open a merge request on Salsa, please let me 
know and I'll do that instead (I don't have a salsa account but AFAIK 
it's relatively straight forward to get one).


Regards,
Jeremy

PS Actually, I've just noticed #1054574 & #1055329 - IMO it's probably 
not worth applying this and just move on with AdminerEvo!?
diff --git a/debian/control b/debian/control
index d6f56f0..58d1d56 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Package: adminer
 Architecture: all
 Depends:
  libapache2-mod-php | php-cgi | php-fpm | php,
- php-mysql | php-sqlite3 | php-pgsql,
+ php-mysql | php-mysqli | php-sqlite3 | php-pgsql,
  ${misc:Depends},
 Recommends:
  php-cli,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061468: gloo: attempts to build on unsupported 32 bit systems

[Petter Reinholdtsen]

[Dan Bungert]
> I suggest adjusting the control file to reflect this state so that
> builds are only attempted on 64 bit systems.

Why?  Which problem are you trying to solve?  Doing such change will
fail to automatically discover if gloo start working on other
architectures, and require extra work to keep the list of architectures
up to date as Debian evolves.  As far as I can see, the disadvantage of
trying to build on non-supported architectures is a few wasted CPU
cycles, while the advantage is less human time spent on package
maintenance.  Did I miss something?  To me, saving humans time is more
valuable than saving CPU time.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1060026: yade: please move away from python3-future

[Andreas Tille]

Hi Anton,

to avoid some race condition:  I'm just applying the patch and try
to build.  I'll let you know about success or failure.

Kind regards
Andreas.

Am Wed, Jan 24, 2024 at 10:13:03PM +0100 schrieb Alexandre Detiste:
> control: tag -1 +patch
> 
> Hi,
> 
> Here's a patch.
> 
> I didn't try to be smart, just to get this done.
> 
> I have seen this package takes hours to build
> on buildd so I'm not even trying on my old fanless
> NUC knockoff.
> 
> Greetings

> diff --git a/core/main/main.py.in b/core/main/main.py.in
> index b8a52ca..11bc619 100644
> --- a/core/main/main.py.in
> +++ b/core/main/main.py.in
> @@ -2,8 +2,11 @@
>  # encoding: utf-8
>  # syntax:python
>  
> -from __future__ import print_function
> -from past.builtins import execfile
> +def execfile(filename, myglobals=None, mylocals=None):
> +with open(filename, "rb") as fin:
> + source = fin.read()
> +code = compile(source, filename, "exec")
> +exec(code)
>  
>  import sys,os,os.path,time
>  try:
> diff --git a/core/main/yade-batch.in b/core/main/yade-batch.in
> index 1d128ef..5b58cd6 100755
> --- a/core/main/yade-batch.in
> +++ b/core/main/yade-batch.in
> @@ -4,12 +4,6 @@
>  # vim: syntax=python
>  # portions © 2008 Václav Šmilauer 
>  
> -from __future__ import print_function
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
> -from builtins import object
>  import os, sys, _thread, time, logging, pipes, socket, xmlrpc.client, re, 
> shutil, random
>  
>  # Add search path for yade Python-modules
> diff --git a/core/main/yade-oar.in b/core/main/yade-oar.in
> index d96b60d..b8eb705 100644
> --- a/core/main/yade-oar.in
> +++ b/core/main/yade-oar.in
> @@ -7,12 +7,6 @@
>  # This script is to be used with OAR task scheduler. May be an example to 
> use use with other task scheduler for clusters
>  # Adapted from yade-batch
>  
> -from __future__ import print_function
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
> -from builtins import object
>  import os, sys, _thread, time, logging, pipes, socket, xmlrpc.client, re, 
> shutil, random
>  
>  # Add search path for yade Python-modules
> diff --git a/doc/sphinx/conf.py b/doc/sphinx/conf.py
> index 001bc1a..548ed88 100644
> --- a/doc/sphinx/conf.py
> +++ b/doc/sphinx/conf.py
> @@ -21,11 +21,6 @@
>  ##
>  ## http://docutils.sourceforge.net/docs/howto/rst-roles.html
>  
> -from __future__ import print_function
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
>  import sys, os, re
>  from docutils import nodes
>  from sphinx import addnodes
> diff --git a/doc/sphinx/ipython_directive.py b/doc/sphinx/ipython_directive.py
> index 816d1bf..4cbcaee 100644
> --- a/doc/sphinx/ipython_directive.py
> +++ b/doc/sphinx/ipython_directive.py
> @@ -51,18 +51,11 @@ Authors
>  - Fernando Perez: refactoring, documentation, cleanups.
>  - VáclavŠmilauer : Prompt generatlizations.
>  """
> -from __future__ import print_function
> -
>  
> #-
>  # Imports
>  
> #-
>  
>  # Stdlib
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
> -from builtins import object
>  import io
>  import imp
>  import os
> diff --git a/doc/sphinx/ipython_directive012.py 
> b/doc/sphinx/ipython_directive012.py
> index c98ecd4..14e7cce 100644
> --- a/doc/sphinx/ipython_directive012.py
> +++ b/doc/sphinx/ipython_directive012.py
> @@ -51,18 +51,11 @@ Authors
>  - VáclavŠmilauer : Prompt generalizations.
>  - Skipper Seabold, refactoring, cleanups, pure python addition
>  """
> -from __future__ import print_function
> -
>  
> #-
>  # Imports
>  
> #-
>  
>  # Stdlib
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
> -from builtins import object
>  import io
>  import os
>  import re
> diff --git a/doc/sphinx/ipython_directive013.py 
> b/doc/sphinx/ipython_directive013.py
> index c606acd..8f68221 100644
> --- a/doc/sphinx/ipython_directive013.py
> +++ b/doc/sphinx/ipython_directive013.py
> @@ -52,18 +52,11 @@ Authors
>  - VáclavŠmilauer : Prompt generalizations.
>  - Skipper Seabold, refactoring, cleanups, pure python addition
>  """
> -from __future__ import print_function
> -
>  
> #-
>  # Imports
>  
> #-
>  
>  # Stdlib
> -from future import standard_library
> -standard_library.install_aliases()
> -
> -from builtins import range
> -from builtins import object
>  

Bug#996647: xdg-email with KDE and Thunderbird

[Шлыков Василий]

I believe this bug due to bug in open_kde function in xdg-email file.

kreadconfig5 reports that configured "thunderbird.desktop" tool. 
Obviously this is not a executable file.


This cound be fixed by adding one line to xdg-email:

if echo "$client" | grep -Eq 'thunderbird|icedove'; then
this line > client=`desktop_file_to_binary "$client"`
run_thunderbird "$client" "$1"
fi

Best regards
Vasiliy Shlykov

Bug#996647: xdg-utils: xdg-email fails with Thunderbind

[Vasiliy Shlykov]

Package: xdg-utils
Version: 1.1.3-4.1
Followup-For: Bug #996647

Dear Maintainer,

xdg-email with Thunderbird as default email tools fails.

xdg-email reports on start:
$ xdg-email:
/usr/bin/xdg-email: 599: thunderbird.desktop: not found



-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=KDE

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.33-1
ii  libnet-dbus-perl   1.2.0-2
ii  libx11-protocol-perl   0.56-9
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+9+b1

xdg-utils suggests no packages.

-- no debconf information

Bug#1059782: mesa-vdpau-drivers: Upgrade to 23.3.* breaks video rendering in tkinter

[Vasyl Gello]

Control: retitle -1: Upgrade to 23.3.* breaks video rendering
Control: severity -1 serious

Dear colleagues,

Yesterday the update reached testing and it completely destroys VA-API 
rendering with Kodi.
Any video file played with VA-API hardware acceleration results in black screen 
with no additional
error messages on Kodi log. Reverting the mesa packages to 23.2.1-1 (and 
installing back libllvm16)
restores the correct behavior.

I am investigating the root cause of the regression and will report it
once I find one.

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1061478: apt: Internal Error, AutoRemover broke stuff, unmet dependencies: linux-headers-6.6.9-amd64

[greg]

Package: apt
Version: 2.7.10
Severity: normal
X-Debbugs-Cc: gre...@gmx.de

Make update everey day (as sudo):

apt update
apt full-upgrade

mm, seems like the AutoRemover destroyed something which really
shouldn't happen. Please file a bug report against apt.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-6.6.9-amd64 : Depends: linux-image-6.6.9-amd64 (= 6.6.9-1+b1)
but it is not installable or
  linux-image-6.6.9-amd64-unsigned (=
6.6.9-1+b1) but it is not going to be installed
E: Internal Error, AutoRemover broke stuff


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts 

Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package

[Jeremy Davis]

reassign 1061469 adminer 4.8.1-1
retitle 1061469 Adminer only depends on php-mysql
thanks

Thank you Ondřej! :)

On 25/1/24 16:05, Ondřej Surý wrote:

The extension package provide names of the extensions actually provided by the 
said package. “mysql” extension has been removed from PHP a quite a while ago 
and is not provided by php8.2-mysql package. (Similar situation can be found in 
php8.2-xml package.)


That makes sense.



This needs to be fixed in the adminer, so it actually depends on an extension 
it actually uses.



Hopefully I have reassigned correctly? I followed the instructions noted 
on this[2] page. (TBH, I'm not very familiar with Debian BT)


[2] https://www.debian.org/Bugs/server-control


Ondrej
--
Ondřej Surý (He/Him)


Thanks again.

Regards,
Jeremy


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061477: Use js as first file name suffix for text/javascript

[Maxim Nikulin]

Package: media-types
Version: 10.0.0

Currently /etc/mime.types has .es as first suffix associated with the 
text/javascript media type


text/javascript es js mjs

I suggest to put the "es" extension last, or perhaps even to add 
text/ecmascript record for it. It would allow to avoid accidents like


python3 -c 'import mimetypes; 
print(mimetypes.guess_extension("text/javascript"))'

.es

Certainly I expect the ".js" result.

My reading of RFC 9239 Updates to ECMAScript Media Types
https://datatracker.ietf.org/doc/rfc9239/
is that ".es" is associated with the obsolete media type 
text/ecmascript, but not with text/javascript.


In Fedora /etc/mime.types has a record for text/ecmascript
https://pagure.io/mailcap/blob/master/f/mime.types#_137

XDG shared-mime-info has the application/ecmascript entry as well
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/data/freedesktop.org.xml.in?ref_type=heads#L1948

I believe that obsolete mappings still have some value.

Please, consider

text/javascript js mjs
text/ecmascript es

or at least

text/javascript js mjs es

Bug#1061432: Add OrangePI PC Plus to sunxi platforms

[Лухнов Андрей Олегович]

Vagrant,

I, eventually, will be able to perform basic tests, at least as long as our org 
is producing Orange PC Plus-based devices.
I should have included contact info in the debian/targets.mk file, sorry.

Here is my contact address: Andrey Loukhnov 

Best,
Andrey

P.S.: my previous mail did not make it to the BTS for unknown reason, sorry for 
spam if both will arrive someday ;)

- Original Message -
From: "Vagrant Cascadian" 
To: "Андрей Лухнов" , 1061...@bugs.debian.org
Sent: Wednesday, January 24, 2024 8:27:25 PM
Subject: Re: Bug#1061432: Add OrangePI PC Plus to sunxi platforms

On 2024-01-24, Лухнов Андрей Олегович wrote:
> please consider adding OrangePI PC Plus to sunxi platforms. Changes
> are trivial, proposed platform is buildable without errors and tested
> bootable on target hardware.
>
> Required changes attached.

Would you or someone else be willing to regularly test new versions of
u-boot as they land in the archive?

  https://wiki.debian.org/U-boot/Status

I prefer to list at least one person with contact information in the
debian/targets.mk file so we know who to ask if problems arise.

Because it supports over a thousand boards, board-specific regressions
are unfortunately all too common in u-boot and it is helpful to find
those regressions early.

live well,
  vagrant

Bug#1061476: transition: elpi

[julien . puydt]

Package: release.debian.org
Usertags: transition
X-Debbugs-Cc: jpu...@debian.org
Severity: normal

there is a new upstream for elpi in the OCaml packages, which has an
impact on a few Coq packages.

I checked locally (using sbuild in a chroot) everything could move
fine.

Several packages need a new version and then some need just a rebuild.
A ben description of the plan is in post scriptum.

Waiting for your ACK to upload the new packages sources.

Thanks,

J.Puydt

PS:
 dw coq-elpi 2.0.0-1 . ANY . -m 'elpi >= 1.18.1-1'
 dw coq-hierarchy-builder_1.7.0-1 . ANY . -m 'coq-elpi >= 2.0.0-1'
 dw ssreflect_2.2.0-1 . ANY . -m 'coq-hierarchy-builder >= 1.7.0-1'
 dw coq-relation-algebra_1.7.10-1 . ANY . -m 'ssreflect >= 2.2.0-1'
 dw mathcomp-finmap_2.1.0-1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu coq-deriving_0.2.0-1+b1 . ANY . -m 'Rebuild because of upload of
ssreflect=2.2.0-1'
 dw coq-deriving_0.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu coq-reglang_1.2.1-1+b1 . ANY . -m 'Rebuild because of upload of
ssreflect=2.2.0-1'
 dw coq-reglang_1.2.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu coquelicot_3.4.1-1+b1 . ANY . -m 'Rebuild because of upload of
ssreflect=2.2.0-1'
 dw coquelicot_3.4.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'Rebuild because of
upload of ssreflect=2.2.0-1'
 dw mathcomp-bigenough_1.0.1-12+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'Rebuild because of
upload of ssreflect=2.2.0-1'
 dw mathcomp-zify_1.5.0+2.0+8.16-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu coq-quickchick_2.0.2-1+b1 . ANY . -m 'Rebuild because of upload of
ssreflect=2.2.0-1'
 dw coq-quickchick_2.0.2-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 nmu coq-extructures_0.4.0-1+b1 . ANY . -m 'Rebuild because of upload
of ssreflect=2.2.0-1 coq-deriving=0.2.0-1+b1'
 dw coq-extructures_0.4.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 dw coq-extructures_0.4.0-1+b1 . ANY . -m 'coq-deriving >= 0.2.0-1+b1'
 nmu coq-interval_4.9.0-1+b2 . ANY . -m 'Rebuild because of upload of
ssreflect=2.2.0-1 coquelicot=3.4.1-1+b1'
 dw coq-interval_4.9.0-1+b2 . ANY . -m 'ssreflect >= 2.2.0-1'
 dw coq-interval_4.9.0-1+b2 . ANY . -m 'coquelicot >= 3.4.1-1+b1'
 nmu mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'Rebuild because of
upload of ssreflect=2.2.0-1 mathcomp-zify=1.5.0+2.0+8.16-1+b1 coq-
elpi=2.0.0-1'
 dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'ssreflect >= 2.2.0-
1'
 dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'mathcomp-zify >=
1.5.0+2.0+8.16-1+b1'
 dw mathcomp-algebra-tactics_1.2.3-1+b1 . ANY . -m 'coq-elpi >= 2.0.0-
1'
 nmu mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'Rebuild because of
upload of ssreflect=2.2.0-1 mathcomp-finmap=2.1.0-1 mathcomp-
bigenough=1.0.1-12+b1'
 dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-finmap >=
2.1.0-1'
 dw mathcomp-multinomials_2.2.0-1+b1 . ANY . -m 'mathcomp-bigenough >=
1.0.1-12+b1'
 nmu mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'Rebuild because of
upload of ssreflect=2.2.0-1 mathcomp-bigenough=1.0.1-12+b1'
 dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'
 dw mathcomp-real-closed_2.0.0-1+b1 . ANY . -m 'mathcomp-bigenough >=
1.0.1-12+b1'
 nmu coqeal_2.0.1-1+b1 . ANY . -m 'Rebuild because of upload of
mathcomp-real-closed=2.0.0-1+b1 ssreflect=2.2.0-1'
 dw coqeal_2.0.1-1+b1 . ANY . -m 'mathcomp-real-closed >= 2.0.0-1+b1'
 dw coqeal_2.0.1-1+b1 . ANY . -m 'ssreflect >= 2.2.0-1'

Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package

[Ondřej Surý]

The extension package provide names of the extensions actually provided by the 
said package. “mysql” extension has been removed from PHP a quite a while ago 
and is not provided by php8.2-mysql package. (Similar situation can be found in 
php8.2-xml package.)

This needs to be fixed in the adminer, so it actually depends on an extension 
it actually uses.

Ondrej
--
Ondřej Surý (He/Him)

> On 25. 1. 2024, at 1:57, Jeremy Davis  wrote:
> 
> Package: php8.2-mysql
> Version: 8.2.7-1~deb12u1
> Severity: normal
> 
> Dear Maintainer/s,
> 
> Whilst I am reporting this against the php8.2-mysql package in bookworm, it 
> applies equally to any/all phpX.Y-mysql packages (where X.Y is the PHP 
> version) including packages from older stables, as well as trixie and sid - 
> from the 'php' source package. As it also applies to the packages in trixie 
> and sid (Version: 8.2.12-1+b1), perhaps I should be explicitly reporting it 
> against that version instead?
> 
> As an aside (perhaps irrelevant here?), this also applies to the packages 
> provided by Ondřej Surý via his deb.sury.org repo - whom I note is a member 
> of the Debian PHP Maintainers Team (hence why mentioning it). Perhaps I 
> should lodge a separate issue directly with him as well?
> 
> 
> The issue
> -
> 
> I note that the phpX.Y-mysql package does not provide a php-mysql virtual 
> package!?
> 
> I can see that it does provide php-mysqli, php-mysqlnd & php-pdo-mysql (as 
> well as phpX.Y-mysqli, phpX.Y-mysqlnd & phpX>Y-pdo-mysql) virtual packages, 
> but not php-mysql?! E.g.:
> 
> Package: php8.2-mysql
> Version: 8.2.7-1~deb12u1
> [...]
> Provides: php-mysqli, php-mysqlnd, php-pdo-mysql, php8.2-mysqli,
>  php8.2-mysqlnd, php8.2-pdo-mysql
> [...]
> 
> I note that the other PHP DB related packages (i.e. phpX.Y-pgsql & 
> phpX.Y-sqlite3) DO provide their counterpart unversioned virtual packages 
> (i.e. php-pgsql & php-sqlite3). For example:
> 
> Package: php8.2-sqlite3
> Version: 8.2.7-1~deb12u1
> [...]
> Provides: php-pdo-sqlite, php-sqlite3, php8.2-pdo-sqlite
> [...]
> 
> If nothing else, this seems inconsistent behaviour.
> 
> Obviously this is no problem whilst using only packages from a stable Debian 
> release. However, in my experience, it is quite common for unpackaged PHP 
> apps (installed direct from upstream source) to require a newer PHP version 
> than that provided in stable (e.g. newer PHP from deb.sury.org).
> 
> It's less of an issue currently as bookworm has the relatively new PHP8.2. It 
> was a bigger issue in bullseye as that had 7.4 fairly late in it's lifecycle.
> 
> If using an alternate version of PHP, Debian packages that depend on 
> php-mysql (e.g. adminer[1]) will always pull in the default versioned PHP 
> package from Debian as well (or latest PHP from sury.org - depending on 
> pinning). I.e. php8.2-mysql if Debian repos are preferred (or the latest PHP 
> version with deb.sury.org).
> 
> [1] https://packages.debian.org/bookworm/adminer
> 
> I acknowledge that supporting this scenario (installing PHP from third party 
> repo and still using one or more PHP apps from Debian) may not be explicitly 
> considered a "normal" Debian issue (so perhaps a "wishlist" item?).
> 
> I also get that the ~500kB may not be that big a deal to some, but IMO it'd 
> be nice to not have to have redundant unused packages installed.
> 
> Further, I understand that the packaged PHP apps (from stable repo) may not 
> be (completely or at all) compatible with a newer PHP version, but IMO that's 
> on users such as myself to resolve, workaround or live with.
> 
> Resolution?
> ---
> 
> Regardless, on face value, it seems to me that if the versioned package 
> (php8.2-mysql) simply provided the php-mysql package virtually this situation 
> would be resolved. Or am I missing something fundamental?
> 
> FWIW I had intended to attach a patch for the php source ('debian/main/8.2' 
> branch) for your consideration, but it's a much more complex package than I 
> have encountered before and I'm not really clear what might be required to 
> achieve what I am requesting/suggesting. With some guidance I'd be more than 
> happy to provide a patch and/or open a merge request on salsa (and/or 
> elsewhere).
> 
> If there is a preferred alternate path to resolve this that I can assist 
> with, please inform me.
> 
> Thank you for your consideration and/or guidance.
> 
> Regards,
> Jeremy
> 
> -- Package-specific info:
>  Additional PHP 8.2 information 
> 
>  PHP @PHP_VERSION SAPI (php8.2query -S): 
> 
>  PHP 8.2 Extensions (php8.2query -M -v): 
> 
>  Configuration files: 
>  /etc/php/8.2/mods-available/mysqlnd.ini 
> extension=mysqlnd.so
> 
>  /etc/php/8.2/mods-available/mysqli.ini 
> extension=mysqli.so
> 
>  /etc/php/8.2/mods-available/pdo_mysql.ini 
> extension=pdo_mysql.so
> 
> 
> -- System Information:
> Debian Release: 12.4
>  APT prefers stable-security
>  APT policy: (500, 

Bug#1061475: icmake: version 11.01.01 FTBFS on 32-bit architectures

[tony mancill]

Source: icmake
Version: 11.01.01-1
Severity: important

Filing this bug for visibility.  The upstream author is aware of the
issue.  The latest version FTBFS on 32-bit architectures.

Refer to https://buildd.debian.org/status/package.php?p=icmake and
https://buildd.debian.org/status/fetch.php?pkg=icmake=i386=11.01.01-1=1706141080=0
for logs.

Bug#1061474: netpanzer: Master Server Outdated - Game Unplayable

[Devon Winrick]

Package: netpanzer
Version: 0.8.7+ds-4
Severity: important
X-Debbugs-Cc: win...@gmail.com

Dear Maintainer,

With the current state of this package, the game is not playable online. This
is due to the master server being down, since the previous server owner has
passed away.

To reproduce, attempt to open the game and go to the server browser. No games
will be shown, despite there being several 0.8.7 servers available (which
myself and others run).

Luckily we obtained the server source code before their passing, and have setup
a new master server at netpanzer.io

We have a patch, which is to prepend "netpanzer.io" to the server_masterservers
string on line 367 of GameConfig.cpp:
https://github.com/netpanzer/netpanzer/compare/master...0.8.7-patched#diff-820a2ec5629a945d19a0b9ac1ba49532fc3e876c17e64ac42eb8344ab044e5f0R367

We have committed to running this master server indefinitely.

Thank you for your time!


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

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

Versions of packages netpanzer depends on:
ii  libc62.35-0ubuntu3.1
ii  liblua5.1-0  5.1.5-8.1build4
ii  libphysfs1   3.0.2-5
ii  libsdl-mixer1.2  1.2.12-17build1
ii  libsdl1.2debian  1.2.15+dfsg2-6
ii  libstdc++6   12.3.0-1ubuntu1~22.04
ii  netpanzer-data   0.8.7+ds-4

netpanzer recommends no packages.

Versions of packages netpanzer suggests:
pn  xqf  

-- no debconf information

Bug#1061473: bookworm-pu: package tinyxml/2.6.2-6+deb12u1

[Guilhem Moulin]

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

[ Reason ]

Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.

The issue has been fixed in buster LTS as well as sid (via NMU).  The
security team argued it didn't warrant a DSA, and suggested to go via
s-pu instead.

[ Impact ]

Buster users will regress when upgrading to bookworm.

[ Tests ]

The vulnerability report came with POCs which was checked against.

[ Risks ]

The patch is trivial but tinyxml appears to be abandoned upstream so I
wrote it myself.

[ Checklist ]

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

[ Changes ]

Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.

-- 
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2

 changelog|9 +
 patches/CVE-2023-34194.patch |   27 +++
 patches/series   |1 +
 3 files changed, 37 insertions(+)

diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog  2021-12-12 23:53:05.0 +0100
+++ tinyxml-2.6.2/debian/changelog  2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-6+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2023-34194 / CVE-2023-40462: Reachable assertion (and application
+exit) via a crafted XML document with a '\0' located after whitespace.
+(Closes: #1059315)
+
+ -- Guilhem Moulin   Thu, 25 Jan 2024 04:27:36 +0100
+
 tinyxml (2.6.2-6) unstable; urgency=medium
 
   * Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch   1970-01-01 
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch   2024-01-25 
04:27:36.0 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin 
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
 b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p, 
TiXmlParsingData* data, TiXm
+   }
+ 
+   p = SkipWhiteSpace( p, _encoding );
++  if ( !p || !*p )
++  {
++  break;
++  }
+   if ( StringEqual( p, "version", true, _encoding ) )
+   {
+   TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series 
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2021-12-12 23:48:07.0 +0100
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:27:36.0 +0100
@@ -1,3 +1,4 @@
 enforce-use-stl.patch
 entity-encoding.patch
 CVE-2021-42260.patch
+CVE-2023-34194.patch


signature.asc
Description: PGP signature

Bug#1061472: bullseye-pu: package tinyxml/2.6.2-4+deb11u2

[Guilhem Moulin]

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

[ Reason ]

Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.

The issue has been fixed in buster LTS as well as sid (via NMU).  The
security team argued it didn't warrant a DSA, and suggested to go via
s-pu instead.

[ Impact ]

Buster users will regress when upgrading to bullseye.

[ Tests ]

The vulnerability report came with POCs which was checked against.

[ Risks ]

The patch is trivial but tinyxml appears to be abandoned upstream so I
wrote it myself.

[ Checklist ]

  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in oldstable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Fix CVE-2023-34194: Reachable assertion (and application exit) via a
crafted XML document with a '\0' located after whitespace.

-- 
Guilhem.
diffstat for tinyxml-2.6.2 tinyxml-2.6.2

 changelog|9 +
 patches/CVE-2023-34194.patch |   27 +++
 patches/series   |1 +
 3 files changed, 37 insertions(+)

diff -Nru tinyxml-2.6.2/debian/changelog tinyxml-2.6.2/debian/changelog
--- tinyxml-2.6.2/debian/changelog  2022-10-20 16:32:51.0 +0200
+++ tinyxml-2.6.2/debian/changelog  2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,12 @@
+tinyxml (2.6.2-4+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2023-34194 / CVE-2023-40462: Reachable assertion (and application
+exit) via a crafted XML document with a '\0' located after whitespace.
+(Closes: #1059315)
+
+ -- Guilhem Moulin   Thu, 25 Jan 2024 04:12:05 +0100
+
 tinyxml (2.6.2-4+deb11u1) bullseye; urgency=medium
 
   * Import fix for CVE-2021-42260.
diff -Nru tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch 
tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch
--- tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch   1970-01-01 
01:00:00.0 +0100
+++ tinyxml-2.6.2/debian/patches/CVE-2023-34194.patch   2024-01-25 
04:12:05.0 +0100
@@ -0,0 +1,27 @@
+From: Guilhem Moulin 
+Date: Sat, 30 Dec 2023 14:15:54 +0100
+Subject: Avoid reachable assertion via crafted XML document with a '\0'
+ located after whitespace
+
+Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
+Bug-Debian: https://bugs.debian.org/1059315
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
+---
+ tinyxmlparser.cpp | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
+index 8aa0dfa..1601962 100644
+--- a/tinyxmlparser.cpp
 b/tinyxmlparser.cpp
+@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p, 
TiXmlParsingData* data, TiXm
+   }
+ 
+   p = SkipWhiteSpace( p, _encoding );
++  if ( !p || !*p )
++  {
++  break;
++  }
+   if ( StringEqual( p, "version", true, _encoding ) )
+   {
+   TiXmlAttribute attrib;
diff -Nru tinyxml-2.6.2/debian/patches/series 
tinyxml-2.6.2/debian/patches/series
--- tinyxml-2.6.2/debian/patches/series 2022-10-20 16:32:49.0 +0200
+++ tinyxml-2.6.2/debian/patches/series 2024-01-25 04:12:05.0 +0100
@@ -1,3 +1,4 @@
 enforce-use-stl.patch
 entity-encoding.patch
 CVE-2021-42260.patch
+CVE-2023-34194.patch


signature.asc
Description: PGP signature

Bug#1057517:

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] 
https://salsa.debian.org/java-team/libcommons-collections3-java/-/merge_requests/4

Bug#1061471: bullseye-pu: package xerces-c/3.2.3+debian-3+deb11u1

[Guilhem Moulin]

On Thu, 25 Jan 2024 at 03:54:46 +0100, Guilhem Moulin wrote:
>  [x] attach debdiff against the package in oldstable

Oops, doing that now :-)

-- 
Guilhem.
diffstat for xerces-c-3.2.3+debian xerces-c-3.2.3+debian

 changelog   |   12 
 patches/CVE-2018-1311-mitigation.patch  |   52 
 patches/CVE-2018-1311.patch |  653 
++
 patches/CVE-2023-37536.patch|   79 
+
 patches/Fix-NetAccessorTest-to-exit-with-non-zero-status-in-case-.patch |   44 
 patches/series  |4 
 salsa-ci.yml|9 
 7 files changed, 800 insertions(+), 53 deletions(-)

diff -Nru xerces-c-3.2.3+debian/debian/changelog 
xerces-c-3.2.3+debian/debian/changelog
--- xerces-c-3.2.3+debian/debian/changelog  2020-12-14 17:43:13.0 
+0100
+++ xerces-c-3.2.3+debian/debian/changelog  2023-12-31 12:43:25.0 
+0100
@@ -1,3 +1,15 @@
+xerces-c (3.2.3+debian-3+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2018-1311: Use-after-free on external DTD scan.  This replaces
+RedHat's mitigation patch (which introduced a memory leak).
+Closes: #947431
+  * Fix CVE-2023-37536: Integer overflows in DFAContentModel class.
+  * Upstream tests: Cherry-pick upstream patch to fix NetAccessorTest to exit
+with non-zero status in case of error.
+
+ -- Guilhem Moulin   Sun, 31 Dec 2023 12:43:25 +0100
+
 xerces-c (3.2.3+debian-3) unstable; urgency=medium
 
   * Fix MemHandlerTest1 on 32-bit systems to compensate for CVE-2018-1311 fix
diff -Nru xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch 
xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch
--- xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch 
2020-12-14 17:43:13.0 +0100
+++ xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311-mitigation.patch 
1970-01-01 01:00:00.0 +0100
@@ -1,52 +0,0 @@
-
-https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311
-
 a/src/xercesc/internal/IGXMLScanner.cpp
-+++ b/src/xercesc/internal/IGXMLScanner.cpp
-@@ -1532,7 +1532,6 @@ void IGXMLScanner::scanDocTypeDecl()
- DTDEntityDecl* declDTD = new (fMemoryManager) 
DTDEntityDecl(gDTDStr, false, fMemoryManager);
- declDTD->setSystemId(sysId);
- declDTD->setIsExternal(true);
--Janitor janDecl(declDTD);
- 
- // Mark this one as a throw at end
- reader->setThrowAtEnd(true);
-@@ -3095,7 +3094,6 @@ Grammar* IGXMLScanner::loadDTDGrammar(co
- DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, 
false, fMemoryManager);
- declDTD->setSystemId(src.getSystemId());
- declDTD->setIsExternal(true);
--Janitor janDecl(declDTD);
- 
- // Mark this one as a throw at end
- newReader->setThrowAtEnd(true);
 a/tests/expected/MemHandlerTest1.log
-+++ b/tests/expected/MemHandlerTest1.log
-@@ -1,4 +1,4 @@
--At destruction, domBuilderMemMonitor has 0 bytes.
--At destruction, sax2MemMonitor has 0 bytes.
--At destruction, sax1MemMonitor has 0 bytes.
-+At destruction, domBuilderMemMonitor has 276 bytes.
-+At destruction, sax2MemMonitor has 276 bytes.
-+At destruction, sax1MemMonitor has 276 bytes.
- At destruction, staticMemMonitor has 0 bytes.
 /dev/null
-+++ b/tests/expected/MemHandlerTest1_32.log
-@@ -0,0 +1,4 @@
-+At destruction, domBuilderMemMonitor has 180 bytes.
-+At destruction, sax2MemMonitor has 180 bytes.
-+At destruction, sax1MemMonitor has 180 bytes.
-+At destruction, staticMemMonitor has 0 bytes.
 a/scripts/run-test.in
-+++ b/scripts/run-test.in
-@@ -46,6 +46,11 @@ run_test() {
- sed -i -e 's;\( *[0-9][0-9]* *ms *\);{timing removed};' "$output"
- 
- exp=$(cat "${srcdir}/expected/${name}.log")
-+
-+if [ "${name}" = "MemHandlerTest1" ] && [ "$(dpkg-architecture -q 
DEB_HOST_ARCH_BITS)" -eq 32 ]; then
-+exp=$(cat "${srcdir}/expected/${name}_32.log")
-+fi
-+
- obs=$(cat "$output")
- 
- echo "--"
diff -Nru xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch 
xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch
--- xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch1970-01-01 
01:00:00.0 +0100
+++ xerces-c-3.2.3+debian/debian/patches/CVE-2018-1311.patch2023-12-31 
12:43:25.0 +0100
@@ -0,0 +1,653 @@
+From: Karen Arutyunov 
+Date: Wed, 13 Dec 2023 09:59:07 +0200
+Subject: XERCESC-2188 - Use-after-free on external DTD scan (CVE-2018-1311)
+
+These are the instructions for observing the bug (before this commit):
+
+$ git clone https://github.com/apache/xerces-c.git
+$ cd xerces-c
+$ mkdir build
+$ cd build
+$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
+$ make -j8
+$ cp ../samples/data/personal.xml .
+
+$ cat 

Bug#1060052: Status?

[Dennis Haney]

Can we please get a new release of a stable kernel?
This keeps crashing our machines, and it is a pain manually updating to the 6.5 
kernel on all of them.

Med venlig hilsen
Dennis Haney d...@voxmeter.dk
Catglobe Direktør Mobil +84 907 42 46 52


Voxmeter A/S   Tlf.: +45 70 20 23 24   Borgergade 6, 4. sal   
DK-1300 København   CVR/VAT: 34217432
Analyser og Interviewarbejde: voxmeter.dk   
Analysesystem: catglobe.com

Bug#1061471: bullseye-pu: package xerces-c/3.2.3+debian-3+deb11u1

[Guilhem Moulin]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: xerce...@packages.debian.org
Control: affects -1 + src:xerces-c

[ Reason ]

xerces-c 3.2.3+debian-3 is vulnerable to CVE-2023-37536 (Integer
overflows in DFAContentModel class).  Also, while it ships a mitigation
for CVE-2018-1311, it does so at the expense of a memory leak, cf.
#947431.

These issues have both been fixed in buster LTS.  The “better”
(upstream-vetted) fix for CVE-2018-1311 have also landed in sid via NMU
and migrated to testing last month.

The security team argued the issues didn't warrant a DSA, and suggested
to go via s-pu instead.

[ Impact ]

Buster users will regress when upgrading to bullseye.

[ Tests ]

The vulnerabilities reports came with POCs which were checked against:

https://issues.apache.org/jira/browse/XERCESC-2241
https://issues.apache.org/jira/browse/XERCESC-2188

Also the package runs the upstream test suite at build time.

[ Risks ]

AFAICT no alternative exists.  I think the risk of regression given
the upstream patches cleanly applied.  Also the fixes are already
shipped in buster and sid/trixie.

[ Checklist ]

  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in oldstable
  [x] the issue is verified as fixed in unstable

[ Changes ]

 * Fix CVE-2018-1311: Use-after-free on external DTD scan.  This replaces
   RedHat's mitigation patch (which introduced a memory leak).
   Closes: #947431
 * Fix CVE-2023-37536: Integer overflows in DFAContentModel class.
 * Upstream tests: Cherry-pick upstream patch to fix NetAccessorTest to exit
   with non-zero status in case of error.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1061470: vasttrafik-cli: API is offline

[Salvo "LtWorf" Tomaselli]

Package: vasttrafik-cli
Version: 1.5-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: ltw...@debian.org

Dear myself.

The public API has completely changed.

There is no way to register new accounts and obtain tokens for the new API.

Until that is solved, this package is completely useless.


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

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.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 vasttrafik-cli depends on:
ii  python3 3.11.6-1
ii  python3-typedload   2.27-1
ii  python3-wcwidth 0.2.5+dfsg1-1.1
ii  python3-xtermcolor  1.2.1-3

vasttrafik-cli recommends no packages.

vasttrafik-cli suggests no packages.

-- no debconf information

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Nicolas Haller]

On 2024-01-23 08:15, Julian Andres Klode wrote:

Control: severity -1 important

On Sat, Nov 25, 2023 at 05:36:41PM -0500, Nicolas Haller wrote:

Package: grub-efi-amd64
Version: 2.06-13
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

My old laptop (Lenovo 11e) runs Sid and all was right before I updated
it the other day (I don't do that very often). After that upgrade, GRUB
wasn't able to load any kernel with the pretty much generic error
"Error: can't load image". The version of GRUB was 2.12~rc1-12.
If I try to boot again, GRUB tells me that I need to load the image
first (I guess it somehow ignores the linux command and sends that when
trying to load the initrd).


I'm downgrading this bug severity, as a single system regressing in
boot ability is not release critical. It is not possible for us to
ensure that grub continues working on every single device out there,
this grub will work for more hardware than previous grubs, and blocking
the transition to testing because it doesn't work on your 11e is not
helping anyone.

We have now also uploaded 2.12-1 and of course we welcome any patches,
but an old Lenovo 11e is not a priority, and we don't have any to test
ourselves.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Hello Julian,

I'm not sure why the aggressive tone here, I was asked if this bug 
breaks my system and it does. How you want to handle this is up to you.
I think GRUB is a critical piece of a Linux system and I thought it was 
worth to report the issue I encounter.


As I mentioned, my Lenovo isn't the newest one but it's not an esoteric 
hardware either. It's a pretty regular amd64 laptop.


To be honest, I'm a bit concerned that GRUB failed where it wasn't 
before (I would called that a regression) but also that it fails without 
giving any error message or any kind of clue that could help to debug this.


I'm not a debian or ubuntu core developer and I don't know the first 
thing about how to develop or debug a boot loader. Asking me for patches 
isn't helping anyone.


If you have any suggestion in order to fix or just to diagnose the 
issue, feel free to share that with me. Meanwhile, I'll try 2.12.1 and 
look for an upgrade as Jeremy suggested.


Have a nice day,

--
Nicolas Haller

Bug#1057510: jmagick: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/jmagick/-/merge_requests/1

Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532

[Tim Schumacher]

On Sun, 14 Jan 2018 13:38:11 +0100 Karsten Merker  wrote:


Machine: Fujitsu Lifebook AH532, first version (with BIOS version 1.09)

[...]

How can one bring the NVRAM back into a sane state that allows
getting into the setup and booting from external devices?


I personally had luck with doing a CMOS-reset (shorting the CL1_CL2
test point under the RAM slot while the machine is powered on is
easier than uncovering the actual battery) to restore the device-based
options in the boot menu, and then using the Fujitsu-provided
BIOS flash utilities [1] (via a bootable FreeDOS USB) to restore
the BIOS Setup option.

If you are feeling adventurous (or the CMOS-reset-and-BIOS-update
option does not work), you may want to try the small program I have
written [2] (which is supposed to restore all relevant entries from
within a running Linux system) instead. Please do note the disclaimer
and supported configurations though.

[1] https://support.ts.fujitsu.com/
[2] https://github.com/timschumi/ah532-biostools/

Bug#1032428: firefox: Menu handling with the mouse is broken

[Vincent Lefevre]

On 2023-05-05 17:37:02 +0200, Vincent Lefevre wrote:
> Actually not completely fixed. I can still see issues with
> the menu bar.

The menus with firefox 122.0-1 and FVWM seem to work fine, which
is not the case with the previous firefox version 121.0.1-1.

Perhaps this bug can be closed as fixed in 122.0-1, or we can wait
for confirmation by upstream (I've posted this information in the
upstream bug).

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

Bug#1059001: dropbear: CVE-2023-48795

[Guilhem Moulin]

Hi,

On Tue, 19 Dec 2023 at 09:08:00 +0100, Salvatore Bonaccorso wrote:
> The following vulnerability was published for dropbear.
>
> CVE-2023-48795[0]:
> […]
> Dropbear commit [1] implements the Strict KEX mode as well. In my
> understanding of [2] the issue might be less of a security concern for
> Dropbear itself, not reducing the Dropbear security.

FWIW this has been clarified at https://github.com/mkj/dropbear/issues/270 ,
where dropbear upstream as well as a terrapin author have chimed in.

I've backported the upstream fix to 2022.83 and will propose fixes for
(old)stable via s-pu.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1057524:

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

Best Regards,
 Vladimir.

 [1]
https://salsa.debian.org/janitor-team/proposed/lombok/-/merge_requests/1

Bug#1057509: jcabi-log: FTBFS with default Java 21

[Vladimir Petko]

Hi,

The issue is no longer reproducible when built against  lombok 1.18.24-2 [1].

Best Regards,
 Vladimir

[1] https://salsa.debian.org/janitor-team/proposed/lombok/-/merge_requests/1

Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package

[Jeremy Davis]

Package: php8.2-mysql
Version: 8.2.7-1~deb12u1
Severity: normal

Dear Maintainer/s,

Whilst I am reporting this against the php8.2-mysql package in bookworm, 
it applies equally to any/all phpX.Y-mysql packages (where X.Y is the 
PHP version) including packages from older stables, as well as trixie 
and sid - from the 'php' source package. As it also applies to the 
packages in trixie and sid (Version: 8.2.12-1+b1), perhaps I should be 
explicitly reporting it against that version instead?


As an aside (perhaps irrelevant here?), this also applies to the 
packages provided by Ondřej Surý via his deb.sury.org repo - whom I note 
is a member of the Debian PHP Maintainers Team (hence why mentioning 
it). Perhaps I should lodge a separate issue directly with him as well?



The issue
-

I note that the phpX.Y-mysql package does not provide a php-mysql 
virtual package!?


I can see that it does provide php-mysqli, php-mysqlnd & php-pdo-mysql 
(as well as phpX.Y-mysqli, phpX.Y-mysqlnd & phpX>Y-pdo-mysql) virtual 
packages, but not php-mysql?! E.g.:


Package: php8.2-mysql
Version: 8.2.7-1~deb12u1
[...]
Provides: php-mysqli, php-mysqlnd, php-pdo-mysql, php8.2-mysqli,
  php8.2-mysqlnd, php8.2-pdo-mysql
[...]

I note that the other PHP DB related packages (i.e. phpX.Y-pgsql & 
phpX.Y-sqlite3) DO provide their counterpart unversioned virtual 
packages (i.e. php-pgsql & php-sqlite3). For example:


Package: php8.2-sqlite3
Version: 8.2.7-1~deb12u1
[...]
Provides: php-pdo-sqlite, php-sqlite3, php8.2-pdo-sqlite
[...]

If nothing else, this seems inconsistent behaviour.

Obviously this is no problem whilst using only packages from a stable 
Debian release. However, in my experience, it is quite common for 
unpackaged PHP apps (installed direct from upstream source) to require a 
newer PHP version than that provided in stable (e.g. newer PHP from 
deb.sury.org).


It's less of an issue currently as bookworm has the relatively new 
PHP8.2. It was a bigger issue in bullseye as that had 7.4 fairly late in 
it's lifecycle.


If using an alternate version of PHP, Debian packages that depend on 
php-mysql (e.g. adminer[1]) will always pull in the default versioned 
PHP package from Debian as well (or latest PHP from sury.org - depending 
on pinning). I.e. php8.2-mysql if Debian repos are preferred (or the 
latest PHP version with deb.sury.org).


[1] https://packages.debian.org/bookworm/adminer

I acknowledge that supporting this scenario (installing PHP from third 
party repo and still using one or more PHP apps from Debian) may not be 
explicitly considered a "normal" Debian issue (so perhaps a "wishlist" 
item?).


I also get that the ~500kB may not be that big a deal to some, but IMO 
it'd be nice to not have to have redundant unused packages installed.


Further, I understand that the packaged PHP apps (from stable repo) may 
not be (completely or at all) compatible with a newer PHP version, but 
IMO that's on users such as myself to resolve, workaround or live with.


Resolution?
---

Regardless, on face value, it seems to me that if the versioned package 
(php8.2-mysql) simply provided the php-mysql package virtually this 
situation would be resolved. Or am I missing something fundamental?


FWIW I had intended to attach a patch for the php source 
('debian/main/8.2' branch) for your consideration, but it's a much more 
complex package than I have encountered before and I'm not really clear 
what might be required to achieve what I am requesting/suggesting. With 
some guidance I'd be more than happy to provide a patch and/or open a 
merge request on salsa (and/or elsewhere).


If there is a preferred alternate path to resolve this that I can assist 
with, please inform me.


Thank you for your consideration and/or guidance.

Regards,
Jeremy

-- Package-specific info:
 Additional PHP 8.2 information 

 PHP @PHP_VERSION SAPI (php8.2query -S): 

 PHP 8.2 Extensions (php8.2query -M -v): 

 Configuration files: 
 /etc/php/8.2/mods-available/mysqlnd.ini 
extension=mysqlnd.so

 /etc/php/8.2/mods-available/mysqli.ini 
extension=mysqli.so

 /etc/php/8.2/mods-available/pdo_mysql.ini 
extension=pdo_mysql.so


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

Kernel: Linux 5.15.126-1-pve (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C), LANGUAGE=en_US.UTF-8

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

Versions of packages php8.2-mysql depends on:
ii  libc6  2.36-9+deb12u3
ii  php-common 2:93
ii  php8.2-common  8.2.7-1~deb12u1
ii  ucf3.0043+nmu1

php8.2-mysql recommends no packages.

php8.2-mysql suggests no packages.
Versions of packages php8.2-common depends 

Bug#1061468: gloo: attempts to build on unsupported 32 bit systems

[Dan Bungert]

Source: gloo
Version: 0.0~git20230519.597accf-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

gloo attempts to build on 32 bit systems.
https://buildd.debian.org/status/package.php?p=gloo

We know this will not work, as cmake reports the following:

> Gloo can only be built on 64-bit systems.

I suggest adjusting the control file to reflect this state so that
builds are only attempted on 64 bit systems. Something like this should
work.

@@ -17,7 +17,7 @@ Rules-Requires-Root: no
 
 Package: libgloo-dev
 Section: libdevel
-Architecture: any
+Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 
loong64 ppc64 sparc64
 Depends: libgloo0 (= ${binary:Version}),
  libhiredis-dev,
  libibverbs-dev,


-Dan

Bug#1061467: RFP: funkwhale -- federated audio sharing platform

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: funkwhale
  Version : 1.4.0-rc2
  Upstream Contact: Funkwhale team
* URL : https://dev.funkwhale.audio/funkwhale/funkwhale 
* License : AGPL-3.0
  Programming Lang: Python
  Description : federated audio sharing platform
 
funkwhale is a federated audio sharing/hosting platform. This repo contains the
server, written in python.

best, 

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWxjuQVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1otgQAK6nriGh0jPez5mco6SA6RPkvrm3
pGmN+P8Ggb+NTUj9ILIQ2pFLWxFI7LHmhHzD9Xda4TH6w8tcB+DbLd4Oi/KMUgB1
e4uPVzlI50youPrUpyeIlmNK1b5sE1Ko8xuDWgfVR4FYpI/ZHVO0/0kjXcOLQtdP
mj5QXfExd/HY1yxKpRgDM/T35P8R1SYU0fOzGxLKIfQdQHf2wb5krt5E7bzkt79s
0dRcEZvQmfiYm8SF5BSUI9/+NwpcOkg2WmC5c6/PbA/MFOOr+IubruEytP6yt0NC
AXeNdIuX81sRw5n7/+L7DnwtT8iUayHGkIwM9v6UT2k102Gfr/08UYMIzFKYiTSj
G8qsUKNVQ9RtwdAf2dxv+9TRHgY1HBR5OLYp4MvDhozZ5zewt+SOtrERBfwEICfm
J7+U7JgKoZLBQmuFSn4Z95WiRR2rVjsCnded95oCZWJwqZrFPka+RguejCujWAe/
wyux27faDaotO2T9+ieMq6gZVMlcbZFyj2/3yqia9lTqNSNeODgzss7StlIPFlLr
YkFJ6RzTq0GhwLhlBQ3PK9GeAh9hLC0TlQraxyDbtZ3ouXn4XQ3R1jOsfVmJc6gX
1HUFKiQl0VJ0y6DfvfEruRXAgQIhTvOHUqmTSX6Sc4+UjNb0tK9eRn56qEy+oNBQ
H5k91nfIvbAG7j1j
=Joi/
-END PGP SIGNATURE-

Bug#1061466: nautilus FTBFS with nocheck profile: ../test/automated/displayless/meson.build:1:19: ERROR: Dependency "tracker-testutils-3.0" not found, tried pkgconfig

[Helmut Grohne]

Source: nautilus
Version: 45.2.1-3
Severity: serious
Tags: patch ftbfs trixie sid

nautilus fails to build from source when built with the nocheck profile.
Since trixie such a build failure is considered release-critical. The
build system does not automatically disable tests when test dependencies
are missing and fails. I'm attaching a patch for your convenience. I
verified that a nocheck build results in bit-identicial artifacts to a
regular build.

Helmut
diff --minimal -Nru nautilus-45.2.1/debian/changelog 
nautilus-45.2.1/debian/changelog
--- nautilus-45.2.1/debian/changelog2024-01-12 02:39:25.0 +0100
+++ nautilus-45.2.1/debian/changelog2024-01-24 23:12:48.0 +0100
@@ -1,3 +1,10 @@
+nautilus (45.2.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix nocheck FTBFS (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 24 Jan 2024 23:12:48 +0100
+
 nautilus (45.2.1-3) unstable; urgency=medium
 
   * Update tracker test patch to really skip the test failure
diff --minimal -Nru nautilus-45.2.1/debian/rules nautilus-45.2.1/debian/rules
--- nautilus-45.2.1/debian/rules2024-01-12 02:39:25.0 +0100
+++ nautilus-45.2.1/debian/rules2024-01-24 23:12:48.0 +0100
@@ -4,6 +4,12 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-O1 -Wl,-z,defs
 export DPKG_GENSYMBOLS_CHECK_LEVEL = 4
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
+ENABLE_TESTS := -Dtests=all
+else
+ENABLE_TESTS := -Dtests=none
+endif
+
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 ENABLE_SELINUX := -Dselinux=true
 else
@@ -24,7 +30,7 @@
dh_auto_configure -- \
-Ddocs=true \
-Dpackagekit=true \
-   -Dtests=all \
+   $(ENABLE_TESTS) \
$(ENABLE_CLOUD) \
$(ENABLE_SELINUX)
 

Bug#1059760: postfix: installs postfix-instance-generator into /lib

[Sven Joachim]

Control: found -1 3.8.5-1

On 2023-12-31 15:31 +0100, Chris Hofstaedtler wrote:

> Source: postfix
> Version: 3.8.4-1
> User: helm...@debian.org
> Usertag: dep17m2
>
> Hi,
>
> postfix installs postfix-instance-generator into
> /lib/systemd/system-generators. This appears to be a hard-coded
> path.
>
> For the currently ongoing Debian UsrMerge effort [1], this file
> should move below /usr.
>
> If you wanted to, you could ask systemd.pc for the correct path:
>   pkg-config --variable=systemdsystemgeneratordir systemd
>
> Please make sure this gets fixed well before trixie's transition
> freeze.
> Please also read the linked wiki page about uploading to
> experimental, so dumat can check your package (also explained
> there).

While all regular files have been moved below /usr/lib/systemd in
version 3.8.5-1, postfix still ships the /lib/systemd/system-generators
directory.  Removing the last line from debian/postfix.dirs should fix
that, see the attached (trivial, but untested) patch.

Cheers,
   Sven

diff --git a/debian/postfix.dirs b/debian/postfix.dirs
index f9e42cc3..253d301b 100644
--- a/debian/postfix.dirs
+++ b/debian/postfix.dirs
@@ -34,4 +34,3 @@ var/spool/postfix/usr/lib/zoneinfo
 var/spool/postfix/usr/lib/sasl2
 var/log
 var/lib/postfix
-lib/systemd/system-generators

Bug#1059606: (no subject)

[Mario Limonciello]

It looks like it's still failing to build, but it's outside of fwupd 
code now.


https://buildd.debian.org/status/fetch.php?pkg=fwupd=loong64=1.9.12-3=1706130974=0

Bug#1061465: bookworm-pu: package usbutils/014-1+deb12u1

[Aurelien Jarno]

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

[ Reason ]
The usbutils package contains a simple shell script called usb-devices
to list all USB devices with their basic characteristics. A regression
has been introduced in the version in bookworm, which causes some
devices behind hubs to be missed.

[ Impact ]
As the script is working partially listing some of the USB devices,
users might come to the wrong conclusion about the attached USB devices.

[ Tests ]
There is no automated testing for this shell script, however the fix has
been tested manually.

[ Risks ]
The patch is really simple and the fix has been in testing/unstable for
about 7 months without any reported issue.

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

[ Changes ]
The changes consists in pulling the upstream patch into the package. The
print_device() function is called recursively to go through the USB
tree. The variables are global by default, so the values of the caller
got overwritten by the callee. The solution is to declare those
variables as local.
diff -Nru usbutils-014/debian/changelog usbutils-014/debian/changelog
--- usbutils-014/debian/changelog   2021-08-18 22:40:42.0 +0200
+++ usbutils-014/debian/changelog   2024-01-24 22:32:47.0 +0100
@@ -1,3 +1,10 @@
+usbutils (1:014-1+deb12u1) bookworm; urgency=medium
+
+  * Add 01-usb-devices-use-local-variable-type-to-handle-recurs.patch to fix
+usb-devices not printing all devices.  Closes: #1052307.
+
+ -- Aurelien Jarno   Wed, 24 Jan 2024 22:32:47 +0100
+
 usbutils (1:014-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru 
usbutils-014/debian/patches/01-usb-devices-use-local-variable-type-to-handle-recurs.patch
 
usbutils-014/debian/patches/01-usb-devices-use-local-variable-type-to-handle-recurs.patch
--- 
usbutils-014/debian/patches/01-usb-devices-use-local-variable-type-to-handle-recurs.patch
   1970-01-01 01:00:00.0 +0100
+++ 
usbutils-014/debian/patches/01-usb-devices-use-local-variable-type-to-handle-recurs.patch
   2024-01-24 22:32:47.0 +0100
@@ -0,0 +1,39 @@
+From b1c31712134d2b28877bbe01de1526a256ca676c Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman 
+Date: Fri, 15 Oct 2021 16:07:17 +0200
+Subject: [PATCH] usb-devices: use 'local' variable type to handle recursion
+
+When recursing into a long USB tree, the local variables in the
+print_device() function would get confused and take on the value of the
+previous device it printed.  This caused devices to not get printed out
+at all, the exact opposite of what we wanted.
+
+Resolve this by using the non-POSIX 'local' variable declaration.
+
+Signed-off-by: Greg Kroah-Hartman 
+---
+ usb-devices | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/usb-devices b/usb-devices
+index 4e14608..9aca88d 100755
+--- a/usb-devices
 b/usb-devices
+@@ -101,10 +101,10 @@ print_interface() {
+ }
+ 
+ print_device() {
+-  devpath=$1
+-  parent=$2
+-  level=$3
+-  count=$4
++  local devpath=$1
++  local parent=$2
++  local level=$3
++  local count=$4
+ 
+   [ -d $devpath ] || return
+   cd $devpath
+-- 
+2.42.0
+
diff -Nru usbutils-014/debian/patches/series usbutils-014/debian/patches/series
--- usbutils-014/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ usbutils-014/debian/patches/series  2024-01-24 22:32:47.0 +0100
@@ -0,0 +1 @@
+01-usb-devices-use-local-variable-type-to-handle-recurs.patch

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

[Scott Kitterman]

On Tue, 16 Jan 2024 20:41:58 +0100 Lucas Nussbaum  wrote:
> Source: pycountry
> Version: 23.12.11+ds1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This is due to changes in the recent iso-codes upload.  the patch below fixes 
it so it should work with either version:

--- pycountry-23.12.11+ds1.orig/src/pycountry/__init__.py
+++ pycountry-23.12.11+ds1/src/pycountry/__init__.py
@@ -169,7 +169,8 @@ class SubdivisionHierarchy(pycountry.db.
 kw["parent_code"] = None
 super().__init__(**kw)
 self.country_code = self.code.split("-")[0]
-if self.parent_code is not None:
+if (self.parent_code is not None and
+self.country_code != self.parent_code.split("-")[0]):
 self.parent_code = f"{self.country_code}-{self.parent_code}"
 
 @property

Please let me know if you don't want an NMU.  This will eventually cause 
xml2rfc to be removed, so I'll NMU at some point unless you want to take care 
of it first (thanks if you do).

Scott K


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

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Diederik de Haas]

Control: tag -1 =upstream

On Wednesday, 24 January 2024 21:41:29 CET Patrice Duroux wrote:
> Finally, no more complaints!
> 
> $ uname -a
> Linux kos-moceratops 6.7+unreleased-amd64 #1 SMP PREEMPT_DYNAMIC
> Debian 6.7.1-1~exp1a~test (2024-01-24) x86_64 GNU/Linux

Excellent, now we know commit b17ef04bf3a4346d66404454d6a646343ddc9749 
introduced the regression.
 
> Does this need further testing from my side?

No, but it should be reported upstream so that an actual fix can be made.
Unfortunately the commit doesn't link to a/the patch discussion (on f.e. 
lore.kernel.org), so I don't know where it should be reported.

Hopefully someone else does ...

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

Bug#1054086: lsm: let dh_installsystemd choose the location of units

[Helmut Grohne]

On Tue, Jan 23, 2024 at 05:25:21PM -0300, Lucas Castro wrote:
> dh_installsystemd look only for maintainer scripts. That means it looks only
> for scripts residing in debian/ folder.
> 
> I guess you should know about that, therefore you propose to create a
> symlink from systemd file provided by upstream.

That's not the reason for proposing the change. The reason is that we
need to move the units from /lib/systemd/system to
/usr/lib/systemd/system in trixie but not bookworm. Encoding this in a
debian/*.install file is not simple, but we updated dh_installsystemd to
do exactly that.

> Sorry, I'm not going to apply the solution proposed on the next release, but
> I take a look what it should be the best approach for this.

I do not insist on using my approach. It merely is the one I considered
most suitable at the time of submitting the bug. Alternatively, you may
employ dh_movetousr or update the location in debian/lsm.install (though
extra work is required in case of backporting for the last option). The
point of this bug is to not ship aliased locations such as /lib.

Helmut

Bug#1061464: tracker FTBFS with nocheck profile: ../meson.build:99:26: ERROR: python3 is missing modules: gi

[Helmut Grohne]

Source: tracker
Version: 3.4.2-3
Severity: serious
Tags: patch trixie sid

tracker fails to build from source when built with the nocheck build
profile. This is considered release-critical since the trixie release,
but not earlier. The failure is:

../meson.build:99:26: ERROR: python3 is missing modules: gi

The build system does not automatically disable building tests and thus
fails. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru tracker-3.4.2/debian/changelog 
tracker-3.4.2/debian/changelog
--- tracker-3.4.2/debian/changelog  2023-06-27 18:09:03.0 +0200
+++ tracker-3.4.2/debian/changelog  2024-01-24 22:37:52.0 +0100
@@ -1,3 +1,10 @@
+tracker (3.4.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix nocheck FTBFS. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 24 Jan 2024 22:37:52 +0100
+
 tracker (3.4.2-3) unstable; urgency=medium
 
   [ Manuel A. Fernandez Montecelo ]
diff --minimal -Nru tracker-3.4.2/debian/rules tracker-3.4.2/debian/rules
--- tracker-3.4.2/debian/rules  2023-06-27 18:09:03.0 +0200
+++ tracker-3.4.2/debian/rules  2024-01-24 22:37:18.0 +0100
@@ -19,7 +19,8 @@
-Dbash_completion_dir=/usr/share/bash-completion/completions \
-Dsoup=soup3 \
-Dsystemd_user_services=true \
-   -Dsystemd_user_services_dir=/usr/lib/systemd/user
+   -Dsystemd_user_services_dir=/usr/lib/systemd/user \
+   -Dtests=$(if $(filter nocheck,$(DEB_BUILD_OPTIONS)),false,true)
 
 # Enforce tight shlibs dependencies
 override_dh_makeshlibs:

Bug#1061463: ardour: Ardour crashing when exporting to audio files when using JACK server via Pipewire

[Chris Joelly]

Package: ardour
Version: 1:8.2.0+ds-1
Severity: normal

When I use JACK as the audio system, which is handled by Pipewire using the
pipewire-jack layer, Ardour crashes almost every time when I export a audio
track or master track to e.g. a WAV or FLAC file. When the audio system is
switched to ALSA, the crashes do not happen. As Paul Davis recommended on the
ardour.org forum, I tried a Linux build from ardour.org (8.2) and that binary
runs very stable during audio exports.
The assumption was that it might be that Pipewire is the source of the
troubles, but ardour.orgs binary did not lead to reproducible crashes with the
audio system JACK with Pipewire, even when switching connections from/to Ardour
using qpwgraph during exports. Even other sources played music through easy
effects to the headset without impacting the export (besides Ardour muted the
headset during export).

Stuff seen on the console after the crashes:

Segfault

and

munmap_chunk(): invalid pointer
Aborted


-- 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-5-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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ardour depends on:
ii  ardour-data  1:8.2.0+ds-1
ii  ardour-lv2-plugins   1:8.2.0+ds-1
ii  libarchive13 3.7.2-1
ii  libasound2   1.2.10-3
ii  libatkmm-1.6-1v5 2.28.3-2+b1
ii  libaubio50.4.9-4.3+b3
ii  libc62.37-13
ii  libcairo21.18.0-1+b1
ii  libcairomm-1.0-1v5   1.14.5-1
ii  libcurl3-gnutls  8.5.0-2
ii  libcwiid10.6.91-5
ii  libdbus-1-3  1.14.10-4
ii  libfftw3-single3 3.3.10-1
ii  libfluidsynth3   2.3.4-1+b1
ii  libfontconfig1   2.14.2-6+b1
ii  libgcc-s113.2.0-10
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libglibmm-2.4-1v52.66.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libgtkmm-2.4-1v5 1:2.24.5-4+b1
ii  liblilv-0-0  0.24.22-1
ii  liblo7   0.31-1
ii  liblrdf0 0.6.1-4
ii  libltc11 1.3.2-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libpangomm-1.4-1v5   2.46.3-1
pn  libpulse0
ii  libqm-dsp0   1.7.1-6
ii  libreadline8 8.2-3
ii  librubberband2   3.3.0+dfsg-2
ii  libsamplerate0   0.2.2-4
ii  libsigc++-2.0-0v52.12.1-1
ii  libsndfile1  1.2.2-1
ii  libstdc++6   13.2.0-10
ii  libsuil-0-0  0.10.20-1
ii  libtag1v51.13.1-1
ii  libusb-1.0-0 2:1.0.26-1
ii  libvamp-hostsdk3v5   2.10.0-4
ii  libvamp-sdk2v5   2.10.0-4
ii  libwebsockets19  4.3.3-1
ii  libx11-6 2:1.8.7-1
ii  libxml2  2.9.14+dfsg-1.3+b2

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:8.2.0+ds-1

ardour suggests no packages.

-- no debconf information

Bug#1061462: revolt: Stop depending on webkit2gtk 4.0

[Jeremy Bícha]

Source: revolt
Version: 0.0+git20211216.7f6f762-1
Severity: serious
Tags: patch trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0
Forwarded: https://salsa.debian.org/matrix-team/revolt/-/merge_requests/1

The webkit2gtk maintainers intend to stop building the 4.0 API soon.
The 4.1 API is the same as the 4.0 API except that it uses libsoup3
instead of libsoup2.4.

I am attaching a merge request to fix this issue. Please review and
upload soon. Otherwise, I will likely do an NMU.

On behalf of the webkit2gtk maintainers,
Jeremy Bícha

Bug#1061461: RFP: jellyfin-web -- jellyfin media server web ui

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jellyfin-web
  Version : 10.8.13
  Upstream Contact: Jellyfin Team
* URL : https://github.com/jellyfin/jellyfin-web 
* License : GPL-2
  Programming Lang: JS
  Description : jellyfin media server web ui

This is the graphical front-end for the jellyfin web server.
Will be a lot of work because of the JS dependencies.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWxfgsVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1NdQQALw2tIN+8kUUS5iaCpT/GgbhUhJx
F450l6StMFBQZDud4ALQau8LWNfpj03WbcL6Yt72lsJ6302Mw+kl2Jwcgl9DQV+n
bvddUGxwoYDhDuQrQFcQOMAhFmHUstY9vGxUJ1zQ9QglEAD8Uyr7ncr/vfnsderr
DvHcpNKgT4y8ZREWtVIkefwDCeCQRO6gOBqCmpXOXVMuPHi0doyhT0lkPghmIXIi
Txq9Pj5G2WW4u42D/3l57dQIyDQSDdKUOzVM+fyKZ4ewjK9WmUC7jHcdyEkK5rcj
sEKBgHXULCEOc3vlDF53hAHHu0LADcPAdrrgmoNdRp0Kh8v9dCJacTqU1UDiiTFl
yiCZNIFo/hqxwNO0lOLY1eL3JT1vTBGEK09B/ZKKZEkA6951N3bTYtdIiil+vcet
qpQ+6bGFN5gDCbXYEB58ePJjRQUYBdSDeNk5K55g5xQydubNrsbA4EOMPoDDlF8e
yJp4M7kCTu+lo7ejCcAaXfPrejsHwXNgN+3OtAJ9TZWuKMU6sP3Esrh+eTO/7TVx
cqC9uisVZaUGT5Wa4R/jIwdTG2c7hrTLYljXRMJxpVzovx+SpTsWovVNWUDoYvOT
EQyK72RqoXcABA/yjP1nROnGw0cZVgfXBMCrKgb6LRzuvQ3PljL3UC/eh8NK83u5
gZb0+nFqZ+7JY5PT
=T5AH
-END PGP SIGNATURE-

Bug#1061460: firmware-nonfree: CVE-2023-4969

[Salvatore Bonaccorso]

Source: firmware-nonfree
Version: 20230625-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for firmware-nonfree.

CVE-2023-4969[0]:
| A GPU kernel can read sensitive data from another GPU kernel (even
| from another user or app) through an optimized GPU memory region
| called _local memory_ on various architectures.

There are though some unclarities about this, so just filling for
keeping track of the issue. [1] mentions that AMD expects to to start
rolling out mitigations beginning of March 2024, so we might see then
more where the mitigations lies and if firmware-nonfree are correct.
They mention there rather "upcoming driver updates".


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-4969
https://www.cve.org/CVERecord?id=CVE-2023-4969
[1] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6010.html

Regards,
Salvatore

Bug#1060026: yade: please move away from python3-future

[Alexandre Detiste]

control: tag -1 +patch

Hi,

Here's a patch.

I didn't try to be smart, just to get this done.

I have seen this package takes hours to build
on buildd so I'm not even trying on my old fanless
NUC knockoff.

Greetings
diff --git a/core/main/main.py.in b/core/main/main.py.in
index b8a52ca..11bc619 100644
--- a/core/main/main.py.in
+++ b/core/main/main.py.in
@@ -2,8 +2,11 @@
 # encoding: utf-8
 # syntax:python
 
-from __future__ import print_function
-from past.builtins import execfile
+def execfile(filename, myglobals=None, mylocals=None):
+with open(filename, "rb") as fin:
+ source = fin.read()
+code = compile(source, filename, "exec")
+exec(code)
 
 import sys,os,os.path,time
 try:
diff --git a/core/main/yade-batch.in b/core/main/yade-batch.in
index 1d128ef..5b58cd6 100755
--- a/core/main/yade-batch.in
+++ b/core/main/yade-batch.in
@@ -4,12 +4,6 @@
 # vim: syntax=python
 # portions © 2008 Václav Šmilauer 
 
-from __future__ import print_function
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
-from builtins import object
 import os, sys, _thread, time, logging, pipes, socket, xmlrpc.client, re, shutil, random
 
 # Add search path for yade Python-modules
diff --git a/core/main/yade-oar.in b/core/main/yade-oar.in
index d96b60d..b8eb705 100644
--- a/core/main/yade-oar.in
+++ b/core/main/yade-oar.in
@@ -7,12 +7,6 @@
 # This script is to be used with OAR task scheduler. May be an example to use use with other task scheduler for clusters
 # Adapted from yade-batch
 
-from __future__ import print_function
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
-from builtins import object
 import os, sys, _thread, time, logging, pipes, socket, xmlrpc.client, re, shutil, random
 
 # Add search path for yade Python-modules
diff --git a/doc/sphinx/conf.py b/doc/sphinx/conf.py
index 001bc1a..548ed88 100644
--- a/doc/sphinx/conf.py
+++ b/doc/sphinx/conf.py
@@ -21,11 +21,6 @@
 ##
 ## http://docutils.sourceforge.net/docs/howto/rst-roles.html
 
-from __future__ import print_function
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
 import sys, os, re
 from docutils import nodes
 from sphinx import addnodes
diff --git a/doc/sphinx/ipython_directive.py b/doc/sphinx/ipython_directive.py
index 816d1bf..4cbcaee 100644
--- a/doc/sphinx/ipython_directive.py
+++ b/doc/sphinx/ipython_directive.py
@@ -51,18 +51,11 @@ Authors
 - Fernando Perez: refactoring, documentation, cleanups.
 - VáclavŠmilauer : Prompt generatlizations.
 """
-from __future__ import print_function
-
 #-
 # Imports
 #-
 
 # Stdlib
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
-from builtins import object
 import io
 import imp
 import os
diff --git a/doc/sphinx/ipython_directive012.py b/doc/sphinx/ipython_directive012.py
index c98ecd4..14e7cce 100644
--- a/doc/sphinx/ipython_directive012.py
+++ b/doc/sphinx/ipython_directive012.py
@@ -51,18 +51,11 @@ Authors
 - VáclavŠmilauer : Prompt generalizations.
 - Skipper Seabold, refactoring, cleanups, pure python addition
 """
-from __future__ import print_function
-
 #-
 # Imports
 #-
 
 # Stdlib
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
-from builtins import object
 import io
 import os
 import re
diff --git a/doc/sphinx/ipython_directive013.py b/doc/sphinx/ipython_directive013.py
index c606acd..8f68221 100644
--- a/doc/sphinx/ipython_directive013.py
+++ b/doc/sphinx/ipython_directive013.py
@@ -52,18 +52,11 @@ Authors
 - VáclavŠmilauer : Prompt generalizations.
 - Skipper Seabold, refactoring, cleanups, pure python addition
 """
-from __future__ import print_function
-
 #-
 # Imports
 #-
 
 # Stdlib
-from future import standard_library
-standard_library.install_aliases()
-
-from builtins import range
-from builtins import object
 import io
 import os
 import re
diff --git a/doc/sphinx/ipython_directive200.py b/doc/sphinx/ipython_directive200.py
index 55ef14d..bca2cf7 100644
--- a/doc/sphinx/ipython_directive200.py
+++ b/doc/sphinx/ipython_directive200.py
@@ -119,18 +119,11 @@ Authors
 - VáclavŠmilauer : Prompt generalizations.
 - Skipper Seabold, refactoring, cleanups, pure python addition
 """
-from __future__ import print_function
-
 #-
 # Imports
 

Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc

[Ludovic Rousseau]

Le 24/01/2024 à 19:43, Ludovic Rousseau a écrit :

Le 24/01/2024 à 18:09, Laurent Bigonville a écrit :

Package: pcscd
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

Hello,

When looking at the logs of pcscd, I see the following messages:

jan 22 09:47:37 edoras pcscd[1663]:  auth.c:125:IsClientAuthorized() 
Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: 
Process not found
jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() 
Process 1565 (user: 115) is NOT authorized for action: access_pcsc

It seems that GDM is not allowed to talk to pcscd.

GDM has the functionality to detect whether there is a smartcard in the
reader and then use the gdm-smartcard PAM service instead of the
gdm-password one to perform login.

I guess that GDM should be whitelisted to allow it to use pcscd?


Exact.
Good point.

You can add polkit config file until I fix the issue.
https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/


The fix is quite easy.
Create a new file /etc/polkit-1/rules.d/03-polkit-pcscd.rules containing:
polkit.addRule(function(action, subject) {
if ((action.id == "org.debian.pcsc-lite.access_pcsc"
|| action.id == "org.debian.pcsc-lite.access_card")
&& subject.user == "Debian-gdm") {
return polkit.Result.YES;
}
});


What I don't know is if this new file should be provided by the pcscd package 
or by the gdm3 package.
I would say gdm3 but I am not sure.

I started a discussion on the pcsclite-muscle list at 
https://lists.infradead.org/pipermail/pcsclite-muscle/2024-January/001457.html

Bye

--
Dr. Ludovic Rousseau

Bug#1061205: Please upgrade to llvm-toolchain-17

[Patrick Franz]

Hej Sylvestre,

Am Samstag, 20. Januar 2024, 21:57:14 CET schrieb Sylvestre Ledru:
> Source: qt6-tools
> Severity: important
> 
> Dear Maintainer,
> 
> As part of the effort to limit the number of llvm packages in the
> archive, it would be great if you could upgrade to -17.
> 
> This package depends on 15.

Unfortunately, qt6-tools 6.4.2 in unstable does not build with 
llvm-toolchain-17, only with -15. I don't know how much work it would be 
to create patches to make this work.
However, qt6-tools 6.6.1 (which is currently in experimental) builds 
fine with llvm-toolchain-17. We do not have an ETA for the transition 
yet, but I hope it's not in the too-distant-future.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1015930: lists.debian.org: Please create debian-livecoding

[Alexander Wirt]

On Sun, Jul 24, 2022 at 11:48:29AM +0200, Joenio Marques da Costa wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I would like to ask the creation of a new mailing list with the following
> details.
> 
> ** Name **
> 
> debian-livecoding

Sorry for the delay! But I created the list. See 
http://lists.debian.org/debian-livecoding

Thanks

Alex


signature.asc
Description: PGP signature

Bug#1061459: wedwde

[alda]

Package: summit.debconf.org
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: a...@gmail.com

Bug#1061458: gdm3: Testsuite breaks with openssl 3.2

[Sebastian Andrzej Siewior]

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

The argument "-extensions v3_ca" for req is invalid and not considered.
Earlier versions of openssl silently ignored that argument, openssl 3.2
throws an error now, see
https://ci.debian.net/packages/g/gdm3/unstable/amd64/
https://ci.debian.net/packages/g/gdm3/unstable/amd64/41875309/

Sebastian
From: Sebastian Andrzej Siewior 
Date: Wed, 24 Jan 2024 21:32:49 +0100
Subject: [PATCH] debian: Adapt tests for openssl3.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The argument "-extensions v3_ca" for req is invalid and not considered.
Earlier versions of openssl silently ignored that argument, openssl 3.2
throws an error now:
|  openssl req -batch -new -nodes … -extensions v3_ca …
| Error adding request extensions from section v3_ca
| 0071DD54987F:error:1179:X509 V3 routines:v2i_AUTHORITY_KEYID:no issuer certificate:../crypto/x509/v3_akid.c:156:
| 0071DD54987F:error:1180:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=v3_ca, name=authorityKeyIdentifier, value=keyid:always,issuer:always

Remove the not relevant argument "-extensions v3_ca".

Signed-off-by: Sebastian Andrzej Siewior 
---
 debian/tests/sssd-softhism2-certificates-tests.sh | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/tests/sssd-softhism2-certificates-tests.sh b/debian/tests/sssd-softhism2-certificates-tests.sh
index 00c533f127dd..a68812673983 100644
--- a/debian/tests/sssd-softhism2-certificates-tests.sh
+++ b/debian/tests/sssd-softhism2-certificates-tests.sh
@@ -217,7 +217,6 @@ openssl req \
   -key "$tmpdir/test-intermediate-CA-key.pem" \
   -passout "$root_ca_key_pass" \
   -sha256 \
-  -extensions v3_ca \
   -out "$tmpdir/test-intermediate-CA-certificate-request.pem"
 
 openssl req -text -noout -in "$tmpdir/test-intermediate-CA-certificate-request.pem"
@@ -306,7 +305,6 @@ openssl req \
   -key "$tmpdir/test-sub-intermediate-CA-key.pem" \
   -passout "$intermediate_ca_key_pass" \
   -sha256 \
-  -extensions v3_ca \
   -out "$tmpdir/test-sub-intermediate-CA-certificate-request.pem"
 
 openssl req -text -noout -in "$tmpdir/test-sub-intermediate-CA-certificate-request.pem"
-- 
2.43.0

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Patrice Duroux]

Finally, no more complaints!

$ uname -a
Linux kos-moceratops 6.7+unreleased-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.7.1-1~exp1a~test (2024-01-24) x86_64 GNU/Linux

$ sudo dmesg | grep '\(amdgpu\|drm\)'
[1.095216] ACPI: bus type drm_connector registered
[2.085314] i915 :00:02.0: [drm] VT-d active for gfx access
[2.085425] i915 :00:02.0: [drm] Using Transparent Hugepages
[2.087746] i915 :00:02.0: [drm] Finished loading DMC firmware
i915/kbl_dmc_ver1_04.bin (v1.4)
[3.608758] [drm] amdgpu kernel modesetting enabled.
[3.608767] amdgpu: vga_switcheroo: detected switching method
\_SB_.PCI0.GFX0.ATPX handle
[3.608784] amdgpu: ATPX version 1, functions 0x0033
[3.608830] amdgpu: ATPX Hybrid Graphics
[3.610446] amdgpu: Virtual CRAT table created for CPU
[3.610455] amdgpu: Topology: Add CPU node
[3.610550] amdgpu :01:00.0: enabling device ( -> 0003)
[3.610586] [drm] initializing kernel modesetting (POLARIS12
0x1002:0x6981 0x1028:0x0926 0x00).
[3.630941] [drm] register mmio base: 0xB430
[3.630944] [drm] register mmio size: 262144
[3.631086] [drm] add ip block number 0 
[3.631087] [drm] add ip block number 1 
[3.631088] [drm] add ip block number 2 
[3.631089] [drm] add ip block number 3 
[3.631089] [drm] add ip block number 4 
[3.631090] [drm] add ip block number 5 
[3.631091] [drm] add ip block number 6 
[3.631091] [drm] add ip block number 7 
[3.631092] [drm] add ip block number 8 
[3.642892] amdgpu :01:00.0: amdgpu: Fetched VBIOS from ATRM
[3.642895] amdgpu: ATOM BIOS: BR43850.001
[3.642927] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_sdma.bin
[3.642991] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_sdma1.bin
[3.643023] [drm] UVD is enabled in VM mode
[3.643024] [drm] UVD ENC is enabled in VM mode
[3.643026] [drm] VCE enabled in VM mode
[3.643027] amdgpu :01:00.0: amdgpu: Trusted Memory Zone (TMZ)
feature not supported
[3.643036] [drm] GPU posting now...
[3.755975] [drm] vm size is 64 GB, 2 levels, block size is 10-bit,
fragment size is 9-bit
[3.756017] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_k_mc.bin
[3.756122] amdgpu :01:00.0: BAR 2: releasing [mem
0x8000-0x801f 64bit pref]
[3.756124] amdgpu :01:00.0: BAR 0: releasing [mem
0x7000-0x7fff 64bit pref]
[3.756142] amdgpu :01:00.0: BAR 0: assigned [mem
0x41-0x41 64bit pref]
[3.756147] amdgpu :01:00.0: BAR 2: assigned [mem
0x408000-0x40801f 64bit pref]
[3.756162] amdgpu :01:00.0: amdgpu: VRAM: 4096M
0x00F4 - 0x00F4 (4096M used)
[3.756163] amdgpu :01:00.0: amdgpu: GART: 256M
0x00FF - 0x00FF0FFF
[3.756174] [drm] Detected VRAM RAM=4096M, BAR=4096M
[3.756175] [drm] RAM width 128bits GDDR5
[3.756337] [drm] amdgpu: 4096M of VRAM memory ready
[3.756338] [drm] amdgpu: 7879M of GTT memory ready.
[3.756357] [drm] GART: num cpu pages 65536, num gpu pages 65536
[3.756874] [drm] PCIE GART of 256M enabled (table at 0x00F4FFF8).
[3.756946] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_pfp_2.bin
[3.756996] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_me_2.bin
[3.757042] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_ce_2.bin
[3.757063] [drm] Chained IB support enabled!
[3.757072] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_rlc.bin
[3.757146] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_mec_2.bin
[3.757726] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_mec2_2.bin
[3.758564] amdgpu: hwmgr_sw_init smu backed is polaris10_smu
[3.758620] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_uvd.bin
[3.759394] [drm] Found UVD firmware Version: 1.130 Family ID: 16
[3.760073] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_vce.bin
[3.760419] [drm] Found VCE firmware Version: 53.26 Binary ID: 3
[3.760798] amdgpu :01:00.0: firmware: direct-loading firmware
amdgpu/polaris12_k_smc.bin
[4.092386] [drm] Display Core v3.2.259 initialized on DCE 11.2
[4.636780] i915 :00:02.0: [drm] *ERROR* Failed to probe lspcon
[4.636791] [drm] Initialized i915 1.6.0 20230929 for :00:02.0 on minor 0
[5.207332] i915 :00:02.0: [drm] *ERROR* Failed to probe lspcon
[5.207335] i915 :00:02.0: [drm] *ERROR* LSPCON init failed on port D
[5.607371] fbcon: i915drmfb (fb0) is primary device
[5.629068] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device
[6.211671] i915 :00:02.0: [drm] *ERROR* Failed to probe lspcon
[6.211682] i915 :00:02.0: [drm] *ERROR* LSPCON init failed on port D
[7.194222] 

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Aurelien Jarno]

Hi,

On 2024-01-23 17:40, Helmut Grohne wrote:
> Hi,
> 
> TL;DR: I brainstorm solutions and appreciated feedback, but no action is
> required at this time.

I am not sure I understood everything from that mail, but let me provide
a few answers.

> On Sun, Jan 21, 2024 at 10:32:29PM +0100, Helmut Grohne wrote:
> > This seems pretty much unfxiable to me now.
> 
> Unfixable was a bit too strong. With much help from Aurelien and ideas
> from Enrico I looked at this more systematically.
> 
> I first tried to understand what kind of file sharing we between glibc
> packages. To that end I wrote a collect.sh (attached) that downlods all
> the glibc packages and a diagnose.py (attached) that tries to scrape
> relevant detail from them. This results in an output.txt (attached).
> This is all quite hacky, but it gets the job done. For the purpose of
> this analysis, I am assuming that files that differ in content also
> differ in size (which of course is not generally correct, but simplifies
> matters). That output.txt lists files (normalized to lack any /usr
> prefix) and the packages shipping them (as a 3-tuple package name,
> architecture, size or symlink target). Assuming that all the packages
> were Multi-Arch: same, files with identical content (i.e. size) are
> discarded. We're left with three kinds of file sharing:
> 
> debhelper version on sh4
> 
> 
> Apparently sh4 has a different debhelper that emits different files in
> /usr/share/doc. This breaks M-A:same, but is otherwise boring in the
> DEP17 context.
> 
> Conflicting multilibs
> =
> 
> Around 300 files in /lib64 conflict between libc6-ppc64:powerpc,
> libc6-amd64:i386 and libc6-amd64:x32. Likewise, around 300 files in
> /lib32 conflict between libc6-s390:s390x, libc6-sparc:sparc64,
> libc6-i386:amd64 libc6-powerpc:ppc64, libc6-i386:x32 and
> libc6-mipsn32:mips64el. These are declared file conflicts.
> Unfortunately, we learned that Conflicts do not reliably prevent
> concurrent unpacks in the presence of aliasing, so when moving these
> libraries, we can construct a file loss, for example:
> 
>  * apt install libc6:mips64el libc6-i386:amd64
>  * Add hypothetical apt sources with a moved glibc.
>  * echo libc6-i386:amd64 deinstall | dpkg --set-selections
>  * dpkg --auto-deconfigure --install libc6-mipsn32_usrmoved_mips64el.deb
> 
> In essence, this will be upgrading from bookworm to trixe while
> simultaneously replacing libc6-i386 with libc6-mipsn32 for some reason.
> On top of that, I guess that apt would prefer removing libc6-i386 before
> unpacking libc6-mipsn32 such that the loss scenario likely requires
> working with dpkg directly.
> 
> There is a relatively simple mitigation. For every file in SLIBDIR in
> the trixie, libc-alt.preinst can set up a diversion for the
> corresponding aliased location diverting to some non-existent filename.
> libc-alt.postinst then removes these diversions. The Conflicts require
> the conflicting libc-alt to actually be removed before libc-alt.postinst
> is run. (Breaks is not sufficient as I learned the hard way.) These are
> very temporary diversions, but they're also quite many (300).
> 
> At the time of this writing, I have not prototyped this approach. Let me
> already pose the question of how you assess the involved risks here.
> Actually triggering this failure is a rather strange corner case and it
> is not clear to me whether this corner case is worth risking possible
> implementation bugs in the mitigation.
> 
> Conflicting runtime dynamic linkers between multiarch packages
> ==
> 
> Some architecture combinations such as s390, powerpc, hppa, m68k,
> mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting
> runtime dynamic loaders. In theory this violates Multi-Arch: same, but
> there is basically nothing we can do about this and dropping Multi-Arch:
> same from the packages would completely break any kind of multiarch
> setup. There is little we can do here and this is also unrelated to
> DEP17.

We tried to add conflicts for those, like it's done for the multilib
packages, but at the time the infrastructure exploded (see #745552). I
don't remember the details, but I guess it was either dak or
dose-builddebcheck.
 
> Conflicting runtime dynamic linkers between multiarch and multilib
> ==
> 
> Runtime dynamic linkers need to be installed both into libc:ARCH and
> libc-ARCH:SIBLINGARCH. An example is libc6:i386 and libc6-i386:amd64
> both containing /lib/ld-linux.so.2. Both packages really need to ensure
> presence of the runtime dynamic linker on installation in the exact
> location so there is little we can do about this. The current situation
> is that the multiarch package Replaces the multilib one such that
> ownership is automatically transferred to the multiarch one when both
> are installed. The multiarch postrm 

Bug#1061457: src:box64: fails to migrate to testing for too long: FTBFS on ppc64el

[Paul Gevers]

Source: box64
Version: 0.2.4+dfsg-1
Severity: serious
Control: close -1 0.2.6+dfsg-2
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061456: src:pmacct: fails to migrate to testing for too long: Build-Depends not available on s390x

[Paul Gevers]

Source: pmacct
Version: 1.7.7-1
Severity: serious
Control: close -1 1.7.8-1
X-Debbugs-CC: Boyuan Yang 
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:pmacct has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable has a new 
Build-Depends that's not available on s390x.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061455: src:r-cran-ggally: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: r-cran-ggally
Version: 2.1.2-2
Severity: serious
Control: close -1 2.2.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1059385

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:r-cran-ggally has been trying to migrate 
for 33 days [2]. Hence, I am filing this bug. The version in unstable 
fails its autopkgtest as reported in bug 1059385.


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=r-cran-ggally



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061454: python3-dput: Does not work with Python 3.12: 'ConfigParser' object has no attribute 'readfp'

[Dmitry Shachnev]

Package: python3-dput
Version: 1.37
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Dear Maintainer,

This module seems to be incompatible with Python 3.12:

  $ dput ftp-master sip6_6.8.2+dfsg-1_source.changes
  Traceback (most recent call last):
File "/usr/bin/dput", line 129, in 
  upload_package(changes, args)
File "/usr/lib/python3/dist-packages/dput/uploader.py", line 274, in 
invoke_dput
  profile = dput.profile.load_profile(args.host)

File "/usr/lib/python3/dist-packages/dput/profile.py", line 191, in 
load_profile
  _multi_config = MultiConfig()
  ^
File "/usr/lib/python3/dist-packages/dput/profile.py", line 85, in __init__
  self.preload(configs)
File "/usr/lib/python3/dist-packages/dput/profile.py", line 101, in preload
  classes[obj['type']](
File "/usr/lib/python3/dist-packages/dput/config.py", line 42, in __init__
  self.preload(configs)
File "/usr/lib/python3/dist-packages/dput/configs/dputcf.py", line 60, in 
preload
  parser.readfp(open(config, 'r'))
  ^
  AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you 
mean: 'read'?

Quoting Python 3.12 changes page:

> Several names deprecated in the configparser way back in 3.2 have been
> removed per gh-89336:
>
> [...]
> - configparser.ConfigParser no longer has a readfp method. Use read_file()
>   instead.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1061445: linux-image-6.7-cloud-amd64: Built CONFIG_VIRTIO_BLK into kernel

[Bastian Blank]

Control: tags -1 wontfix

On Wed, Jan 24, 2024 at 06:13:05PM +0100, Paul Menzel wrote:
> Trying to quickly start a VM, it’d be great to not use an initrd image, and
> also use the Virtio features, for example with the command below:

Please use virtiofs in this case.

> qemu-system-x86_64 -M q35 -m 32G -enable-kvm -cpu host -smp cpus=32
> -device virtio-rng-pci -net nic,model=virtio-net-pci -net
> user,hostfwd=tcp::5-:22 -drive
> if=virtio,file=/scratch/local2/debian-linux-build.img -vga none -nographic

But you don't specify a kernel, so it boots fine using the initramfs
within.  So this already boots quite fine.

I don't see what exactly you mean will be easier.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Bug#1061453: lintian: Confusing use of NEWS.Debian (vs debian/NEWS)

[Diederik de Haas]

Package: lintian
Version: 2.116.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm not sure if this belongs to the lintian or developers-reference
package, or both. But it's at least confusing to me in lintian.

Based on this paragraph in developers-reference, I added a
``debian/NEWS.Debian`` file to a package:
6.3.5 Supplementing changelogs with NEWS.Debian files

After building the package and running lintian, I get a warning:
incorrect-packaging-filename better: debian/NEWS [debian/NEWS.Debian]

So I updated the package by renaming it to ``debian/NEWS``.
Build the package again and run lintian and I get this warning:
debian-news-entry-has-strange-distribution UNRELEASED

Note that this warning did NOT show up when I had a
``debian/NEWS.Debian`` file, so it seems to 'require' ``debian/NEWS``.

``lintian-explain-tags debian-news-entry-has-strange-distribution`` then
explains what it's for, mentioning ``NEWS.Debian``.

So I cloned the lintian repo to make a MR to replace ``NEWS.Debian``
with ``debian/NEWS`` for that tag.
Thinking there may be more such things, I ran ``grep -rn "NEWS.Debian"``
... which returned a LONG list. So I filed this bug instead of the MR.

The incorrect-packaging-filename explainer also has this line:
"Debhelper sometimes adds *.Debian extensions to NEWS, README and TODO
files."

So it *sometimes* adds the ``.Debian`` extension (but not always?),
but ``wrong-name-for-debian-news-file`` says this:
"The Debian news file must be installed as
/usr/share/doc/*pkg*/NEWS.Debian.gz with exactly that capitalization"

I'm assuming the *must* word complies with RFC2119 and was deliberately
chosen?

So it's confusing to first get a warning about using ``NEWS.Debian`` to
then get a warning which uses ``NEWS.Debian`` in its explanation.

I don't know if (some?) references are outdated and should use the
'new' name or whether it's all technically correct and just confusing as
hell for 'newbies' like me, in which case an explanation in
developers-reference would be much appreciated.


PS: The ``wrong-name-for-debian-news-file`` tag references 6.3.4.

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

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

Versions of packages lintian depends on:
ii  binutils2.41.90.20240122-1
ii  bzip2   1.0.8-5+b2
ii  diffstat1.65-1
ii  dpkg1.22.2
ii  dpkg-dev1.22.2
ii  file1:5.45-2+b1
ii  gettext 0.21-14
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b3
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b2
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b2
ii  libclone-perl   0.46-1+b1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.2
ii  libemail-address-xs-perl1.05-1+b2
ii  libencode-perl  3.20-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b2
ii  libperlio-utf8-strict-perl  0.010-1+b1
ii  libproc-processtable-perl   0.636-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b1
ii  libsereal-encoder-perl  5.004+ds-1+b1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1+b1
ii  libterm-readkey-perl2.38-2+b2
ii  libtext-levenshteinxs-perl  0.03-5+b2
ii  

Bug#1061451: renpy: remove dependency on python3-future

[Alexandre Detiste]

Package: renpy
Version: 8.0.3+dfsg-1
Severity: serious


pitfall n°1: there's no version 8.2.0: it's a daily snapshot,
 we need to wait for a proper release


pitfall n°2: removing python3-future from RenPy seems not so complicated
 but that _may_ or not break games if they depends
 on renpy/compat/__init__.py

 I don't know how/where to find such game.

 It would be stubbed somehow.



$ renpy/compat/__init__.py  
  

"""
This module is defined to allow us to program in Python 2 with a high degree
of compatibility with Python 3, and vice versa. It's intended to be invoked
with the following preamble::

from __future__ import division, absolute_import, with_statement, 
print_function, unicode_literals
from renpy.compat import *

Right now, it does the following things:

* Sets up aliases for Python 3 module moves, allowing the Python 3 names
  to be used in Python 2.

* Defines PY2 in the current context, to make Python 2 conditional.

* Aliases pickle to cPickle on Python 3, to support Python 2 code
  choosing between the implementations, where the choice is meaningful

* Replaces open with a function that mimics the Python 3 behavior, of
  opening files in a unicode-friendly mode by default.

* Redefines the text types, so that str is always the unicode type, and
  basestring is the list of string types available on the system.

* Exposes bchr, bord, and tobytes from future.utils.

* Changes the meaning of the .items(), .keys(), and .values() methods of
  dict to return views, rather than lists. (This is a fairly major change,
  and so is only available when with_statement and division are both
  imported.

* Aliases xrange to range on Python 2.

* Changes the behavior of TextIOWrapper.write so that bytes strings are promoted
  to unicode strings before being written.
"""

Bug#1017026: ITP: gnome-kiosk -- mutter based compositor for kiosks

[Jeremy Bícha]

control: owner -1 "Mohammed Sadiq "
control: affects -1 src:gnome-kiosk

Thank you Mohammed for working on packaging this. Here is your first review.

1. Please remove debian/control.in, the first few commented lines of
debian/control, and debian/control's Build-Depends: dh-sequence-gnome

The Debian GNOME team has deprecated debian/control.in and is in the
slow process of removing it across their team packages.
dh-sequence-gnome is now only needed for some packages.

2. This package will not build in Experimental (which is where we are
targeting it for now) because it is missing Build-Depends:
libgtk-4-dev

3. Please Build-Depend on dconf-cli instead of libdconf-dev.
meson.build has find_program('dconf') and dconf-cli ships
/usr/bin/dconf

4. I think the ftpmasters will not like that Red Hat is listed in your
debian/copyright but isn't mentioned in the source at all. There are a
few different ways to fix this. One way is to add a Comment field at
the end of the Red Hat paragraph pointing to
https://gitlab.gnome.org/GNOME/gnome-kiosk/-/commit/9cf264d

5. Let's split the package like Fedora did. You can see the file
structure for Fedora's split at
https://koji.fedoraproject.org/koji/buildinfo?buildID=2291875 . Click
info next to the rpm files for noarch (this is equivalent to Debian's
arch: all) and x86_64. Ignore the debuginfo and debugsource files.

For reference, here is Fedora's spec file:
https://src.fedoraproject.org/rpms/gnome-kiosk/blob/f39/f/gnome-kiosk.spec

Thank you,
Jeremy Bícha

Bug#1061450: /usr/bin/dpkg-buildpackage: dpkg-buildpackage does not have tab completion

[Aidan Gallagher]

Package: dpkg-dev
Version: 1.20.12
Severity: wishlist
File: /usr/bin/dpkg-buildpackage
Tags: newcomer
X-Debbugs-Cc: aidg...@gmail.com

Hi,

I'm creating a wrapper around dpkg-buildpackage that allows package builds to 
run in a docker container (https://github.com/aidan-gallagher/debpic).

My package has tab completion for everything however when I added the option to 
specify dpkg-buildpackage options I realised dpkg-buildpackage doesn't have tab 
completion.

I assume this is an easy task that is free for picking up?


-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.35.2-2
ii  bzip2 1.0.8-4
ii  libdpkg-perl  1.20.12
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.32.1-4+deb11u2
ii  tar   1.34+dfsg-1
ii  xz-utils  5.2.5-2.1~deb11u1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.9
ii  fakeroot 1.25.3-1.1
ii  gcc [c-compiler] 4:10.2.1-1
ii  gcc-10 [c-compiler]  10.2.1-6
ii  gnupg2.2.27-2+deb11u2
ii  gpgv 2.2.27-2+deb11u2
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2021.07.26

-- no debconf information

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Diederik de Haas]

Control: tag -1 moreinfo

On Wednesday, 24 January 2024 19:38:16 CET Patrice Duroux wrote:
> Package: src:linux
> Version: 6.7.1-1~exp1
> Severity: normal
> 
> Giving a try to 6.7, here is a message extracted from dmesg:

Is that dmesg output from 6.7(.0) or 6.7.1?
If from 6.7.1, does the error NOT occur with 6.7.0?
If that's the case, can you test the attached patch with the `test-patches`
script? See the following link for instructions:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4>From 48e0efa8ff3b5f97cd2b12040b676dad09dbcefd Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Wed, 24 Jan 2024 19:59:35 +0100
Subject: [PATCH] Revert "drm/amd/display: Pass pwrseq inst for backlight and
 ABM"

This reverts commit f90fb3a482d1d4705603ab6c320de0ccd611055c.
---
 .../drm/amd/display/dc/bios/bios_parser2.c|  4 +-
 .../drm/amd/display/dc/bios/command_table2.c  | 12 ++--
 .../drm/amd/display/dc/bios/command_table2.h  |  2 +-
 .../gpu/drm/amd/display/dc/dc_bios_types.h|  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c |  8 +--
 .../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.c |  7 +--
 .../gpu/drm/amd/display/dc/dce/dmub_abm_lcd.h |  2 +-
 .../amd/display/dc/dcn31/dcn31_panel_cntl.c   |  5 +-
 .../amd/display/dc/hwss/dce110/dce110_hwseq.c | 16 ++---
 .../amd/display/dc/hwss/dcn21/dcn21_hwseq.c   | 36 +++
 drivers/gpu/drm/amd/display/dc/inc/hw/abm.h   |  3 +-
 .../drm/amd/display/dc/inc/hw/panel_cntl.h|  2 -
 .../drm/amd/display/dc/link/link_factory.c| 59 ++-
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   | 14 +
 14 files changed, 53 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index b5b29451d2db..2d1f5efa9091 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1698,7 +1698,7 @@ static enum bp_result bios_parser_enable_disp_power_gating(
 static enum bp_result bios_parser_enable_lvtma_control(
 	struct dc_bios *dcb,
 	uint8_t uc_pwr_on,
-	uint8_t pwrseq_instance,
+	uint8_t panel_instance,
 	uint8_t bypass_panel_control_wait)
 {
 	struct bios_parser *bp = BP_FROM_DCB(dcb);
@@ -1706,7 +1706,7 @@ static enum bp_result bios_parser_enable_lvtma_control(
 	if (!bp->cmd_tbl.enable_lvtma_control)
 		return BP_RESULT_FAILURE;
 
-	return bp->cmd_tbl.enable_lvtma_control(bp, uc_pwr_on, pwrseq_instance, bypass_panel_control_wait);
+	return bp->cmd_tbl.enable_lvtma_control(bp, uc_pwr_on, panel_instance, bypass_panel_control_wait);
 }
 
 static bool bios_parser_is_accelerated_mode(
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
index ab0adabf9dd4..90a02d7bd3da 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.c
@@ -976,7 +976,7 @@ static unsigned int get_smu_clock_info_v3_1(struct bios_parser *bp, uint8_t id)
 static enum bp_result enable_lvtma_control(
 	struct bios_parser *bp,
 	uint8_t uc_pwr_on,
-	uint8_t pwrseq_instance,
+	uint8_t panel_instance,
 	uint8_t bypass_panel_control_wait);
 
 static void init_enable_lvtma_control(struct bios_parser *bp)
@@ -989,7 +989,7 @@ static void init_enable_lvtma_control(struct bios_parser *bp)
 static void enable_lvtma_control_dmcub(
 	struct dc_dmub_srv *dmcub,
 	uint8_t uc_pwr_on,
-	uint8_t pwrseq_instance,
+	uint8_t panel_instance,
 	uint8_t bypass_panel_control_wait)
 {
 
@@ -1002,8 +1002,8 @@ static void enable_lvtma_control_dmcub(
 			DMUB_CMD__VBIOS_LVTMA_CONTROL;
 	cmd.lvtma_control.data.uc_pwr_action =
 			uc_pwr_on;
-	cmd.lvtma_control.data.pwrseq_inst =
-			pwrseq_instance;
+	cmd.lvtma_control.data.panel_inst =
+			panel_instance;
 	cmd.lvtma_control.data.bypass_panel_control_wait =
 			bypass_panel_control_wait;
 	dm_execute_dmub_cmd(dmcub->ctx, , DM_DMUB_WAIT_TYPE_WAIT);
@@ -1012,7 +1012,7 @@ static void enable_lvtma_control_dmcub(
 static enum bp_result enable_lvtma_control(
 	struct bios_parser *bp,
 	uint8_t uc_pwr_on,
-	uint8_t pwrseq_instance,
+	uint8_t panel_instance,
 	uint8_t bypass_panel_control_wait)
 {
 	enum bp_result result = BP_RESULT_FAILURE;
@@ -1021,7 +1021,7 @@ static enum bp_result enable_lvtma_control(
 	bp->base.ctx->dc->debug.dmub_command_table) {
 		enable_lvtma_control_dmcub(bp->base.ctx->dmub_srv,
 uc_pwr_on,
-pwrseq_instance,
+panel_instance,
 bypass_panel_control_wait);
 		return BP_RESULT_OK;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table2.h b/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
index 41c8c014397f..b6d09bf6cf72 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table2.h
@@ -96,7 +96,7 @@ struct cmd_tbl {
 			struct bios_parser *bp, uint8_t id);
 	enum bp_result (*enable_lvtma_control)(struct bios_parser *bp,
 			uint8_t 

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Patrice Duroux]

Yes, the message is from the version 6.7.1-1~exp1, sorry for the doubt.
It is just because, package name is «simply»: linux-image-6.7-amd64
and so I wrote 6.7, expecting the exact version from reportbug.
I will give it a try then and be back.


Le mer. 24 janv. 2024 à 20:02, Diederik de Haas
 a écrit :
>
> Control: tag -1 moreinfo
>
> On Wednesday, 24 January 2024 19:38:16 CET Patrice Duroux wrote:
> > Package: src:linux
> > Version: 6.7.1-1~exp1
> > Severity: normal
> >
> > Giving a try to 6.7, here is a message extracted from dmesg:
>
> Is that dmesg output from 6.7(.0) or 6.7.1?
> If from 6.7.1, does the error NOT occur with 6.7.0?
> If that's the case, can you test the attached patch with the `test-patches`
> script? See the following link for instructions:
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4

Bug#1061423: xpdf: performance of a second text search should be improved

[Adam Sampson]

On Wed, Jan 24, 2024 at 11:30:01AM +0100, Vincent Lefevre wrote:
> With zathura, the first search needs the same time as xpdf, but a
> second search is much faster (almost immediate). xpdf text search
> should be improved to be as fast as zathura.

Looking at the code, Zathura uses poppler-glib, which implements search
in the same way as xpopple -- it renders each page to a TextPage object
and searches the text strings in that. However, poppler-glib caches the
TextPages once they've been rendered, whereas xpopple renders them again
for each new search.

I've just pushed a commit to xpopple git to add a similar cache, which
seems to have the desired effect. It'll use a bit more memory this way
but I don't expect it'll be a concern relative to the size of the rest
of the PDF data...

Cheers,

-- 
Adam Sampson  

Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc

[Ludovic Rousseau]

Le 24/01/2024 à 18:09, Laurent Bigonville a écrit :

Package: pcscd
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

Hello,

When looking at the logs of pcscd, I see the following messages:

jan 22 09:47:37 edoras pcscd[1663]:  auth.c:125:IsClientAuthorized() 
Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: 
Process not found
jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() 
Process 1565 (user: 115) is NOT authorized for action: access_pcsc

It seems that GDM is not allowed to talk to pcscd.

GDM has the functionality to detect whether there is a smartcard in the
reader and then use the gdm-smartcard PAM service instead of the
gdm-password one to perform login.

I guess that GDM should be whitelisted to allow it to use pcscd?


Exact.
Good point.

You can add polkit config file until I fix the issue.
https://blog.apdu.fr/posts/2023/11/pcsc-lite-and-polkit/

Bye

--
Dr. Ludovic Rousseau

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Patrice Duroux]

Package: src:linux
Version: 6.7.1-1~exp1
Severity: normal

Dear Maintainer,

Giving a try to 6.7, here is a message extracted from dmesg:

[4.177226] [ cut here ]
[4.177227] WARNING: CPU: 6 PID: 248 at
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
construct_phy+0xb26/0xd60 [amdgpu]
[4.177658] Modules linked in: amdgpu(+) i915(+) sd_mod drm_exec amdxcp
gpu_sched drm_buddy nvme i2c_algo_bit drm_suballoc_helper drm_display_helper
ahci nvme_core hid_generic crc32_pclmul libahci crc32c_intel t10_pi cec libata
crc64_rocksoft_generic ghash_clmulni_intel rc_core drm_ttm_helper
crc64_rocksoft sha512_ssse3 i2c_hid_acpi ttm rtsx_pci_sdmmc i2c_hid xhci_pci
crc_t10dif sha512_generic mmc_core scsi_mod xhci_hcd drm_kms_helper video hid
crct10dif_generic intel_lpss_pci crct10dif_pclmul i2c_i801 sha256_ssse3
intel_lpss crc64 thunderbolt drm e1000e usbcore sha1_ssse3 rtsx_pci i2c_smbus
scsi_common crct10dif_common idma64 usb_common battery wmi button aesni_intel
crypto_simd cryptd
[4.177689] CPU: 6 PID: 248 Comm: (udev-worker) Not tainted 6.7-amd64 #1
Debian 6.7.1-1~exp1
[4.177691] Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.29.0
11/03/2023
[4.177692] RIP: 0010:construct_phy+0xb26/0xd60 [amdgpu]
[4.178050] Code: b9 01 00 00 00 83 fe 01 74 40 48 8b 82 f8 03 00 00 89 f2
48 c7 c6 00 35 a7 c1 48 8b 40 10 48 8b 00 48 8b 78 08 e8 ba b7 5b fb <0f> 0b 49
8b 87 d0 01 00 00 b9 0f 00 00 00 48 8b 80 e8 04 00 00 48
[4.178052] RSP: 0018:aad300857408 EFLAGS: 00010246
[4.178053] RAX:  RBX: 96df636a1700 RCX:
c000efff
[4.178054] RDX:  RSI: efff RDI:
0001
[4.178055] RBP: 96df4d379c00 R08:  R09:
aad3008571d0
[4.178056] R10: 0003 R11: bded2428 R12:
aad300857474
[4.178057] R13: c1933140 R14: aad3008577d0 R15:
96df43e82000
[4.178058] FS:  7fcd5d9648c0() GS:96e2cc38()
knlGS:
[4.178060] CS:  0010 DS:  ES:  CR0: 80050033
[4.178061] CR2: 7fcd5d932a6d CR3: 000103e9a004 CR4:
003706f0
[4.178062] DR0:  DR1:  DR2:

[4.178063] DR3:  DR6: fffe0ff0 DR7:
0400
[4.178063] Call Trace:
[4.178066]  
[4.178067]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.178422]  ? __warn+0x81/0x130
[4.178426]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.178784]  ? report_bug+0x171/0x1a0
[4.178787]  ? handle_bug+0x3c/0x80
[4.178789]  ? exc_invalid_op+0x17/0x70
[4.178790]  ? asm_exc_invalid_op+0x1a/0x20
[4.178793]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.179149]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.179507]  link_create+0x1b2/0x200 [amdgpu]
[4.179865]  create_links+0x135/0x420 [amdgpu]
[4.180196]  dc_create+0x321/0x640 [amdgpu]
[4.180529]  amdgpu_dm_init.isra.0+0x2a0/0x1ed0 [amdgpu]
[4.180881]  ? sysvec_apic_timer_interrupt+0xe/0x90
[4.180883]  ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
[4.180885]  ? delay_tsc+0x37/0xa0
[4.180889]  dm_hw_init+0x12/0x30 [amdgpu]
[4.181240]  amdgpu_device_init+0x1e42/0x24a0 [amdgpu]
[4.181517]  amdgpu_driver_load_kms+0x19/0x190 [amdgpu]
[4.181793]  amdgpu_pci_probe+0x165/0x4c0 [amdgpu]
[4.182067]  local_pci_probe+0x42/0xa0
[4.182070]  pci_device_probe+0xc7/0x240
[4.182072]  really_probe+0x19b/0x3e0
[4.182075]  ? __pfx___driver_attach+0x10/0x10
[4.182076]  __driver_probe_device+0x78/0x160
[4.182078]  driver_probe_device+0x1f/0x90
[4.182079]  __driver_attach+0xd2/0x1c0
[4.182081]  bus_for_each_dev+0x85/0xd0
[4.182083]  bus_add_driver+0x116/0x220
[4.182085]  driver_register+0x59/0x100
[4.182087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
[4.182356]  do_one_initcall+0x58/0x320
[4.182359]  do_init_module+0x60/0x240
[4.182361]  init_module_from_file+0x89/0xe0
[4.182364]  idempotent_init_module+0x120/0x2b0
[4.182366]  __x64_sys_finit_module+0x5e/0xb0
[4.182367]  do_syscall_64+0x61/0x120
[4.182370]  ? do_syscall_64+0x70/0x120
[4.182372]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[4.182375] RIP: 0033:0x7fcd5e130f19
[4.182376] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d cf 1e 0d 00 f7 d8 64 89 01 48
[4.182378] RSP: 002b:7ffd314afa38 EFLAGS: 0246 ORIG_RAX:
0139
[4.182379] RAX: ffda RBX: 5611ee7f84d0 RCX:
7fcd5e130f19
[4.182380] RDX:  RSI: 7fcd5e2644f5 RDI:
0024
[4.182381] RBP:  R08: 0040 R09:
5611ee7d3140
[4.182382] R10: 0038 R11: 0246 R12:
7fcd5e2644f5
[4.182383] R13: 0002 R14: 5611ee7f0670 R15:

Bug#1061448: "screen -ls" shows incorrect timestamps

[Sergio Durigan Junior]

Package: screen
Version: 4.9.1-1
Severity: minor

Hi,

This is the Debian counterpart of
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/2050938.

"screen -ls" doesn't print correct timestamps.  I noticed that we carry
our own patch to calculate the session creation time, so it's likely
that this is a Debian specific bug, although I haven't checked other
distros.

--8<---cut here---start->8---
root@bla:~# date
Wed Jan 24 06:37:04 PM UTC 2024
root@bla:~# screen -ls
There is a screen on:
470.pts-1.bla   (02/18/2024 03:35:25 PM)(Detached)
1 Socket in /run/screen/S-root.
--8<---cut here---end--->8---

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1061447: O: django-maintenancemode

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-maintenancemode

Orphaning the package on behalf of the Debian Python Team as the sole
uploader (no one else on the team expressed interest in taking over and
I no longer use the package).

The package itself is in reasonable shape.  Upstream is mostly dean, so
if you take over this package, expect to have to do more than just
package new upstream releases.

Scott K

Bug#1015287: Most other distributions support this ...

[Thomas Kuhlmann]

A solution would be really great, because ...

... crypted root and vlan (in combination) are not uncommon.

... all other (large) distributions (Ubuntu, RedHat, SuSe) already 
supports this.


With many thanks in advance,
Thomas

Bug#1061220: w-scan-cpp: Rewrite 'd/watch'. Use GitHub original sources and make repack simpler.

[Phil Wyett]

Hi all,

This was fix in commit: 0b21082cf1b8e5e10f2b7aea71f6d80f19258c90 and will part 
of the next
upload.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1061446: ITP: cosign -- Code signing and transparency for containers and binaries

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: cosign
  Version : 2.2.2-1
  Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
  Programming Lang: Go
  Description : Code signing and transparency for containers and binaries

 Signing OCI containers (and other artifacts) using Sigstore
 (https://sigstore.dev/)!
 .
 Go Report Card
 (https://goreportcard.com/report/github.com/sigstore/cosign) e2e-tests
 (https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml) CII
 Best Practices
 (https://bestpractices.coreinfrastructure.org/projects/5715) OpenSSF
 Scorecard
 (https://api.securityscorecards.dev/projects/github.com/sigstore/cosign)
 .
 Cosign aims to make signatures **invisible infrastructure**.
 .
 Cosign supports:
 .
  * "Keyless signing" with the Sigstore public good Fulcio certificate
authority and Rekor transparency log (default)
  * Hardware and KMS signing
  * Signing with a cosign generated encrypted private/public keypair
  * Container Signing, Verification and Storage in an OCI registry.
  * Bring-your-own PKI
 .
 Info
 .
 Cosign is developed as part of the sigstore (https://sigstore.dev)
 project. We also use a slack channel (https://sigstore.slack.com)! Click
 here (https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-
 XmY3bcfWn4XEyMqUUutbUQ) for the invite link.
 .
 Installation
 .
 For Homebrew, Arch, Nix, GitHub Action, and Kubernetes installs see the
 installation docs
 (https://docs.sigstore.dev/system_config/installation/).
 .
 For Linux and macOS binaries see the GitHub release assets
 (https://github.com/sigstore/cosign/releases/latest).
 .
 :rotating_light: If you are downloading releases of cosign from our GCS
 bucket - please see more information on the July 31, 2023 deprecation
 notice (https://blog.sigstore.dev/cosign-releases-bucket-deprecation/)
 :rotating_light:
 .
 Developer Installation
 .
 If you have Go 1.19+, you can setup a development environment:
 .
   $ git clone https://github.com/sigstore/cosign
   $ cd cosign
   $ go install ./cmd/cosign
   $ $(go env GOPATH)/bin/cosign
 .
 Contributing
 .
 If you are interested in contributing to cosign, please read the
 contributing documentation (/CONTRIBUTING.md).
 .
 Dockerfile
 .
 Here is how to install and use cosign inside a Dockerfile through the
 gcr.io/projectsigstore/cosign image:
 .
   FROM gcr.io/projectsigstore/cosign:v1.13.0 as cosign-bin
 .
   # Source: https://github.com/chainguard-images/static
   FROM cgr.dev/chainguard/static:latest
   COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
   ENTRYPOINT [ "cosign" ]
 .
 Quick Start
 .
 This shows how to:
 .
  * sign a container image with the default "keyless signing" method (see
KEYLESS.md (/KEYLESS.md))
  * verify the container image
 .
 Sign a container and store the signature in the registry
 .
 Note that you should always sign images based on their digest
 (@sha256:...) rather than a tag (:latest) because otherwise you might
 sign something you didn't intend to!
 .
cosign sign $IMAGE
 .
   Generating ephemeral keys...
   Retrieving signed certificate...
 .
Note that there may be personally identifiable information associated
 with this signed artifact.
This may include the email address associated with the account with
 which you authenticate.
This information will be used for signing this artifact and will be
 stored in public transparency logs and cannot be removed later.
 .
   By typing 'y', you attest that you grant (or have permission to grant)
 and agree to have this information stored permanently in transparency
 logs.
   Are you sure you would like to continue? [y/N] y
   Your browser will now be opened to:
 .
 
https://oauth2.sigstore.dev/auth/auth?access_type=online_id=sigstore_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY_challenge_method=S256=2KvOWeTFxYfxyzHtssvlIXmY6Jk_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback_type=code=openid+email=2KvOWfbQJ1caqScgjwibzK2qJmb
   Successfully verified SCT...
   tlog entry created with index: 12086900
   Pushing signature to: $IMAGE
 .
 Cosign will prompt you to authenticate via OIDC, where you'll sign in
 with your email address. Under the hood, cosign will request a code
 signing certificate from the Fulcio certificate authority. The subject
 of the certificate will match the email address you logged in with.
 Cosign will then store the signature and certificate in the Rekor
 transparency log, and upload the signature to the OCI registry alongside
 the image you're signing.
 .
 Verify a container
 .
 To verify the image, you'll need to pass in the expected certificate
 issuer and certificate subject via the --certificate-identity and --
 certificate-oidc-issuer flags:
 .
   cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-
 issuer=$OIDC_ISSUER
 .
 You can also pass in a regex for the certificate 

Bug#1061432: Add OrangePI PC Plus to sunxi platforms

[Vagrant Cascadian]

On 2024-01-24, Лухнов Андрей Олегович wrote:
> please consider adding OrangePI PC Plus to sunxi platforms. Changes
> are trivial, proposed platform is buildable without errors and tested
> bootable on target hardware.
>
> Required changes attached.

Would you or someone else be willing to regularly test new versions of
u-boot as they land in the archive?

  https://wiki.debian.org/U-boot/Status

I prefer to list at least one person with contact information in the
debian/targets.mk file so we know who to ask if problems arise.

Because it supports over a thousand boards, board-specific regressions
are unfortunately all too common in u-boot and it is helpful to find
those regressions early.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1061445: linux-image-6.7-cloud-amd64: Built CONFIG_VIRTIO_BLK into kernel

[Paul Menzel]

Package: linux-image-6.7-cloud-amd64
Version: 6.6.13-1
Severity: normal


Dear Debian folks,


Trying to quickly start a VM, it’d be great to not use an initrd image, 
and also use the Virtio features, for example with the command below:


qemu-system-x86_64 -M q35 -m 32G -enable-kvm -cpu host -smp cpus=32 
-device virtio-rng-pci -net nic,model=virtio-net-pci -net 
user,hostfwd=tcp::5-:22 -drive 
if=virtio,file=/scratch/local2/debian-linux-build.img -vga none -nographic


Currently, that is not possible, as the driver is only available as 
module `virtio_blk.ko` (`CONFIG_VIRTIO_BLK=m`). It’d be great, if it 
could be built into the Linux kernel cloud image.



Kind regards,

Paul

Bug#1061152: asymptote: autopkgtest should test installed package

[Sven Joachim]

Hi Hilmar,

Am 24.01.2024 um 12:42 schrieb Preuße, Hilmar:

> On 19.01.2024 17:23, Sven Joachim wrote:
>
> Hello,
>
>> Your package's autopkgtest runs the upstream test suite which is
>> nice. However, it first builds the program and then tests that,
>> rather than the package from the archive.  This is not very useful,
>> as changes in reverse dependencies could cause breakage at runtime
>> which might vanish after a rebuild.
>> 
>
> Not sure how to change that. I removed the "build-needed" restriction
> from the test suite control file and run the autopkgtest as follows:
>
> autopkgtest asymptote_2.86+ds1-2_amd64.deb asymptote_2.86+ds1-2.dsc --
> schroot unstable-amd64-sbuild
>
> The test fails:
>
> (Reading database ... 52447 files and directories currently installed.)
> Removing autopkgtest-satdep (0) ...
> autopkgtest [12:35:24]: test test-suite: [---
> make: *** No rule to make target 'test'.  Stop.
> autopkgtest [12:35:25]: test test-suite: ---]
> autopkgtest [12:35:25]: test test-suite:  - - - - - - - - - - results
> - - - - - - - - - -
> test-suite   FAIL non-zero exit status 2
> autopkgtest [12:35:25]:  summary
> test-suite   FAIL non-zero exit status 2
>
> ...probably b/c the build did not run yet and there is no Makefile.

Yes, the Makefile is generated from Makefile.in.

> Were you able to run the test suite w/o running a build first? If yes
> let me know how. Thanks!

I have not tried it, but in the tests/ directory there is a nice
Makefile which can be used.  It only needs to be persuaded to run the
installed asy program rather than the one from the parent directory.

Something like the attached patch might work, at least if run the
test-suite script under autopkgtest (otherwise you need to create the
$AUTOPKGTEST_TMP temporary directory first).

Sorry for not having tested the patch - actually I do not use asymptote,
only its strange autopkgtest failures like [1] last week motivated me to
look at it.

Good luck,
Sven


1. https://ci.debian.net/packages/a/asymptote/testing/amd64/41886606/

diff --git a/debian/tests/test-suite b/debian/tests/test-suite
index cff9edf2..21797e58 100644
--- a/debian/tests/test-suite
+++ b/debian/tests/test-suite
@@ -2,5 +2,9 @@

 set -e

+cp -a tests "$AUTOPKGTEST_TMP"
+ln -s /usr/share/asymptote "$AUTOPKGTEST_TMP"/base
+ln -s /usr/bin/asy "$AUTOPKGTEST_TMP"/asy
+
 export ASYMPTOTE_HOME=$(mktemp -d)
-make test
\ No newline at end of file
+make -C "$AUTOPKGTEST_TMP"/tests all

Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc

[Laurent Bigonville]

Package: pcscd
Version: 2.0.1-1
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

Hello,

When looking at the logs of pcscd, I see the following messages:

jan 22 09:47:37 edoras pcscd[1663]:  auth.c:125:IsClientAuthorized() 
Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: 
Process not found
jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() 
Process 1565 (user: 115) is NOT authorized for action: access_pcsc

It seems that GDM is not allowed to talk to pcscd.

GDM has the functionality to detect whether there is a smartcard in the
reader and then use the gdm-smartcard PAM service instead of the
gdm-password one to perform login.

I guess that GDM should be whitelisted to allow it to use pcscd?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages pcscd depends on:
ii  init-system-helpers 1.66
ii  libc6   2.37-13
ii  libccid [pcsc-ifd-handler]  1.5.5-1
ii  libglib2.0-02.78.3-1
ii  libpcsclite12.0.1-1
ii  libpolkit-gobject-1-0   124-1
ii  libsystemd0 255.2-4
ii  libudev1255.2-4

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  255.2-4

-- no debconf information

Bug#1061301: test failures are caused by python3.12

[Matthias Klose]

looks like the tests pass with python 3.11, but fail with 3.12. Not 
related to any network lookups.


Is there a reason that the tests are not run for all supported Python 
versions?

Bug#1061443: exit

[wedwe]

Package: weded
Severity: wishlist
X-Debbugs-Cc: o...@gmail.com




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

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

Bug#1060706: Info received (Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable)

[Arno Lehmann]

Some news, but unfortunately not helping me to understand what we see :-)

Network link was lost during the day.

dmesg shows this:
[Tue Jan 23 06:54:24 2024] igc :0a:00.0 eno1: NIC Link is Up 1000 
Mbps Full Duplex, Flow Control: RX
[Tue Jan 23 16:24:13 2024] [drm:retrieve_link_cap [amdgpu]] *ERROR* 
retrieve_link_cap: Read receiver caps dpcd data failed.

[Tue Jan 23 23:09:16 2024] igc :0a:00.0 eno1: NIC Link is Down
[Tue Jan 23 23:09:19 2024] igc :0a:00.0 eno1: NIC Link is Up 1000 
Mbps Full Duplex, Flow Control: RX

[Wed Jan 24 12:00:23 2024] systemd-journald[750]:
[Wed Jan 24 14:46:17 2024] nfs: server  not responding, timed out
[Wed Jan 24 14:46:17 2024] nfs: server  not responding, timed out
[Wed Jan 24 17:00:09 2024] nfs: server  not responding, timed out

Here, I rmmod'ed the igc module and modprobe'd it immediately.

[Wed Jan 24 17:00:36 2024] igc :0a:00.0 eno1: PHC removed
[Wed Jan 24 17:00:42 2024] Intel(R) 2.5G Ethernet Linux Driver
[Wed Jan 24 17:00:42 2024] Copyright(c) 2018 Intel Corporation.
[Wed Jan 24 17:00:42 2024] igc :0a:00.0: PCIe PTM not supported by 
PCIe bus/controller

[Wed Jan 24 17:00:42 2024] pps pps0: new PPS source ptp0
[Wed Jan 24 17:00:42 2024] igc :0a:00.0 (unnamed net_device) 
(uninitialized): PHC added
[Wed Jan 24 17:00:42 2024] igc :0a:00.0: 4.000 Gb/s available PCIe 
bandwidth (5.0 GT/s PCIe x1 link)

[Wed Jan 24 17:00:42 2024] igc :0a:00.0 eth0: MAC: c8:7f:54:67:6d:cc
[Wed Jan 24 17:00:42 2024] igc :0a:00.0 eno1: renamed from eth0
[Wed Jan 24 17:00:45 2024] igc :0a:00.0 eno1: NIC Link is Up 1000 
Mbps Full Duplex, Flow Control: RX
[Wed Jan 24 17:00:45 2024] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link 
becomes ready



So, we have a case of the NIC becoming unresponsive for some reason, but 
I can not see or even guess the reason. I'll leave the system as it is 
for a few more days, I think, and then try a much newer kernel.


Or -- any better suggestions?

Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1061442: plymouth: unable to boot with the message : "begin : running /scripts/init-premount ...."

[guillaume]

Package: plymouth
Version: 24.004.60-1
Severity: important
Tags: a11y
X-Debbugs-Cc: miste...@hotmail.com

Dear Maintainer,

since these new update version, the pc is not booting.
with a downgrade to the previous version, the pc is booting and everything is
ok.

when i have this error message : "begin : running /scripts/init-premount ",
i just can reboot.
no escape, no console log, nothing.

to resolve that, i remove the splash option in the boot and everything is ok.

regards
Guillaume


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

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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.66
ii  initramfs-tools  0.142
ii  libc62.37-14
ii  libdrm2  2.4.120-1
ii  libplymouth5 24.004.60-1
ii  systemd  255.2-4
ii  udev 255.2-4

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 12.0.6+nmu1
pn  plymouth-themes  

-- no debconf information

Bug#1061441: python-glanceclient: autopkgtest failure with Python 3.12

[Graham Inggs]

Source: python-glanceclient
Version: 1:4.4.0-2
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

python-glanceclient's autopkgtests fail with Python 3.12 [1].  I've
copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-glanceclient/testing/amd64/


75s ==
75s FAIL: 
glanceclient.tests.unit.test_ssl.TestHTTPSVerifyCert.test_v1_requests_cert_verification
75s 
glanceclient.tests.unit.test_ssl.TestHTTPSVerifyCert.test_v1_requests_cert_verification
75s --
75s testtools.testresult.real._StringException: Traceback (most recent
call last):
75s File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 716, in urlopen
75s httplib_response = self._make_request(
75s ^^^
75s File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 405, in _make_request
75s self._validate_conn(conn)
75s File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py",
line 1059, in _validate_conn
75s conn.connect()
75s File "/usr/lib/python3/dist-packages/urllib3/connection.py", line
419, in connect
75s self.sock = ssl_wrap_socket(
75s 
75s File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line
453, in ssl_wrap_socket
75s ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls)
75s 
75s File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line
495, in _ssl_wrap_socket_impl
75s return ssl_context.wrap_socket(sock)
75s ^
75s File "/usr/lib/python3.12/ssl.py", line 455, in wrap_socket
75s return self.sslsocket_class._create(
75s ^
75s File "/usr/lib/python3.12/ssl.py", line 1046, in _create
75s self.do_handshake()
75s File "/usr/lib/python3.12/ssl.py", line 1321, in do_handshake
75s self._sslobj.do_handshake()
75s ssl.SSLEOFError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred
in violation of protocol (_ssl.c:1000)

...

75s --
75s Ran 693 tests in 3.084s
75s
75s FAILED (failures=4, skipped=7)
75s + echo ==> STESTR TEST SUITE FAILED FOR python3.12: displaying
pip3 freeze output...
75s + [ -x /usr/bin/pip3 ]
75s + pip3 freeze

Bug#1061440: azure-cosmos-table-python: autopkgtest failure with Python 3.12

[Graham Inggs]

Source: azure-cosmos-table-python
Version: 1.0.5+git20191025-6
Severity: serious
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

azure-cosmos-table-python's autopkgtests fail with Python 3.12 [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/a/azure-cosmos-table-python/testing/amd64/


279s === FAILURES
===
279s ___ StorageTableTest.test_set_table_acl_too_many_ids
___
279s
279s self = 
279s
279s def recording_test(self):
279s with self.recording():
279s > test(self)
279s
279s tests/testcase.py:383:
279s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
279s
279s self = 
279s
279s @record
279s def test_set_table_acl_too_many_ids(self):
279s # Arrange
279s table_name = self._create_table()
279s
279s # Act
279s identifiers = dict()
279s for i in range(0, 6):
279s identifiers['id{}'.format(i)] = AccessPolicy()
279s
279s # Assert
279s > with self.assertRaisesRegexp(AzureException,
279s 'Too many access policies provided. The server does not support
setting more than 5 access policies on a single resource.'):
279s E AttributeError: 'StorageTableTest' object has no attribute
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?
279s
279s tests/table/test_table.py:342: AttributeError

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

[Quanah Gibson-Mount]

--On Wednesday, January 24, 2024 3:07 PM +0100 wouldsmina 
 wrote:





Hello,


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


To reproduce, simply activate the dynlist module and try to make an LDAP
query. In slapd.conf add:

moduleload   dynlist
overlay dynlist


Likely .

--Quanah

Bug#1061439: initramfs-tools-core: since zstd raid mapper not implemented in initramfs

[Christian Kiss]

Package: initramfs-tools-core
Version: 0.142
Severity: important
X-Debbugs-Cc: christianpeterk...@yahoo.com

Dear Maintainer,

since change of compression of kernel initramfs 5.9 to zstd

#keypoint update-initramfs does not seem to include the correct raid mappers

any boot drops to a shell early on which lists
a dos ptuuid
sda as part of a raid
sdb as part of a raid
but

#keypoint not the mapper withe raid

not boot not root
this is a bug

i suspected itis

#keypoint because of change of bullseye to bookworm
but it doesnot seem to get fixed

cc i use a backedup initramfs of a former kernel but since bullseye there is no
upgraded bookworm or bullseye kernel bootable since


all the best

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 
'oldstable')
Architecture: i386 (i686)

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.47.0-2
ii  klibc-utils  2.0.12-1
ii  kmod 30+20221128-1
ii  logsave  1.47.0-2
ii  udev 252.19-1~deb12u1

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.35.0-4+b3
ii  zstd 1.5.4+dfsg2-5

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-6

-- no debconf information

Bug#1060746: Info received (Wrong text for resource tab)

[Sergio Vavassori]

Hello,

Here is the recently published upstream release with the fix:
https://github.com/mate-desktop/mate-system-monitor/releases/tag/v1.26.3

Regards,
Sergio

Bug#1061438: tpm2-tss: can't upgrade the tpm2-tss packages to 4.0.1-6; missing Conflicts?

[Vincent Lefevre]

Source: tpm2-tss
Version: 4.0.1-6
Severity: serious

It is not possible to upgrade the tpm2-tss packages to 4.0.1-6 with
"apt upgrade" or with aptitude (command line or its TUI, without a
*manual* dependency resolution):

root@disset:~# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  libtss2-esys-3.0.2-0 libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0
  libtss2-tcti-mssim0 libtss2-tcti-swtpm0
[...]

This is apparently due to the rename of libtss2-mu0 to
libtss2-mu-4.0.1-0. This latter package has a Breaks+Replaces,
but is that sufficient? i.e. isn't Conflicts needed?

https://wiki.debian.org/RenamingPackages says "Conflicts should only
be used if two packages can never be unpacked at the same time",
which is the case for libtss2-mu0 and libtss2-mu-4.0.1-0.

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

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

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

[wouldsmina]

Hello,

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

To reproduce, simply activate the dynlist module and try to make an LDAP
query. In slapd.conf add:
moduleload   dynlist
overlay dynlist

Thanks,
Saïd

Bug#1061418: [Pkg-pascal-devel] Bug#1061418: castle-game-engine: please add support for loong64

[Michalis Kamburelis]

Hi,

(Upstream of CGE here.)

For a new architecture, we need to have FPC (our compiler) with the
appropriate support for the architecture first.

- And at least upstream FPC 3.2.2 doesn't have this support (the CPU
isn't listed in
https://gitlab.com/freepascal.org/fpc/source/-/blob/fixes_3_2/packages/fpmkunit/src/fpmkunit.pp?ref_type=heads
).

- Only FPC from GitLab (not yet released) has this, and it is called
"loongarch64" (see
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fpmkunit/src/fpmkunit.pp
). I don't know whether the support is considered stable or not.

- The FPC in Debian (
https://packages.debian.org/sid/fp-compiler-3.2.2 ) isn't released for
this architecture.

So, we need FPC to support this architecture (in some stable way), and
we need this FPC to be packaged in Debian, first.

Then adding it to CGE will be easy :)

- Once the FPC (at least packaged in Debian) has this supported, then
CGE unit ToolArchitectures ( tools/common-code/toolarchitectures.pas )
should be extended, to add a new enum to TCPU type.

- Extending the ToolDebian", as the attached patch does, is also nice
(but optional, it's only useful for `castle-engine package
--format=deb` to create DEBs of your games for new architeture; it's
not necessary to just build applications for new architecture).

- The attached patch just adds "loong64: Result := 'loong64';" to
"ToolDebian" but I don't think it can compile right now -- it
certainly doesn't compile with FPC 3.2.2 upstream.

Regards,
Michalis

śr., 24 sty 2024 o 09:18 wuruilong  napisał(a):
>
> Source: castle-game-engine
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
>
> Dear Maintainer,
>
> Please refer to the attachment patch to support loong64 arch
>
> wuruilong
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
>
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> ___
> Pkg-pascal-devel mailing list
> pkg-pascal-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

[Jeremy Bícha]

Source: firefox-esr
Version: 115.6.0esr-1
Severity: serious
Tags: ftbfs patch sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

mozjs115 115.7.0 failed to build on Ubuntu 24.04 LTS which is one step
ahead of Debian on the Python 3.12 transition. I didn't check the
firefox-esr build but I assume it would probably have the same
failure.

https://launchpad.net/ubuntu/+source/mozjs115/115.7.0-1/+latestbuild/amd64

I found a fix for this issue in the source for Firefox 120 and I
adapted it to work with the mozjs115 package.
https://salsa.debian.org/gnome-team/mozjs/-/blob/debian/115/master/debian/patches/python3.12-six.patch

Thank you,
Jeremy Bícha

Bug#1061436: RFP: python3-sphinxcontrib.django -- Sphinx extension which improves the documentation of Django apps

[Elena Grandi]

Package: wnpp
Severity: wishlist

* Package name: python3-sphinxcontrib.django
  Version : 2.5
  Upstream Contact: Diederik van der Boor 
* URL : https://github.com/sphinx-doc/sphinxcontrib-django
* License : Apache 2.0
  Programming Lang: Python
  Description : Sphinx extension which improves the documentation of Django 
apps

Sphinx extension for adding django-specific improvements to the output
of Sphinx, as well as custom markup.

This package will be required to build (the documentation of) version
3.4 of python-django-registration.

Bug#1061435: lintian-brush ftbfs with updated pyo3 version

[Matthias Klose]

Package: src:lintian-brush
Version: 2.0.5-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

the package ftbfs, with:

running build_rust
cargo build --manifest-path debianize/Cargo.toml 
--message-format=json-render-diagnostics --release -v

error: failed to select a version for the requirement `pyo3 = "^0.19"`
candidate versions found which didn't match: 0.20.2
location searched: directory source `/usr/share/cargo/registry` (which 
is replacing registry `crates-io`)
required by package `lintian-brush v0.150.0 
(/home/packages/tmp/lintian-brush-0.152ubuntu1/lintian-brush)`



relaxing that in Cargo.toml to >= 0.19 lets the build succeed (and build 
with python3-defaults from experimental).

Bug#741496: old syslog.service bug still alive

[Aleksi Suhonen]

Hi,

FWIW, I just ran into this bug on several machines while switching from 
inetutils-syslogd to rsyslog. Not being very familiar with systemd, I 
scratched my head for a few days with it.


My workaround at the end:

for e in stop disable enable start; do systemctl $e rsyslog; done
logger test
tail /var/log/syslog

Hoping this helps others running into the bug,

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail

Bug#1061263: spglib: buildsystem could be switched to scikit-build-core

[Andrius Merkys]

Hi,

On 2024-01-23 09:32, Andrius Merkys wrote:
I think both #1061263 and #1061357 could be solved by switching spglib's 
buildsystem to one based on scikit-build-core, as its pyproject.toml 
supports that.


I made an attempt to build spglib with scikit-build-core by specifying 
'--buildsystem pybuild' in debian/rules, adding the required build 
dependencies and patching pyproject.toml to run tests for Python. As 
expected, spglib is built for all supported Python versions. Shared 
libraries are built as well, but they are built for every supported 
Python version separately and are different (at least of same size). 
Fortran interface does not get built at all.


So the buildsystem could be switched, possibly resolving both #1061263 
and #1061357, but with the price of losing Fortran interface and strange 
issue with different shared libraries (maybe just an unreproducible build).


Best,
Andrius

Bug#1061417: RFS: pusimp/0.1.0-1 [ITP] -- prevent user-site imports (python3)

[Francesco Ballarin]

Adding debian-pyt...@lists.debian.org in 
cc


On Wed, Jan 24, 2024 at 7:39 AM Francesco Ballarin 
mailto:francesco.balla...@unicatt.it>> wrote:
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: 
francesco.balla...@unicatt.it

Dear mentors,

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

 * Package name : pusimp
   Version  : 0.1.0-1
   Upstream contact : Francesco Ballarin 
mailto:francesco.balla...@unicatt.it>>
 * URL  : https://github.com/python-pusimp/pusimp
 * License  : MIT
 * Vcs  : https://salsa.debian.org/python-team/packages/pusimp
   Section  : python3

The source builds the following binary packages:

  python3-pusimp -- prevent user-site imports (Python 3)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pusimp/pusimp_0.1.0-1.dsc

pusimp is a python library to prevent user-site imports of specific
dependencies of a package. The typical scenario for using pusimp is
in combination with a system manager (e.g., apt for Debian), to prevent
dependencies from being loaded from user-site instead of the location
provided by the system manager.

We designed pusimp with in mind the specific use case of the FEniCS
project. It happens often that users post messages at the FEniCS discourse
forum asking why their ubuntu/debian installation is not working correctly,
and several times this is due to the presence of user-made installation
attempts in user-site locations. For whatever reason, this happens
somewhat frequently, see for instance
https://fenicsproject.discourse.group/t/installation-trouble/13029/16
https://fenicsproject.discourse.group/t/hdf5-update-didnt-work/13323/4
https://fenicsproject.discourse.group/t/ubuntu-18-04-importerror-cannot-import-name-sub-forms-by-domain/4257/14
https://fenicsproject.discourse.group/t/unknown-ufl-object-type-vectorelement-error/13145/2
https://fenicsproject.discourse.group/t/importerror-cannot-import-name-abstractfiniteelement-from-ufl-finiteelement/13154/2
for five examples of users who made this same mistake in the last 30
days.

We thus initially plan to use pusimp in the python3-dolfin and
python3-dolfinx packages, but the logic behind pusimp is purposely
simple and general and could also be used for other packages which have
similar issues.
See
https://salsa.debian.org/science-team/fenics/dolfin/-/merge_requests/4
for an example of some error messages that pusimp would produce for the
python3-dolfin package.

This RFS will close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060805

Cheers,
Francesco Ballarin
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 

Bug#1061434: python 3.12 extension not working

[Matthias Klose]

Package: python3-levenshtein
Version: 0.12.2-2+b5
Severity: serious
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12


the python 3.12 extension is not working:

$ python3.12 -c 'import Levenshtein'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/Levenshtein/__init__.py", line 
1, in 

from Levenshtein import _levenshtein
ImportError: 
/usr/lib/python3/dist-packages/Levenshtein/_levenshtein.cpython-312-x86_64-linux-gnu.so: 
undefined symbol: PyUnicode_AS_UNICODE