Bug#1100060: gobject-introspection 1.83 causes build failures

[Jeremy Bícha]

The correct link is https://bugs.debian.org/1100054 which was fixed
today. I think we want gir-rust-code-generator to migrate to Testing
before we let gobject-introspection migrate.

Thank you,
Jeremy Bícha

Bug#1100072: initscripts: Provide script to load kernel modules during boot

[Mark Hindley]

Control: severity -1 important

Tim,

Thanks.

Yes, we became aware of this yesterday[1], but it is complicated by src:sysvinit
about to enter freeze.

I pushed unreleased code for testing to src:sysvinit salsa yesterday.

On Mon, Mar 10, 2025 at 11:32:54PM +0100, Tim H. wrote:
> [1] 
> https://salsa.debian.org/md/kmod/-/commit/c2ae42ca3a338fba0f190e3a61a635d386b1e8fa

This will need resolving in src:kmod unless we rename the initscript. But that
will lose sysadmin modifications.

Mark

[1]  https://bugs.debian.org/1100035

Bug#1100081: pyspread: creates /usr/pyspread/share/applications/ instead of using /usr/share/applications/

[cacin]

Source: pyspread
Version: 2.3.1-2
Severity: serious
Justification: Policy 9.1.1
X-Debbugs-Cc: ca...@allfreemail.net

Dear Maintainer,

pyspread creates the directory /usr/pyspread/share/applications/ and
places its .desktop entry into that directory, instead of using the
correct /usr/share/applications/ directory for that purpose.

I cannot pinpoint where exactly in the debian policy it is disallowed,
maybe a combination of §9.1.1 [1] "The location of all files and
directories must comply with the Filesystem Hierarchy Standard (FHS),
version 3.0, [...]" and FHS [2]. It is however definitely the wrong
location for the .desktop entry, and does not function as intended.

[1] 
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#theUsrHierarchy

Bug#1100076: gcc-avr: Missing man page for "avr-gcc" command

[Steve M]

On Mon, 2025-03-10 at 22:22 -0500, R Philley wrote:
> Package: gcc-avr
> Version: 1:5.4.0+Atmel3.6.2-3
> Severity: minor
> X-Debbugs-Cc: rp80...@flash.net
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> Needed to lookup options for the "avr-gcc" command. Could not find a
> man page.
> As "gcc" has a companion package "gcc-doc", I looked for and could
> not find a
> package "gcc-avr-doc". Tried the "gcc" man page, but it was not
> helpful due
> different version levels.
> 
> avr-gcc --version:  avr-gcc (GCC) 5.4.0
> gcc --version:  gcc (Debian 12.2.0-14) 12.2.0
> 
> Specifically, I was looking for program optimization options. Tried
> "-Oz" from
> "gcc" man page, but it was not supported by "avr-gcc".
> 
> This leads me to humbly request that the man for "avr-gcc" be built
> into an
> installable package. (Perhaps "gcc-avr-doc" ?)
> 
> 
> Any attention to this issue would be appreciated. Thanks!
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'),
> (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-31-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gcc-avr depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.6.2-4
> ii  libc6 2.36-9+deb12u9
> ii  libgmp10  2:6.2.1+dfsg1-1.1
> ii  libmpc3   1.3.1-1
> ii  libmpfr6  4.2.0-1
> ii  zlib1g    1:1.2.13.dfsg-1
> 
> gcc-avr recommends no packages.
> 
> Versions of packages gcc-avr suggests:
> ii  avr-libc  1:2.0.0+Atmel3.6.2-3
> ii  gcc   4:12.2.0-3
> ii  gcc-doc   5:12.2.0-1
> 
> -- no debconf information

You will probably get better results by updating your AVR toolchain to
the latest if possible.

$ avr-gcc --version
avr-gcc (GCC) 14.2.0

$ avr-gcc --help=optimizers
The following options control optimizations:
  -O  Set optimization level to .
  -Ofast  Optimize for speed disregarding exact
standards compliance.
  -Og Optimize for debugging experience rather
than speed or size.
  -Os Optimize for space rather than speed.
  -Oz Optimize for space aggressively rather
than speed.
<...>

For a trivial example:
$ rm a.out
$ avr-gcc -mmcu=attiny1616 -Oz main.c
$ avr-size a.out
   textdata bss dec hex filename
210   0   0 210  d2 a.out

You may also wish to refer to /usr/share/doc/gcc-avr/README.Debian

Thanks
-Steve

Bug#1100078: budie-desktop: something weird happen, it causes login failure

[Kentaro Hayashi]

Package: budgie-desktop
Version: 10.9.2-7
Severity: important
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,

* What led up to the situation?

Can't login to budgie-desktop environment.

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

1. Install budgie-desktop
2. Switch from GNOME to budgie-desktop from GDM
3. Try to login

* What was the outcome of this action?

In step 3, shown something wrong happen dialog, and only can do
Alt+L (logout)

* What outcome did you expect instead?

No login failure.

Additional Information:

Recently GNOME components were frequently updated toward GNOME 48,
so it might be related, but not identified yet.

Here are installed packages about budgie-desktop:

* budgie-control-center 1.4.0-5.1
* budgie-control-center-data 1.4.0-5.1
* budgie-core 10.9.2-7
* budgie-desktop 10.9.2-7
* budgie-desktop-view 1.3-2
* budgie-session 0.9.1-3
* gir1.2-budgie-1.0 10.9.2-7
* gir1.2-budgieraven-1.0 10.9.2-7
* libbudgie-appindexer0 10.9.2-7
* libbudgie-plugin0 10.9.2-7
* libbudgie-private0 10.9.2-7
* libbudgie-raven-plugin0 10.9.2-7
* libbudgietheme0 10.9.2-7
* libraven0 10.9.2-7


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

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

Versions of packages budgie-desktop depends on:
ii  blueman  2.4.3-1+b1
ii  budgie-control-center1.4.0-5.1
ii  budgie-core  10.9.2-7
ii  dconf-cli0.40.0-5
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-5
ii  network-manager-applet   1.36.0-3+b1
ii  xdotool  1:3.20160805.1-5+b2

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view 1.3-2
ii  gir1.2-budgie-1.0   10.9.2-7
ii  gir1.2-budgieraven-1.0  10.9.2-7

Versions of packages budgie-desktop suggests:
ii  budgie-desktop-environment  0.1.1-3
ii  gnome-terminal  3.55.91-1
ii  nautilus48~rc-2

-- no debconf information

Bug#1100082: xserver-xorg-video-amdgpu: amdgpu segfault using retroarch craft core

[Patrick Hibbs]

Package: xserver-xorg-video-amdgpu
Version: 23.0.0-1
Severity: normal
X-Debbugs-Cc: hibbsncc1...@gmail.com

Dear Maintainer,

   While playing with the retroarch core Craft (Minecraft), the system's gpu
crashed. It's reset attempt didn't complete properly, and the X11 server was
killed.
   Booting the user out and killing all other active programs in the session.
After which, the user was able to log back in and from the dm and continue
using the
   system normally. A system reboot was not required.

   I've attached the dmesg output from the kernel.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Phoenix1 [1002:15bf] (rev 04)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.1.0-31-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 39939 Mar 11 02:06 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 32569 Mar 11 03:00 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[  5680.364] 
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[  5680.364] Current Operating System: Linux yui 6.1.0-31-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64
[  5680.364] Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-31-amd64 
root=UUID=f1331b8f-1b83-4b87-97ad-0958831bf642 ro quiet
[  5680.364] xorg-server 2:21.1.7-3+deb12u9 (https://www.debian.org/support) 
[  5680.364] Current version of pixman: 0.42.2
[  5680.364]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  5680.364] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  5680.364] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 11 03:00:18 
2025
[  5680.365] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  5680.365] (==) No Layout section.  Using the first Screen section.
[  5680.365] (==) No screen section available. Using defaults.
[  5680.365] (**) |-->Screen "Default Screen Section" (0)
[  5680.365] (**) |   |-->Monitor ""
[  5680.365] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  5680.365] (==) Automatically adding devices
[  5680.365] (==) Automatically enabling devices
[  5680.365] (==) Automatically adding GPU devices
[  5680.365] (==) Automatically binding GPU devices
[  5680.365] (==) Max clients allowed: 256, resource mask: 0x1f
[  5680.365] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  5680.365]Entry deleted from font path.
[  5680.365] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  5680.365] (==) ModulePath set to "/usr/lib/xorg/modules"
[  5680.365] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  5680.365] (II) Loader magic: 0x560bc964cf00
[  5680.365] (II) Module ABI versions:
[  5680.365]X.Org ANSI C Emulation: 0.4
[  5680.365]X.Org Video Driver: 25.2
[  5680.365]X.Org XInput driver : 24.4
[  5680.365]X.Org Server Extension : 10.0
[  5680.366] (++) using VT number 7

[  5680.366] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  5680.368] (II) xfree86: Adding drm device (/dev/dri/card0)
[  5680.368] (II) Platform probe for 
/sys/devices/pci:00/:00:08.1/:09:00.0/drm/card0
[  5680.395] (--) PCI:*(9@0:0:0) 1002:15bf:1043:17f3 rev 4, Mem @ 
0x781000/268435456, 0xfc20/2097152, 0xfc70/524288, I/O @ 
0xe000/256
[  5680.396] (II) LoadModule: "glx"
[  5680.396] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  5680.397] (II) Module glx: vendor="X.Org Foundation"
[  5680.397]compiled for 1.21.1.7, module version = 1.0.0
[  5680.397]ABI class: X.Org Server Extension, version 10.0
[  5680.397] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[  5680.397]loading driver: amdgpu
[  5680.397] (==) Matched amdgpu as autoconfig

Bug#1099802: borgmatic: Weird message durig dist-upgrade

[Geoffroy Youri Berret]

Hi Martin

Thanks for your feedback :)

On Sat, 08 Mar 2025 12:31:17 +0100 Martin Dosch  wrote:
>
> during upgrading I got the following message:
> 
> Pay attention to changes in borgmatic when upgrading!
> 
> Look for breaking changes since bookworm version 1.7.7 in
> /usr/share/doc/borgmatic/changelog.gz
> 
> IMO you should list breaking changes directly instead of asking people
> to look in the changelog to check if there are breaking changes.

Because there was so many changes, I though it was better to point to
the exhaustive changelog and let users identify what is relevant for
their setup.

Anyway here is a extract I made, what do you think?

---8<---

1.9.3
 * deprecate the "store_config_files" option at the global scope and move it 
under the "bootstrap"
   hook. see the documentation for more information:
   
https://torsion.org/borgmatic/docs/how-to/extract-a-backup/#extract-the-configuration-files-used-to-create-an-archive

1.9.2
 * #722: remove the restriction that the "extract" and "mount" actions must 
match a single
   repository. now they work more like other actions, where each repository is 
applied in turn.

1.9.0
 * #609: breaking: apply the "working_directory" option to all actions, not 
just "create". this
   includes repository paths, destination paths, mount points, etc.
 * #562: deprecate the "borgmatic_source_directory" option in favor of 
"user_runtime_directory"
   and "user_state_directory".
 * #562: breaking: move the default borgmatic streaming database dump and 
bootstrap metadata
   directory from ~/.borgmatic to /run/user/$uid/borgmatic, which is more 
xdg-compliant. you can
   override this location with the new "user_runtime_directory" option. 
existing archives with
   database dumps at the old location are still restorable.
 * #562, #638: move the default check state directory from ~/.borgmatic to
   ~/.local/state/borgmatic. this is more xdg-compliant and also prevents these 
state files from
   getting backed up (unless you explicitly include them). you can override 
this location with the
   new "user_state_directory" option. after the first time you run the "check" 
action with borgmatic
   1.9.0, you can safely delete the ~/.borgmatic directory.
 * #838: breaking: with borg 1.4+, store database dumps and bootstrap metadata 
in a "/borgmatic"
   directory within a backup archive, so the path doesn't depend on the current 
user. this means
   that you can now backup as one user and restore or bootstrap as another 
user, among other use
   cases.
 * #915: breaking: rename repository actions like "rcreate" to more explicit 
names like
   "repo-create" for compatibility with recent changes in borg 2.0.0b10.
 * #918: breaking: when databases are configured, don't auto-enable the 
"one_file_system" option,
   as existing auto-excludes of special files should be sufficient to prevent 
borg from hanging on
   them. but if this change causes problems for you, you can always enable 
"one_file_system"
   explicitly.
 * #921: breaking: change soft failure command hooks to skip only the current 
repository rather than
   all repositories in the configuration file.
 * when using borg 2, default the "archive_name_format" option to just 
"{hostname}", as borg 2 does
   not require unique archive names; identical archive names form a common 
"series" that can be
   targeted together. see the borg 2 documentation for more information:
   
https://borgbackup.readthedocs.io/en/2.0.0b13/changes.html#borg-1-2-x-1-4-x-to-borg-2-0

1.8.5
 * #701: deprecate the "disabled" value for the "checks" option in favor of the 
new "skip_actions"
   option.

1.8.3
 * #665: breaking: simplify logging logic as follows: syslog verbosity is now 
disabled by
   default, but setting the "--syslog-verbosity" flag enables it regardless of 
whether you're at an
   interactive console. additionally, "--log-file-verbosity" and 
"--monitoring-verbosity" now
   default to 1 (info about steps borgmatic is taking) instead of 0. and both 
syslog logging and
   file logging can be enabled simultaneously.

1.8.0
 * #575: breaking: for the "borgmatic borg" action, instead of implicitly 
injecting
   repository/archive into the resulting borg command-line, pass repository to 
borg via an
   environment variable and make archive available for explicit use in your 
commands. see the
   documentation for more information:
   https://torsion.org/borgmatic/docs/how-to/run-arbitrary-borg-commands/
 * #721: remove configuration sections ("location:", "storage:", "hooks:", 
etc.), while still
   keeping deprecated support for them. now, all options are at the same level, 
and you don't need
   to worry about commenting/uncommenting section headers when you change an 
option (if you remove
   your sections first).
 * #721: breaking: the retention prefix and the consistency prefix can no 
longer have different
   values (unless one is not set).
 * #721: breakin

Bug#1100001: ITS: phzero

[Andreas Tille]

Hi Peter,

Am Tue, Mar 11, 2025 at 01:34:58AM + schrieb Peter Green:
> (assuming phzero is a typo for pgzero)

Sorry, yes, that was a typo.

> I was asked to help get pgzero into Debian, but I'm not
> particularly a python expert and I don't use it personally.
> 
> Please feel free to update the package, modernize the packaging
> and bring it into the python team, I'm already technically a
> member of said team.

Thanks a lot for the quick confirmation.  I'll upload on behalf
of the DPT.

Kind regards
Andreas. 
 
> On 10/03/2025 07:08, Andreas Tille wrote:
> > Source: pgzero
> > Version: 1.2.post4+dfsg-2
> > Severity: important
> > X-Debbugs-Cc: Debian Python Team , Peter 
> > Michael Green , Serge Schneider 
> > , 1060...@bugs.debian.org, 1083...@bugs.debian.org, 
> > Package Salvaging Team 
> > 
> > Hi,
> > 
> > I'm interested in salvaging your package phzero, in accordance with the
> > Package Salvaging procedure outlined in the Developers Reference[1].
> > Your package meets the criteria for this process, and I would love to
> > assist in preserving and maintaining it. As the Salvage process
> > suggests, here is a list of the criteria that apply, in my opinion:
> > 
> > 
> >- Bugs filed against the package do not have answers from the
> >  maintainer.
> >- Upstream has released several versions, but despite there being
> >  a bug entry asking for it, it has not been packaged.
> >- There are QA issues with the package.
> > 
> > 
> > I believe your package would be a great addition to the Debian Python
> > Team, and I took the liberty to create the Salsa repository here[2]. If
> > you choose not to accept the ITS, I'd be more than happy to help you
> > move it to another location, such as debian/, or wherever you prefer. My
> > goal is to make it as easy as possible for you to join the team. I'd
> > also be delighted to assist in adding you as a team member if you could
> > share your Salsa login.
> > 
> > Your package was highlighted in the Bug of the Day[3] initiative, which
> > aims to introduce newcomers to manageable tasks and guide them through
> > the workflow to solve them. The focus of this initiative is on migrating
> > packages to Salsa, as it's a great way to familiarize newcomers with a
> > consistent Git-based workflow.
> > 
> > Kind regards
> >  Andreas.
> > 
> > [1] 
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> > [2] https://salsa.debian.org/python-team/packages/pgzero
> > [3] https://salsa.debian.org/qa/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: trixie/sid
> >APT prefers testing
> >APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), 
> > (5, 'experimental'), (1, 'buildd-experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 6.12.12-amd64 (SMP w/4 CPU threads; PREEMPT)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=sh: 0: getcwd() 
> > failed: No such file or directory
> > UTF-8), LANGUAGE=de_DE:de
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> 
> 

-- 
https://fam-tille.de

Bug#1094736: transition: libcdio

[gregor herrmann]

On Mon, 10 Mar 2025 16:41:41 -0700, Gabriel F. T. Gomes wrote:

> * Emilio Pozuelo Monfort:
> > So perhaps the test is broken, 
> > although I'm not sure why it segfaults on those arches and not others, and 
> > that 
> > may be a real bug.
> I agree that it could be a real bug, but do you think this could be a
> bug in the CI itself? It is testing the old packages... Have they
> always failed?

No, they are green all across the board (for tests _within_ testing 
or unstable):
https://ci.debian.net/packages/libd/libdevice-cdio-perl/


Cheers,
gregor 

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

Bug#1099767: RFS: python-certbot-dns-luadns/2.9.0-1 [ITP] -- LuaDNS Authenticator plugin for Certbot

[Phil Wyett]

Control: tags -1 -moreinfo
Control: tags -1 +confirmed

On Tue, 2025-03-11 at 04:16 +0100, ch...@chancellor.cc wrote:
> Hello Phil,
> 
> I appreciate you taking a look! I've updated to version 2.11.0 which is the
> highest that the sid release of certbot supports. Truth be told, there isn't
> a code difference between the two versions for this particular package
> (versioning mirrors the certbot release), but it's much cleaner this way,
> you're right.
> 
> Please let me know if I need to take a look at anything else!
> 
> Sincerely,
> Chris Chancellor
> 

Hi Chris,

Many thanks for the update and the information you provided.

I have performed my tests on the package and it looks in good shape. I will tag
as 'confirmed' and hope a DD can look at the package, review it and posssibly
upload for you.

-- 

Regards

Phil

Donate: https://buymeacoffee.com/kathenasorg

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--






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

Bug#1100030: why adduser in preinst?

[Simon Josefsson]

Marc Haber  writes:

> Package: jabberd2
> Version: 2.7.0-7
> Severity: minor
>
> Hi,
>
> I am the main maintainer of adduser and am always interested in usage
> patterns of my software. jabberd2 is one of the _very_ few (<5) packages
> in Debian that use adduser in their preinst.
>
> Since this might interfere with adduser's development (preinst might and
> probably will run with an un-updated adduser during upgrades), I would
> like to know why it was decided in jabberd2 to create the user in
> preinst.
>
> If there is no real reason, I'd love the usage of adduser being moved
> too postinst like hundreds of other packages do it.
>
> In addition, in trixie, the scaffolding you're using around your adduser
> calls is no longer necessary.
>
> A single call of
> adduser --system --group --home=/var/lib/jabberd2 --no-create-home jabber
> will already do it.

Thanks -- I suspect the actual reason may be lost in time.  What is the
exact patch you are thinking of, is it the one below?  I'm happy to
apply it and see of Salsa is happy and then upload and see if we get any
reports.

/Simon

diff --git a/debian/postinst b/debian/postinst
index aa845ab..4ed42c5 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -21,6 +21,17 @@ case "$1" in
 ;;
 esac
 
+if ! getent group | grep -q "^jabber:"
+then
+   addgroup --system jabber
+fi
+
+if ! getent passwd | grep -q "^jabber:"
+then
+   adduser --system --home /var/lib/jabberd2 --no-create-home \
+   --quiet --disabled-password --ingroup jabber jabber
+fi
+
 #DEBHELPER#
 
 exit 0
diff --git a/debian/preinst b/debian/preinst
index abc46e1..4843a2d 100644
--- a/debian/preinst
+++ b/debian/preinst
@@ -35,17 +35,6 @@ case "$1" in
 ;;
 esac
 
-if ! getent group | grep -q "^jabber:"
-then
-   addgroup --system jabber
-fi
-
-if ! getent passwd | grep -q "^jabber:"
-then
-   adduser --system --home /var/lib/jabberd2 --no-create-home \
-   --quiet --disabled-password --ingroup jabber jabber
-fi
-
 #DEBHELPER#
 
 exit 0


signature.asc
Description: PGP signature

Bug#1100090: ITP: didder -- An extensive, fast, and accurate command-line image dithering tool.

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: didder
  Version : 1.3.0-1
  Upstream Author : makeworld
* URL : https://github.com/makeworld-the-better-one/didder
* License : GPL-3.0
  Programming Lang: Go
  Description : An extensive, fast, and accurate command-line image 
dithering tool.

 didder is an extensive, fast, and accurate command-line image dithering
 tool. It is designed to work well for both power users as well as
 pipeline scripting. It is backed by the author's dithering library
 (https://github.com/makeworld-the-better-one/dither), and is unique
 in its correctness and variety of dithering algorithms. It provides
 many options, while being correct (linearizing the image, weighting
 channels by luminance).
 .
 Types of dithering supported
 .
  * Random noise (in grayscale and RGB)
  * Ordered Dithering
* Bayer matrix of any size (as long as dimensions are powers of two)
* Clustered-dot - many different preprogrammed matrices
* Some unusual horizontal or vertical line matrices
* Yours? You can provide your own ordered dithering matrix in JSON format
  * Error diffusion dithering
* Simple 2D
* Floyd-Steinberg, False Floyd-Steinberg
* Jarvis-Judice-Ninke
* Atkinson
* Stucki
* Burkes
* Sierra/Sierra3, Sierra2, Sierra2-4A/Sierra-Lite
* Steven Pigeon (https://hbfs.wordpress.com/2013/12/31/dithering/)
* Yours? You can provide your own error diffusion matrix in JSON format
 .
 Features
 .
  * Set palette using RGB tuples, hex codes, number 0-255 (grayscale), or
SVG color names (https://www.w3.org/TR/SVG11/types.html#ColorKeywords)
  * Optionally recolor image with a different palette after dithering
  * Set dithering strength
  * Image is automatically converted to grayscale if palette is grayscale
  * Force image to grayscale with --grayscale
  * Change image saturation, brightness, or contrast before dithering
  * Read EXIF rotation tags by default (disabled with --no-exif-rotation)
  * Downscale image before dithering, keeping aspect ratio
  * Upscale image after dithering, without producing artifacts
  * Supports input image of types JPEG, GIF (static), PNG, BMP, TIFF
  * Output to PNG or GIF
  * Process multiple images with one command
  * Combine multiple images into an animated GIF
  * Uses all CPU cores when possible
  * Support images with transparency (alpha channel is kept the same)

This is a fine little CLI tool that is easy to use, and all of its
dependencies are already packaged in Debian.

Bug#1039005: gnome-software: lists updated packages twice after update

[Sid T]

Can this bug be closed ?

Bug#1100108: neovim: update-alternatives: error: alternative link /usr/bin/rvim is already managed by rvim

[Jochen Sprickerhof]

Package: neovim
Version: 0.10.4-6
Severity: normal

# apt upgrade
Upgrading:
  neovim  neovim-runtime

Summary:
  Upgrading: 2, Installing: 0, Removing: 0, Not Upgrading: 0
  Download size: 6861 kB
  Space needed: 3072 B / 6971 MB available

Continue? [Y/n]
Get:1 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 
neovim amd64 0.10.4-6 [2275 kB]
Get:2 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 
neovim-runtime all 0.10.4-6 [4586 kB]
Fetched 6861 kB in 1s (4777 kB/s)
(Reading database ... 6004 files and directories currently installed.)
Preparing to unpack .../neovim_0.10.4-6_amd64.deb ...
Unpacking neovim (0.10.4-6) over (0.10.4-5) ...
Preparing to unpack .../neovim-runtime_0.10.4-6_all.deb ...
Unpacking neovim-runtime (0.10.4-6) over (0.10.4-5) ...
Setting up neovim-runtime (0.10.4-6) ...
Setting up neovim (0.10.4-6) ...
update-alternatives: error: alternative link /usr/bin/rvim is already managed 
by rvim
dpkg: error processing package neovim (--configure):
 installed neovim package post-installation script subprocess returned error 
exit status 2
Errors were encountered while processing:
 neovim
Error: Sub-process /usr/bin/dpkg returned an error code (1)

Cheers Jochen


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

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

Versions of packages neovim depends on:
ii  libc62.41-4
ii  libluajit-5.1-2  2.1.0+openresty20250117-2
ii  libmsgpack-c26.0.1-3+b1
ii  libtree-sitter0  0.22.6-4
ii  libunibilium42.1.1-2+b1
ii  libuv1t641.50.0-2
ii  libvterm00.3.3-3+b1
ii  lua-lpeg 1.1.0-2
ii  lua-luv  1.48.0-2-3
ii  neovim-runtime   0.10.4-6

Versions of packages neovim recommends:
ii  python3-pynvim  0.5.0-2
ii  xclip   0.13-4
pn  xxd 

Versions of packages neovim suggests:
pn  ctags
pn  vim-scripts  

-- no debconf information

Bug#1100094: kodi: Kodi fails to build with pipewire 1.4.0

[Vasyl Gello]

Hi Daniele,

Known bug - will upload the fixed version tonight.

Vasyl

-- 
Vasyl Gello
==
Certified SolidWorks Expert

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

11 березня 2025 р. 10:08:53 UTC, Daniele Ricci  
пише:
>Package: kodi
>Version: 2:21.2+dfsg-1
>Severity: serious
>Tags: ftbfs
>Justification: fails to build from source (but built successfully in the past)
>
>Dear Maintainer,
>
>Kodi fails to build on testing with pipewire 1.4.0 on x86_64 (although I
>suppose the architecture doesn't really matter in this case). Relevant excerpt
>from log is attached.
>
>To reproduce, just try to build the package on latest testing.
>
>The package will build successfully against pipewire 1.2.7 (that was the
>previous available version on testing, now available only on bookworm-backports
>without the "-0t64" suffix) - build script available here and tested:
>https://github.com/daniele-athome/my-debian-
>packages/blob/master/kodi/Dockerfile#L3
>
>
>-- System Information:
>Debian Release: trixie/sid
>  APT prefers testing
>  APT policy: (900, 'testing'), (600, 'stable'), (500, 'stable-updates')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 6.12.17-amd64 (SMP w/8 CPU threads; PREEMPT)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
>TAINT_UNSIGNED_MODULE
>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 kodi depends on:
>ii  kodi-bin   2:21.2+dfsg-1
>ii  kodi-data  2:21.2+dfsg-1
>
>Versions of packages kodi recommends:
>ii  kodi-repository-kodi [kodi-repository]  2:21.2+dfsg-1
>ii  kodi-visualization-spectrum 21.0.2+ds-1
>
>kodi suggests no packages.
>
>-- no debconf information

Bug#1100109: suricata: Please drop ancient dpkg versioned Pre-Depends

[Guillem Jover]

Source: suricata
Source-Version: 1:7.0.8-1
Severity: wishlist

Hi!

This package contains an ancient versioned Pre-Depends on dpkg, added
in 2016 for dpkg-maintsctipt-helper. This is not currently needed, but
has been entangling this package with dpkg's testing migration for
several Debian releases via its autopkgtests.

Please drop dpkg from the Pre-Depends.

Thanks,
Guillem

Bug#1100110: fonts-unfonts-core: Please drop ancient dpkg versioned Pre-Depends

[Guillem Jover]

Source: fonts-unfonts-core
Source-Version: 1:1.0.2-080608-18
Severity: wishlist

Hi!

This package contains an ancient versioned Pre-Depends on dpkg, added
in 2012 for dpkg-maintsctipt-helper. This is not currently needed, but
has been entangling this package with dpkg's testing migration for
several Debian releases via its autopkgtests.

Please drop dpkg from the Pre-Depends.

Thanks,
Guillem

Bug#1100101: pyqt6-webengine: autopkgtest fails with glibc 2.41 due to executable stack

[Aurelien Jarno]

control: retitle -1 qt6-webengine: libQt6WebEngineCore.so.6 has an executable 
stack
control: found -1 6.7.2+dfsg2-2
control: fixed -1 6.8.2+dfsg-3

On 2025-03-11 12:05, Luca Boccassi wrote:
> Source: pyqt6-webengine
> Version: 6.8.0-1
> Severity: grave
> Justification: blocks glibc 2.41 from migrating to trixie
> X-Debbugs-Cc: aure...@debian.org
> 
> Dear Maintainer(s),
> 
> glibc 2.41 added some hardening that block having an executable stack
> for security reasons.
> 
> pyqt6-webengine seems to require an executable stack and autopkgtest
> using it are failing with glibc 2.41 from unstable:
> 
>  75s python3.13 -c "import PyQt6.QtWebEngineCore"
>  75s Traceback (most recent call last):
>  75s   File "", line 1, in 
>  75s import PyQt6.QtWebEngineCore
>  75s ImportError: libQt6WebEngineCore.so.6: cannot enable executable stack as 
> shared object requires: Invalid argument
> 
> https://ci.debian.net/packages/p/pyqt6-webengine/testing/i386/58709056/

The problem is actually in qt6-webengine which provides
libQt6WebEngineCore.so.6 with an executable stack on i386.

> A possible solution would be to build libQt6WebEngineCore.so.6 with '-
> Wl,-z,noexecstack' assuming it's not actually needed to work.

The problem has already been fixed by a rebuild, the package just need
to migrate to testing (or binNMUed in testing). The release team
proposed to just ignore the issue for the glibc migration.

Regards
Aurelien

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

Bug#1100112: ITP: golang-github-ashcrow-osrelease -- Go library/binary for parsing osrelease

[Thomas Goirand]

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

* Package name: golang-github-ashcrow-osrelease
  Version : 0.0.1
  Upstream Contact: Steve Milner 
* URL : https://github.com/ashcrow/osrelease
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library/binary for parsing osrelease

 The osrelease package is a Go library designed to simplify the process of
 reading and parsing /etc/os-release files. These files contain operating
 system identification data, which can be useful for various system
 administration and automation tasks.
 .
 This package provides an easy-to-use API for accessing the contents of
 os-release files, making it straightforward to retrieve information such as
 the operating system's name, version, and other relevant details. It supports
 both automatic detection of the os-release file and explicit file loading.

I'll maintain this package in the Go team.

Bug#1100111: suitesparse-graphblas: Please add extra cflags for loong64

[zhangdandan]

Source: suitesparse-graphblas
Version: 7.4.0+dfsg-1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the suitesparse-graphblas failed for loong64 in the Debian 
Package Auto-Building environment.

The error log is as follows,
```
..
[100%] Linking C shared library libgraphblas.so
/usr/bin/ld: 
CMakeFiles/graphblas.dir/Source/Generated2/GB_binop__div_fc32.c.o: 
relocation R_LARCH_B26 overflow 0xf7ffe73c

Dump relocate record:
stack top        relocation name        symbol
at 
CMakeFiles/graphblas.dir/Source/Generated2/GB_binop__div_fc32.c.o(.text+0xb80):

...
0x R_LARCH_B26    `.L115'
..
```
The full build log can be found at 
https://buildd.debian.org/status/logs.php?pkg=suitesparse-graphblas&ver=7.4.0%2Bdfsg-1%2Bb1&arch=loong64.


Please consider the patch I attached (Add extra build cflags to fix 
relocation R_LARCH_B26 overflow).
Based on attached patch, I have built suitesparse-graphblas_7.4.0+dfsg-1 
successfully on locally.

```
..
    dh_builddeb
dpkg-deb: building package 'libgraphblas7-dbgsym' in 
'../libgraphblas7-dbgsym_7.4.0+dfsg-1_loong64.deb'.
dpkg-deb: building package 'libgraphblas-doc' in 
'../libgraphblas-doc_7.4.0+dfsg-1_all.deb'.
dpkg-deb: building package 'libgraphblas-dev' in 
'../libgraphblas-dev_7.4.0+dfsg-1_loong64.deb'.
dpkg-deb: building package 'libgraphblas7' in 
'../libgraphblas7_7.4.0+dfsg-1_loong64.deb'.
 dpkg-genbuildinfo --build=binary 
-O../suitesparse-graphblas_7.4.0+dfsg-1_loong64.buildinfo
 dpkg-genchanges --build=binary 
-O../suitesparse-graphblas_7.4.0+dfsg-1_loong64.changes

```

Your opinions are welcome.

Best regards,
Dandan Zhang

--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,10 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 CFLAGS := $(CFLAGS) $(CPPFLAGS)
 
+ifneq (,$(filter $(DEB_BUILD_ARCH),loong64))
+CFLAGS := $(CFLAGS) $(CPPFLAGS) -mcmodel=medium
+endif
+
 # Flags for CMake
 export CMAKE_OPTIONS := -DCMAKE_INSTALL_PREFIX=/usr

Bug#1100113: iproute2: Please drop dpkg and build-essential from autopkgtest Depends

[Guillem Jover]

Source: iproute2
Source-Version: 6.13.0-1
Severity: wishlist

Hi!

This package explicitly depends dpkg-dev (which is part of
build-essential), and build-essential in its autopkgtest Depends,
where it is also explicitly depending on @builddeps@, which already
includes the latter (which transitively includes the former).

This is redundant, and has been entangling this package with dpkg's
testing migration for several Debian releases via its autopkgtests.

Please drop both explicit dpkg and build-essential from the autopkgtest
Depends.

Thanks,
Guillem

Bug#1099773: fluidsynth.1: Some remarks and a patch with editorial changes for this man page

[Fabian Greffrath]

control: tags -1 forwarded https://github.com/FluidSynth/fluidsynth/pull/1499


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

Bug#1084073: Bug#1084072: rocm-compilersupport: Please upgrade build-dep to llvm/clang 18 or 19

[Emilio Pozuelo Monfort]

On 21/12/2024 00:42, Emilio Pozuelo Monfort wrote:

Hi,

On 20/12/2024 23:00, Cordell Bloor wrote:

Hi Emilio,

On Fri, 6 Dec 2024 11:36:22 +0100 Emilio Pozuelo Monfort  
wrote:

  >
  > Thanks for the update. After your email, I asked ftp-masters about 
rocm-llvm,
  > and it got accepted. With that done, how's the update to 6.1 coming along? 
Do
  > you think it can happen soon?
  >

Thank you for the help with that. After migrating rocm-llvm to unstable, I think
the main thing will just be to get rocm-hipamd updated. That is difficult, but
it's still just one package. It will be a couple of days work. I'm not sure if I
will have time to take it on before January, but I'll try.


Great, that sounds good. Thanks for looking into it.


I see that 6.1 got uploaded and into testing, but with the toolchain freeze so 
close, I don't know if there will be time to update to 6.2/6.3 and use LLVM 
18/19. Thoughts?


Cheers,
Emilio

Bug#1100130: ITP: cookidoo-api -- Access Cookidoo recipes and content programmatically

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: cookidoo-api
  Version : 0.13.0
  Upstream Author : Cyrill Raccaud 
* URL : https://github.com/miaucl/cookidoo-api
* License : MIT
  Programming Lang: Python
  Description : Access Cookidoo recipes and content programmatically

  This library provides tools to interact with the Cookidoo platform, allowing
  users to access a wide variety of recipes and related content
  programmatically. Through the use of network requests and data handling, it
  communicates with Cookidoo's servers, enabling the retrieval of recipe
  details, ingredient lists, and cooking instructions. Designed for integration
  with automation systems, it supports tasks such as fetching user-specific
  content and accessing recipe collections. The library utilizes asynchronous
  requests to efficiently manage data exchanges over the Internet, adapting to
  dynamic content updates and changes in user preferences.

This library is a dependancy of Home Assistant, the Python smart home platform.
I plan to maintain it as part of the Home Assistant team.

Bug#1083133: bug resolution

[Oswald Buddenhagen]

i think this should be most probably closed. alejandro?

Bug#1100131: ITP: golang-github-eggsampler-acme -- Go client library implementation for ACME v2 (RFC8555)

[Luca Soler]

Package: wnpp
Severity: wishlist
Owner: Luca Soler 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-eggsampler-acme
  Version : 3.6.1-1
  Upstream Author : Isaac Truscott
* URL : https://github.com/eggsampler/acme
* License : Expat
  Programming Lang: Go
  Description : Go client library implementation for ACME v2 (RFC8555)

Indirect dependency of apptainer.
This package will be maintained within the Debian Go Packaging Team.

--
Luca

signature.asc
Description: OpenPGP digital signature

Bug#1100127: ITP: python-enamlx -- Additional Qt Widgets for Enaml

[Alexander Sulfrian]

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

* Package name: python-enamlx
  Version : 0.6.4
  Upstream Contact: Jairus Martin 
* URL : https://github.com/frmdstryr/enamlx/
* License : Expat
  Programming Lang: Python
  Description : Additional Qt Widgets for Enaml

Enamlx provides the following additional widgets for Enaml:

 * TableView
 * TreeView
 * DoubleSpinBox
 * GraphicsView
 * PyQtGraph Plot
 * KeyEvent


This is a dependency for InkCut which I also intend to package.

I plan to maintain this package as part of the Debian Python team.

Bug#1100128: ITP: golang-github-letsencrypt-borp -- Boulder's version of go-gorp/gorp

[Luca Soler]

Package: wnpp
Severity: wishlist
Owner: Luca Soler 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-letsencrypt-borp
  Version : 0.0~git20240620.a78493c-1
  Upstream Author : Let's Encrypt (ISRG)
* URL : https://github.com/letsencrypt/borp
* License : Expat
  Programming Lang: Go
  Description : Boulder's version of go-gorp/gorp

Indirect dependency of apptainer.
This package will be maintained within the Debian Go Packaging Team.

--
Luca

signature.asc
Description: OpenPGP digital signature

Bug#1100040: xapps: missing intltool prerequisite for dpkg-buildpackage on xapps

[Fabio Fantoni]

Il 10/03/2025 16:02, Douglas Wade Goodall ha scritto:

Package: xapps-common
Version: 2.8.8+faye
Severity: serious
File: xapps
Tags: l10n ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: d...@goodall.com


Control: tags -1 + unreproducible

Hi, from the version seems you don't use Debian packaging, that already 
has intltool in build-depends.


I also tried to rebuild 2.8.8-1 in salsa-ci and was successful.

Faye seems Mint Debian edition 6 that use upstream packaging instead, 
even if Mint don't built in clean environment and in many cases deps are 
missing from a fast look also it already have intltool in build-deps [1].


So I can only assume that you are using another unofficial packaging, 
neither from Debian nor upstream based on the only data provided at the 
time.


[1] https://github.com/linuxmint/xapp/blob/master/debian/control



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1100126: ippsample: Unused B-D on libmupdf-dev

[Bastian Germann]

Source: ippsample
Version: 0.0~git20220607.72f89b3-1
Severity: important

Please drop the unused libmupdf-dev, which is not available on mips64el
anymore and is not used by ippsample.

Bug#1100015: In-kernel X.509 certificates fail to load since 6.13.6

[Bastian Blank]

On Mon, Mar 10, 2025 at 12:51:35PM +0200, Raul Tambre wrote:
> Starting with 6.13.6-1~exp1 the following error is logged during boot:
> 
>   Mar 10 12:11:53 laptop kernel: Loading compiled-in X.509 certificates
>   Mar 10 12:11:53 laptop kernel: Problem loading in-kernel X.509 certificate 
> (-2)
> 
> I imagine this is likely caused by commit 
> ca3d0e60f548ed18c360fa87c5a2966606862b05 ("Store build time signing key 
> encrypted").

Yeah.  And the immediate reason:

| -Signature Algorithm: sha256WithRSAEncryption
| +Signature Algorithm: ecdsa-with-SHA256

The old kernel tried to configure with ecdsa, but failed, due to some
conflicts in the config, falling back to rsa.

And missing support for ecdsa, but for some reason built-in suport for
rsa.

| root@boot1:/usr/lib/debug/boot# grep CONFIG_CRYPTO_RSA /boot/config-6.1*
| /boot/config-6.12.17-cloud-amd64:CONFIG_CRYPTO_RSA=y
| /boot/config-6.13-cloud-amd64:CONFIG_CRYPTO_RSA=y
| root@boot1:/usr/lib/debug/boot# grep CONFIG_CRYPTO_ECDS /boot/config-6.1*
| /boot/config-6.12.17-cloud-amd64:# CONFIG_CRYPTO_ECDSA is not set
| /boot/config-6.13-cloud-amd64:# CONFIG_CRYPTO_ECDSA is not set

Bastian

-- 
Knowledge, sir, should be free to all!
-- Harry Mudd, "I, Mudd", stardate 4513.3

Bug#1100117: ITP: aiodukeenergy -- Asyncio-based library for interacting with Duke Energy's services

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: aiodukeenergy
  Version : 0.2.2
  Upstream Author : Jason Hunter 
* URL : https://github.com/hunterjm/aiodukeenergy
* License : MIT
  Programming Lang: Python
  Description : Asyncio-based library for interacting with Duke Energy's 
services

  This library provides asynchronous capabilities to access and interact with
  Duke Energy's services efficiently. Designed to handle multiple data requests
  and responses asynchronously, it enables users to retrieve and process energy
  consumption data, account information, and billing details from Duke Energy.
  By utilizing this library, applications can perform complex data operations in
  a non-blocking manner, thus enhancing performance when dealing with energy
  data queries and other service interactions. This is especially beneficial in
  context where quick data access and response is necessary, such as monitoring
  applications or data analysis tools.

This library is a dependancy of Home Assistant, the Python smart home platform.
I plan to maintain it as part of the Home Assistant team.

Bug#1099405: riseup-vpn: build error "undefined: CacheLinePadSize and doinit"

[Gianfranco Costamagna]

control: reassign -1 src:golang-refraction-networking-utls
control: found -1 1.2.1-3
control: affects -1 riseup-vpn
control: tags -1 patch pending

Hello, I NMUed the package in sid, and I'm attaching the patch to this bug 
report.

Note: the patch only touches loong64 code, and can be dropped on next release 
since the cpu detection code
is now on a separate package.

thanks

Gianfranco

On Mon, 3 Mar 2025 16:31:35 +0800 zhangdandan  wrote:

Source: riseup-vpn
Version: 0.24.10+ds1-1
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the riseup-vpn failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
# github.com/refraction-networking/utls/cpu
../../../github.com/refraction-networking/utls/cpu/cpu_loong64.go:10:7: 
CacheLineSize redeclared in this block
../../../github.com/refraction-networking/utls/cpu/cpu.go:20:5: other 
declaration of CacheLineSize
../../../github.com/refraction-networking/utls/cpu/cpu.go:15:30: 
undefined array length CacheLinePadSize or missing type constraint
../../../github.com/refraction-networking/utls/cpu/cpu.go:20:29: 
undefined: CacheLinePadSize
../../../github.com/refraction-networking/utls/cpu/cpu.go:123:2: 
undefined: doinit

...
```
The full build log can be found at 
https://buildd.debian.org/status/fetch.php?pkg=riseup-vpn&arch=loong64&ver=0.24.10%2Bds1-1&stamp=1740475439&raw=0.


After analyzing, I checked that we need to update loong64 support in 
golang-refraction-networking-utls-dev(build-depends).
Please consider the patch I attached for 
golang-refraction-networking-utls source packgage.


Based on the attached patch, golang-refraction-networking-utls 
(1.2.1-3+loong64) was built successfully on local ENV.
And then, based on 
golang-refraction-networking-utls-dev_1.2.1-3+loong64_all.deb, I have 
built riseup-vpn normally.


Please update loong64 support in the depend of 
golang-refraction-networking-utls(which is a build dependency of 
riseup-vpn).


Best regards,
Dandan Zhang
diff -Nru golang-refraction-networking-utls-1.2.1/debian/changelog 
golang-refraction-networking-utls-1.2.1/debian/changelog
--- golang-refraction-networking-utls-1.2.1/debian/changelog2025-02-04 
19:49:43.0 +0100
+++ golang-refraction-networking-utls-1.2.1/debian/changelog2025-03-11 
14:32:05.0 +0100
@@ -1,3 +1,13 @@
+golang-refraction-networking-utls (1.2.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Dandan Zhang   Tue, 11 Mar 2025 
14:32:05 +0100
+
 golang-refraction-networking-utls (1.2.1-3) unstable; urgency=medium
 
   * Team Upload.
diff -Nru golang-refraction-networking-utls-1.2.1/debian/patches/loong64.patch 
golang-refraction-networking-utls-1.2.1/debian/patches/loong64.patch
--- golang-refraction-networking-utls-1.2.1/debian/patches/loong64.patch
1970-01-01 01:00:00.0 +0100
+++ golang-refraction-networking-utls-1.2.1/debian/patches/loong64.patch
2025-03-11 14:32:05.0 +0100
@@ -0,0 +1,22 @@
+Description: Update loong64 support patch for new release
+Author: Dandan Zhang 
+Bug-Debian: https://bugs.debian.org/1099405
+Last-Update: 2025-03-11
+
+--- golang-refraction-networking-utls-1.2.1.orig/cpu/cpu_loong64.go
 golang-refraction-networking-utls-1.2.1/cpu/cpu_loong64.go
+@@ -2,12 +2,9 @@
+ // Use of this source code is governed by a BSD-style
+ // license that can be found in the LICENSE file.
+ 
+-//go:build loong64
+-// +build loong64
+-
+ package cpu
+ 
+-const CacheLineSize = 64
++const CacheLinePadSize = 64
+ 
+-func initOptions() {
++func doinit() {
+ }
diff -Nru golang-refraction-networking-utls-1.2.1/debian/patches/series 
golang-refraction-networking-utls-1.2.1/debian/patches/series
--- golang-refraction-networking-utls-1.2.1/debian/patches/series   
2025-02-04 19:48:12.0 +0100
+++ golang-refraction-networking-utls-1.2.1/debian/patches/series   
2025-03-11 14:32:05.0 +0100
@@ -1,2 +1,3 @@
 0001-Skip-client-server-handshake-tests.patch
 0002-Skip-TestVerifyConnection.patch
+loong64.patch

Bug#986232: ITP organicmaps

[Matthias Geiger]

Control: retitle -1 RFP: organicmaps -- offline maps application
Control: nowner -1

On Wed, 13 Dec 2023 12:28:34 +0100 Federico Ceratto 
 wrote:

Thanks for your interest in the package, Matthias, and sorry for the late
reply.
The packaging at https://salsa.debian.org/debian/organicmaps has been done
by Jochen Sprickerhof.
Feel free to take over the ITP related to libsuccint if you want:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025499

Have a nice day,
--
Federico


Hi federico,

thanks for working on organicmaps. I am downgrading this to an RFP again 
since I do not have the time to work on this (and the work was done 
anyway)


best,

werdahias

Bug#1083133: bug resolution

[Alejandro Colomar]

On Tue, Mar 11, 2025 at 11:52:25AM +0100, Oswald Buddenhagen wrote:
> i think this should be most probably closed. alejandro?

Yep, please close it.  Thanks!

-- 



signature.asc
Description: PGP signature

Bug#1100121: ITP: golang-github-poy-onpar -- Parallel testing framework for Go

[Luca Soler]

Package: wnpp
Severity: wishlist
Owner: Luca Soler 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-poy-onpar
  Version : 0.3.3-1
  Upstream Author : Andrew Poydence
* URL : https://github.com/poy/onpar
* License : Expat
  Programming Lang: Go
  Description : Parallel testing framework for Go (library)

Onpar provides a BDD style of testing, similar to what you might find with
something like ginkgo or goconvey. The biggest difference between onpar and its
peers is that a BeforeEach function in onpar may return a value, and that value
will become the parameter required in child calls to Spec, AfterEach, and
BeforeEach.

This allows you to write tests that share memory between BeforeEach, Spec, and
AfterEach functions without sharing memory with other tests. When used
properly, this makes test pollution nearly impossible and makes it harder to
write flaky tests.

Indirect dependency of apptainer.
This package will be maintained within the Debian Go Packaging Team.

--
Luca

signature.asc
Description: OpenPGP digital signature

Bug#1099632: Treat AARs as zips

[Chris Lamb]

Matt Corallo wrote:

> https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.1.0;hb=refs/heads/main
> and
> https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.0.0;hb=refs/heads/main

Thanks for linking these. So, the proximate cause of this issue is
that the underlying file(1) utility reports these as Android packages:

$ file v0.1.0.0_LDK-release.aar v0.1.1.0_LDK-release.aar
v0.1.0.0_LDK-release.aar: Android package (APK), with AndroidManifest.xml
v0.1.1.0_LDK-release.aar: Android package (APK), with AndroidManifest.xml

In general, diffoscope basically has to trust what file(1) reports and
proceed on that basis. We used to work around its bugs, but as you can
imagine, that became something of a game of whack-a-mole...

In the first instance, just to confirm that file(1) is at fault here? As
in, these are definitely not Android packages. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#1098265: netpipes uploaded to delayed=10

[Andreas Tille]

Control: tags -1 pending
Thanks

Hi Mats,

I need to admit I closed the ITS bug with an NMU to delayed=10.
Unfortunately nobody from the package Salvage team intended to add the
own ID to the Uploaders field which is required by the ITS procedure.
I hope you are fine with the NMU - of not let me know and I'll cancel
it.

Kind regards
 Andreas.

-- 
https://fam-tille.de

Bug#1096190: Missing https support with rustls-tls

[Jonas Smedegaard]

Quoting kpcyrd (2025-03-11 13:04:11)
> On 3/10/25 8:40 AM, Jonas Smedegaard wrote:
> > If you are proposing a "semi-adoption" of the v0.24 branch of the crate
> > hyper-rustls, then that is fine with me. If you woould like to take over
> > maintenance fully of hyper-rustls crate, then that is fine with me as
> > well, but please state so explicitly ahead of doing so, to avoid wasting
> > time on duplicate work.
> 
> I've checked in with other people in #debian-rust and we'd gladly take 
> the package. :) Thanks for your response!

Uhm, sorry for confusing the conversation by lumping together multiple
options:

a) Rust team introduces and maintaines src:rust-hyper-rustls-0.24
b) Rust team takes over maintenance of src:rust-hyper-rustls

Do you accept a) or b) (with a) implicitly included)?

I think the simplest is that you do only a) for now, because (without
looking closely at it) I am currently maintaining most of the packages
directly related to the rustls crate.  But I am open to suggestions.


> > If instead you are offering to bootstrap that branch but expect me to
> > maintain it, then it is not helpful for me that you've used the Rust
> > team packaging style.
> 
> To be clear, of course there's no expectation of you to maintain the 
> hyper-rustls-0.24 crate that I've prepared.

Thanks for the confirmation on that (yes, speculative) 3rd option.

 - Jonas

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

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

Bug#1100106: ITP: golang-go4-netipx -- extra stuff from inet.af/netaddr that didn't make it into Go's net/netip

[Thomas Goirand]

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

* Package name: golang-go4-netipx
  Version : 0.0~git20231129.fdeea32
  Upstream Contact: Brad Fitzpatrick 
* URL : https://github.com/go4org/netipx
* License : BSD-3-clause
  Programming Lang: Go
  Description : extra stuff from inet.af/netaddr that didn't make it into 
Go's net/netip

 This is a package containing the bits of the old inet.af/netaddr package
 that didn't make it into Go 1.18's net/netip standard library package.
 .
 As background, see:
 .
  * https://github.com/inetaf/netaddr/ (now deprecated)
  * https://tailscale.com/blog/netaddr-new-ip-type-for-go/ - blog post about
why the package came to be originally
  * https://go.dev/doc/go1.18#netip - Go 1.18 release notes
 .
 This package requires Go 1.18+ to use and complements the net/netip.

I'll maintain this in the Go team.

Bug#1074250: NMUed (Re: ifupdown2 not working with python3.12)

[Julien Fortin]

Hi,

This is good, we can go ahead with this NMU.

Thanks,
Julien Fortin

From: Fabian Grünbichler 
Sent: Tuesday, March 11, 2025 1:11 PM
To: 1074...@bugs.debian.org <1074...@bugs.debian.org>
Subject: Bug#1074250: NMUed (Re: ifupdown2 not working with python3.12)

[You don't often get email from f.gruenbich...@proxmox.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

External email: Use caution opening links or attachments


Control: tags 1074250 + patch
Control: tags 1074250 + pending


Dear maintainer,

I've prepared an NMU for ifupdown2 (versioned as 3.0.0-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ifupdown2-3.0.0/debian/changelog ifupdown2-3.0.0/debian/changelog
--- ifupdown2-3.0.0/debian/changelog2024-07-08 01:02:35.0 +0200
+++ ifupdown2-3.0.0/debian/changelog2025-03-11 12:51:10.0 +0100
@@ -1,3 +1,10 @@
+ifupdown2 (3.0.0-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * cherry-pick upstream fix for python 3.12 compat (Closes: #1074250)
+
+ -- Fabian Grünbichler   Tue, 11 Mar 2025 
12:51:10 +0100
+
 ifupdown2 (3.0.0-1.2) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru ifupdown2-3.0.0/debian/patches/bug-296-python-3.12-compability.patch 
ifupdown2-3.0.0/debian/patches/bug-296-python-3.12-compability.patch
--- ifupdown2-3.0.0/debian/patches/bug-296-python-3.12-compability.patch
1970-01-01 01:00:00.0 +0100
+++ ifupdown2-3.0.0/debian/patches/bug-296-python-3.12-compability.patch
2025-03-11 12:51:10.0 +0100
@@ -0,0 +1,26 @@
+From: Jan Huijsmans 
+Date: Tue, 9 Jul 2024 09:03:25 +0200
+X-Dgit-Generated: 3.0.0-1.3 25127847996b30ded7825cb98247e54478bdd350
+Subject: Bug #296: python 3.12 compability
+
+Since python 3.2, readfp needs to be replaced by read_file.
+Python 3.12 dropped the readfp function.
+
+Patch provided as PR by me, as the original reporter failed to do
+so since 4-4-2024 and my systems break due to this issue.
+
+---
+
+diff --git a/ifupdown2/ifupdown/main.py b/ifupdown2/ifupdown/main.py
+index 5ab07fa..141a922 100644
+--- a/ifupdown2/ifupdown/main.py
 b/ifupdown2/ifupdown/main.py
+@@ -139,7 +139,7 @@ class Ifupdown2:
+ configStr = '[ifupdown2]\n' + config
+ configFP = io.StringIO(configStr)
+ parser = configparser.RawConfigParser()
+-parser.readfp(configFP)
++parser.read_file(configFP)
+ configmap_g = dict(parser.items('ifupdown2'))
+
+ # Preprocess config map
diff -Nru ifupdown2-3.0.0/debian/patches/series 
ifupdown2-3.0.0/debian/patches/series
--- ifupdown2-3.0.0/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ ifupdown2-3.0.0/debian/patches/series   2025-03-11 12:51:10.0 
+0100
@@ -0,0 +1 @@
+bug-296-python-3.12-compability.patch

Bug#1100129: neovim: Fails to update due to conflict with vim

[Bastian Venthur]

Package: neovim
Version: 0.10.4-6
Severity: normal
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

neovim fails to update due to a conflict with vim:

Errors were encountered while processing:
 neovim
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up neovim (0.10.4-6) ...
update-alternatives: error: alternative link /usr/bin/rvim is already managed 
by rvim
dpkg: error processing package neovim (--configure):
 installed neovim package post-installation script subprocess returned error 
exit status 2
Errors were encountered while processing:
 neovim


Cheers,

Bastian

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

Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 neovim depends on:
ii  libc62.41-4
ii  libluajit-5.1-2  2.1.0+openresty20250117-2
ii  libmsgpack-c26.0.1-3+b1
ii  libtree-sitter0  0.22.6-4
ii  libunibilium42.1.1-2+b1
ii  libuv1t641.50.0-2
ii  libvterm00.3.3-3+b1
ii  lua-lpeg 1.1.0-2
ii  lua-luv  1.48.0-2-3
ii  neovim-runtime   0.10.4-6

Versions of packages neovim recommends:
ii  python3-pynvim  0.5.0-2
ii  wl-clipboard2.2.1-2
ii  xclip   0.13-4
ii  xsel1.2.1-1
ii  xxd 2:9.1.1113-1

Versions of packages neovim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-2
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1098924: crowbar: Please consider renaming source package to libcrowbar-ocaml

[Gianfranco Costamagna]

Hello,

I opened the bug now

https://bugs.debian.org/1100125

G.

On Fri, 28 Feb 2025 09:07:22 +0700 Arnaud Rebillout  wrote:

On 26/02/2025 16:23, Stéphane Glondu wrote:
> I've uploaded ocaml-crowbar:
>
>   https://ftp-master.debian.org/new/ocaml-crowbar_0.2.1-7.html

Wow, it's already in Debian unstable, that was quick!

Do we need to file a bug to ftp.debian.org to ask for removal of the old
src:crowbar now? Or does it need to wait before new src:ocaml-crowbar
enter testing?

I filed a MR (assuming you want to move the git repo in salsa to the new
name): https://salsa.debian.org/ocaml-team/crowbar/-/merge_requests/1

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1099045: transition: fuse3

[Cyril Brulebois]

László Böszörményi (GCS)  (2025-03-11):
> Almost two weeks have passed. Friendly ping, do you ACK or NACK this
> fuse3 transition kibi?

Sorry for the delay and thanks for the reminder…

Glancing at the packages in unstable and experimental, the diff between
both udebs looks good, as does the updated shlibs file. As far as d-i is
concerned, feel free to go ahead.


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


signature.asc
Description: PGP signature

Bug#1099278: python-uvicorn: FTBFS: E assert '{"example":123}' == '{"example": 123}'

[Sebastiaan Couwenberg]

Control: tags -1 upstream patch

The attached patch resolves the issue by supporting both JSON formats.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru python-uvicorn-0.32.0/debian/patches/json-format.patch 
python-uvicorn-0.32.0/debian/patches/json-format.patch
--- python-uvicorn-0.32.0/debian/patches/json-format.patch  1970-01-01 
01:00:00.0 +0100
+++ python-uvicorn-0.32.0/debian/patches/json-format.patch  2025-03-11 
09:38:40.0 +0100
@@ -0,0 +1,14 @@
+Description: Fix test failures due to changed JSON formatting.
+Author: Bas Couwenberg 
+
+--- a/tests/middleware/test_wsgi.py
 b/tests/middleware/test_wsgi.py
+@@ -72,7 +72,7 @@ async def test_wsgi_post(wsgi_middleware
+ async with httpx.AsyncClient(transport=transport, 
base_url="http://testserver";) as client:
+ response = await client.post("/", json={"example": 123})
+ assert response.status_code == 200
+-assert response.text == '{"example": 123}'
++assert response.text in ['{"example": 123}', '{"example":123}']
+ 
+ 
+ @pytest.mark.anyio
diff -Nru python-uvicorn-0.32.0/debian/patches/series 
python-uvicorn-0.32.0/debian/patches/series
--- python-uvicorn-0.32.0/debian/patches/series 2024-12-09 21:53:12.0 
+0100
+++ python-uvicorn-0.32.0/debian/patches/series 2025-03-11 09:38:40.0 
+0100
@@ -3,3 +3,4 @@
 0003-Fix-asyncio-warnings.patch
 0004-Use-local-image-resource-to-prevent-privacy-breach.patch
 0005-ignore-deprecationwarning-in-tests.patch
+json-format.patch

Bug#1100035: kmod: Please add the init script

[Marco d'Itri]

Control: severity -1 wishlist

Maybe I was not clear enough: I will really not spend more time on 
sysvinit support, so if you want this change then send a tested patch.
This is not RC, so stop adjusting the severity.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1100096: unblock: sysvinit/3.14-4 (pre-approval)

[Mark Hindley]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sysvi...@packages.debian.org
Control: affects -1 + src:sysvinit

Please pre-approve unblocking of package sysvinit.

[ Reason ]

src:kmod removed /etc/init.d/kmod in version 34.1-1[1]. It was suggested that it
be included in src:orphan-sysvinit-scripts[2], but orphan-sysvinit-scripts
requires a matching unit file to use as a dpkg trigger. The equivalent systemd
unit is in systemd itself. Therefore we consider /etc/init.d/kmod to be a better
fit in bin:initscripts.

bin:initscripts is built from src:sysvinit which also builds bin:sysvinit-utils
which is part of the toolchain freeze from 15th March -- hence the pre-approval
unblock request.

[ Impact ]

Without this transition, non-systemd systems will no longer load kernel modules
statically configured in /etc/mod*. The upload will fix #1100072.

[ Tests ]

I have manually tested installation with existing kmod/34-3. The Breaks/Replaces
forces apt to upgrade kmod as expected.

[ Risks ]

Moving files between packages is not risk free. However, the uncoordinated
actions of the kmod maintainer has made this necessary despite the current
stage of the release cycle.

[ 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 testing

[ Other info ]
kmod.postinst also runs[3]

 rm -f /etc/rcS.d/[SK]*kmod

This breaks upgrades and has also been highlighted in #1100035

unblock sysvinit/3.14-4

[1]  
https://salsa.debian.org/md/kmod/-/commit/8ca034958ad7d1734087a78078be4897209ab22e

[2]  https://bugs.debian.org/1100035

[3]  
https://salsa.debian.org/md/kmod/-/commit/c2ae42ca3a338fba0f190e3a61a635d386b1e8fa

Thanks for your consideration.

Mark
dpkg-source: warning: extracting unsigned source package 
(/home/mark/src/devuan/build/sysvinit_3.14-4.dsc)
diff -Nru sysvinit-3.14/debian/changelog sysvinit-3.14/debian/changelog
--- sysvinit-3.14/debian/changelog  2025-02-24 09:27:01.0 +
+++ sysvinit-3.14/debian/changelog  2025-03-10 16:49:51.0 +
@@ -1,3 +1,10 @@
+sysvinit (3.14-4) unstable; urgency=medium
+
+  * d/control: bump Standards Version (no changes).
+  * Take over /etc/init.d/kmod from src:kmod << 34.1-1 (Closes: #1100072).
+
+ -- Mark Hindley   Mon, 10 Mar 2025 16:49:51 +
+
 sysvinit (3.14-3) unstable; urgency=medium
 
   * rcS: Default to ASYNCMOUNTNFS=no if ip= or nfsroot= specified on kernel
diff -Nru sysvinit-3.14/debian/control sysvinit-3.14/debian/control
--- sysvinit-3.14/debian/control2025-02-24 09:27:01.0 +
+++ sysvinit-3.14/debian/control2025-03-10 16:49:51.0 +
@@ -14,7 +14,7 @@
  libselinux1-dev [linux-any],
  po4a,
 Rules-Requires-Root: no
-Standards-Version: 4.7.1
+Standards-Version: 4.7.2
 Homepage: https://github.com/slicer69/sysvinit
 Vcs-Git: https://salsa.debian.org/debian/sysvinit.git
 Vcs-Browser: https://salsa.debian.org/debian/sysvinit
@@ -111,9 +111,11 @@
  psmisc,
  util-linux-extra,
 Breaks: udev (<<  254.3-1),
-   util-linux-extra (<< 2.39.2-2.1~)
+   util-linux-extra (<< 2.39.2-2.1~),
+   kmod (<< 34.1-1)
 Replaces: udev (<<  254.3-1),
- util-linux-extra (<< 2.39.2-2.1~)
+ util-linux-extra (<< 2.39.2-2.1~),
+ kmod (<< 34.1-1)
 Description: scripts for initializing and shutting down the system
  The scripts in this package initialize a standard Debian
  system at boot time and shut it down at halt or reboot time.
diff -Nru sysvinit-3.14/debian/initscripts.postinst 
sysvinit-3.14/debian/initscripts.postinst
--- sysvinit-3.14/debian/initscripts.postinst   2025-02-24 09:27:01.0 
+
+++ sysvinit-3.14/debian/initscripts.postinst   2025-03-10 16:49:51.0 
+
@@ -42,7 +42,7 @@
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
-   bootlogs rc.local rmnologin hwclock.sh"
+   bootlogs rc.local rmnologin hwclock.sh kmod"
 
 for F in $INITSCRIPTS; do
if [ -x "$DPKG_ROOT/etc/init.d/$F" ]; then
diff -Nru sysvinit-3.14/debian/src/initscripts/etc/init.d/kmod 
sysvinit-3.14/debian/src/initscripts/etc/init.d/kmod
--- sysvinit-3.14/debian/src/initscripts/etc/init.d/kmod1970-01-01 
01:00:00.0 +0100
+++ sysvinit-3.14/debian/src/initscripts/etc/init.d/kmod2025-03-10 
16:49:51.0 +
@@ -0,0 +1,92 @@
+#!/bin/sh -e
+### BEGIN INIT INFO
+# Provides:  kmod
+# Required-Start:
+# Required-Stop: 
+# Should-Start:  checkroot
+# Should-Stop:
+# Default-Start: S
+# Default-Stop:
+# Short-Description: Load the modules listed in /etc/modules.
+# Description:   Load the modules listed in /etc/modules.
+### END INIT INFO
+
+# Silently exit if the kernel does not suppo

Bug#1100042: ITP: python-casttube -- Interact with the YouTube Chromecast API

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-casttube
  Version : 0.2.1
  Upstream Author : Uri Katz <4urik...@gmail.com>
* URL : https://github.com/ur1katz/casttube
* License : MIT
  Programming Lang: Python
  Description : Interact with the YouTube Chromecast API

  This library allows users to engage with the YouTube Chromecast API, enabling
  control over video playback on devices with Chromecast capabilities. It can
  initiate the playing of videos or playlists, manage queue operations such as
  adding and removing videos, and handle playback controls including play next
  and clearing the queue. This library communicates with a YouTube app running
  on a Chromecast device, requiring a screen ID for interactions. Leveraging
  this API, casttube provides functionality for controlling media displayed
  through Chromecast, making it possible to manage streaming directly from a
  programmatic interface.

I plan to maintain this package as part of the Python team.

Bug#1099278: python-uvicorn: FTBFS: E assert '{"example":123}' == '{"example": 123}'

[Santiago Vila]

The attached patch resolves the issue by supporting both JSON formats.


Thanks a lot! I'm going to push that to salsa and will make a team upload
if it passes CI tests.

Thanks.

Bug#1093124: libhsa-runtime64-1: HSA exception: Queue create failed at hsaKmtCreateQueue with multiple programs

[Dieter Faulbaum]

Hello to all who are involved,

there is a newer kernel (6.10.17) in trixie but it seems for me, 
that the patch

https://lore.kernel.org/all/2025013412.29812-1-philip.y...@amd.com/T/
from Philip Yang hasn't found its way into this kernel.
The problem still exists.

With regards
Dieter

Bug#1099716: s-nail: needlessly depends on base-files

[cacin]

Source: s-nail
Followup-For: Bug #1099716

It started as trying to remove dependencies on usr-is-merged or usrmerge
packages, so that they can be removed from trixie, because /usr-merge is
finished in trixie.

base-files provides usr-is-merged so it was caught as a dependency for
the packages I checked. And for those packages I checked if base-files
dependency is still needed (for backports as a fallback, which is a
little bit of an antipattern, but is sometimes used), and if not then it
can be removed as a dependency too.

And if base-files is removed as a dependency from all packages, then
it's more likely the Provides: usr-is-merged can be dropped from
base-files in the debian release after trixie.

I can see why it could be seen as QA cleanup on packages, and I agree
with that assessment. I'm not aware of any immediate issue resulting
from keeping the base-files dependency.

Bug#1100099: ITP: python-elastcsearch8 -- Python client for Elasticsearch8

[Karsten Schöke]

Package: wnpp
Severity: wishlist
Owner: Karsten Schöke 
X-Debbugs-Cc: debian-de...@lists.debian.org

  Package name: python-elastcsearch8
  Version : 8.17.2
  Upstream Contact: Elastic Client Library Maintainers 

  URL : https://github.com/elastic/elasticsearch-py
  License : Apache-2.0
  Programming Lang: Python
  Description : Python client for Elasticsearch8

Official low-level client for Elasticsearch version 8.
Its goal is to provide common ground for all 
Elasticsearch-related code in Python; because of this it tries
to be opinion-free and very extendable.
 
The client's features include:
 * translating basic Python data types to and from json (datetimes are not
   decoded for performance reasons)
 * configurable automatic discovery of cluster nodes
 * persistent connections
 * load balancing (with pluggable selection strategy) across all available
   nodes
 * failed connection penalization (time based - failed connections won't be
   retried until a timeout is reached)
 * thread safety
 * pluggable architecture
 * Helper functions for idiomatically using APIs together

This is a new dependency of python-elasticsearch-curator
an will be maintained by DPT.

Bug#1100100: postfix: configure-instance's cp call fails on overlayfs over nfs4

[Cornelius Hoffmann]

Package: postfix
Version: 3.10.1-1
Severity: important

Hi,

I'm facing an issue on a ephemeral machine booted into a read-only nfs4
root with an overlayfs to make / writable. postfix doesn't start, since
the copy command in configure-instance:91 fails. It copies the data, but
overlayfs has an long-standing issue with nfs4_acls [1], which cp -p will
try to copy but fail. The files are thus copied over and on the next
start of postfix, the service will start without any issues (complaing
again about the same problem for copying the libraries in Line 109, which
is ignored though by the trailing || : in this line.
Is there a specific reason to copy these files with -p? From what I can
tell, they're all word-readable and owned by root:root, so maybe
preserving timestamps (if that is intended) would be enough? From the
commit introducing -p [2], It seems like this was done to have more
readable code.

That would solve this issue for this specific scenario without
interfering with other installations as far as I can tell.

I acknowledge that this should ideally be fixed in overlayfs for a
general solution, but in hope of getting a faster solution, I wanted to
ask if you'd consider changing the cp options.

Best,
Cornelius Hoffmann

[1] 
https://lore.kernel.org/linux-fsdevel/cajfpeguwutrwrgmnmimnp-fxzwqmccqmb24iwpu0w_j0_ro...@mail.gmail.com/
[2] 
https://salsa.debian.org/postfix-team/postfix-dev/-/commit/ca82392182402ab7de571346d27345e6644952d2


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

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

Versions of packages postfix depends on:
ii  adduser3.137
ii  debconf [debconf-2.0]  1.5.89
ii  init-system-helpers1.68
ii  libc6  2.40-7
ii  libdb5.3t645.3.28+dfsg2-9
ii  libicu72   72.1-6
ii  libnsl21.3.0-3+b3
ii  libsasl2-2 2.1.28+dfsg1-9
ii  libssl3t64 3.4.1-1
ii  libtlsrpt0 0.5.0rc1-2
ii  netbase6.4

Versions of packages postfix recommends:
ii  ca-certificates  20241223
ii  python3  3.13.2-1
pn  ssl-cert 

Versions of packages postfix suggests:
ii  emacs-nox [mail-reader]1:30.1+1-4
pn  libsasl2-modules | dovecot-common  
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mongodb
pn  postfix-mta-sts-resolver   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  postfix-sqlite 
pn  procmail   
pn  sasl2-bin | dovecot-common 
ii  systemd-resolved [resolvconf]  257.3-1
pn  ufw

-- debconf information:
  postfix/main_mailer_type: No configuration
  postfix/bad_recipient_delimiter:
  postfix/rfc1035_violation: false
  postfix/protocols:
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/mailbox_limit: 0
  postfix/recipient_delim: +
  postfix/relayhost:
  postfix/destinations:
  postfix/root_address:
  postfix/procmail:
  postfix/not_configured:
  postfix/mailname: /etc/mailname

Bug#1099278: python-uvicorn: FTBFS: E assert '{"example":123}' == '{"example": 123}'

[Sebastiaan Couwenberg]

On 3/11/25 12:41 PM, Santiago Vila wrote:

The attached patch resolves the issue by supporting both JSON formats.


Thanks a lot! I'm going to push that to salsa and will make a team upload
if it passes CI tests.


Thanks for the team upload. A similar patch is available for starlette in 
#1100087.

Both packages are the reason for a lot of testing autoremovals.

Kind Regards,

Bas

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

Bug#1100120: libopenmpi-dev: mpi4py spawn tests get OPAL ERROR: Unreachable in file ../../../ompi/runtime/ompi_mpi_finalize.c at line 286

[Drew Parsons]

Package: libopenmpi-dev
Version: 5.0.7-1
Severity: serious
Justification: FTBFS (dependencies)

mpi4py build-time tests are showing problems in openmpi, with
buildtime tests failing. That's with mpi4py 4.0.3-1.
debci tests from its last build are still passing for now.

I'm assuming the bug is in openmpi, not mpi4py itself, since mpi4py is
passing tests with mpich (32 bit arches).

The first problem comes from PMIX,
  An error occurred in PMIx Event Notification
The error is reproducible,
cf. 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mpi4py.html

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/mpi4py_4.0.3-1.rbuild.log.gz
It is triggered by test_util_pkl5, and also test_util_pool,
test_util_sync and test_win.
It is associated with a kernel general protection fault from prte.
That bug is reported in Bug#1098576, currently assigned to pmix though
I suspect it might be an openmpi issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098576


Here I'm reporting a second problem: spawn is failing,
for instance:

ERROR: testNoArgs (test_spawn.TestSpawnSingleWorldMany.testNoArgs)
--
Traceback (most recent call last):
  File "/home/drew/projects/python/build/mpi4py/test/test_spawn.py", line 175, 
in testNoArgs
child = self.COMM.Spawn(
script, None, self.MAXPROCS,
info=self.INFO, root=self.ROOT,
)
  File "src/mpi4py/MPI.src/Comm.pyx", line 2544, in mpi4py.MPI.Intracomm.Spawn
with nogil: CHKERR( MPI_Comm_spawn(
mpi4py.MPI.Exception: MPI_ERR_UNKNOWN: unknown error

--
Ran 1857 tests in 84.632s

FAILED (errors=40, skipped=162)
[sandy:272668] OPAL ERROR: Unreachable in file 
../../../ompi/runtime/ompi_mpi_finalize.c at line 286


I've marked this bug severity serious because of the message at the
end concerning the OPAL error in ompi_mpi_finalize.c (as well as the
MPI_ERR_UNKNOWN errors in the spawn tests).  If the OPAL message is a
red herring then please downgrade severity if appropriate.



We could just skip the failing tests in mpi4py (in fact I will for now),
but the underlying problem should be fixed in any case.

With mpi4py, I will upload 4.0.3-2 skipping the pmix failures, in
order to get a reproducible record of the spawn failure. After that I
will upload a release of mpi4py to skip the spawn tests, until the
issue is fixed in openmpi (or pmix).



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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15] 4:14.2.0-1
ii  gfortran-11 [gfortran-mod-15]  11.5.0-2
ii  gfortran-12 [gfortran-mod-15]  12.4.0-4
ii  gfortran-13 [gfortran-mod-15]  13.3.0-12
ii  gfortran-14 [gfortran-mod-15]  14.2.0-17
ii  libevent-dev   2.1.12-stable-10+b1
ii  libhwloc-dev   2.12.0-1
ii  libibverbs-dev 56.0-2
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui1.13.2+dfsg-1
ii  libopenmpi40   5.0.7-1
ii  libpmix-dev5.0.6-5
ii  openmpi-bin5.0.7-1
ii  openmpi-common 5.0.7-1
ii  zlib1g-dev 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.10.2+ds-4

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#1100119: plasma-pass: Incompatible with Plasma 6

[Hendrik Iseke]

Package: plasma-pass
Version: 1.2.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The plasma-pass is not compatible with Plasma 6 in Trixie/Sid. The widget 
appears in the configuration panel, but it's not selectable and marked as 
"unsupported widget".

The issue seems to be resolved in upstream with this commit [1].

Regards,
Hendrik Iseke

[1] 
https://invent.kde.org/plasma/plasma-pass/-/commit/74c011b634f3bdbdcd80a74b252e6499774756f2


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

Kernel: Linux 6.12.17-amd64 (SMP w/12 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 plasma-pass depends on:
ii  libc6 2.41-4
ii  libgpgmepp6t641.24.2-1+b1
ii  libkf5coreaddons5 5.115.0-2+b1
ii  libkf5i18n5   5.115.1-2+b3
ii  libkf5itemmodels5 5.115.0-2+b1
ii  libkf5plasma5 5.115.0-7
ii  liboath0t64   2.6.12-1
ii  libqgpgme15t641.24.2-1+b1
ii  libqt5concurrent5t64  5.15.15+dfsg-4
ii  libqt5core5t645.15.15+dfsg-4
ii  libqt5dbus5t645.15.15+dfsg-4
ii  libqt5gui5t64 5.15.15+dfsg-4
ii  libqt5qml55.15.15+dfsg-3
ii  libstdc++614.2.0-17

plasma-pass recommends no packages.

Versions of packages plasma-pass suggests:
ii  pass1.7.4-7
pn  pass-extension-otp  

-- no debconf information

Bug#1100115: font-manager: please make the build reproducible

[Jeremy Bícha]

Control: forwarded -1 https://github.com/FontManager/font-manager/issues/439

On Tue, Mar 11, 2025 at 9:21 AM Chris Lamb  wrote:
>   ./usr/share/metainfo/com.github.FontManager.FontManager.metainfo.xml
>@@ -173,15 +173,15 @@
>   
>   
>-
>+
>   
>
> A patch is attached that generates this value using SOURCE_DATE_EPOCH.

I'm not sure if using SOURCE_DATE_EPOCH is appropriate for AppStream
metadata release dates, but I've reported this issue upstream.

Thank you,
Jeremy Bícha

Bug#1100078: budie-desktop: something weird happen, it causes login failure

[Kentaro HAYASHI]

At least, I can reproduce using snapshot.d.o (JST)

* http://snapshot.debian.org/archive/debian/20250306T21Z
  * able to login budgie-desktop
* http://snapshot.debian.org/archive/debian/20250307T00Z
  * failed to login budgie-desktop

In these time frame, GNOME components such as gnome-shell was changed
from 48~beta-4 to 48~rc-2 and so on.

Here is the journalctl -xe logs. I hope it will help.


 3月 11 20:56:20 unstable-desktop gnome-keyring-daemon[1660]:
 discover_other_daemon: 1
 3月 11 20:56:20 unstable-desktop at-spi-bus-launcher[1619]:
 dbus-daemon[1619]: Activating service name='org.a11y.atspi.Registry' requested 
by ':1.3' (uid=1000 pid=1678 comm="/usr/libexec/gsd-keyboard")
 3月 11 20:56:20 unstable-desktop at-spi-bus-launcher[1619]:
 dbus-daemon[1619]: Successfully activated service 'org.a11y.atspi.Registry'
 3月 11 20:56:20 unstable-desktop at-spi-bus-launcher[1795]:
 SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
 3月 11 20:56:20 unstable-desktop gsd-xsettings[1667]: Failed to get
 current UI scaling factor: GDBus.Error:org.freedesktop.DBus.Error.NameH
asNoOwner: Name "org.gnome.Mutter.X11" does not exist
 3月 11 20:56:20 unstable-desktop dbus-daemon[1414]: [session uid=1000
 pid=1414 pidfd=5] Activating service name='org.gnome.ScreenSaver' req
uested by ':1.32' (uid=1000 pid=1679
 comm="/usr/libexec/gsd-usb-protection")
 3月 11 20:56:20 unstable-desktop gsd-keyboard[1678]: g_variant_unref:
 assertion 'value != NULL' failed
 3月 11 20:56:20 unstable-desktop kernel: rfkill: input handler disabled
 3月 11 20:56:20 unstable-desktop dbus-daemon[1414]: [session uid=1000
 pid=1414 pidfd=5] Successfully activated service 'org.gnome.ScreenSav
er'
 3月 11 20:56:20 unstable-desktop budgie-session[1507]:
 budgie-session-binary[1507]: WARNING: Could not retrieve current screensaver 
active 
state: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message
 recipient disconnected from message bus without replying
 3月 11 20:56:20 unstable-desktop budgie-session-binary[1507]: WARNING:
 Could not retrieve current screensaver active state: GDBus.Error:org
.freedesktop.DBus.Error.NoReply: Message recipient disconnected from
 message bus without replying
 3月 11 20:56:20 unstable-desktop gsd-usb-protect[1679]: Failed to get
 screen saver status: GDBus.Error:org.freedesktop.DBus.Error.NoReply: 
Message recipient disconnected from message bus without replying
 3月 11 20:56:20 unstable-desktop dbus-daemon[1414]: [session uid=1000
 pid=1414 pidfd=5] Activating service name='org.gnome.ScreenSaver' req
uested by ':1.46' (uid=1000 pid=1704 comm="/usr/libexec/gsd-power")
 3月 11 20:56:20 unstable-desktop gsd-usb-protect[1679]: Failed to
 fetch USBGuard parameters: GDBus.Error:org.freedesktop.DBus.Error.Service
Unknown: The name org.usbguard1 was not provided by any .service files
 3月 11 20:56:20 unstable-desktop dbus-daemon[1414]: [session uid=1000
 pid=1414 pidfd=5] Successfully activated service 'org.gnome.ScreenSav
er'
 3月 11 20:56:20 unstable-desktop budgie-session[1507]:
 budgie-session-binary[1507]: WARNING: Could not retrieve current screensaver 
active 
state: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message
 recipient disconnected from message bus without replying
 3月 11 20:56:20 unstable-desktop budgie-session-binary[1507]: WARNING:
 Could not retrieve current screensaver active state: GDBus.Error:org
.freedesktop.DBus.Error.NoReply: Message recipient disconnected from
 message bus without replying
 3月 11 20:56:20 unstable-desktop budgie-wm[1860]: Running
 Mutter(Budgie) (using mutter 0.9.4) as a X11 window and compositing manager
 3月 11 20:56:20 unstable-desktop gsd-power[1704]: Error setting
 property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: メソ
ッドを起動できません: proxy がオーナーのない既知の名前
 org.gnome.Mutter.DisplayConfig で、G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START フラグで prox
y が作成されていました (g-io-error-quark, 0)
 3月 11 20:56:20 unstable-desktop budgie-wm[1860]:
 g_variant_get_string: assertion 'value != NULL' failed
 3月 11 20:56:20 unstable-desktop budgie-wm[1860]: The mapping function
 given to g_settings_get_mapped() for key 'overlay-key' in schema 'or
g.gnome.mutter' returned FALSE when given a NULL value.
 3月 11 20:56:20 unstable-desktop kernel: traps: budgie-wm[1860] trap
 int3 ip:7f93021ad6f7 sp:7ffcff3c5150 error:0 in libglib-2.0.so.0.8305.
0[656f7,7f9302166000+a1000]
 3月 11 20:56:20 unstable-desktop budgie-session[1507]:
 budgie-session-binary[1507]: WARNING: Application 
'org.buddiesofbudgie.BudgieWm.desk
top' killed by signal 5
 3月 11 20:56:20 unstable-desktop budgie-session-binary[1507]: WARNING:
 Application 'org.buddiesofbudgie.BudgieWm.desktop' killed by signal 
5
 3月 11 20:56:20 unstable-desktop budgie-wm[1899]: Running
 Mutter(Budgie) (using mutter 0.9.4) as a X11 window and compositing manager
 3月 11 20:56:20 unstable-desktop budgie-wm[1899]:
 g_variant_get_string: assertion 'value != NULL' failed
 3月 11 20:56:20 unstable-desktop budgie-wm[1899]: The mapping functi

Bug#1100122: ITP: aiorussound -- Asyncio client for Russound RIO devices

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: aiorussound
  Version : 4.4.0
  Upstream Author : Noah Husby 
* URL : https://github.com/noahhusby/aiorussound
* License : MIT
  Programming Lang: Python
  Description : Asyncio client for Russound RIO devices

  Provides an asynchronous client implementation for interacting with Russound
  audio controllers using the Russound I/O (RIO) protocol. This library
  accommodates communication through TCP/IP and RS232, enabling integration with
  various Russound devices like MBX-PRE, MBX-AMP, and MCA-C5. It offers support
  for push notifications of system changes and utilizes the built-in Ethernet
  port on Russound devices for seamless connectivity. The RS232 port can be
  configured via the SCS-C5 configuration tool or the controller's Web GUI to
  support RIO protocol instead of RNET.

This library is a dependancy of Home Assistant, the Python smart home platform.
I plan to maintain it as part of the Home Assistant team.

Bug#1100123: RFP: pg-parquet -- Copy to/from Parquet in S3 or Azure Blob Storage from within PostgreSQL

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: h...@torproject.org, debian-r...@lists.debian.org

* Package name: pg-parquet
  Version : 0.3.0
  Upstream Contact: https://github.com/CrunchyData/
* URL : https://github.com/CrunchyData/pg_parquet/
* License : PostgreSQL
  Programming Lang: Rust
  Description : Copy to/from Parquet in S3 or Azure Blob Storage from 
within PostgreSQL

pg_parquet is a PostgreSQL extension that allows you to read and write
Parquet files, which are located in S3 or file system, from PostgreSQL
via COPY TO/FROM commands. It depends on Apache Arrow project to read
and write Parquet files and pgrx project to extend PostgreSQL's COPY
command.



This is something we're looking at using inside Tor to archive
long-term data from postgresql into object storage. See
https://gitlab.torproject.org/tpo/tpa/team/-/issues/41416 and related.

Another alternative is a "foreign data wrapper" like:

https://github.com/pgspider/parquet_s3_fdw

We're not absolutely sure which one the best, we might need both.

Bug#1099632: Treat AARs as zips

[Matt Corallo]

On 3/11/25 10:16 AM, Chris Lamb wrote:

Matt Corallo wrote:


https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.1.0;hb=refs/heads/main
and
https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.0.0;hb=refs/heads/main


Thanks for linking these. So, the proximate cause of this issue is
that the underlying file(1) utility reports these as Android packages:

 $ file v0.1.0.0_LDK-release.aar v0.1.1.0_LDK-release.aar
 v0.1.0.0_LDK-release.aar: Android package (APK), with AndroidManifest.xml
 v0.1.1.0_LDK-release.aar: Android package (APK), with AndroidManifest.xml

In general, diffoscope basically has to trust what file(1) reports and
proceed on that basis. We used to work around its bugs, but as you can
imagine, that became something of a game of whack-a-mole...

In the first instance, just to confirm that file(1) is at fault here? As
in, these are definitely not Android packages. :)


They're android "packages" in that they're libraries that other APKs can depend on, but certainly 
not runnable apps or anything of the like.


AFAIU, all "Android package (APK)"s should be treated like zips cause they are just zips with 
specific files in them.

Bug#1090742: Please drop Provides: avahi-autoipd

[Martin-Éric Racine]

pe 24.1.2025 klo 19.20 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti:
>
> pe 24.1.2025 klo 19.04 Michael Biebl (bi...@debian.org) kirjoitti:
> >
> > Am 24.01.25 um 17:39 schrieb Martin-Éric Racine:
> > > pe 24.1.2025 klo 18.20 Michael Biebl (bi...@debian.org) kirjoitti:
> > >> Am 27.12.24 um 10:42 schrieb Martin-Éric Racine:
> > >>> dhclient doesn't provide IPv4LL but has hooks to call avahi-autoipd as
> > >>> needed. Meanwhile dhcpcd provides IPv4LL out of the box, along the
> > >>> same fallback connectivity logic as avahi-autoipd. Having both
> > >>> installed is not only redundant, it concurrently tries to control the
> > >>> same interfaces.
> > >>
> > >> Ok, let's drill down here a bit. I assume you mean the following two 
> > >> hooks:
> > >>
> > >> avahi-autoipd: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd
> > >> avahi-autoipd: /etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd
> > >>
> > >> Are those hooks executed by dhpcd? My understanding is, that those hooks
> > >> are only executed by isc-dhcp-client and dhcpd ignores them.
> > >
> > > Those are indeed ignored by dhcpcd.
> >
> > Ok, thanks for confirming.
> >
> > > However, those are triggered on any host running ifupdown:
> > >
> > > avahi-autoipd: /etc/network/if-down.d/avahi-autoipd
> > > avahi-autoipd: /etc/network/if-up.d/avahi-autoipd
> > >
> > > That is what overlaps with dhcpcd's built-in IPv4LL fallback.
> >
> > What exactly is problematic in those hooks?
> > Those add a 169.254.0.0 route if not already existent. How does this
> > clash with dhcpcd?
>
> It has been ages since I resorted to purging avahi-autoipd as a
> solution, but of what I recall a 169.254.0.0 route kept on appearing
> regardless of whether we had acquired an outside IP or not. As soon as
> I purged it, dhcpcd handled the whole process itself without
> interference.

I into this looked again. Two things:

1) On Bookworm, avahi-autoipd explicitly Recommends the ISC client.
Since the ISC client is the first DHCP implementation in ifupdown's
search path, it results in dhcpcd getting ignored in favor of
dhclient. That's probably what got me investigating ways to prevent
this from happening. In fairness, the explicit Recommends is gone in
Trixie, and ifupdown's search path has been shuffled to favor dhcpcd.

2) Adding 169.254.0.0 via avahi-autoipd is superflous since dhcpcd
already provides the feature built-in. Besides, on systems where
dhcpcd is used, both packages would compete for adding and managing
that network.

Maritn-Éric

Bug#1086805: ffmpeg: please provide versionless libav* that pull the latest versioned binaries

[Martin-Éric Racine]

to 7.11.2024 klo 12.13 Fabian Greffrath (fab...@greffrath.com) kirjoitti:
>
> Am 2024-11-07 11:04, schrieb Martin-Éric Racine:
> > Replacing all the *-extra with the metapackage already is possible.
> > Replacing the non-extra ones is not.
>
> I see, so this is about dlopen()ed shared libraries. Thanks for the
> example!

Welcome. Has there been any progress on this?

Martin-Éric

Bug#1100035: kmod: Please add the init script

[Mark Hindley]

On Mon, Mar 10, 2025 at 06:10:39PM +0100, Marco d'Itri wrote:
> OK, but do I need do do anything else other than removing 
> kmod.maintscript?

You also need to rework or revert

  
https://salsa.debian.org/md/kmod/-/commit/c2ae42ca3a338fba0f190e3a61a635d386b1e8fa

as also mentioned in https://bugs.debian.org/1100072. Kmod shouldn't be using rm
on the symlinks. At least use update-rc.d and check if /etc/init.d/kmod doesn't
still exist (i.e hasn't been taken over). If you are unsure, you might want to
look at Michael Biebl's way of dealing with this situation in udev.postinst.

Mark

Bug#1100084: gnome-software: Outdated apps listed in Editor's choice in GNOME 48

[sidt]

Package: gnome-software
Version: 48~rc-1
Severity: normal
X-Debbugs-Cc: sidto...@gmail.com

The list of curated apps in the following default files shipped with GNOME
Software are outdated.

- /usr/share/swcatalog/xml/org.gnome.Software.Curated.xml
- /usr/share/swcatalog/xml/org.gnome.Software.Featured.xml

E.g GNOME dictionary and GNOME photos are archived GNOME projects.

We still use the following options in "debian/rules"

  -Dhardcoded_curated=true \
  -Ddefault_featured_apps=true

which uses the default files listed above. The recommended fix is to use the
app list from https://gitlab.gnome.org/GNOME/gnome-app-list.

Also refer https://gitlab.gnome.org/GNOME/gnome-
software/-/blob/main/doc/vendor-customisation.md#3-appstream-files-shipped-
with-gnome-software-for-testing-purposes-only

Thanks!


-- 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)
Foreign Architectures: i386

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

Versions of packages gnome-software depends on:
ii  dconf-gsettings-backend [gsettings-backend]0.40.0-5
ii  gnome-software-common  48~rc-1
ii  gnome-software-plugin-deb [gnome-software-plugin]  48~rc-1
ii  gnome-software-plugin-flatpak [gnome-software-plugin]  48~rc-1
ii  gnome-software-plugin-snap [gnome-software-plugin] 48~rc-1
ii  gsettings-desktop-schemas  48~beta-1
ii  libadwaita-1-0 1.7~beta-2
ii  libappstream5  1.0.4-1
ii  libc6  2.41-3
ii  libgdk-pixbuf-2.0-02.42.12+dfsg-2
ii  libglib2.0-0t642.83.5-1
ii  libgtk-4-1 4.17.5+ds-3
ii  libgudev-1.0-0 238-6
ii  libjson-glib-1.0-0 1.10.6+ds-1
ii  libmalcontent-0-0  0.13.0-1
ii  libpackagekit-glib2-18 1.3.0-3
ii  libpango-1.0-0 1.56.1-1
ii  libpolkit-gobject-1-0  126-2
ii  libsoup-3.0-0  3.6.4-2
ii  libxmlb2   0.3.21-1

Versions of packages gnome-software recommends:
ii  gnome-software-plugin-deb48~rc-1
ii  gnome-software-plugin-fwupd  48~rc-1

Versions of packages gnome-software suggests:
ii  gnome-software-plugin-flatpak  48~rc-1
ii  gnome-software-plugin-snap 48~rc-1

-- Configuration Files:
/etc/xdg/autostart/org.gnome.Software.desktop [file not found]

-- no debconf information

Bug#1100095: ITP: golang-github-tredoe-osutil -- access to operating system functionality

[Thomas Goirand]

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

* Package name: golang-github-tredoe-osutil
  Version : 1.5.0
  Upstream Contact: 2021-2024, Nathan Otterness
* URL : https://github.com/tredoe/osutil
* License : MPL-2.0
  Programming Lang: Go
  Description : access to operating system functionality

 The tredoe/osutil package provides access to operating system functionality
 that is dependent on the platform. It includes utilities for executing
 commands with standard input, output, and error handling, as well as
 cryptographic functions for hashing passwords using various algorithms such
 as SHA-512 and SHA-256.
 .
 This module is useful for developers who need to interact with the operating
 system in a platform-agnostic way, ensuring compatibility across different
 environments.
 .
 Features:
  * Execute commands with full control over standard input, output, and error
streams.
  * Cryptographic utilities for hashing passwords using SHA-512, SHA-256, and
other algorithms.
  * Platform-dependent functionality abstracted for ease of use.

I'll maintain this package in the Go team, as a reverse-depends for mgmt-config.

Bug#1094083: fixed in bzrtp 5.3.104-1

[Emilio Pozuelo Monfort]

On Fri, 07 Feb 2025 11:20:41 + Debian FTP Masters 
 wrote:

Source: bzrtp
Source-Version: 5.3.104-1
Done: Victor Seva 

We believe that the bug you reported is fixed in the latest version of
bzrtp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1094...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Victor Seva  (supplier of updated bzrtp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 07 Feb 2025 10:25:57 +0100
Source: bzrtp
Architecture: source
Version: 5.3.104-1
Distribution: unstable
Urgency: medium
Maintainer: Debian VoIP Team 
Changed-By: Victor Seva 
Closes: 1094083
Changes:
 bzrtp (5.3.104-1) unstable; urgency=medium
 .
   * add myself to Uploaders. wrap-and-sort -sat
   * Set upstream metadata fields: Repository-Browse.
   * New upstream version 5.3.104
   * update stack dependencies (Closes: #1094083)
   * debian/copyright: update
   * remove empty patches/to_upstream
   * refresh debian/patches
   * update Breaks with versions in trixie and bookworm


The auto-removals is triggering removal of this package, which is preventing the 
fix from entering testing. As the rest of the stack seems to be ready and is 
blocked by this removal, let's ping the bug so the autoremoval is dropped, and 
the packages are tried for migration, which should hopefully fix this issue in 
testing.


Emilio

Bug#973654: AW: Bug#973654: marked as done (TLS: start_SSL fails to set SSL_verifycn_name)

[Syldatke, Andreas]

Hi,

I don't need any infos via bugs.debian.org, but I don't know, how to unsuscribe 
from that list.
May you can give me a hint or unsubscribe me from the list. Thanks in advance.

Andreas Syldatke


Mit freundlichen Grüßen

V O L K S W O H L  B U N D
Lebensversicherung a.G.
Sachversicherung Aktiengesellschaft

Andreas Syldatke
IT-Serversysteme&Netze

Telefon: 0231 5433-585
Fax: 0231 5433-750585
andreas.sylda...@volkswohl-bund.de

Sie finden Informationen zur Verarbeitung Ihrer Daten unter:
http://www.volkswohl-bund.de/datenschutz
Auf Wunsch schicken wir Ihnen die Datenschutzhinweise auch gerne zu.


VOLKSWOHL BUND LEBENSVERSICHERUNG a.G., Südwall 37 - 41, 44137 Dortmund
Vorstand: Dr. Gerrit Böhm (Vorsitzender), Celine Carstensen-Opitz, Klaus 
Keßner, Stefanie van Holt
Vorsitzender des Aufsichtsrats: Dr. Joachim Maas
Sitz des Unternehmens: Dortmund, Registergericht: Amtsgericht Dortmund, HRB 
29381

VOLKSWOHL BUND SACHVERSICHERUNG AG, Südwall 37 - 41, 44137 Dortmund
Vorstand: Dr. Gerrit Böhm (Vorsitzender), Celine Carstensen-Opitz, Klaus 
Keßner, Stefanie van Holt
Vorsitzender des Aufsichtsrats: Dr. Joachim Maas
Sitz des Unternehmens: Dortmund, Registergericht: Amtsgericht Dortmund, HRB 3134

Telefon: 0231/5433-0, Telefax: 0231/5433-400,  i...@volkswohl-bund.de,  
i...@volkswohl-bund.epost.de, www.volkswohl-bund.de

-Ursprüngliche Nachricht-
Von: Debian Bug Tracking System 
Gesendet: Sonntag, 9. März 2025 21:45
An: Brian May 
Betreff: Bug#973654: marked as done (TLS: start_SSL fails to set 
SSL_verifycn_name)

Your message dated Mon, 10 Mar 2025 07:41:29 +1100 with message-id 
<87msduc4xy@debian.org> and subject line Re: Bug#973654: TLS: start_SSL 
fails to set SSL_verifycn_name has caused the Debian Bug report #973654, 
regarding TLS: start_SSL fails to set SSL_verifycn_name to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the Bug report 
if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this message is 
talking about, this may indicate a serious mail system misconfiguration 
somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Bug#1100092: bmap-tools: --psplash-pipe flag not working in bmap-tools version 3.6 in Bookworm

[Shekar, Kasturi]

Hi Andrej Shadura,

I have worked on fixing Bug #1100092 in the bmap-tools package,
addressing the issue where the --psplash-pipe flag was not functioning. Even 
after applying an initial fix, the _psplash_pipe part was skipped when 
_progress_file was null, preventing progress updates from being displayed 
correctly when using psplash with bmap-tools.
With the attached patch, the issue has been resolved, and I am now able to use 
psplash with bmap-tools as expected, with progress being updated properly.

Please review the patch at your convenience.

Note: This issue is fixed with 3.8 version in Debian 13 Trixie but the issue is 
still present in Debian 12 Bookworm.

Thank you,
Kasturi Shekar
kasturi.she...@siemens.com



0002-Fix-_psplash_pipe-part-was-skipped-when-_progress_fi.patch
Description:  0002-Fix-_psplash_pipe-part-was-skipped-when-_progress_fi.patch


0001-Fix-path-parameter-passing-error-of-set_psplash_pipe.patch
Description:  0001-Fix-path-parameter-passing-error-of-set_psplash_pipe.patch

Bug#1099716: s-nail: needlessly depends on base-files

[Paride Legovini]

On 2025-03-07 02.05, ca...@allfreemail.net wrote:
> Source: s-nail
> Version: 14.9.25-1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> the s-nail package needlessly depends on the base-files package, which
> is an essential package installed on all debian systems.
> 
> Please remove this dependency. Patch attached. Thanks.

Hi and thanks for the patch!

The dependency on base-files is not entirely useless as it is a
*versioned* dependency. However, the required version is so old that we
can safely drop it, even considering backports.

How would you like the change to be attributed in the packaging
repository git history [1] and in the package changelog? Is just
"ca...@allfreemail.net" fine?

The best way to answer this question is by converting the patch you
submitted into a salsa MR against [1]. This way we'll also get CI to run
on your change before merging.

Cheers,

Paride

[1] https://salsa.debian.org/debian/s-nail

Bug#1013093: info

[Oswald Buddenhagen]

this has been discussed upstream, see
https://sourceforge.net/p/isync/mailman/isync-devel/thread/20a4197379dc195856bcd53cb0ecb325%40doctors.org.uk/

my conclusion was that there is a bug in debian, but obviously not in
the isync package, but something openssl-related.

Bug#1100092: bmap-tools: --psplash-pipe flag not working in bmap-tools version 3.6 in Bookworm

[Andrej Shadura]

Hi,

On Tue, 11 Mar 2025, at 11:26, Kasturi Shekar wrote:
> I have worked on fixing Bug #1100092 in the bmap-tools package,
>  
> Note: This issue is fixed with 3.8 version in Debian 13 Trixie but the issue 
> is still present in Debian 12 Bookworm.

Thanks for your work, but I believe this bug is not serious enough to warrant 
an upload into bookworm. I’ll think about it a bit more, but don’t hold your 
hopes high.

-- 
Cheers,
  Andrej

Bug#1100089: adduser: french update of adduser translations

[Guillonneau Jean-Paul]

Package: adduser
Version: 3.137
Severity: wishlist

Dear Maintainer,

Please find attached the french update of the translation of the following
files of adduser, proofread by the
debian-l10n-french mailing list contributors :
/adduser/po/fr.po
/adduser/doc/po4a/translator_french.add
/adduser/doc/po4a/translator_french2.add ⇒ /dev/null
/adduser/doc/po4a/po/fr.po

Regards
Jean-Paul Guillonneau


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

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

Versions of packages adduser depends on:
ii  passwd  1:4.17.3-1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron3.0pl1-194
ii  liblocale-gettext-perl  1.07-7+b1
ii  perl5.40.1-2
pn  quota   

-- no debconf information
PO4A-HEADER:mode=after;position=^\.SH "VOIR AUSSI";beginboundary=^\.SH
.SH TRADUCTION
Ce document est une traduction réalisée par Christophe Sauthier
(2002), reprise avec po4a par Nicolas FRANÇOIS
(2004-2008) et mise à jour par David Prévot  (2010) et
Jean-Paul Guillonneau  (2016-2025).

L'équipe de traduction a fait le maximum pour réaliser une adaptation
française de qualité.

La version anglaise de ce document est toujours consultable
en ajoutant l'option «\ \-L C\ » à la commande \fBman\fR.

N'hésitez pas à signaler à l'auteur ou à la liste de traduction
.nh
<\fIdebian\-l10n\-fre...@lists.debian.org\fR>,
.hy
selon le cas, toute erreur dans cette page de manuel.


adduser.tar.bz2
Description: BZip2 compressed data


adduser.tar.bz2
Description: BZip2 compressed data

Bug#1100088: node-public-encrypt: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1

[Naaz, Syeda Shagufta]

Source: node-public-encrypt
Version: 4.0.3-1
Severity: serious
Justification: FTBFS
Tags: bookworm ftbfs

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
(Explain what the reason for the (old-)stable update is. I.e.
what is the bug, when was it introduced, is this a regression
with respect to the previous (old-)stable.)
The bug is introduced in Nodejs v18.20.4+dfsg-1~deb12u1 by the security fix for 
CVE-2023-46809, 
which removed support for RSA_PKCS1_PADDING for private decryption.
This is a regression compared to the previous Nodejs v18.19.0+dfsg-6~deb12u2, 
where the padding was allowed.
Node-public-encrypt is failing to build with the newer nodejs version.
Log:
```
node:internal/crypto/cipher:80
return method(data, format, type, passphrase, buffer, padding, oaepHash,
   ^

TypeError: RSA_PKCS1_PADDING is no longer supported for private decryption, 
this can be reverted with --security-revert=CVE-2023-46809
at Object.privateDecrypt (node:internal/crypto/cipher:80:12)
at Test. (/<>/test/index.js:56:25)
at Test.bound [as _cb] (/usr/share/nodejs/tape/lib/test.js:95:17)
at Test.run (/usr/share/nodejs/tape/lib/test.js:115:28)
at Test.bound [as run] (/usr/share/nodejs/tape/lib/test.js:95:17)
at Test._end (/usr/share/nodejs/tape/lib/test.js:218:5)
at Test.bound [as _end] (/usr/share/nodejs/tape/lib/test.js:95:17)
at Test. (/usr/share/nodejs/tape/lib/test.js:217:34)
at Test.emit (node:events:517:28)
at Test.bound [as emit] (/usr/share/nodejs/tape/lib/test.js:95:17) {
  code: 'ERR_INVALID_ARG_VALUE'
}

Node.js v18.20.4
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:8: binary] Error 25
```

[ Impact ]
(What is the impact for the user if the update isn't approved?)
The ratt test fails to build node‑public-encrypt, it indicates that the changes 
to RSA_PKCS1_PADDING in newer Nodejs version are causing failures.
In our case, the failure isn’t just about decryption errors at runtime, it 
prevents the entire test suite (and thus the build process) from completing.

[ Tests ]
(What automated or manual tests cover the affected code?)
In node‑public-encrypt, the automated test suite (invoked via npm run test or 
through autopkgtest) is affected, the test causing failure is test/index.js.
In Nodejs, the ratt test to build node‑public-encrypt is impacted.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, alternatives available.)
Without this update, our test would fail in Nodejs versions that no longer 
support RSA_PKCS1_PADDING padding for private decryption.
This inconsistency can lead to build failures (e.g., ratt test failures) and 
runtime errors.

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

[ Changes ]
(Explain *all* the changes)
I have submitted my proposed changes for your review. Please take a moment to 
look them over,
https://salsa.debian.org/js-team/node-public-encrypt/-/merge_requests/1
The try/catch block now checks for PKCS1 padding when private decryption is 
attempted. This prevents the test from failing on Nodejs newer versions where 
this behavior has been removed due to security fix for 
CVE-2023-46809.

[ Other info ]
(Anything else the release team should know.)
The npm run test and autopkgtest are passing successfully for 
node-public-encrypt on both older(18.19.0+dfsg-6~deb12u2) and 
newer(18.20.4+dfsg-1~deb12u1) Nodejs versions.

Syeda Shagufta Naaz

Bug#1100003: hx: Syntax highlighting requires building grammar plugins locally

[Bastian Venthur]

Package: hx
Followup-For: Bug #113
X-Debbugs-Cc: vent...@debian.org

Hi Jonas,

thanks for your reply.

> There are multiple concerns here:
> 
> # Sources for grammar plugins is not in Debian
> 
> Either hundreds of source packages need to be introduced to Debian, or
> the src:hx package would need to carry hundreds of embedded projects.
> 
> I think the best approach is to package the sources for the more
> popular grammars only, and think the best approach is that those
> interested in some grammar join the tree-sitter team and file a
> bugreport against hx when sources are available in Debian.

Thanks for the explanation, I understand that these tree-sitter plugins
should be packaged separately so they can be used by other packages such
as neovim. Does that mean that the few existing tree-sitter packages for
C, Lua, Markdown, etc. could already be utilized by hx?

Also, would you be open to make hx depend on a reasonable set of
treesitter plugins by default?

> # Grammar plugins are either system-shared or personal
> 
> If I recall correctly (it is some time ago I looked into that),
> grammar plugins can be stored below /usr - but if a single plugin
> exists below ~/.config/helix/runtime/grammars then the system-shared
> plugins are all ignored.
> 
> Ideally we should convince upstream to improve this, but if not then I
> am willing to carry a reasonably small patch for Debian. Help making
> such patch is welcome.

This sounds not right, maybe this has been fixed upstream already. If
not, this should probably be fixed.

> # Grammar plugins slows startup of Helix
> 
> My main concern with many plugins is not size but speed: As I recall,
> I experienced a noticable slowdown in startup of Helix when many
> plugins are loaded.

Can you verify if that is still the case? I tried both cases: none and
all tree-siter plugins and did not perceive any performance difference.


Thank you for your patience,

Bastian


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

Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 hx depends on:
ii  libc6  2.41-4
ii  libgcc-s1  14.2.0-17

Versions of packages hx recommends:
ii  g++  4:14.2.0-1

Versions of packages hx suggests:
ii  bash-completion1:2.16.0-7
pn  clangd 
pn  delve  
pn  dhall  
pn  elan   
pn  elvish 
pn  fortran-language-server
pn  gopls  
pn  lldb   
pn  perlnavigator  
ii  python3-pylsp  1.12.0-3
pn  qt6-declarative-dev-tools  

-- no debconf information

Bug#1099017: debci: apt-listbugs autopkgtest fails on riscv64: /usr/bin/auto-apt-proxy: 176: avahi-browse: not found

[Francesco Poli]

On Tue, 4 Mar 2025 13:41:11 -0300 Antonio Terceiro wrote:

[...]
> At this point this was either done silently by someone else, or the 
> system fixed itself:
> 
> root@ci-worker-s390x-01:~# zcat 
> /var/lib/lxc/autopkgtest-unstable-s390x/rootfs/usr/share/doc/auto-apt-proxy/changelog.gz
>   | head -1
> auto-apt-proxy (16.3) unstable; urgency=medium
> root@ci-worker-s390x-01:~# zcat 
> /var/lib/lxc/autopkgtest-testing-s390x/rootfs/usr/share/doc/auto-apt-proxy/changelog.gz
>   | head -1
> auto-apt-proxy (16.3) unstable; urgency=medium
> 
> containers are usually updated twice a day, automatically.
[...]

Indeed, a new upload of apt-listbugs migrated from unstable to testing
in 2 or 3 days, due to all the autopkgtest checks being successful.

In other words, I no longer seem to experience issues with
auto-apt-proxy and 'avahi-browse'-related errors.

Thanks to Antonio and to all the people involved in fixing this bug!


There's something about Debian CI that I do not fully understand though.

The autopkgtest checks that shortened the testing-migration delay were
successful: apt-listbugs/0.1.47 (from unstable) tested within a Debian
testing container was OK (tests pass).

This can be seen for [amd64] in the line:

0.1.47  2025-03-08 01:11:47 UTC  apt-listbugs/0.1.47  src:apt-listbugs from 
unstable  1m 47s  pass  britney  test log (6.5 KB) artifacts (9.89 KB)

[amd64]: 

And similarly for other architectures.

Now this version (apt-listbugs/0.1.47) has migrated to Debian testing.

Nonetheless, the DebCI [summary] page for apt-listbugs still shows
several failed tests and no results for apt-listbugs/0.1.47:

[...]
|  unstable  testing   stableoldstable
| amd640.1.46 fail   0.1.46 fail   0.1.40 pass   0.1.35 pass
| arm640.1.45 pass   0.1.46 fail   0.1.40 pass   0.1.35 pass
| armel0.1.46 pass   0.1.46 fail   0.1.40 pass   0.1.35 pass
| armhf0.1.46 fail   0.1.46 fail   0.1.40 pass   0.1.35 pass
| i386 0.1.46 fail   0.1.46 fail   0.1.40 pass   0.1.35 pass
| loong64  0.1.45 pass   No reference  No reference  No reference
| ppc64el  0.1.46 fail   0.1.46 fail   0.1.40 pass   0.1.35 pass
| riscv64  0.1.44 fail   0.1.45 pass   No reference  No reference
| s390x0.1.45 pass   0.1.46 fail   0.1.40 pass   0.1.35 pass 
[...]

[summary]: 

And the package [tracker] page still complains about failed Debci tests:

[...]
| Debci reports failed tests
[...]

[tracker]: 


When will these failed test results be replaced by the passed test
results for apt-listbugs/0.1.47 ?

Could you please clarify?
Thanks for your time and patience!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1ZroWrwpF7.pgp
Description: PGP signature

Bug#1100083: pixelmed-www: creates files in /webstart under root directory

[cacin]

Package: pixelmed-www
Severity: serious
Justification: Policy 9.1.1

Dear Maintainer,

the package pixelmed-www unpacks these files directly under the / root
directory:
/webstart/DicomCleanerUsage.html
/webstart/DicomImageViewerUsage.html
/webstart/DoseUtilityUsage.html

This is definitely the wrong location for those files, and likely
violates debian policy §9.1.1 [1] "The location of all files and
directories must comply with the Filesystem Hierarchy Standard (FHS),
version 3.0, [...]" and FHS [2]. It is however definitely the wrong
location for the .desktop entry, and does not function as intended.

[1] 
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

Bug#1062662: gnome-software: Option "--show-metainfo" is missing in manpage

[Sid T]

This was fixed in 47.rc.

Bug#1091979: u-boot-menu: Fails to add fdt or fdtdir entries

[Vagrant Cascadian]

Control: Severity 1091979 serious
Control: tags 1091979 confirmed

On 2025-03-03, Vagrant Cascadian wrote:
> Looping Arnaud into the conversation, as I suspect the patches submitted
> were touching this code quite a bit:
>
> 51d120d549e5b21a19ce659c7bef578c86ed9636 Allow to automatically sync DTBs 
> when /boot is on a separate partition (Closes: #1025956)
> 96a866bc886f118de9286a00587b2e1fcf263105 read-config: make /boot partition 
> check a function
>
> Of course I am the one who uploaded them, but antoehr pair of eyes
> obviously will not hurt! :)
>
> live well,
>   vagrant
>
> On 2025-03-03, Johannes Schauer Marin Rodrigues wrote:
>> Quoting Johannes Schauer Marin Rodrigues (2025-01-02 23:53:53)
>>> The lines that should contain an fdt or fdtdir entry are missing. Lets look 
>>> at
>>> the sh -x output to figure out why they were not generated:
>>> 
>>>  1 P: Writing config for vmlinuz-6.12.6-mnt-reform-arm64...
>>>  2 + _NUMBER=0
>>>  3 + _ENTRY=1
>>>  4 + [ -e /boot/initrd.img-6.12.6-mnt-reform-arm64 ]
>>>  5 + _INITRD=initrd /initrd.img-6.12.6-mnt-reform-arm64
>>>  6 + [ -e  ]
>>>  7 + [ -e /boot6.12.6-mnt-reform-arm64/ ]
>>>  8 + [ -d /boot6.12.6-mnt-reform-arm64/ ]
>>>  9 + [ -f /boot/dtb-6.12.6-mnt-reform-arm64 ]
>>> 10 + [ /usr/lib/linux-image- =  ]
>>> 11 + _FDT=
>>> 
>>> Line 6 checks an empty value because U_BOOT_FDT is unset. Line 7 and 8 
>>> cannot
>>> work because there is a missing slash between ${_BOOT_PATH} and
>>> ${U_BOOT_FDT_DIR}. Line 9 finds /boot/dtb-6.12.6-mnt-reform-arm64 but the 
>>> check
>>> in line 10 fails because {U_BOOT_FDT_DIR} is unset. Why is it unset? Because
>>> even though read-config found a separate /boot partition in
>>> has_separate_boot(), U_BOOT_SYNC_DTBS was set to false, so _FDT_DIR was 
>>> never
>>> set to "/dtb-" and even if it were set to that, the check in line 10 would
>>> still fail because "/usr/lib/linux-image-" is not equal to "/dtb-". So to
>>> summarize:
>>> 
>>>  1. why is a fdt or fdtdir line not added by default?
>>>  2. why are there missing slashes in line 7 and 8?
>>>  3. why do i have to enable U_BOOT_SYNC_DTBS? I already use flash-kernel 
>>> for that
>>>  4. why is there a check for "/usr/lib/linux-image-" if _FDT_DIR gets set 
>>> to "/dtb-"?
>>> 
>>> One workaround is to set:
>>> 
>>> U_BOOT_FDT_DIR="/dtbs/"
>>> 
>>> which will then add fdtdir entries that look correct. The slashes are 
>>> critical
>>> because they are missing in the u-boot-update script.
>>
>> so here is a potential patch:
>>
>> --- /usr/share/u-boot-menu/read-config
>> +++ /usr/share/u-boot-menu/read-config
>> @@ -48,6 +48,8 @@
>>  if [ "${U_BOOT_SYNC_DTBS}" = "true" ]
>>  then
>>  _FDT_DIR="/dtb-"
>> +else
>> +_FDT_DIR="/dtbs/"
>>  fi
>>  else
>>  # / and /boot are on the same filesystem
>>
>> With that in place, extlinux.conf will now contain a line like this:
>>
>>  fdtdir /dtbs/6.12.15-mnt-reform-arm64/
>>
>> Note, how this is still a change in behaviour. With u-boot-menu from 
>> Bookworm,
>> not fdtdir would be set but one would have:
>>
>>  fdt /dtb-6.12.15-mnt-reform-arm64
>>
>> But maybe that change is intentional?
>>
>> I can make an attempt at different fix for this problem but I'd need to
>> understand what is supposed to happen first. My four questions above still 
>> are
>> unanswered and especially with the missing slashes and the unset _FDT_DIR, 
>> the
>> code *can* not work as it is or am I missing something?

I one problem is that u-boot-menu and flash-kernel and using the same
path, e.g. /boot/dtb-X.Y.Z-ARCH, but for flash-kernel it expects it to
be a symlink to the specific .dtb file to use, and the new u-boot-menu
syncing functionality expects it to be a directory...

I think if u-boot-menu used /boot/dtbs/X.Y.Z-ARCH which flash-kernel
includes as a directory, it might just work. Still probably a few more
issues to sort out... (e.g. it behaves differently if
U_BOOT_SYNC_DTBS=true rather than just responding to what files are
present). I noticed a few runs where it still broke the older kernels
even if I managed to somewhat manually fix a newer one.

I have not had a chance to dig into untangling this yet, but it warrants
a serious severity, as it can break booting on previously valid
combinations of packages (e.g. u-boot-menu and flash-kernel), which
could be an ugly surprise for a bookworm upgrade...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1074796: gnome-shell: Silently applies pending package updates on shutdown

[Sid T]

> When I select "Power off" from the power menu at the top right of the
> screen if there any pending package updates then instead of shutting
> down GNOME will reboot into a single user mode, apply the pending
> package updates and then shut down.  I have never noticed any visible
> indication that this will happen rather than an immediate shutdown.

When shutting down using "Power Off" you should see a checkbox in the
shutdown dialog.

Bug#1100083: pixelmed-www: creates files in /webstart under root directory

[cacin]

Package: pixelmed-www
Followup-For: Bug #1100083

I meant to say .html files, not .desktop files, they should likely
belong in the /usr/share/pixelmed/ directory, and editing the
debian/pixelmed-www.install file is the way of solving this.

Bug#1100054: gir-rust-code-generator: Does not grok output of newer gobject-introspection

[Jeremy Bícha]

Control: reopen -1

On Mon, Mar 10, 2025 at 7:57 PM Samuel Thibault  wrote:
> When building rust-gdk4 against a rebuilt gtk4, I am still getting
>
> Error: "GirXml: ./Gdk-4.0.gir at line 17:3: Unexpected element "
>
> To save yourself a complete gtk4 rebuild, I have attached the generated
> Gdk-4.0.gir, you can overwrite your /usr/share/gir-1.0/Gdk-4.0.gir with
> it.

I confirm that my rust-libadwaita test case is still failing.

Thank you,
Jeremy Bícha

Bug#1100104: network-manager-l2tp: trying access /usr/lib/ipsec/charon which cannot be installed

[David Heidelberg]

Package: network-manager-l2tp
Version: 1.20.20-1+b1
Severity: normal

Hello!

I was trying to connect to network over l2tp.

# apt install network-manager-l2tp-gnome

setup connection using L2TP and IPSEC in GNOME settings.

After trying to connect, this appears in the log:

NetworkManager[21788]:   [1741693089.1265] audit: 
op="connection-activate" uuid="_redacted_" name="IceW>
nm-l2tp-service[26306]: nm-l2tp-service (version 1.20.20) starting...
nm-l2tp-service[26306]: /sbin/ipsec status > /dev/null 2>&1
nm-l2tp-service[26306]: /sbin/ipsec start  --conf /run/nm-l2tp-_redacted_/" 
ipsec.conf --debug
NetworkManager[26323]: IKE daemon '/usr/lib/ipsec/charon' not found
ipsec_starter[26323]: IKE daemon '/usr/lib/ipsec/charon' not found
NetworkManager[21788]:   [1741693089.1915] 
vpn[0x555942418f10,_redacted_,"_redacted_"]: failed to connect:>

strongswan-charon cannot be installed as it conflicts.

Thank you
David

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

Kernel: Linux 6.12.17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 network-manager-l2tp depends on:
ii  libc62.41-4
ii  libglib2.0-0t64  2.84.0-1
ii  libnm0   1.52.0-4
ii  libnspr4 2:4.36-1
ii  libnss3  2:3.109-1
ii  libssl3t64   3.4.1-1
ii  network-manager  1.52.0-4
ii  ppp  2.5.2-1+1
ii  xl2tpd   1.3.18-1+b1

network-manager-l2tp recommends no packages.

network-manager-l2tp suggests no packages.

-- no debconf information

Bug#1100105: linux-image-amd64: Issues with Framework audio module

[Richard]

Package: linux-image-amd64
Version: 6.12.17-1
Severity: normal

Dear Maintainer,

as of a couple of months ago I have regular issues with the USB C to audio jack 
module from Framework, and any error logs of the time this happens point to the 
Kernel. E.g. I compiled 6.13.4 from source, based on the config Debian shipped 
with the 6.12.15 Kernel (updated with make olddefconfig), there it shows these 
messages:

Mär 01 17:31:43 kernel: usb 1-2.2: 1:1: cannot set freq 48000 (v2/v3): err -110
Mär 01 17:31:48 kernel: usb 1-2.2: uac_clock_source_is_valid(): cannot get 
clock validity for id 9
Mär 01 17:31:48 kernel: usb 1-2.2: clock source 9 is not valid, cannot use
Mär 01 17:31:53 kernel: usb 1-2.2: 1:1: cannot get freq (v2/v3): err -110


These issues started at some point late last years, possibly since 6.12 was 
introduced into testing. I've tested up until 6.13.6 now, with no change, only 
a varying degree of information in the logs. A detailed thread can be found in 
[1]. What should be mentioned, originally, when this happened, all audio 
devices would vanish from Gnome settings audio page. But with 6.13, they still 
all show up, but e.g. if you open the little audio channel test widget and try 
to test a channel, the widget just freezes up.


Framework themselves can't to further debugging, as they only officially 
support Ubuntu and Fedora. Running any of them as a live distro is simply not 
feasible, as this issue can't just be triggered and only appears about once a 
week.


Is there something else to help finding out, where the issue is located, or 
even rule out a software issue? I'm already testing out the other USB C ports 
of my Framework 16, but the point is that I don't have any other device capable 
of USB C and using that audio module.


[1]: 
https://community.frame.work/t/responded-audio-expansion-card-connection-sometimes-unreliable/62951/20

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

Kernel: Linux 6.13.6-falcot (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 linux-image-amd64 depends on:
ii  linux-image-6.12.17-amd64  6.12.17-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#1100107: uim: Please drop ancient dpkg versioned Pre-Depends

[Guillem Jover]

Source: uim
Source-Version: 1:1.9.0-2
Severity: wishlist

Hi!

This package contains an ancient versioned Pre-Depends on dpkg, added
in 2012 for dpkg-maintsctipt-helper. This is not currently needed, but
has been entangling this package with dpkg's testing migration for
several Debian releases via its autopkgtests.

Please drop dpkg from the Pre-Depends.

Thanks,
Guillem

Bug#1100101: pyqt6-webengine: autopkgtest fails with glibc 2.41 due to executable stack

[Luca Boccassi]

Control: severity -1 normal

On Tue, 11 Mar 2025 12:05:14 + Luca Boccassi 
wrote:
> Source: pyqt6-webengine
> Version: 6.8.0-1
> Severity: grave
> Justification: blocks glibc 2.41 from migrating to trixie
> X-Debbugs-Cc: aure...@debian.org
> 
> Dear Maintainer(s),
> 
> glibc 2.41 added some hardening that block having an executable stack
> for security reasons.
> 
> pyqt6-webengine seems to require an executable stack and autopkgtest
> using it are failing with glibc 2.41 from unstable:
> 
>  75s python3.13 -c "import PyQt6.QtWebEngineCore"
>  75s Traceback (most recent call last):
>  75s   File "", line 1, in 
>  75s import PyQt6.QtWebEngineCore
>  75s ImportError: libQt6WebEngineCore.so.6: cannot enable executable
stack as shared object requires: Invalid argument
> 
>
https://ci.debian.net/packages/p/pyqt6-webengine/testing/i386/58709056/
> 
> A possible solution would be to build libQt6WebEngineCore.so.6 with
'-
> Wl,-z,noexecstack' assuming it's not actually needed to work.

Downgrading as this is a known issue and only on i386, and the failing
autopkgtest will be bypassed

Bug#1100087: starlette: autopkgtest failure

[Bas Couwenberg]

Source: starlette
Version: 0.46.1-1
Severity: serious
Tags: upstream patch
Justification: makes the package unusable

Dear Maintainer,

The autopkgtests fail with the older dependencies in testing due to changes in 
the JSON formatting:

  89s E   assert {'body': '{"a": "123"}'} == {'body': '{"a":"123"}'}

The attached patch fixes the issue by supporting both formats.

Kind Regards,

Bas
diff -Nru starlette-0.46.1/debian/patches/json-format.patch 
starlette-0.46.1/debian/patches/json-format.patch
--- starlette-0.46.1/debian/patches/json-format.patch   1970-01-01 
01:00:00.0 +0100
+++ starlette-0.46.1/debian/patches/json-format.patch   2025-03-11 
09:12:42.0 +0100
@@ -0,0 +1,34 @@
+Description: Fix test failures with older dependencies in testing.
+Author: Bas Couwenberg 
+
+--- a/tests/middleware/test_wsgi.py
 b/tests/middleware/test_wsgi.py
+@@ -78,7 +78,7 @@ def test_wsgi_post(test_client_factory:
+ client = test_client_factory(app)
+ response = client.post("/", json={"example": 123})
+ assert response.status_code == 200
+-assert response.text == '{"example":123}'
++assert response.text in ['{"example":123}', '{"example": 123}']
+ 
+ 
+ def test_wsgi_exception(test_client_factory: TestClientFactory) -> None:
+--- a/tests/test_requests.py
 b/tests/test_requests.py
+@@ -92,7 +92,7 @@ def test_request_body(test_client_factor
+ assert response.json() == {"body": ""}
+ 
+ response = client.post("/", json={"a": "123"})
+-assert response.json() == {"body": '{"a":"123"}'}
++assert response.json() in [{"body": '{"a":"123"}'}, {'body': '{"a": 
"123"}'}]
+ 
+ response = client.post("/", data="abc")  # type: ignore
+ assert response.json() == {"body": "abc"}
+@@ -113,7 +113,7 @@ def test_request_stream(test_client_fact
+ assert response.json() == {"body": ""}
+ 
+ response = client.post("/", json={"a": "123"})
+-assert response.json() == {"body": '{"a":"123"}'}
++assert response.json() in [{"body": '{"a":"123"}'}, {'body': '{"a": 
"123"}'}]
+ 
+ response = client.post("/", data="abc")  # type: ignore
+ assert response.json() == {"body": "abc"}
diff -Nru starlette-0.46.1/debian/patches/series 
starlette-0.46.1/debian/patches/series
--- starlette-0.46.1/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ starlette-0.46.1/debian/patches/series  2025-03-11 09:12:42.0 
+0100
@@ -0,0 +1 @@
+json-format.patch

Bug#1099192:

[Raul Tambre]

X-Debbugs-CC: debian-input-met...@lists.debian.org

FYI for ibus-anthy maintainers too since I'm not sure which it belongs to.
And I initially accidentally assigned this to src:python3-gi, which is at fault.

Bug#1093987: mbsync.1: Missing documentation for SSLType deprecation

[Oswald Buddenhagen]

On Sun, Feb 02, 2025 at 02:47:55PM +0100, Alejandro Colomar wrote:

With the former, I might confuse it for an internal error notice.


seems a bit far-fetched, but fair enough. done in commit 281a9ba4.
note that no line number is printed, as that would be potentially
confusing, given that repetitions are suppressed.


It doesn't take too much space, and documents the transition.


that's kinda true, but it seems pointless to do that, as mbsync reports
both the old and new keywords. remaining use cases seem rather
academical to me.

Bug#1099624: libc6 2.41 pthread cause pari to FTBFS

[Bill Allombert]

On Tue, Mar 11, 2025 at 09:12:15AM +0100, Bill Allombert wrote:
> On Mon, Mar 10, 2025 at 11:49:39PM +0100, Aurelien Jarno wrote:
> > I also noticed it failed the same way on arm64.
> 
> Thanks for confirming!
> 
> > > > Please tell me if you would like me to do more experiments.
> > > 
> > > If you have time, yes, that's very useful. I'll also try to have a
> > > closer look at your testcase, but it already seems relatively small.
> > 
> > I am not sure I understand everything yet, but it seems that building
> > pari with -fexceptions is a good workaround for the issue.
> 
> Alas, this would break the ABI of the libpari,
> and I still get failure with -fexceptions: instead of crashes, the program
> terminate without printing Done:
> 
> %for i in `seq 1 100`; do (set -e; echo -n "$i " && sid ./pthread1) || break; 
> done
> 1 Done!
> 2 3 4 5 6 Done!
> 7 8 Done!
> 9 10 11 12 13 Done!
> 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Done!
> 29 30 31 Done!
> 32 33 34 Done!
> 35 36 37 38 39 40 Done!
> 41 42 43 44 45 46 Done!
> 47 48 49 50 51 52 53 Done!
> 54 55 56 57 58 59 60 61 62 63 64 65 ^C%
> 
> I join a simplified test-case.

which is compiled with

gcc  pthread3.c -Wall -O0 -g -pthread -o pthread3 -fexceptions

by doing 'br _exit' under gdb I get

Thread 5016 "pthread3" hit Breakpoint 1.1, __GI__exit (status=status@entry=0) 
at ../sysdeps/unix/sysv/linux/_exit.c:27
warning: 27 ../sysdeps/unix/sysv/linux/_exit.c: Aucun fichier ou dossier de 
ce nom
(gdb) bt
#0  __GI__exit (status=status@entry=0) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1  0x77dcb1d6 in __run_exit_handlers (status=status@entry=0, 
listp=0x77f70680 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) 
at ./stdlib/exit.c:141
#2  0x77dcb31a in __GI_exit (status=status@entry=0) at 
./stdlib/exit.c:148
#3  0x77e1bba1 in start_thread (arg=) at 
./nptl/pthread_create.c:497
#4  0x77e997b8 in __GI___clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) c
Continuing.
[Thread 0x72d7b6c0 (LWP 3665238) exited]
[Inferior 1 (process 3660113) exited normally]

But actually the line printf("Done!") was not reached.

Cheers,
Bill

Bug#1100092: bmap-tools: --psplash-pipe flag not working in bmap-tools version 3.6 in Bookworm

[kasturi]

Package: bmap-tools
Version: 3.8.0-1
Severity: important
Tags: d-i patch upstream
X-Debbugs-Cc: kasturi.she...@siemens.com

Dear Maintainer,

*** 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.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages bmap-tools depends on:
ii  python3  3.11.2-1+b1
ii  python3-gpg  1.18.0-3+b1
ii  python3-six  1.16.0-4

Versions of packages bmap-tools recommends:
ii  bzip2 1.0.8-5+b1
ii  lzop  1.04-2
ii  xz-utils  5.4.1-0.2

Versions of packages bmap-tools suggests:
ii  lz4 1.9.4-1
ii  pbzip2  1.1.13-1
ii  pigz2.6-1
ii  unzip   6.0-28

-- no debconf information

Bug#1093987: mbsync.1: Missing documentation for SSLType deprecation

[Alejandro Colomar]

On Tue, Mar 11, 2025 at 12:59:58PM +0100, Oswald Buddenhagen wrote:
> On Sun, Feb 02, 2025 at 02:47:55PM +0100, Alejandro Colomar wrote:
> > With the former, I might confuse it for an internal error notice.
> > 
> seems a bit far-fetched, but fair enough. done in commit 281a9ba4.
> note that no line number is printed, as that would be potentially
> confusing, given that repetitions are suppressed.

Hi Oswald,

Thanks!  That commit should be enough.


Have a lovely day!
Alex

> 
> > It doesn't take too much space, and documents the transition.
> > 
> that's kinda true, but it seems pointless to do that, as mbsync reports
> both the old and new keywords. remaining use cases seem rather
> academical to me.
> 

-- 



signature.asc
Description: PGP signature

Bug#1021178: gnome-software: does not properly render package description (-tags)

[Sid T]

Can this bug be closed ?

Bug#1099624: libc6 2.41 pthread cause pari to FTBFS

[Bill Allombert]

On Mon, Mar 10, 2025 at 11:49:39PM +0100, Aurelien Jarno wrote:
> I also noticed it failed the same way on arm64.

Thanks for confirming!

> > > Please tell me if you would like me to do more experiments.
> > 
> > If you have time, yes, that's very useful. I'll also try to have a
> > closer look at your testcase, but it already seems relatively small.
> 
> I am not sure I understand everything yet, but it seems that building
> pari with -fexceptions is a good workaround for the issue.

Alas, this would break the ABI of the libpari,
and I still get failure with -fexceptions: instead of crashes, the program
terminate without printing Done:

%for i in `seq 1 100`; do (set -e; echo -n "$i " && sid ./pthread1) || break; 
done
1 Done!
2 3 4 5 6 Done!
7 8 Done!
9 10 11 12 13 Done!
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Done!
29 30 31 Done!
32 33 34 Done!
35 36 37 38 39 40 Done!
41 42 43 44 45 46 Done!
47 48 49 50 51 52 53 Done!
54 55 56 57 58 59 60 61 62 63 64 65 ^C%

I join a simplified test-case.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 
/* Copyright (C) 2013  The PARI group.

This file is part of the PARI/GP package.

PARI/GP is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version. It is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY WHATSOEVER.

Check the License for details. You should have received a copy of it, along
with the package; see the file 'COPYING'. If not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */
#include 
#include 
#include 
#include 

struct mt_state
{
  long workid;
};

struct mt_queue
{
  long workid;
};

struct mt_pstate
{
  pthread_t *th;
  void **pth;
  struct mt_queue *mq;
  long n;
};

static void
mt_queue_cleanup(void *arg)
{
  (void) arg;
}

static void*
mt_queue_run(void *arg)
{
  pthread_cleanup_push(mt_queue_cleanup,NULL);
  for(;;)
  {
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,NULL);
for(long u=1; u<1; u++);
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,NULL);
  }
  pthread_cleanup_pop(1);
  return NULL;
}

void
mt_queue_start_lim(long lim)
{
  struct mt_pstate *mt =
 (struct mt_pstate*) malloc(sizeof(struct mt_pstate));
  long i;
  mt->mq  = (struct mt_queue *) malloc(sizeof(*mt->mq)*lim);
  mt->th  = (pthread_t *) malloc(sizeof(*mt->th)*lim);
  mt->pth = (void **) malloc(sizeof(*mt->pth)*lim);
  mt->n = lim;
  for (i=0;imq+i;
mt->pth[i] = (void*)mq;
  }
  for (i=0;ith[i],NULL, &mt_queue_run, (void*)mt->pth[i]);
  for (i=0; ith[i]);
  for (i=0; ith[i],NULL);
}

int
main(void)
{
  long k;
  for (k = 1; k<1000; k++)
mt_queue_start_lim(8);
  printf("Done!\n");
}

Bug#1100086: zvol sync/flush regression in 2.2.7+

[Fabian Grünbichler]

Subject: zvol sync/flush regression in 2.2.7+
Package: zfs-dkms
X-Debbugs-Cc: f.gruenbich...@proxmox.com
Version: 2.2.7-1
Severity: grave
Forwarded: https://github.com/openzfs/zfs/pull/17131
Tags: upstream patch

hi!

zfs 2.2.7 and later do not honor all kinds of sync writes/flush requests
properly when issued on zvols. notably, using a zvol as backing device
for a Qemu virtual block device is affected, and ZFS treats all sync
writes issued by applications in the VM as async. this can lead to
inconsistencies or dataloss.

I bisected and found the upstream commit introducing the regression, and
proposed a fix upstream (see linked PR, which also contains a reproducer).

the packages in trixie and bookworm-backports should probably both be
updated, the fix is rather small and targeted ;)

thanks for your consideration!
Fabian

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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.91
ii  dkms   3.1.5-1
ii  file   1:5.45-3+b1
ii  libc6-dev [libc-dev]   2.41-4
ii  libpython3-stdlib  3.13.2-2
ii  lsb-release12.1-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.12.17-1
ii  zfs-zed 2.3.0-2
ii  zfsutils-linux  2.3.0-2

Versions of packages zfs-dkms suggests:
ii  debhelper  13.24.1

-- debconf information excluded
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
55 lines yanked 

   1,1   All

Bug#1100085: mnemosyne: creates /usr/pixmaps/ instead of using /usr/share/pixmaps/

[cacin]

Source: mnemosyne
Version: 2.11+ds1-1
Severity: serious
Justification: Policy 9.1.1

Dear Maintainer,

the mnemosyne package currently creates the /usr/pixmaps/ directory and
places files there. The correct directory to use is however
/usr/share/pixmaps/

This is likely some violation of debian policy §9.1.1 [1] and FHS [2],
and also goes against user expectations of pixmaps being placed in
/usr/share/pixmaps/

[1] 
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#theUsrHierarchy

Bug#1100091: thunderbird: Can't connect to google calendar anymore

[Bastian Venthur]

Package: thunderbird
Version: 1:136.0-1
Severity: normal
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

recently, google calendars stopped working with Thunderbird. I observed
the behaviour with 128.8.0esr-1 and it persists with 136.0 from
experimental. I did not see this issue with 128.6 and 128.7.

Thunderbird is showing me a dialog for my existing google calenders
asking for permission to access my google account and all calendars,
after affirming, i get an error message:

> Unable to connect
> 
> The connection was refused when attempting to contact localhost.
> 
> The site could be temporarily unavailable or too busy. Try again
> in a few moments. If you are unable to load any pages, check your
> computer’s network connection. If your computer or network is
> protected by a firewall or proxy, make sure that Thunderbird is
> permitted to access the web.

I notice that the url in the error window points to:

https://localhost/?code=XXX&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar

I've redacted the code segment, observe the localhost.


Cheers,

Bastian

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

Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 thunderbird depends on:
ii  debianutils  5.21
ii  fontconfig   2.15.0-2.1
ii  libasound2t641.2.13-1+b1
ii  libatk1.0-0t64   2.55.2-1
ii  libc62.41-4
ii  libcairo-gobject21.18.2-2
ii  libcairo21.18.2-2
ii  libdbus-1-3  1.16.2-2
ii  libevent-2.1-7t642.1.12-stable-10+b1
ii  libffi8  3.4.7-1
ii  libfontconfig1   2.15.0-2.1
ii  libfreetype6 2.13.3+dfsg-1
ii  libgcc-s114.2.0-17
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-2
ii  libglib2.0-0t64  2.84.0-1
ii  libgtk-3-0t643.24.48-4
ii  libnspr4 2:4.36-1
ii  libnss3  2:3.109-1
ii  libotr5t64   4.1.1-6
ii  libpango-1.0-0   1.56.1-1
ii  librnp0  0.17.1-1+b1
ii  libstdc++6   14.2.0-17
ii  libvpx9  1.15.0-2
ii  libx11-6 2:1.8.10-2
ii  libx11-xcb1  2:1.8.10-2
ii  libxcb-shm0  1.17.0-2+b1
ii  libxcb1  1.17.0-2+b1
ii  libxext6 2:1.3.4-1+b3
ii  libxrandr2   2:1.5.4-1+b3
ii  psmisc   23.7-2
ii  x11-utils7.7+7
ii  zenity   4.1.90-1
ii  zlib1g   1:1.3.dfsg+really1.3.1-1+b1

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-15
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-3

Versions of packages thunderbird suggests:
ii  apparmor  4.1.0~beta5-3
ii  fonts-lyx 2.4.3-1
ii  libgssapi-krb5-2  1.21.3-4

-- no debconf information

Bug#1100035: kmod: Please add the init script

[Mark Hindley]

Control: retitle -1 Kmod removes LSB initscript and startup links 
unconditionally which breaks non-systemd systems
Control: severity -1 serious

These changes are already causing breakage in non-systemd systems[1].
Specifically, even where the sysadmin has explicitly kept a copy of
/etc/init.d/kmod the kmod postinst will remove it and the symlinks regardless.
To avoid further spread, the broken version in sid should not migrate to
trixie. Hence, raising to RC severity.

Mark

[1]   https://bugs.debian.org/1100072

Bug#1099017: debci: apt-listbugs autopkgtest fails on riscv64: /usr/bin/auto-apt-proxy: 176: avahi-browse: not found

[Francesco Poli]

On Tue, 11 Mar 2025 09:35:10 + Simon McVittie wrote:

[...]
> That will happen when ci.debian.net gets far enough through its queue to 
> have done a test that consists purely of packages from unstable or 
> testing (as appropriate) and includes apt-listbugs/0.1.47. (It will be 
> labelled "migration-reference".)
[...]
> There has been no migration-reference job run in testing since 0.1.47 
> migrated, and it is the migration-reference jobs that are shown in the 
> summary.

OK, thanks for the explanation!   :-)
I was beginning to suspect something like that, but I wanted to be sure.

So, I will have to wait for the queue to be processed...
Bye!


P.S.: if others agree, I think this bug report can be safely closed.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgplZjmMlTNYM.pgp
Description: PGP signature

Bug#1100030: why adduser in preinst?

[Marc Haber]

Hi Simon,

On Tue, Mar 11, 2025 at 08:34:46AM +0100, Simon Josefsson wrote:

A single call of
adduser --system --group --home=/var/lib/jabberd2 --no-create-home jabber
will already do it.


Thanks -- I suspect the actual reason may be lost in time.  What is the
exact patch you are thinking of, is it the one below?  I'm happy to
apply it and see of Salsa is happy and then upload and see if we get any
reports.


Actually, just doing
adduser --system --group --home=/var/lib/jabberd2 --no-create-home jabber
in postinst without any scaffolding SHOULD give you what you want. If it 
doesn't, it's a bug in adduser which I would ask you to report.


If you apply this for trixie, you might need a versioned dependency on 
adduser >= 3.145 or test with bookworm's adduser as well (it might be 
non-silent on the console but should yield the same results).


Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421