Bug#1064991: nvidia-open-gpu-kernel-modules: CVE-2024-0074, CVE-2024-0075, CVE-2024-0078

[Andreas Beckmann]

Followup-For: Bug #1064991
Control: severity -1 important

migration is currently blocked by the t64 migration

Andreas

Bug#1069538: zeroc-ice: FTBFS on armel: appears to be out-of-memory condition

[Chris Knadle]

tags 1069538 + moreinfo

thanks

Bug#1042614: upstream patch available

[Matthias Klose]

Control: tags -1 + patch

patch at
https://launchpadlibrarian.net/725823106/libsass-python_0.22.0-1build1_0.22.0-1ubuntu1.diff.gz

Bug#1069738: python-bumps: please package v0.9.2 and remove the python3-six dependency

[Stuart Prescott]

Hi Alexandre

The only user of bumps in Debian is sasview and their releases tend to 
be coordinated. I tend to avoid upgrading them in Debian independently 
of each other.


However SasView 6 is still some way off and will be even further off in 
Debian due to its dependency on pyside6 (which is a beast that is 
half-packaged and ftbfs still)


I'll look at whether old-sasview and new-bumps will be happy with each 
other. Most of the 0.9.x releases of bumps are compatibility patches for 
numpy/scipy/matplotlib that we're already carrying as patches in the 
Debian package anyway.


thanks for your contribution to removing six!
Stuart



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1069745: magics-python: wrong arch: any packaging builds potentially uninstallable packages

[Steve Langasek]

Package: magics-python
Version: 2:1.5.8-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi Alastair,

Working to resolve per-arch uninstallability of python3-magics++ in Ubuntu
for the upcoming release, I found significant issues in the packaging that
should be resolved.

 - The package build-depends on libeccodes-dev, but does not use it
 - It depends on libmagplus3v5, but nothing ensures that this package is
   only built for architectures on which libmagplus3v5 is available (both
   libmagplus3v5 and libeccodes have *similar* portability issues, but not
   identical; in Ubuntu we're now in the situation that we have architectures
   where libeccodes-dev is available but libmagplus is not)
 - It doesn't actually *use* libmagplus3v5, so this dependency is wrong;
   what it does use is libMagPlus.so, from libmagics++-dev, which is resolved
   via python3-ecmwflibs
 - But the package is missing an actual dependency on python3-ecmwflibs, so
   installing python3-magics++ by itself results in a python module that
   fails to import
 - But also, this package is a pure-python module containing no
   architecture-dependent code, so it should be Architecture: all anyway
   instead of Architecture: any (which also makes the per-arch
   installability issues go away)
 - And because it's architecture-independent it should build-depend on
   python3 - not python3-dev, which is for binary modules.

Please find attached a patch addressing these issues, which has been
uploaded to Ubuntu.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru magics-python-1.5.8/debian/control magics-python-1.5.8/debian/control
--- magics-python-1.5.8/debian/control  2022-04-17 00:12:44.0 -0700
+++ magics-python-1.5.8/debian/control  2024-04-23 17:10:54.0 -0700
@@ -4,8 +4,7 @@
 Maintainer: Alastair McKinstry 
 Build-Depends: debhelper-compat (= 13), 
   dh-sequence-python3,
-  libeccodes-dev,
-  python3-dev, 
+  python3, 
   python3-setuptools,
   python3-pytest-runner
 Standards-Version: 4.6.0
@@ -14,8 +13,8 @@
 Vcs-Git: https://salsa.debian.org:/science-team/magics-python.git -b 
debian/latest
 
 Package: python3-magics++
-Architecture: any
-Depends:  libmagplus3v5 , ${misc:Depends}, 
+Architecture: all
+Depends: python3-ecmwflibs, ${misc:Depends}, 
  ${python3:Depends}, 
  python3-simplejson, 
  python3-jinja2

Bug#1069744: btrfs-progs: btrfs dev usa as non-root is wrong in every way and should just give an error

[Russell Coker]

Package: btrfs-progs
Version: 6.6.3-1.1+b2
Severity: normal
Tags: upstream

Below is an example of comparing btrfs dev usa as root and non-root.  When
run as non-root it is wrong in every way, there is not a single correct
value.  I've done this on my laptop (single device) and on a server with 3
devices and the results were similarly wrong.

Instead of providing information that is wrong and misleading it should
just give an error and say that it needs root permissions.

# btrfs dev usa /
/dev/mapper/root, ID: 1
   Device size:   476.37GiB
   Device slack:1.50KiB
   Data,single:   170.01GiB
   Metadata,DUP:6.00GiB
   System,DUP: 64.00MiB
   Unallocated:   300.29GiB

$ btrfs dev usa /
WARNING: cannot read detailed chunk info, per-device usage will not be shown, 
run as root
/dev/mapper/root, ID: 1
   Device size:   952.73MiB
   Device slack:   16.00EiB
   Unallocated:   476.37GiB

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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: unable to detect

Versions of packages btrfs-progs depends on:
ii  libblkid12.40-6
ii  libc62.37-18
ii  libcom-err2  1.47.0-2.4
ii  libext2fs2t641.47.0-2.4
ii  liblzo2-22.10-2+b1
ii  libreiserfscore0t64  1:3.6.27-7.1+b2
ii  libudev1 255.4-1+b1
ii  libuuid1 2.40-6
ii  libzstd1 1.5.5+dfsg2-2
ii  zlib1g   1:1.3.dfsg-3.1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
pn  duperemove  

-- debconf-show failed

Bug#1065268: phpseclib 1.0.19-3+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065268 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: phpseclib
Version: 1.0.19-3+deb11u2

Explanation: force system dependency loading; guard isPrime() and randomPrime() 
for BigInteger [CVE-2024-27354]; limit OID length in ASN1 [CVE-2024-27355]; fix 
BigInteger getLength()

Bug#1065266: php-phpseclib 2.0.30-2+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065266 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-phpseclib
Version: 2.0.30-2+deb11u2

Explanation: force system dependency loading; guard isPrime() and randomPrime() 
for BigInteger [CVE-2024-27354]; limit OID length in ASN1 [CVE-2024-27355]; fix 
BigInteger getLength()

Bug#1065079: php-doctrine-annotations 1.11.2-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065079 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-doctrine-annotations
Version: 1.11.2-1+deb11u1

Explanation: force system dependency loading

Bug#1065077: php-zend-code 4.0.0-2+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065077 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-zend-code
Version: 4.0.0-2+deb11u1

Explanation: force system dependency loading

Bug#1065076: php-proxy-manager 2.11.1+1.0.3-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065076 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-proxy-manager
Version: 2.11.1+1.0.3-1+deb11u1

Explanation: force system dependency loading

Bug#1069743: keepassxc does not support hardware keys, need to use keepassxc-full

[Michael Musenbrock]

Package: keepassxc
Version: 2.7.7+dfsg.1-2
Severity: important

Hi,
first of all thank you very much for packaging keepassxc for Debian!

I am aware of the split of keepassxc and keepassxc-full and the idea is great, 
to have a real network-less password manager.

But since the upgrade to version 2.7.7+dfsg.1-2 I am not able to use my keepass 
database, as it is secured with a hardware key (YubiKey).
It seems since the split, keepassxc does not detect those either, which makes 
it impossible to open the database.

If this is intentional, please close the issue, but it would still be 
beneficial to have the isolated keepass working with a hardware key.

Everything works fine with keepass-full.

Thanks in advance,
br m


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

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

Versions of packages keepassxc depends on:
ii  libargon2-1   0~20190702+dfsg-4+b1
ii  libbotan-2-19 2.19.4+dfsg-1
ii  libc6 2.37-18
ii  libgcc-s1 14-20240330-1
ii  libminizip1t641:1.3.dfsg-3.1
ii  libqrencode4  4.1.1-1+b2
ii  libqt5concurrent5t64  5.15.10+dfsg-7.2+b1
ii  libqt5core5t645.15.10+dfsg-7.2+b1
ii  libqt5dbus5t645.15.10+dfsg-7.2+b1
ii  libqt5gui5t64 5.15.10+dfsg-7.2+b1
ii  libqt5network5t64 5.15.10+dfsg-7.2+b1
ii  libqt5svg55.15.10-2+b2
ii  libqt5widgets5t64 5.15.10+dfsg-7.2+b1
ii  libqt5x11extras5  5.15.10-2+b2
ii  libreadline8t64   8.2-4
ii  libstdc++614-20240330-1
ii  libx11-6  2:1.8.7-1
ii  libxtst6  2:1.2.3-1.1
ii  libzxcvbn02.5+dfsg-2
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1

keepassxc suggests no packages.

-- no debconf information

Bug#1069740: kitty: incorrectly acts like mouse button is pressed

[Russell Coker]

Package: kitty
Version: 0.33.1-1
Severity: normal

I routinely run kitty with between 4 and 16 terminals in one kitty window.
When moving the mouse across the screen it's a common occurance (multiple
times per hour) for one terminal to act like the mouse button is pressed
and try to make it a swipe to select operation.

This happens on my laptop running Unstable and my workstation running
Bookworm.

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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: unable to detect

Versions of packages kitty depends on:
ii  kitty-shell-integration  0.33.1-1
ii  kitty-terminfo   0.33.1-1
ii  libc62.37-18
ii  libdbus-1-3  1.14.10-4+b1
ii  libharfbuzz0b8.3.0-2+b1
ii  liblcms2-2   2.14-2+b1
ii  libpng16-16t64   1.6.43-5
ii  libpython3.11t64 3.11.9-1
ii  libssl3t64   3.2.1-3
ii  libwayland-client0   1.22.0-2.1+b1
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcursor1  1:1.2.1-1
ii  libxkbcommon-x11-0   1.6.0-1
ii  libxkbcommon01.6.0-1
ii  libxxhash0   0.8.2-2+b1
ii  python3  3.11.8-1
ii  python3.11   3.11.9-1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages kitty recommends:
pn  kitty-doc   
ii  libcanberra0t64 [libcanberra0]  0.30-12.2+b2

Versions of packages kitty suggests:
ii  imagemagick  8:6.9.12.98+dfsg1-5.2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5.2

-- debconf-show failed

Bug#1065075: symfony 4.4.19+dfsg-2+deb11u5 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065075 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: symfony
Version: 4.4.19+dfsg-2+deb11u5

Explanation: force system dependency loading; DateTypTest: ensure submitted 
year is accepted choice

Bug#1069739: plasma-nm: loses connection when NetworkManager.service is restarted

[Russell Coker]

Package: plasma-nm
Version: 4:5.27.10-1+b1
Severity: normal

When I run "systemctl restart NetworkManager.service" or an equivalent
operation is performed as part of a system upgrade the plasma-nm connection
to the NetworkManager daemon is lost.  Currently it seems that the only way
to reestablish the connection is to logout and login again or to run
"systemctl --user restart plasma-plasmashell.service", but restarting the
plasmashell doesn't seem to put it in a state where it can operate, I tell
it to connect to a widi network and then it immediately says "disconnected".
But it does at least show the current connection status correctly after the
restart of the plasmashell.

The plasma-nm should be able to detect that NetworkManager restarted and
talk to the new daemon without problems.

When the plasmashell is restarted the plasma-nm should be able to work with
full functionality including connecting to wifi networks. 

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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: unable to detect

Versions of packages plasma-nm depends on:
ii  kio 5.107.0-1+b2
ii  libc6   2.37-18
ii  libglib2.0-0t64 2.78.4-6
ii  libkf5completion5   5.107.0-1+b2
ii  libkf5configcore5   5.107.0-1+b2
ii  libkf5configwidgets55.107.0-2+b2
ii  libkf5coreaddons5   5.107.0-1+b2
ii  libkf5dbusaddons5   5.107.0-1+b2
ii  libkf5i18n5 5.107.0-1+b2
ii  libkf5kiogui5   5.107.0-1+b2
ii  libkf5kiowidgets5   5.107.0-1+b2
ii  libkf5modemmanagerqt6   5.107.0-1+b2
ii  libkf5networkmanagerqt6 5.107.0-1+b1
ii  libkf5notifications55.107.0-1+b2
ii  libkf5solid55.107.0-1+b2
ii  libkf5wallet-bin5.107.0-1+b2
ii  libkf5wallet5   5.107.0-1+b2
ii  libkf5widgetsaddons55.107.0-1+b2
ii  libkf5windowsystem5 5.107.0-1+b2
ii  libnm0  1.46.0-1+b2
ii  libopenconnect5 9.12-1+b2
ii  libqca-qt5-22.3.8-1+b1
ii  libqt5core5t64  5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64   5.15.10+dfsg-7.2+b1
ii  libqt5network5t64   5.15.10+dfsg-7.2+b1
ii  libqt5qml5  5.15.10+dfsg-2+b2
ii  libqt5quickwidgets5 5.15.10+dfsg-2+b2
ii  libqt5widgets5t64   5.15.10+dfsg-7.2+b1
ii  libqt5xml5t64   5.15.10+dfsg-7.2+b1
ii  libstdc++6  14-20240330-1
ii  mobile-broadband-provider-info  20230416-1
ii  network-manager 1.46.0-1+b2
ii  plasma-framework5.107.0-1+b2
ii  qml-module-org-kde-kcoreaddons  5.107.0-1+b2
ii  qml-module-org-kde-kirigami25.107.0-1+b2
ii  qml-module-org-kde-prison   5.107.0-2+b2

Versions of packages plasma-nm recommends:
ii  systemsettings  4:5.27.10-1+b1

Versions of packages plasma-nm suggests:
pn  network-manager-fortisslvpn  
pn  network-manager-iodine   
pn  network-manager-l2tp 
pn  network-manager-openconnect  
pn  network-manager-openvpn  
pn  network-manager-pptp 
pn  network-manager-ssh  
pn  network-manager-strongswan   
pn  network-manager-vpnc 

-- debconf-show failed

Bug#1065070: php-composer-xdebug-handler 1.4.5-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065070 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: php-composer-xdebug-handler
Version: 1.4.5-1+deb11u1

Explanation: force system dependency loading

Bug#264500: fmtools: fmscan patch to allow choice of threshold signal strength (attached)

[Ben Pfaff]

I incorporated this patch into fmtools 1.0 back in 2004. It is in the current
Debian release (version 2.0.8). The bug can be closed.

On Mon, Apr 22, 2024 at 4:53 PM Petter Reinholdtsen  wrote:
>
> Control: tags -1 + patch
>
> [Gregory P. Smith] 2004-08-08]
> > The fmscan utility is not nearly as useful as it could be without
> > this patch.  this adds the -t command line option to allow control of
> > the threshold signal strength that fmscan uses to decide if a station
> > can be received.  please apply to future debian packages of this tool
> > and submit to the upstream maintainer.
>
> Thank you for the patch.  I am sad to see it has lingered here for so
> long.  CC to the upstream email address, in the hope that upstream can
> have a look at the patch in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264500 >.  Not
> convinced that the old email address still work, but it is worth a try.
> :)
> --
> Happy hacking
> Petter Reinholdtsen

Bug#1069738: python-bumps: please package v0.9.2 and remove the python3-six dependency

[Alexandre Detiste]

Source: python-bumps
Version: 0.9.1-2
Severity: normal

My previous PR is part of this release:

https://github.com/bumps/bumps/pull/136

Greetings

Bug#1069737: bioxtasraw: please drop dependency on obsolete python3-mock

[Alexandre Detiste]

Source: bioxtasraw
Version: 2.2.1-2
Severity: normal

It's not even used at all.

Greetings

tchet@brix /tmp/bioxtasraw $ grep mock -r
debian/control: python3-mock ,
tchet@brix /tmp/bioxtasraw $ 

Bug#1069735: general: atlantic driver doesn't work on thinkpad

[Benjamin Gounine]

Package: general
Severity: important

Dear Maintainer,

I have a problem with atlantic driver on debian testing kernel 6.6.15.
When I plug my device (Sonnet tech 10G adapter thunderbolt 3), the
device will not appear in lspci but it detect from dmesg command.

On an ubuntu, the device works.

This is traces :

```
root@Elliot:~# lspci -tv
-[:00]-+-00.0  Intel Corporation Coffee Lake HOST and DRAM Controller
   +-02.0  Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620]
   +-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Thermal Subsystem
   +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 
6th/7th/8th Gen Core Processor Gaussian Mixture Model
   +-12.0  Intel Corporation Cannon Point-LP Thermal Controller
   +-14.0  Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller
   +-14.2  Intel Corporation Cannon Point-LP Shared SRAM
   +-14.3  Intel Corporation Cannon Point-LP CNVi [Wireless-AC]
   +-15.0  Intel Corporation Cannon Point-LP Serial IO I2C Controller #0
   +-16.0  Intel Corporation Cannon Point-LP MEI Controller #1
   +-1c.0-[01]00.0  Genesys Logic, Inc GL9750 SD Host Controller
   +-1c.4-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0  Intel 
Corporation JHL6240 Thunderbolt 3 NHI (Low Power) [Alpine Ridge LP 2016]
   |   +-01.0-[05-39]--
   |   \-02.0-[3a]00.0  Intel 
Corporation JHL6240 Thunderbolt 3 USB 3.1 Controller (Low Power) [Alpine Ridge 
LP 2016]
   +-1d.0-[3c]--
   +-1d.4-[3d]00.0  Micron/Crucial Technology P2 [Nick P2] / P3 / 
P3 Plus NVMe PCIe SSD (DRAM-less)
   +-1f.0  Intel Corporation Cannon Point-LP LPC Controller
   +-1f.3  Intel Corporation Cannon Point-LP High Definition Audio 
Controller
   +-1f.4  Intel Corporation Cannon Point-LP SMBus Controller
   +-1f.5  Intel Corporation Cannon Point-LP SPI Controller
   \-1f.6  Intel Corporation Ethernet Connection (6) I219-V


root@Elliot:~# modinfo atlantic
filename:   
/lib/modules/6.6.15-amd64/kernel/drivers/net/ethernet/aquantia/atlantic/atlantic.ko.xz
description:Marvell (Aquantia) Corporation(R) Network Driver
author: Marvell
license:GPL v2
alias:  pci:v1D6Ad11C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad34C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad12C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad14C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad04C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad93C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad94C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad00C0sv*sd*bc*sc*i*
alias:  pci:v1D6Ad92B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad91B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad89B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad88B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad87B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad80B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad12B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad11B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad09B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad08B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad07B1sv*sd*bc*sc*i*
alias:  pci:v1D6Ad00B1sv*sd*bc*sc*i*
alias:  pci:v1D6AdD109sv*sd*bc*sc*i*
alias:  pci:v1D6AdD108sv*sd*bc*sc*i*
alias:  pci:v1D6AdD107sv*sd*bc*sc*i*
alias:  pci:v1D6AdD100sv*sd*bc*sc*i*
alias:  pci:v1D6Ad0001sv*sd*bc*sc*i*
depends:macsec
retpoline:  Y
intree: Y
name:   atlantic
vermagic:   6.6.15-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:21:EC:AB:7F:99:B0:2B:29:F0:14:9D:30:26:B6:2F:1B:F0:91:ED:13
sig_hashalgo:   sha256
signature:  30:65:02:31:00:C5:7E:D8:EA:3A:0A:D9:65:E4:44:64:B7:AD:C6:58:
83:27:E6:87:BE:DB:4C:F8:17:68:D1:CE:CA:49:45:27:17:20:9A:67:
3B:0C:FC:77:A6:D1:DB:B8:C1:A0:1E:4D:CA:02:30:1A:43:B0:9C:14:
10:A3:A9:B7:A4:11:E6:69:4F:43:46:55:08:AF:9B:11:08:25:78:58:
68:E0:A4:32:CB:53:4E:7D:34:BF:7B:11:C8:E2:AA:46:C7:4F:96:CF:
55:94:73
parm:   aq_itr:Interrupt throttling mode (uint)
parm:   aq_itr_tx:TX interrupt throttle rate (uint)
parm:   aq_itr_rx:RX interrupt throttle rate (uint)


root@Elliot:~# lsmod
Module  Size  Used by
vmnet  77824  13
vmw_vsock_vmci_transport45056  0
vsock  61440  1 vmw_vsock_vmci_transport
vmw_vmci  110592  1 vmw_vsock_vmci_transport
vmmon 163840  0
ccm20480  6
rfcomm102400  16
snd_seq_dummy  12288  0
snd_hrtimer12288  1
snd_seq

Bug#1069736: liac-arff: please drop extraneous python3-mock build-dependency

[Alexandre Detiste]

Source: liac-arff
Version: 2.5.0-5
Severity: normal


Dear Maintainer,

Can you please remove python3-mock from d/control.

It is an obsolete library that is slowly being removed from Debian.

The code was integrated a long time ago in the standard library
as unittest.mock.

Greetings


tchet@brix /tmp/liac-arff $ grep mock -r -C 2
debian/control:   python3-mock ,
--
debian/tests/control:Depends: python3-liac-arff, python3-mock
--
tests/test_data.py-if arff.PY2:
tests/test_data.py:import mock
tests/test_data.py-else:
tests/test_data.py:import unittest.mock as mock

Bug#1069734: pytango: please drop extraneous dependency on python3-mock

[Alexandre Detiste]

Source: pytango
Version: 9.5.0-2
Severity: normal

Dear Maintainer,

Can you please remove python3-mock from d/control.

It is an obsolete library that is slowly being removed from Debian.

The code was integrated a long time ago in the standard library
as unittest.mock.

Greetings


tchet@brix /tmp/pytango $ grep mock -r | grep -e import -e debian
grep: .git/index : fichiers binaires correspondent
debian/changelog:  * Depend on python-mock for generating the docs
debian/control: python3-mock ,
doc/conf.py:from mock_tango_extension import tango
doc/mock_tango_extension.py:from unittest.mock import MagicMock

Bug#1069733: python-procrunner: please drop dependency on python3-mock

[Alexandre Detiste]

Source: python-procrunner
Version: 2.3.3-1
Severity: normal

Dear Maintainer,

Can you please remove python3-mock from d/control.

It is an obsolete library that is slowly being removed from Debian.

The code was integrated a long time ago in the standard library
as unittest.mock.

Greetings


tchet@brix /tmp/python-procrunner $ grep mock -r | grep -e import -e debian
debian/control:Build-Depends: , python3-mock
tests/test_procrunner.py:from unittest import mock
tchet@brix /tmp/python-procrunner $ 

Bug#1069732: ros-rospkg: please drop extraneous dependency on python3-mock

[Alexandre Detiste]

Source: ros-rospkg
Version: 1.5.0-1
Severity: normal


Dear Maintainer,

Can you please remove python3-mock from d/control.

It is an obsolete library that is slowly being removed from Debian.

The code was integrated a long time ago in the standard library
as unittest.mock.

Greetings




tchet@brix /tmp/ros-rospkg $ grep mock -r -C 2
CHANGELOG.rst:- Use unittest.mock where possible.
debian/control:Build-Depends: ... python3-mock ...
--
setup.py-'extras_require': {
setup.py-'test': [
setup.py:"mock; python_version < '3.3'",
setup.py-'pytest',
setup.py-]},
--
test/test_rospkg_os_detect.py-try:
test/test_rospkg_os_detect.py:from unittest.mock import Mock, patch
test/test_rospkg_os_detect.py-except ImportError:
test/test_rospkg_os_detect.py:from mock import Mock, patch

Bug#1064347: openssh-server: sshd crashes under heavy traffic

[Bernhard Übelacker]

Hello,
I am no maintainer, just tried to reproduce this issue which I could
inside a minimal Bullseye amd64 qemu VM with the instructions
from the linked Ubuntu bug.

I could not reproduce it within Bookworm or Trixie/testing.

Without "LogLevel DEBUG" it was also not observable.

Unfortunately did also not happen with a ssh package built with asan enabled.

And I upgraded step by step via snapshot.d.o, around 2021-11-15 it
stopped to be an issue. This step brought openssh 8.7p1-1.
Downgrading just openssh 8.4p1-6 in this exact VM showed it again.

Therefore I assume this issue got fixed between openssh 8.4p1-6 and 8.7p1-1.

Kind regards,
Bernhard


#13 
#14 malloc_consolidate (av=av@entry=0x7faa3b64cb80 ) at 
malloc.c:4518
#15 0x7faa3b5023d5 in _int_malloc (av=av@entry=0x7faa3b64cb80 , 
bytes=bytes@entry=8193) at malloc.c:3699
#16 0x7faa3b503063 in malloc_check (sz=8192, caller=) at 
hooks.c:239
#17 0x7faa3b504cea in __libc_calloc (n=n@entry=1, 
elem_size=elem_size@entry=8192) at malloc.c:3387
#18 0x7faa3b4f6ef4 in __GI___open_memstream 
(bufloc=bufloc@entry=0x7ffe636eb6e0, sizeloc=sizeloc@entry=0x7ffe636eb6e8) at 
memstream.c:83
#19 0x7faa3b5726e1 in __vsyslog_internal (pri=39, fmt=0x55b451dcb150 
"%.500s", ap=0x7ffe636eb7d0, mode_flags=2) at ../misc/syslog.c:181
#20 0x7faa3b572d5f in __syslog_chk (pri=pri@entry=7, flag=flag@entry=1, 
fmt=fmt@entry=0x55b451dcb150 "%.500s") at ../misc/syslog.c:136
#21 0x55b451d87e16 in syslog (__fmt=0x55b451dcb150 "%.500s", __pri=7) at 
/usr/include/x86_64-linux-gnu/bits/syslog.h:31
#22 do_log (level=level@entry=SYSLOG_LEVEL_DEBUG1, fmt=fmt@entry=0x55b451dba421 
"Forked child %ld.", args=args@entry=0x7ffe636ec110) at ../../log.c:484
#23 0x55b451d88254 in debug (fmt=fmt@entry=0x55b451dba421 "Forked child 
%ld.") at ../../log.c:229
#24 0x55b451d3c86e in server_accept_loop (config_s=0x7ffe636ec270, newsock=, sock_out=, sock_in=) at 
../../sshd.c:1377
#25 main (ac=, av=) at ../../sshd.c:2089
# 2024-04-23 Bullseye/stable amd64 qemu VM


apt update
apt dist-upgrade
apt install systemd-coredump moreutils parallel htop fakeroot mc ccache gdb 
openssh-server-dbgsym
apt build-dep glibc
apt build-dep openssh-server


mkdir /home/benutzer/source/glibc/orig -p
cd/home/benutzer/source/glibc/orig
apt source glibc

mkdir /home/benutzer/source/openssh-server/orig -p
cd/home/benutzer/source/openssh-server/orig
apt source openssh-server



sed -i.bak 's/#LogLevel INFO/LogLevel DEBUG/g' /etc/ssh/sshd_config
systemctl restart sshd



ssh-keygen -b 4096
ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
parallel -j 32 -N0 "ssh benutzer@localhost 'true'" ::: {1..2}







benutzer@debian:~/.ssh$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/benutzer/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/benutzer/.ssh/id_rsa
Your public key has been saved in /home/benutzer/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Hgx6dUtFBhKiI0wBYKtXMkwZeRcP/eEZCUsU69bbO+o benutzer@debian
The key's randomart image is:
+---[RSA 4096]+
|+o==  ++B+.++|
|.=+ ...=.++o |
| .*.+.. =oo+ |
|.  = o = ++. |
|. . . . S o  |
| .   . o . o |
|. . .|
|..   |
| .E...   |
+[SHA256]-+


benutzer@debian:~$ ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter 
out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are 
prompted now it is to install the new keys
benutzer@localhost's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'benutzer@localhost'"
and check to make sure that only the key(s) you wanted were added.





parallel -j 800 -N0 "ssh benutzer@localhost 'mount; sleep 1; cat /proc/cpuinfo; 
free -h; dd if=/dev/zero of=/dev/null bs=1 count=8192; mount -av; sleep 
$(($RANDOM % 5)); lscpu'" ::: {1..1}
# AMD Ryzen 1700, VM, 16 threads















root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2024-04-23 00:20:53 CEST 124297 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:02 CEST 159284 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:47 CEST 229261 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:32 CEST 277265 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:54 CEST 301567 0 0   6 present   /usr/sbin/sshd





root@debian:~# coredumpctl gdb 301567
   PID: 301567 (sshd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Tue 2024-04-23 00:24:53 CEST (47s ago)
  Command Line: sshd: /usr/sbin/sshd -D [listener] 4 of 10-100 startups
Executable: /usr/sbin/sshd
 

Bug#1069731: pyct: please drop extraneous dependency on python3-mock

[Alexandre Detiste]

Source: pyct
Version: 0.5.0-1
Severity: normal

Dear Maintainer,

Can you please remove python3-mock from d/control.

It is an obsolete library that is slowly being removed from Debian.

The code was integrated a long time ago in the standard library
as unittest.mock.

Greetings



tchet@brix /tmp/pyct $ grep mock -r
debian/control: python3-mock,
pyct/tests/test_report.py:from unittest.mock import patch
tchet@brix /tmp/pyct $ grep mock -r

Bug#1068314: python-inflate64_1.0.0+ds-1_amd64.changes REJECTED

[Andreas Tille]

Hi Hiroshi,

Am Wed, Apr 24, 2024 at 01:14:27AM +0900 schrieb yokota:
> > please also mention Ma Lin in your debian/copyright.

Thanks for fixing this issue.  I've uploaded to new again.
 
> I was updated Debian salsa repository to fix the issue.
> https://salsa.debian.org/python-team/packages/python-inflate64

Remarks to your changes:  As long as the package is not in unstable
please stick to Debian revision "-1".  Thus I cleaned up the changelog.

Some words about tagging:  I removed all debian/* tags in Git - please
make sure you delete them in your clone as well.  Please do not tag
the state you push to Salsa.  Tagging is something that should happen
for the state which will be really uploaded to Debian.  If the package
is in new we can't be sure it will move to unstable.  I'd do this
only *after* the package is accepted.

Also if you need a sponsor for your packages the tagging should be
done by the sponsor.  The rationale is that the sponsor might see
some need for further changes which need to be incorporated into the
tag.

At least this is what I know from all teams I'm working in.

> Please upload it as Debian package by Debian Python Team because I
> don't have upload rights.

Done.

Thanks again for all your work
   Andreas. 

-- 
https://fam-tille.de

Bug#1069730: unblock: glibc/2.37-18

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: security
X-Debbugs-Cc: gl...@packages.debian.org
Control: affects -1 + src:glibc
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

glibc 2.37-18 fixes an import security issue (CVE-2024-2961), and it
would be nice to have it in testing asap. It is currently blocked by the
proftpd-dfsg autopkgtest, which fails due to the lack of libnsl-dev in
the chroot, as this dependency got removed in glibc version 2.37-15.1 as
part of the time_t transition.

proftpd-dfsg has already been fixed by making it an explicity
build-dependency, however this fixed version can't enter testing as it
is entangled in the time_t transition. The glibc doesn't break
proftpd-dfsg in testing, but basically breaks its buildability and thus
its autopkgtest.

Do you think it would be possible to allow this glibc version to enter
testing by ignoring the result of the proftpd-dfsg autopkgtest?

Regards
Aurelien

Bug#1069729: bsdgames: Please keep quiz

[Kacper Gutowski]

Package: bsdgames
Version: 2.17-33
Severity: wishlist

Dear Maintainer,

Recently quiz(6) was removed from the package.
I understand that the plan is to switch to a different fork linked in
changelog whose developers consider quiz(6) to be "just plain junk."
I can't say I understand that rationale, or why does it apply to quiz(6)
but not to arithmetic(6), for example. But seeing that pom(6) was
retained despite that fork disliking it, I would like to request
that quiz(6) is kept packaged as well. I find it useful.

-k

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

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

Versions of packages bsdgames depends on:
ii  libc6  2.37-15
ii  libfl2 2.6.4-8.2+b2
ii  libgcc-s1  14-20240201-3
ii  libncurses66.4+20240414-1
ii  libstdc++6 14-20240201-3
ii  libtinfo6  6.4+20240414-1
ii  miscfiles [wordlist]   1.5+dfsg-5
ii  wamerican [wordlist]   2020.12.07-2
ii  wamerican-huge [wordlist]  2020.12.07-2
ii  wbritish [wordlist]2020.12.07-2
ii  wbritish-huge [wordlist]   2020.12.07-2
ii  wesperanto [wordlist]  3.7-2
ii  wfrench [wordlist] 1.2.7-2
ii  wpolish [wordlist] 20240101-1
ii  wspanish [wordlist]1.0.30
ii  wukrainian [wordlist]  1.8.0+dfsg-1

bsdgames recommends no packages.

Versions of packages bsdgames suggests:
pn  mailutils  

-- no debconf information

Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected

[Daniel Kahn Gillmor]

On Mon 2024-04-22 20:17:54 +, Holger Levsen wrote:
> fixed in git.

thanks!  I've just uninstalled the octopus, but i'll consider
reinstalling it later if this and some of the performance issues can be
ironed out (or maybe to help iron out the performance issues, visible
upstream at
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/issues/102)

> the change seems innocent enough... (I just wasnt expected the different
> formatting styles...)

i hear you, and i've made this exact mistake myself more times than i
can count :P

> the irony is: the autopkg tests for the package had failed which I blamed
> on unstables unstableness these days, so I reviewed the diff once more,
> (again) didnt notice the introduced bug and did a source only upload,
> because the change were tiny... :/

urgh, yeah, unstable breakage makes everything harder.

I'm still thinking about what kinds of autopkgtests might be useful in
terms of ensuring that thunderbird actually works with librnp, though.
that's different from the autopkgtests generated by debcargo.

I'll report that in a different bug report, though, maybe we can
brainstorm there.

   --dkg


signature.asc
Description: PGP signature

Bug#1069728: freerdp2: CVE-2024-32039 CVE-2024-32040 CVE-2024-32041 CVE-2024-32458 CVE-2024-32459 CVE-2024-32460

[Salvatore Bonaccorso]

Source: freerdp2
Version: 2.11.5+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freerdp2.

CVE-2024-32039[0]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients using a version of FreeRDP prior to 3.5.0 or
| 2.11.6 are vulnerable to integer overflow and out-of-bounds write.
| Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, do not
| use `/gfx` options (e.g. deactivate with `/bpp:32` or `/rfx` as it
| is on by default).


CVE-2024-32040[1]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 and have connections to servers using the `NSC` codec are
| vulnerable to integer underflow. Versions 3.5.0 and 2.11.6 patch the
| issue. As a workaround, do not use the NSC codec (e.g. use `-nsc`).


CVE-2024-32041[2]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and
| 2.11.6 patch the issue. As a workaround, deactivate `/gfx` (on by
| default, set `/bpp` or `/rfx` options instead.


CVE-2024-32458[3]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and
| 2.11.6 patch the issue. As a workaround, use `/gfx` or `/rfx` modes
| (on by default, require server side support).


CVE-2024-32459[4]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients and servers that use a version of FreeRDP
| prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read.
| Versions 3.5.0 and 2.11.6 patch the issue. No known workarounds are
| available.


CVE-2024-32460[5]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based based clients using `/bpp:32` legacy `GDI` drawing
| path with a version of FreeRDP prior to 3.5.0 or 2.11.6 are
| vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch
| the issue. As a workaround, use modern drawing paths (e.g. `/rfx` or
| `/gfx` options). The workaround requires server side support.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-32039
https://www.cve.org/CVERecord?id=CVE-2024-32039
[1] https://security-tracker.debian.org/tracker/CVE-2024-32040
https://www.cve.org/CVERecord?id=CVE-2024-32040
[2] https://security-tracker.debian.org/tracker/CVE-2024-32041
https://www.cve.org/CVERecord?id=CVE-2024-32041
[3] https://security-tracker.debian.org/tracker/CVE-2024-32458
https://www.cve.org/CVERecord?id=CVE-2024-32458
[4] https://security-tracker.debian.org/tracker/CVE-2024-32459
https://www.cve.org/CVERecord?id=CVE-2024-32459
[5] https://security-tracker.debian.org/tracker/CVE-2024-32460
https://www.cve.org/CVERecord?id=CVE-2024-32460
[6] https://www.freerdp.com/2024/04/17/2_11_6-release

Regards,
Salvatore

Bug#1067699: libllvm18:i386 contains files, also in libllvm18:amd64

[Sylvestre Ledru]

Le 23/04/2024 à 21:21, Witold Baryluk a écrit :

Package: libllvm18
Version: 1:18.1.4-1
Followup-For: Bug #1067699
X-Debbugs-Cc: witold.bary...@gmail.com

It looks there is some problem:


sure but how is it different from the initial message?


S

Bug#1033028: fixed in pydata-sphinx-theme 0.15.2-1

[Andreas Tille]

Hi Gianfranco,

Am Tue, Apr 23, 2024 at 08:52:56PM +0200 schrieb Gianfranco Costamagna:
> control: notfixed -1 0.15.2-1
> control: reopen -1
> Hello Andreas, I tried to upload your package,

Not really "my" package - I used "QA upload".

> but I failed due to some nodejs failures.
> Looks like the new theme-switcher is running some npm install during build,
> failing due to network access...
> 
> Any idea?

Sorry, absolutely not.  I admit I do not really remember.  There must
have been some reason why I finally did not upload.  In addition to
having no good idea I also have no spare time any more now due to my new
task.

> In the meanwhile I reuploaded 0.7 version in sid.

Thanks a lot.  If I where you I would seek advise on DPT list.

Kind regards and thanks for keeping me informed
Andreas.

-- 
https://fam-tille.de

Bug#1069727: libsequoia-octopus-librnp: Thunderbird integration autopkgtests

[Daniel Kahn Gillmor]

Package: libsequoia-octopus-librnp
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 

the octopus has a simple, superficial autopkgtest, which just confirms
that the library has the expected symbols.

It would be great to have an autopkgtest that confirms that it actually
interoperates with Thunderbird as expected.

For example, such a test might:

- set up a bogus, local-only MTA

- configure two Thunderbird profiles with OpenPGP to talk to that MTA

- send an mail from profile A to profle B, including the OpenPGP cert
  for A
  
- read the mail on profile B, and reply with a signed-and-encrypted mail
  to A.

- read the cleartext message with profile A.

Perhaps upstream could help us assemble a comparable test that would run
reliably in ci.debian.org.

 --dkg
- 

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)


signature.asc
Description: PGP signature

Bug#1025912: rust-serde-yaml: please upgrade to v0.9

[Peter Green]

On 23/04/2024 15:52, Arnaud Ferraris wrote:

Hi,

On Thu, 27 Jul 2023 20:19:19 +0100 Peter Green  wrote:

> squeekboard - not investigated yet.

Tests fail after bumping dependency.

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


I've just uploaded the new version of squeekboard to experimental, built using 
serde-yaml 0.9.

IIUC that was the last blocker, so feel free to upload to unstable whenever you 
see fit.


It looks like at least one new rdep has popped up, and it's a binary crate, so 
it this is
done now it will entangle itself with the time_t transition.

Will take a closer look when the time_t transition is over.

Bug#1067699: libllvm18:i386 contains files, also in libllvm18:amd64

[Witold Baryluk]

Package: libllvm18
Version: 1:18.1.4-1
Followup-For: Bug #1067699
X-Debbugs-Cc: witold.bary...@gmail.com

It looks there is some problem:

Running sudo 
--preserve-env=DEBIAN_FRONTEND,APT_LISTCHANGES_FRONTEND,NEEDRESTART_MODE,NEEDRESTART_SUSPEND,DEBIAN_FRONT
 apt-get install --option APT::Get::HideAutoRemove=1 --option 
quiet::NoProgress=1 --no-install-recommends libllvm18 libllvm18:amd64 
llvm-18-dev libllvm18:i386
The following additional packages will be installed:
  libclang-cpp18 llvm-18 llvm-18-linker-tools llvm-18-runtime llvm-18-tools
Suggested packages:
  llvm-18-doc
The following NEW packages will be installed:
  libclang-cpp18 libllvm18 libllvm18:i386 llvm-18 llvm-18-dev 
llvm-18-linker-tools llvm-18-runtime llvm-18-tools
0 upgraded, 8 newly installed, 0 to remove and 4958 not upgraded.
Need to get 133 MB of archives.
After this operation, 796 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package libllvm18:amd64.
(Reading database ... 1385961 files and directories currently installed.)
Preparing to unpack .../0-libllvm18_1%3a18.1.4-1_amd64.deb ...
Unpacking libllvm18:amd64 (1:18.1.4-1) ...
Selecting previously unselected package libclang-cpp18.
Preparing to unpack .../1-libclang-cpp18_1%3a18.1.4-1_amd64.deb ...
Unpacking libclang-cpp18 (1:18.1.4-1) ...
Selecting previously unselected package libllvm18:i386.
Preparing to unpack .../2-libllvm18_1%3a18.1.4-1_i386.deb ...
Unpacking libllvm18:i386 (1:18.1.4-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-VuwoDu/2-libllvm18_1%3a18.1.4-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/lib/llvm-18/lib/libLLVM.so.1', which is 
different from other instances of package libllvm18:i386
Selecting previously unselected package llvm-18-runtime.
Preparing to unpack .../3-llvm-18-runtime_1%3a18.1.4-1_amd64.deb ...
Unpacking llvm-18-runtime (1:18.1.4-1) ...
Selecting previously unselected package llvm-18-linker-tools.
Preparing to unpack .../4-llvm-18-linker-tools_1%3a18.1.4-1_amd64.deb ...
Unpacking llvm-18-linker-tools (1:18.1.4-1) ...
Selecting previously unselected package llvm-18.
Preparing to unpack .../5-llvm-18_1%3a18.1.4-1_amd64.deb ...
Unpacking llvm-18 (1:18.1.4-1) ...
Selecting previously unselected package llvm-18-tools.
Preparing to unpack .../6-llvm-18-tools_1%3a18.1.4-1_amd64.deb ...
Unpacking llvm-18-tools (1:18.1.4-1) ...
Selecting previously unselected package llvm-18-dev.
Preparing to unpack .../7-llvm-18-dev_1%3a18.1.4-1_amd64.deb ...
Unpacking llvm-18-dev (1:18.1.4-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-VuwoDu/2-libllvm18_1%3a18.1.4-1_i386.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Command failed: sudo 
--preserve-env=DEBIAN_FRONTEND,APT_LISTCHANGES_FRONTEND,NEEDRESTART_MODE,NEEDRESTART_SUSPEND,DEBIAN_FRONT
 apt-get install --option APT::Get::HideAutoRemove=1 --option 
quiet::NoProgress=1 --no-install-recommends libllvm18 libllvm18:amd64 
llvm-18-dev libllvm18:i386
with exit code: 100


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

Kernel: Linux 6.6.15-amd64 (SMP w/32 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 libllvm18:i386 depends on:
ii  libc6   2.37-18
ii  libedit23.1-20230828-1
ii  libffi8 3.4.4-2
ii  libgcc-s1   14-20240201-3
ii  libstdc++6  14-20240201-3
ii  libtinfo6   6.4+20240113-1
ii  libxml2 2.9.14+dfsg-1.3+b2
ii  libz3-4 4.8.12-3.1+b2
ii  libzstd11.5.5+dfsg2-2
ii  zlib1g  1:1.3.dfsg-3.1

libllvm18:i386 recommends no packages.

libllvm18:i386 suggests no packages.

Bug#1069334: nautilus-wipe: diff for NMU version 0.4.alpha2-0.2

[Sebastian Ramacher]

Control: tags 1069334 + patch
Control: tags 1069334 + pending

Dear maintainer,

I've prepared an NMU for nautilus-wipe (versioned as 0.4.alpha2-0.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru nautilus-wipe-0.4.alpha2/debian/changelog nautilus-wipe-0.4.alpha2/debian/changelog
--- nautilus-wipe-0.4.alpha2/debian/changelog	2023-09-11 00:49:27.0 +0200
+++ nautilus-wipe-0.4.alpha2/debian/changelog	2024-04-23 21:19:59.0 +0200
@@ -1,3 +1,11 @@
+nautilus-wipe (0.4.alpha2-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Remove hard-coded dependency on libgtk-3-0 (Closes:
+#1069334)
+
+ -- Sebastian Ramacher   Tue, 23 Apr 2024 21:19:59 +0200
+
 nautilus-wipe (0.4.alpha2-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru nautilus-wipe-0.4.alpha2/debian/control nautilus-wipe-0.4.alpha2/debian/control
--- nautilus-wipe-0.4.alpha2/debian/control	2023-09-11 00:49:27.0 +0200
+++ nautilus-wipe-0.4.alpha2/debian/control	2024-04-23 19:44:27.0 +0200
@@ -23,7 +23,6 @@
 Multi-Arch: same
 Depends:
  libgsecuredelete0 (>= 0.3),
- libgtk-3-0,
  ${misc:Depends},
  ${shlibs:Depends},
 Description: Secure deletion extension for Nautilus

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Fabian Grünbichler]

On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote:
> Hello Go and Rust packagers,
> 
> On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote:
> 
> > With the increasing amount of programs in Debian that Build-Depend and
> > statically link with Golang and Rust libraries, it's important that
> > the Debian Policy clearly sets out the requirements for declaring
> > these statically-linked libraries.
> 
> I think Maytham is right that updating Policy for this is a priority.
> It has been bothering me that misunderstandings of Built-Using have been
> proliferating somewhat among newer contributors.  See also #999785.
> 
> Could you take a look at his proposed changes to Policy in #1069256,
> please, and confirm they successfully reconcile Debian Policy with your
> team policies?

Speaking for the Rust side - I'd say they match our expected usage of
the field. A slight rephrasing of "linked to libraries in other
packages" might match it even better, since in Rust's case, we are
usually talking about linking to libraries compiled from sources shipped
in other packages (librust-X-dev only contains the sources and possibly
helper scripts needed to build them, but not the compiled library).

But it also covers static linking of native libraries, so the current
phrasing matches that. Might be bikeshedding/nitpicky though ;)

> I think that we should also include an explanation of why we have chosen
> to do this using a new field in d/control like Static-Built-Using.
> Policy is meant to be a record of our lessons learned in building a
> distribution, and the lessons learned in trying to handle these new
> hyper-statically linked language ecosystems seem important.
> 
> My immediate question is why the Haskell and OCaml team's approaches,
> were not copied.  They seem to work well and don't require a new field.
> That seems worth writing down.

I am not sure about the details of their approach... are those available
somewhere?

> Thank you Maytham for your work so far.

Thanks to both of you! :)

Bug#1069704: bookworm-pu: package xscreensaver/6.06+dfsg1-3+deb12u1

[Jonathan Wiltshire]

On Tue, Apr 23, 2024 at 08:29:06PM +0200, Tormod Volden wrote:
> On Tue, Apr 23, 2024 at 7:05 PM Jonathan Wiltshire wrote:
> >
> > Thanks for the upload. Once built I intend to release it through the
> > stable-updates mechanism, but the announcement will carry your name. Any
> > comments on the following text?
> >
> > | The XScreenSaver package as released in Debian 12 includes an "out-of-date
> > | software warning", which is displayed prior to each unlock operation.
> > | This update disables such warnings.
> > |
> > | Users can rest assured that XScreenSaver remains supported by Debian
> > | for the lifetime of the stable distribution.
> >
> 
> Thanks a lot for processing this update. Your suggested text is very
> well formulated, I have nothing to add.

Amusingly it turns out our template example is the last xscreensaver
update, so I've just used that. It says the same things anyway.

Should be published tonight or tomorrow.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Fabian Grünbichler]

On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote:
> Hi Matthias,
> 
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > This is the same situation as in #1040477. This is an issue wrt how we
> > generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> > problem. Quoting you from 1040477:
> 
> Right!
> 
> > Is the only workaround dropping Ma:same here ?
> 
> I see very little alternatives. We must choose:
> 
>  * Do not combine M-A:same + Provides: foo + Breaks: foo.
>  * Fix dose/apt/dpkg to agree on what this means.
> 
> If we were to adapt dose and apt, they's simply arrive at the conclusion
> that M-A:same would not work here so that really is not what you'd want
> here. This amounts to fixing dpkg to allow this very combination in the
> same way that apt and dose allow it. So yeah, changing dpkg could be an
> option. Ccing dpkg-devel about it.
> 
> The first alternative means that we must not combine them at the same
> time. As we very much want M-A:same, we must not have this combination
> of Provides and Brekas. Keep in mind that they serve slightly different
> purposes. We have Breaks + Replaces and you can only replace a real
> package but Provides introduce a virtual package. In effect we're
> dealing with a package that sometimes is virtual and other times is
> real. We can choose different names for these uses. The real package
> could be renamed and also provide the virtual facility. All of them
> would now provide the virtual one as virtual only and none of them would
> have the virtual name. The Breaks and Replaces would be updated to match
> the real name.

we discussed this in the past already around bookworm's release, but
haven't fixed the debcargo side generating these.

see #1040477 and #1054156

IIRC the solution was to switch to Conflicts, and maybe stop providing
librust-bitflags-dev and friends (those without any semver parts in the
package name) in the semver-suffix variant, right?

> This may not work for the in-archive situations right now as Breaks and
> Replaces may still be necessary for upgrades, but it is something that
> may work in future situations of the same kind.
> 
> In the mean time, consider that M-A:same presently is a lie. Removing it
> is better than continuing to lie. It's not like we must have everything
> in perfect multiarch. Even for cross compilation, we often can get away
> without M-A:same by only requiring a package for the host architecture.
> M-A:same is not the goal. It's a tool and way may consider using other
> tools.
> 
> Helmut
> 

Bug#1033028: fixed in pydata-sphinx-theme 0.15.2-1

[Gianfranco Costamagna]

control: notfixed -1 0.15.2-1
control: reopen -1
Hello Andreas, I tried to upload your package, but I failed due to some nodejs 
failures.
Looks like the new theme-switcher is running some npm install during build,
failing due to network access...

Any idea?

In the meanwhile I reuploaded 0.7 version in sid.

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068008: rustc: Please package rust 1.75 or higher

[Fabian Grünbichler]

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> > Hi Wesley, Yaroslav, Carsten and Mike,
> 
> Hi Fabian,
> 
> Let me start by thanking you for the work going into packaging rustc.
> 
> > while we try to keep rustc somewhat current in sid, this is not always
> > possible in a timely manner.
> 
> rustc 1.70 was released on June 1 and made it to unstable in September.
> We're now 7 months later.

yeah, most of the delay there was a result of bookworm and the freeze
(rustc as part of the toolchain set gets frozen early, and we found out
the hard way this time around that if we prepare release in experimental
we still have to go through bin-NEW - and of course, we've also had our
hands full with other getting-rustc-stuff-ready-for-bookworm things at
that time).

> At the time rustc 1.70 was released, unstable had... 1.63, which was
> released close to a year prior, at which time unstable had... 1.59.

see above. 4-5 versions is  not unheard of. when 1.70 was released, we
had 1.67 in experimental, for example.

> "rustc somewhat current in sid" might have been true in the past, but
> that has unfortunately not been the case for at least two years, now.
> I'm not discounting your work, merely stating the hard truth.

we might have different definitions of "somewhat current" :)

most stable projects are okay with about 6 months lag, which is about 4
rustc releases.  and that's not taking into account that we don't always
package the latest release the moment it's out of the door for things
depending on rustc/cargo either.

I do aim for less, of course, but it doesn't always work out as
intended.

> The sad part is, as you noted, the more outdated the version in unstable
> is, the worse it gets to update it...

well, the amount of work it takes is about the same, but the wait is of
course longer if the lag is bigger, yes.

> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

well, I'd be happy to share the workload ;)

but it requires a substantial commitment - reviewing an MR for an
update is not that much less work than doing it myself, since the
package is quite complex, and quite important. I can do that a few
times, but if it's not for somebody who wants to comaintain long-term
it's probably time better spent improving the tooling or specific bugs.

I do hope to at least get rid of two bottle necks soon that have
affected updates in the past
- the split between cargo and rustc, with cargo having its own set of
  problems that made updating harder, which should be mostly eliminated
  with the merge
- me just being a DM, with additional delays introduced by waiting for
  somebody else from the team somewhat familiar with the packages
  uploading to bin-NEW (I am a DD now, but my key/account is not active
  yet)

> At least for firefox, I managed to relax the rustc requirement back to
> 1.70, so the urgency is slightly less severe at least for that package,
> for now.

that's good to know, I'll still try to get the lag reduced ASAP!

Bug#1069726: gophernicus: Default documentroot in man page does not match default config file

[William Morris]

Package: gophernicus
Version: 3.1.1-3
Severity: normal
X-Debbugs-Cc: w...@unux.org

Dear Maintainer,

When installing Gophernicus, the man page states that the -r option specifies 
the documentroot of the server, and the default is /var/gopher

The file /etc/default/gophernicus contains one line:

OPTIONS=-r /srv/gopher

setting the document root to /srv/gopher instead

I expected the default directory listed in the manual page to be the default 
location for the server's document root


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

Kernel: Linux 5.10.0-28-amd64 (SMP w/1 CPU thread)
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 gophernicus depends on:
ii  adduser   3.118+deb11u1
ii  libc6 2.31-13+deb11u9
ii  libwrap0  7.6.q-31

gophernicus recommends no packages.

gophernicus suggests no packages.

-- Configuration Files:
/etc/default/gophernicus changed [not included]
/etc/xinetd.d/gophernicus changed [not included]

-- no debconf information

Bug#1069704: bookworm-pu: package xscreensaver/6.06+dfsg1-3+deb12u1

[Tormod Volden]

On Tue, Apr 23, 2024 at 9:51 AM Jonathan Wiltshire wrote:
> Urgh, I thought this was long since dealt with. Please go ahead urgently.
>
> I presume you've taken steps to avoid it creeping back into future
> releases?

It requires a thorough review of the code (and testing) at every
upstream release (and in particular for the ones that ends up in our
stable), for as long as we want to keep shipping this package.
Sometimes it changes location and form, and extent, therefore this one
was missed. We are getting better at it though. And I'll try to handle
it in a more timely manner if it happens again.

I will also try to get the latest upstream version into backports, so
it will be easier for users to install the version that upstream so
dearly wants everybody to use.

Tormod

Bug#1069704: bookworm-pu: package xscreensaver/6.06+dfsg1-3+deb12u1

[Tormod Volden]

On Tue, Apr 23, 2024 at 7:05 PM Jonathan Wiltshire wrote:
>
> Thanks for the upload. Once built I intend to release it through the
> stable-updates mechanism, but the announcement will carry your name. Any
> comments on the following text?
>
> | The XScreenSaver package as released in Debian 12 includes an "out-of-date
> | software warning", which is displayed prior to each unlock operation.
> | This update disables such warnings.
> |
> | Users can rest assured that XScreenSaver remains supported by Debian
> | for the lifetime of the stable distribution.
>

Thanks a lot for processing this update. Your suggested text is very
well formulated, I have nothing to add.

Best regards,
Tormod

Bug#1067884: KiCad no longer seems to recognize any of the built-in libraries

[Kai-Martin Knaak]

On Fri, 12 Apr 2024 08:45:34 + Erich Minderlein
 wrote:
> I must correct my self: This was an update from devuan chimaera and
> an old history concerning $HOME, which lives with me since years
> 
> Today I made a fresh install in a virtual machine and every thing
> works fine.
> 
> Then I deleted directories
> rm -r $HOME/.config/kicad $HOME/.cache/kicad $HOME/.local/share/kicad
> 
> I started KiCad again as $USER and it acknowledged the libraries.
> 
> This is an aide at least for those who do not have a valuable history
> in KiCad
> 
> For the others the problem remains to be solved

I beg to differ. You upgraded to Devuan Daedalus which is based on
Debian bookworm, aka Debian stable. However, the original bug report
concerns in Debian trixie, i.e. Debian testing. 

In current testing the package kicad depends on kicad-libraries with a 
version string >=7.0.1~ , which in turn depends on kicad-footprints, 
kicad-symbols, kicad-templates and kicad-packages3d, again with version
string >=7.0.1~ . About two weeks ago, the packages or symbols,
footprints, etc. were upgraded to version 8.0.1-1 in testing.
 
So an 'apt upgrade' on debian testing happily pulls these v8 kicad
libraries. However, kicad still remains on v7.0.1 . Since kicad
libraries are explicitly not downward compatible across major versions,
the 7.0.1 kicad binary refuses to load any element from a 8.0.1
library. This makes the package virtually unusable for its intended
purpose.

I got bitten by the bug, too. Unfortunately, a downgrade to stable is no
option, since kicad is on v6.0 over there. All my kicad projects are on
v7.0 already and will not open with kicad6. Unfortunately, I
found no way to make apt downgrade to version 7.0 of the
libraries. Luckily, I was able to regained access to my projects by
manually replacing the upgraded v8 libraries with v7 versions from a
backup. 

The upgrade of the package kicad is blocked until until gtk+3.0,
libgllib2.0t64, python3.11, curl, opencascade and wywidgets3.2
have all received a successful upgrade. This will probably take a few
days. How about adding '<8.0' to the version requirement for the time
being?

Best regards,

---<)kaimartin(>---
-- 
Kai-Martin Knaak   kn...@iqo.uni-hannover.de
Universität Hannover, Inst. für Quantenoptik   tel: +49-511-762-2895
Welfengarten 1, 30167 Hannover fax: +49-511-762-2211
PGP-Key: https://keys.openpgp.org/search?q=kn...@iqo.uni-hannover.de


pgpQBpw2EC1l5.pgp
Description: OpenPGP digital signature

Bug#1069725: nagios-plugins-contrib: pmp-check-mysql-file-privs generates WARN state on default MariaDB installation

[Moritz Schlarb]

Source: nagios-plugins-contrib
Version: 46.20240417
Severity: normal
Tags: upstream

On a not heavily modified default installation, the check pmp-check-mysql-file-
privs gives the following warning by default:

WARN files with wrong ownership: /var/lib/mysql/debian-10.11.flag

(
For systems that have been upgraded, it is probably even more:
WARN files with wrong ownership: /var/lib/mysql/mysql_upgrade_info
/var/lib/mysql/debian-10.5.flagWARN
)

Of course, a workaround would be to chown those files, since that should not do
much harm, but it might be nice to just patch the check to ignore those
(debian-specific) files.


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

Kernel: Linux 6.6.15-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

Bug#1069697: lintian: debian-changelog-line-too-short CVEs

[Thorsten Glaser]

Richard Lewis dixit:

>would it make a difference if the somewhat ambiguous line "CVEs" was
>changed to "Fixes the following CVEs:" ?

It’s very much not ambiguous, as the entire entry is a list of
fixes, that’d be reducing the signal:noise ratio (besides this
part of the changelog is copy-pasted from the upstream release
announcement).

I find that lintian is overly opinionated here. I could agree,
were this just a single line (given the tag’s stated purpose),
but not for multi-line or lists.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1069724: slurm-wlm: autopkgtest regression on !amd64: trying to overwrite '/usr/lib/-linux-gnu/slurm-wlm/accounting_storage_mysql.so'

[Paul Gevers]

Source: slurm-wlm
Version: 23.11.4-1.4
X-Debbugs-CC: bdr...@debian.org, vor...@debian.org, mckins...@debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of slurm-wlm the autopkgtest of slurm-wlm fails in 
testing when that autopkgtest is run with the binary packages of 
slurm-wlm from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
slurm-wlm  from testing23.11.4-1.4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=3Dslurm-wlm

https://ci.debian.net/data/autopkgtest/testing/arm64/s/slurm-wlm/45786802/log.gz

 96s Unpacking slurm-wlm-mysql-plugin (23.11.4-1.4) ...
 96s dpkg: error processing archive 
/tmp/apt-dpkg-install-zn5wp3/17-slurm-wlm-mysql-plugin_23.11.4-1.4_arm64.deb 
(--unpack):
 96s  trying to overwrite 
'/usr/lib/aarch64-linux-gnu/slurm-wlm/accounting_storage_mysql.so', 
which is also in package slurm-wlm-basic-plugins 23.11.4-1.4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068207: [Pkg-nginx-maintainers] Bug#1068207:

[Ervin Hegedüs]

Hi Jan,

On Tue, Apr 23, 2024 at 07:29:37PM +0200, Jan Mojzis wrote:
> Hi,
> 
> 'https://wiki.debian.org/qa.debian.org/FTBFS'
> see:
> 2024-03-13 -Werror=implicit-function-declaration
> ... In dpkg version 1.22.6, the compiler flag 
> -Werror=implicit-function-declaration was enabled by default for all 
> architectures in build flags
> ...
> ...

oh, thanks, this is what I was looking for...

> You  need to patch libnginx-mod-http-modsecurity source code:
> 
> ~~~
> diff --git a/config b/config
> index c6e7467..3bf06a8 100644
> --- a/config
> +++ b/config
> @@ -10,7 +10,8 @@
>  
>  ngx_feature_name=
>  ngx_feature_run=no
> -ngx_feature_incs="#include "
> +ngx_feature_incs="#include 
> +#include "
>  ngx_feature_libs="-lmodsecurity"
>  ngx_feature_test='printf("hello");'
>  ngx_modsecurity_opt_I=
> ~~~

yes, this is how my patch looks like.

Perhaps I will add this to the upstream too.


Many thanks.


a.
 

Bug#1069723: RM: pytest-salt-factories -- RoQA; RC-buggy; salt is not in Debian

[Andrey Rakhmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pytest-salt-factor...@packages.debian.org
Control: affects -1 + src:pytest-salt-factories
User: ftp.debian@packages.debian.org
Usertags: remove

salt was just removed from unstable (#1067062), this package doesn't seem to be
useful without salt and is RC-buggy since 2022. No revdeps.

Bug#1068207:

[Jan Mojzis]

Hi,

'https://wiki.debian.org/qa.debian.org/FTBFS'
see:
2024-03-13 -Werror=implicit-function-declaration
... In dpkg version 1.22.6, the compiler flag 
-Werror=implicit-function-declaration was enabled by default for all 
architectures in build flags
...
...


You  need to patch libnginx-mod-http-modsecurity source code:

~~~
diff --git a/config b/config
index c6e7467..3bf06a8 100644
--- a/config
+++ b/config
@@ -10,7 +10,8 @@
 
 ngx_feature_name=
 ngx_feature_run=no
-ngx_feature_incs="#include "
+ngx_feature_incs="#include 
+#include "
 ngx_feature_libs="-lmodsecurity"
 ngx_feature_test='printf("hello");'
 ngx_modsecurity_opt_I=
~~~

Jan

Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target

[Luca Boccassi]

On Tue, 23 Apr 2024 12:23:21 +0100 Colin Watson 
wrote:
> On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote:
> > According to systemd.special(7)
> > 
> > nss-user-lookup.target
> > 
> > A target that should be used as synchronization point for
all
> > regular UNIX user/group name service lookups. [...] All
> > services for which the availability of the full user/group
> > database is essential should be ordered after this target,
but
> > not pull it in. All services which provide parts of the
> > user/group database should be ordered before this target,
and
> > pull it in.
> > 
> > I have a custom .service that does exactly as described in the
second
> > part, i.e. provides part of the user/group database and says
> > Before=nss-user-lookup.target, Wants=nss-user-lookup.target
> > (concretely, it modifies /etc/shadow to update a default password,
but
> > that's not really important). I believe sshd definitely belongs in
the
> > former category, i.e. sshd should not be started until any such
> > service that updates the user/group database, such as updating
> > /etc/shadow, have run.
> > 
> > Hence the ssh.service and ssh.socket files should add
> > 
> > After=nss-user-lookup.target
> > 
> > in their [Unit] sections. This is a no-op on systems that do not
have
> > any service pulling in that target, but required for correctness on
> > systems that do.
> > 
> > Of course, I could, and currently do, handle this via a drop-in
config
> > fragment in some ssh.service.d/ directory. But this, and other
similar
> > synchronization targets, exist so that one does not necessarily
need
> > to know about every other service running on the system.
> 
> This sounds like a reasonable proposal to me.  I'm just CCing
Debian's
> systemd maintainers for a quick review to make sure I'm not missing
> anything subtle.

That sounds fine - maybe the service, but not the socket, so that
connections can start to come in early.
I also note there's accountsservice pulling that target in but it
shouldn't, but that's a separate matter and can be handled upstream.

-- 
Kind regards,
Luca Boccassi


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

Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd

[Alexandre Rossi]

Hi,

> I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my box
> running transmission-daemon is on stable..

backporting is straightforward (no change) and I publish[1] a built backport
if you want to try.

[1] http://deb.zincube.net/

Thanks,

Alex

Bug#1069704: bookworm-pu: package xscreensaver/6.06+dfsg1-3+deb12u1

[Jonathan Wiltshire]

Thanks for the upload. Once built I intend to release it through the
stable-updates mechanism, but the announcement will carry your name. Any
comments on the following text?

| The XScreenSaver package as released in Debian 12 includes an "out-of-date
| software warning", which is displayed prior to each unlock operation.
| This update disables such warnings.
|
| Users can rest assured that XScreenSaver remains supported by Debian
| for the lifetime of the stable distribution.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069637: hd-idle: version 1.21+ds-1 hangs the upgrade process

[Arthur Marsh]

This was without actually changing /etc/defaukt/hd-idle from what was in the 
packages.

The /etc/init.d/hd-idle script on the 1.12+ds-1 package just tries to start 
hd-idle with not parameters.

Arthur. 

On 22 April 2024 4:08:49 pm ACST, Alex Mestiashvili  
wrote:
>On 4/22/24 02:54, Arthur Marsh wrote:
>> Package: hd-idle
>> Version: 1.21+ds-1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>> * What led up to the situation?
>> 
>> Setting up hd-idle (1.21+ds-1) ...
>> Installing new version of config file /etc/default/hd-idle ...
>> Installing new version of config file /etc/logrotate.d/hd-idle ...
>> Stopping the hd-idle daemon: hd-idle.
>> Starting the hd-idle daemon: hd-idlesymlinkPolicy=0, defaultIdle=600, 
>> defaultCommand=scsi, defaultPowerCondition=0, debug=false, logFile=, devices=
>> 
>> process just hung at this point.
>> 
>> * What exactly did you do (or not do) that was effective (or
>>   ineffective)?
>> 
>> Had to kill hd-idle process then downgrade hd-idle.
>
>Could you please share parts of your hd-idle configuration?
>I couldn't reproduce the problem, so I suspect it might be related to some 
>incompatibility in the config options.
>
>Thanks,
>Alex

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1

[Peter Van Eynde]

This looks a lot like a problem between the 
`OBSERVED-INTERNAL-REAL-TIME-DELTA-SEC` which is a word and the new 64-bit 
counters.

❯ git grep observed-internal-real-time-delta-sec
src/code/thread-structs.lisp:  #-64-bit (observed-internal-real-time-delta-sec 
0 :type sb-vm:word)
src/code/unix.lisp:   
(sb-thread::thread-observed-internal-real-time-delta-sec thr))

While the current sources still have:

❯ grep -A 2 -B 2 '(tv-sec' 
crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp
(define-alien-type nil
  (struct timeval
  (tv-sec (signed 32))
  (tv-usec (signed 32
(define-alien-type nil
  (struct timespec
  (tv-sec (signed 32))
  (tv-nsec (signed 32

I’m guessing that this is no longer the case on armhf anymore. I’m trying to 
test this on the porter box abel.debian.org.

Best regards, Peter

Bug#1069605: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[Darshaka Pathirana]

Hi,

On Sun, 21 Apr 2024 13:39:36 +0200 mt22j  wrote:
> 
> When mounting a samba-share by a Debian Bookworm client, kernel 
> 6.1.0-20-amd64, on this client some subdirectories and files within the 
> mounted share are missing.

Interesting.

Can you tell us, what you mean by "some"?
Or can you provide a before and after directory/file listing?

Thx!

Regards,
 - Darsha


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066327: chmlib: FTBFS: chm_http.c:167:32: error: implicit declaration of function ‘inet_addr’ [-Werror=implicit-function-declaration]

[Zixing Liu]

Package: chmlib
Followup-For: Bug #1066327
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

This is the updated patch that tries to address the build issue on amd64.

Thanks for considering the patch.


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

Kernel: Linux 6.5.0-28-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru chmlib-0.40a/debian/patches/implicit-declarations.patch 
chmlib-0.40a/debian/patches/implicit-declarations.patch
--- chmlib-0.40a/debian/patches/implicit-declarations.patch 1969-12-31 
17:00:00.0 -0700
+++ chmlib-0.40a/debian/patches/implicit-declarations.patch 2024-04-19 
20:28:40.0 -0600
@@ -0,0 +1,39 @@
+Description: Add missing includes and fix large file support
+Author: Zixing Liu 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066327
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2062947
+Forwarded: no
+Last-Update: 2024-04-19
+---
+Index: chmlib/src/chm_http.c
+===
+--- chmlib.orig/src/chm_http.c
 chmlib/src/chm_http.c
+@@ -34,6 +34,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #if __sun || __sgi
+ #include 
+ #define strrchr rindex
+@@ -43,6 +44,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ /* threading includes */
+ #include 
+Index: chmlib/src/chm_lib.c
+===
+--- chmlib.orig/src/chm_lib.c
 chmlib/src/chm_lib.c
+@@ -48,6 +48,7 @@
+  * *
+  ***/
+ 
++#define _LARGEFILE64_SOURCE 1
+ #include "chm_lib.h"
+ 
+ #ifdef CHM_MT
diff -Nru chmlib-0.40a/debian/patches/series chmlib-0.40a/debian/patches/series
--- chmlib-0.40a/debian/patches/series  1969-12-31 17:00:00.0 -0700
+++ chmlib-0.40a/debian/patches/series  2024-04-19 20:25:29.0 -0600
@@ -0,0 +1 @@
+implicit-declarations.patch

Bug#1057107: libssh2 1.9.0-2+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1057107 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libssh2
Version: 1.9.0-2+deb11u1

Explanation: fix out of bounds memory check in _libssh2_packet_add 
[CVE-2020-22218]

Bug#1068947: curl 7.74.0-1.3+deb11u12 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068947 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: curl
Version: 7.74.0-1.3+deb11u12

Explanation: fix memory leak when HTTP/2 server push is aborted [CVE-2024-2398]

Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec

[Noah Meyerhans]

On Sun, Apr 14, 2024 at 02:09:05PM +0200, Alessandro Vesely wrote:
> Sorry for the delay.  Today a new kernel image was loaded, so I had to
> reboot. I attach a screenshot of the closing session.  Near the bottom, it
> says:
> 
> Stopping S.M.A.R.T. daemon smartd.
> Stopping SpamAssassin Mail Filter Daemon spamd.
> start-stop-daemon: warning: this system is not able to track process names
> longer than 15 characters. please use --exec instead of --name.
> 
> Next it hangs there for several seconds (~30).  The next string says:
> 
> Asking all remaining processes to terminate...done.
> 
> Is it not SpamAssassin causing that warning?

If it is, it doesn't do it on Debian.  Even with sysvinit, though, the
stop jobs during shutdown run in parallel, so that message may be coming
from somewhere else.

If you manually stop spamassassin with `/etc/init.d/spamd stop`, do you
get the same warning?

noah

Bug#1069704: xscreensaver 6.06+dfsg1-3+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069704 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: xscreensaver
Version: 6.06+dfsg1-3+deb12u1

Explanation: disable warning about old versions

Bug#1069722: RFS: libtranscript/0.3.3-1.1 [NMU] [RC] -- Character set conversion library

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : libtranscript
   Version  : 0.3.3-1.1
   Upstream contact : Gertjan Halkes 
 * URL  : https://os.ghalkes.nl/libtranscript.html
 * License  : GPL-3
 * Vcs  : [fill in URL of packaging vcs]
   Section  : libs

The source builds the following binary packages:

  libtranscript-dev - Development files for libtranscript
  libtranscript1 - Character set conversion library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtranscript/libtranscript_0.3.3-1.1.dsc

Changes since the last upload:

 libtranscript (0.3.3-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add 00-fix-impfuncdef-issue.patch to fix ftbfs issue.
 (Closes: #1066225)


-- 
Regards,
--
  Bo YU

diff -Nru libtranscript-0.3.3/debian/changelog 
libtranscript-0.3.3/debian/changelog
--- libtranscript-0.3.3/debian/changelog2017-12-29 00:43:51.0 
+0800
+++ libtranscript-0.3.3/debian/changelog2024-04-24 00:14:00.0 
+0800
@@ -1,3 +1,11 @@
+libtranscript (0.3.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 00-fix-impfuncdef-issue.patch to fix ftbfs issue. 
+(Closes: #1066225)
+
+ -- Bo YU   Wed, 24 Apr 2024 00:14:00 +0800
+
 libtranscript (0.3.3-1) unstable; urgency=low
 
   * Initial release. (Closes: #885600)
diff -Nru libtranscript-0.3.3/debian/patches/00-fix-impfuncdef-issue.patch 
libtranscript-0.3.3/debian/patches/00-fix-impfuncdef-issue.patch
--- libtranscript-0.3.3/debian/patches/00-fix-impfuncdef-issue.patch
1970-01-01 07:30:00.0 +0730
+++ libtranscript-0.3.3/debian/patches/00-fix-impfuncdef-issue.patch
2024-04-24 00:13:15.0 +0800
@@ -0,0 +1,17 @@
+Description: fix implicit-function-declaration issue
+Author: Bo YU 
+Bug: https://bugs.debian.org/1066225
+Forwarded: forward this to the author of upstream
+Last-Update: 2024-04-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/config.pkg
 b/config.pkg
+@@ -66,6 +66,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ int main(int argc, char *argv[]) {
+   DIR *dir;
diff -Nru libtranscript-0.3.3/debian/patches/series 
libtranscript-0.3.3/debian/patches/series
--- libtranscript-0.3.3/debian/patches/series   1970-01-01 07:30:00.0 
+0730
+++ libtranscript-0.3.3/debian/patches/series   2024-04-24 00:06:47.0 
+0800
@@ -0,0 +1 @@
+00-fix-impfuncdef-issue.patch


signature.asc
Description: PGP signature

Bug#1065222: O: pychm -- Python binding for CHMLIB - Python 3

[yokota]

Hello,

> In case you might become Debian Maintainer we could grant you
> upload permissions for the packages you are maintaining.

Thank you.
I want upload permissions to maintain this package.

--
YOKOTA Hiroshi

Bug#1068314: python-inflate64_1.0.0+ds-1_amd64.changes REJECTED

[yokota]

Hello,

> please also mention Ma Lin in your debian/copyright.

I was updated Debian salsa repository to fix the issue.
https://salsa.debian.org/python-team/packages/python-inflate64

Please upload it as Debian package by Debian Python Team because I
don't have upload rights.

--
YOKOTA Hiroshi

Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml

[Bo YU]

Hi Stéphane!

Thanks for reviewing it.

On Tue, Apr 23, 2024 at 7:57 PM Stéphane Glondu  wrote:
>
> Dear Bo,
>
> On Mon, 4 Mar 2024 16:40:29 +0800 Bo YU  wrote:
> > I am looking for a sponsor for my package "ocaml-linenoise":
>
> Here is my review of the packaging:
>
> - There is a comment about ocaml-parany in debian/salsa-ci.yml I don't
> understand.

Ah, sorry, I forgot to drop it when I referred to the salsa yaml file
of ocaml-cpu[0]. Now I update it with more precise salsa ci target.
But to my confusion, I can not enable the ci on salsa repo on my side.
>
> - In debian/liblinenoise-ocaml.install.in, the *.cma should not be
> prefixed by "OPT: " and the *.cmxs should be prefixed by "DYN: ".

Done. I mixed them sometime but I think I will have a clear
understanding of these files.

Thanks again.

BR,
Bo

[0]: 
https://salsa.debian.org/ocaml-team/ocaml-cpu/-/blob/master/debian/salsa-ci.yml?ref_type=heads
> Cheers,
>
> --
> Stéphane
>

Bug#1040690: failure in a chroot

[David Edmondson]

The failure in a chroot looks the same as that described in #1041415,
and is due to the lack of /proc. It doesn't seem related to the
originally described problem.
-- 
Time is waiting to explain, why refuse?

Bug#1041415: details

[David Edmondson]

tag 1041415 - upstream
thanks

Ultimately this fails because /proc is not available in the chroot.

The version of libc in use *emulates* fchmodat() using /proc/self/fd
rather than using the fchmodat system call.

When /proc is provided in the chroot, the fchmodat emulation works
successfully and emacs is happy.

zarquon% sudo chroot /var/lib/machines/debian-sid
root@zarquon:/# mount
mount: failed to read mtab: No such file or directory
root@zarquon:/# /usr/bin/emacs --no-init-file --no-site-file -batch -f 
batch-byte-compile /usr/share/emacs/site-lisp/debian-startup.el
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcGBDJRw"))
root@zarquon:/# mount -t proc /proc /proc
root@zarquon:/# mount
/proc on /proc type proc (rw,relatime)
root@zarquon:/# /usr/bin/emacs --no-init-file --no-site-file -batch -f 
batch-byte-compile /usr/share/emacs/site-lisp/debian-startup.el
root@zarquon:/# exit
zarquon% 

So, not an upstream bug, and not really a bug at all.
-- 
We're deep in discussion, the party's on mute.

Bug#1069721: RFS: bugz/0.14-1 [ITA] -- command-line interface to Bugzilla

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : bugz
   Version  : 0.14-1
   Upstream contact : William Hubbs 
 * URL  : https://github.com/williamh/pybugz
 * License  : GPL-2+, GPL-2
 * Vcs  : https://salsa.debian.org/debian/bugz
   Section  : misc

The source builds the following binary packages:

  bugz - command-line interface to Bugzilla

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bugz/bugz_0.14-1.dsc


Changes since the last upload:

 bugz (0.14-1) unstable; urgency=medium
 .
   * New upstream version 0.14 (Closes: #1036334)
   * New Maintainer (Closes: #900234)
   * d/control:
 - Update Maintainer name
 - Bump Standards-Version to 4.7.0
 - Add new Build-Depends 'flit' & 'pybuild-plugin-pyproject' as 
build backend

 - Remove dh-exec from Build-Depends as it's not needed anymore
   * d/copyright:
 - Change 'man/*' to 'data/share/man/*' copyright stanza as per 
upstream

 - Update packaging copyright information
 - Update Upstream-Contact with upstream maintainer's details
   * Remove d/install since it's not needed anymore

Regards,
--
  Akash Doppalapudi


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)

[Jeremy Bícha]

On Tue, Apr 23, 2024 at 11:00 AM Colin Watson  wrote:
> I've been attempting to debug this on an AWS instance provided by
> Santiago.  So far I'm afraid I can only report some partial progress,
> but I might as well write down what I've got so far.

Colin, thanks for looking into this issue. It also affects source gcr
(which is just the older version of gcr4).

If you have time, feel free to forward this issue to
https://gitlab.gnome.org/GNOME/gcr/-/issues/

Jeremy Bícha

Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)

[Colin Watson]

On Tue, Mar 12, 2024 at 03:48:24PM -0400, Jeremy Bícha wrote:
> Debian Policy does not say that it is a severity: serious bug because
> you are unable to compile gcr4 on your particular AWS instance. I
> understand that this bug appears serious to you. I also agree that
> there is a real bug in gcr. Perhaps the bug is a race condition.
> Fixing the issue that causes gcr build tests to fail 100% in your test
> case may also fix the flakiness issue seen on the official buildds.

I've been attempting to debug this on an AWS instance provided by
Santiago.  So far I'm afraid I can only report some partial progress,
but I might as well write down what I've got so far.

Whatever the bug is, it is highly sensitive to small perturbations.  For
instance, I found that commenting out non-failing g_test_add calls from
gck/test-gck-object.c:main (even those that run _after_ the tests that
typically fail) was enough to make it fail significantly less often.  I
suspect that this is just the effect of tweaking the state of hash
tables or a random number generator or something.

More unfortunately, attaching almost any kind of debugging tool seems to
perturb timing such that the problem is no longer reproducible; in
particular I was unable to reproduce failures under gdb.  The best I
could do was to generate a core dump, as follows:

  $ gdb gck/test-gck-object core
  GNU gdb (Debian 13.2-1+b1) 13.2
  Copyright (C) 2023 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from gck/test-gck-object...
  [New LWP 31755]
  [New LWP 31753]
  [New LWP 31754]
  [New LWP 31751]
  [New LWP 31756]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Core was generated by 
`/home/cjwatson/gcr4-4.2.0/obj-x86_64-linux-gnu/gck/test-gck-object'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x7f4fef3a5633 in find_attribute (attr_type=3, 
n_attrs=12008468691120727718, attrs=0x55bef952d90a) at 
../gck/gck-attributes.c:336
  336 if (attrs[i].type == attr_type)
  [Current thread is 1 (Thread 0x7f4fed97a6c0 (LWP 31755))]
  (gdb) thread apply all bt
  
  Thread 5 (Thread 0x7f4fed1796c0 (LWP 31756)):
  #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  #1  0x7f4fef2ffc90 in g_cond_wait_until () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #2  0x7f4fef26e143 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #3  0x7f4fef2d24ba in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #4  0x7f4fef2d1ab1 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #5  0x7f4fef08f45c in start_thread (arg=) at 
./nptl/pthread_create.c:444
  #6  0x7f4fef10fbbc in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
  
  Thread 4 (Thread 0x7f4fee9c4a00 (LWP 31751)):
  #0  0x7f4fef102abf in __GI___poll (fds=0x55bba2e90cb0, nfds=1, 
timeout=500) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f4fef2a4277 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #2  0x7f4fef2a4c1f in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #3  0x55bba2564664 in loop_wait_until (timeout=) at 
../egg/egg-testing.c:310
  #4  0x55bba2562a4d in test_find_objects (test=0x55bba2e8f5c0, 
unused=) at ../gck/test-gck-object.c:403
  #5  0x7f4fef2cf71e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #6  0x7f4fef2cf513 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #7  0x7f4fef2cf513 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #8  0x7f4fef2cfc32 in g_test_run_suite () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #9  0x7f4fef2cfcb8 in g_test_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #10 0x55bba2564b96 in egg_tests_run_with_loop () at 
../egg/egg-testing.c:326
  #11 0x55bba256268e in main (argc=, argv=) 
at ../gck/test-gck-object.c:426
  
  Thread 3 (Thread 0x7f4fee17b6c0 (LWP 31754)):
  #0  0x7f4fef102abf in __GI___poll (fds=0x55bba2e904b0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f4fef2a4277 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #2  0x7f4fef2a4930 in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
  #3  0x7f4fef2a4981 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
  #4  0x7f4fef2d1ab1 in  () at 

Bug#1025912: rust-serde-yaml: please upgrade to v0.9

[Arnaud Ferraris]

Hi,

On Thu, 27 Jul 2023 20:19:19 +0100 Peter Green  wrote:

> squeekboard - not investigated yet.

Tests fail after bumping dependency.

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


I've just uploaded the new version of squeekboard to experimental, built 
using serde-yaml 0.9.


IIUC that was the last blocker, so feel free to upload to unstable 
whenever you see fit.


Cheers,
Arnaud


OpenPGP_0xD3EBB5966BB99196.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057222: pwnam: couldn't get password of "loginname" xscreensaver-auth exited with signal 6

[Andreas Sindermann]

Hi,

as I could not resolve that issue, I complete moved away from 
xscreensaver, sorry...


Andreas

On 4/22/24 18:12, Tormod Volden wrote:

Hi Andreas, did you find out more about this issue?

Just to clarify a few things:


  pwnam: couldn't get password of "loginname"

This is a normal condition if PAM is used, therefore this message is
only printed in verbose mode, and is likely not important here.


xscreensaver-auth exited with signal 6

Signal 6 is SIGABRT and this is likely xscreensaver-auth calling
abort(). I would guess it happens in xscreensaver_auth_conv() due to
an unexpected condition.

Would you be able to debug this function a bit closer? If rebuilding,
it would be nice if you could try 6.08 from unstable also, it should
build fine on stable without any changes.

Not so many use NIS nowadays, I suspect the issue is related to the
use of NIS through PAM.

Regards,
Tormod


--
Dr. Andreas Sindermann   fon: +49 (221) 470-90234
Institut fuer Theoretische Physikfax: +49 (221) 470-5159
Universitaet zu Koeln
Zuelpicher Str. 77   mailto:sin...@thp.uni-koeln.de
D-50937 Koeln, Germany   http://www.thp.uni-koeln.de/~sinder

Bug#1052376: lxpanel: no longer obeys its geometry settings

[jim_p]

Package: lxpanel
Version: 0.10.2.rc1-1
Followup-For: Bug #1052376
X-Debbugs-Cc: pitsior...@outlook.com

Since there is no interest from the maintainers in fixing a 6+ month old grave
bug, I want to ask. Has anyone moved away from lxpanel or even lxde? I would
switch to lxqt, but lxqt is one major version behind in debian (or 2, if you
count the qt6-based lxde 2.0 which was released a week ago).

Knowing that lxde, as a project, is not that actively developed from upstrean,
that gtk3 migration of its apps should not have happened in the first place. In
arch, they still build lxpanel with gtk2 and even pcmanfm has a seperate
package for its gtk3 version.


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

Kernel: Linux 6.6.15-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)

Versions of packages lxpanel depends on:
ii  libasound2   1.2.10-3
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libcurl3-gnutls  8.5.0-2
ii  libfm-gtk3-4 1.3.2-4
ii  libfm-modules1.3.2-4
ii  libfm4   1.3.2-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libiw30  30~pre9-16+b1
ii  libkeybinder-3.0-0   0.3.2-1.1+b1
ii  libmenu-cache3   1.1.0-1.1+b1
ii  libpango-1.0-0   1.52.0+ds-1
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.7-1
ii  libxkbfile1  1:1.1.0-1
ii  libxml2  2.9.14+dfsg-1.3+b2
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.2.rc1-1

Versions of packages lxpanel recommends:
ii  alacritty [x-terminal-emulator] 0.12.2-2+b2
ii  dunst [notification-daemon] 1.9.2-1
ii  libnotify-bin   0.8.3-1
ii  notification-daemon 3.20.0-4+b1
pn  pavucontrol | gnome-alsamixer   
ii  rxvt-unicode [x-terminal-emulator]  9.31-3
ii  xkb-data2.41-2

Versions of packages lxpanel suggests:
ii  brave-browser [www-browser]  1.65.114
ii  chromium [www-browser]   123.0.6312.105-1~deb13u1
ii  firefox [www-browser]123.0-1

-- no debconf information

Bug#1041415: details

[David Edmondson]

tag 1041415 + upstream
thanks

The error message:

>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcFx8oFi"))

comes from the emacs byte compiler. Tracing through the byte compiler,
we find that the error is reported by the call to `set-file-modes` in
`byte-write-target-file`.

set-file-modes is implemented in C, and ultimately results in a call to
`fchmodat`.

`byte-write-target-file` *always* sets the 'nofollow flag when calling
`set-file-modes`, which results in `fchmodat` being called with the
AT_SYMLINK_NOFOLLOW flag.

Unfortunately, documentation for `fchmodat` on Linux indicates:

> AT_SYMLINK_NOFOLLOW
> If pathname is a symbolic link, do not dereference it: instead
> operate on the link itself. This flag is not currently
> implemented.

...and...

> ENOTSUP
> (fchmodat()) flags specified AT_SYMLINK_NOFOLLOW, which is not supported.

ENOTSUP maps to "Operation not supported", which is the error returned
back up the stack.

So this looks like a bug in upstream emacs 28. Will take it there.
-- 
She's got no name, but she is family.

Bug#1006344: rasdaemon: inconsistent /var/lib/rasdaemon permissions between upgraded and new installs

[Sergio Gelato]

In addition, since /var/lib/rasdaemon is no longer in the package's file list 
it may need to be explicitly removed by the postrm script.

Bug#1069692: nfs-ganesha: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Christoph Martin]

Hi Sebastian,

this is interesting. If you take a look into the commandline you see

-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64

there is -D_FILE_OFFSET_BITS=64 even twice. ..

But the GPFS code has:


/* _FILE_OFFSET_BITS macro causes F_GETLK/SETLK/SETLKW to be defined to
 * F_GETLK64/SETLK64/SETLKW64. Currently GPFS kernel module doesn't work
 * with these 64 bit macro values through ganesha interface. Undefine it
 * here to use plain F_GETLK/SETLK/SETLKW values.
 */
#undef _FILE_OFFSET_BITS


I'll exclude the GPFS module for armel and armhf.

Regards
Christoph



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069710: [Pkg-utopia-maintainers] Bug#1069710: network-manager: WWAN adapter (Modem) is not found after update of stable Debian

[Michael Biebl]

Well, the network-manager version did not changed between 12.2 and 12.5

So it's most likely a regression in some other part, like the kernel.

If you want to see this fixed, you will likely need to narrow down the 
problem to the actual package update which caused the regression.



Michael
Am 23.04.24 um 15:04 schrieb beer-b...@yandex.ru:

Yesterday as planned update
Debian 12.2.0-14 -> Debian 12.5

Kernel was updated as well
 From Linux 6.1.0-18-amd64 (working) to Linux 6.1.0-20-amd64
23.04.2024, 16:17, "Michael Biebl" :

Control: tags -1 + moreinfo

Am 23.04.2024 um 12:09 schrieb Serge Polyakov:

  Package: network-manager
  Version: 1.42.4-1
  Severity: important
  X-Debbugs-Cc: beer-b...@yandex.ru 

  Dear Maintainer,

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

  * What led up to the situation?

  After updating stable Debian to the latest version my laptop
losts modem
  device.


  From which version did you upgrade?
What was the last working version?
Did the upgrade involve other components like the kernel?





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041415: details

[David Edmondson]

Ah, by specifically using a chroot rather than a systemd-nspawn
container, I *am* able to reproduce the failure.

Off to debug...
-- 
I'm not living in the real world, no more, no more.

Bug#1069268: gnulib: package version is long

[Vincent Lefevre]

Hi Simon,

On 2024-04-19 09:13:01 +0200, Simon Josefsson wrote:
> Vincent Lefevre  writes:
> 
> > Package: gnulib
> > Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2
> > Severity: normal
> >
> > A long package version is annoying for the user (for the "dpkg -l"
> > output and other reasons). I doubt that such a long version is
> > necessary;

I would also add that long version strings are truncated in the
aptitude TUI due to the limited terminal width.

> Hi Vincent and thanks for the report.
> 
> Yeah, I can sympathise with this concern, and deciding on the version
> scheme probably took me the most time in the last update.  Some
> discussion would help.  Quoting README.source:
[...]

Thanks for the explanations. However, I think that it is not the
goal of the Debian version string to entirely reflect all the
Debian-side and upstream-side versions involved. This may be a
good idea when the obtained version string is short enough and
easy to understand, but here, this is not the case. There are
probably better places to give such information, in a clearer
way. This could be in well-chosen files and/or output from
commands like "gnulib-tool --version" (see below).

> The only superflous information in the version strings are the dates,
> but removing them does not seem like it would improve on your concern,
> rather the opposite.  Maybe the dates are what makes sense for users.
> 
> And something like dates are needed for dpkg version ordering.

Yes, for version strings, dates are much more important than things
like commit ids (which just look like random characters).

> Some ideas for improvement:
> 
> 20240411+stable-1 - revert to earlier pattern, this loses the commit id
> information and which stable branch was used, potentially making it
> impossible to use the same pattern in the future if there is one Debian
> upload of 20240411+stable-1 and somehow upstream gnulib commits an
> important patch on the same date that we need to package.

In the *rare* case of an upstream commit at the same date, a suffix
can be used, something like 20240411-2+stable-1.

BTW, is the "+stable" really useful in the version string?
Such information could be given in the Debian changelog
(which is already the case) and at some other places.

If it is dropped, there's also:
  20240411-1 (first version)
  20240411a-1 (additional commit on the same date)

[...]
> To be honest, after writing all this, I'm no longer certain why anyone
> would really look at the version number at all for the gnulib Debian
> package.  A sequentially increasing number is sufficient for packaging
> reasons: if anyone really wants to know what git commits are inside the
> package, just read the source code in the package to find out.

IMHO, for additional version information, the Debian changelog is a
good place for the user + output from a standard command providing
the version, e.g. "gnulib-tool --version". Scripts can use such a
command to record the necessary information about software in log
files. By "standard", I mean that it needs to exist upstream.

For instance, for GCC, there is "gcc --version", where Debian adds
some information. In particular for gcc-snapshot:

$ gcc-snapshot --version
gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
r14-8187-gb00be6f1576]
[...]

One has all the details... When compiling software, this can be
found in the generated config.log file, which is really nice for
bug reports and debugging.

And the gcc-snapshot version string is basically just a date.

Regards,

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

Bug#1068951: new upstream (6.x)

[Jakub Ružička]

On 4/23/24 14:05, Daniel Baumann wrote:

Hi,

On 4/23/24 13:58, Jakub Ružička wrote:
but we've agreed the time has come to get extra testing & feedback 
through Debian experimental.


yay, thanks!

[ we use knot-resolver at work for the central resolvers for the 
university, and we love it. kresd 6 offers some nice improvements for 
us, so looking forward testing it (via local bookworm-backports we 
maintain) ]
Awesome, I've forwarded your words of praise to the hard-working Knot 
Resolver team :)


The only blocker for that is missing python3-json-schema-for-humans 
needed for docs build which I intend to package later - for now I 
guess I'll just disable the docs build.


(just as an offer) I'll maintain a bunch of python modules already and 
don't mind another, so I can upload that later today if this is any help.


Thanks, but I'm part of PythonTeam so I can do that myself and I'm 
actually quite interested in (the nightmares of) python packaging in 
general so it's a welcome opportunity to have some real world experience 
plus I think it will be a trivial package.





I'm hitting boundaries of my Debian knowledge so it's slow.


I'm happy to help if you want.
Cool, I've already mental-marked you as a person I'm gonna bother with 
reviewing my v6 changes even before your willing reply :)




For example, upstream package uses meson directly and builds in 
meson_deb dir, but debian package uses debhelper with 
obj-x86_64-linux-gnu dir and I don't know howto properly reference it 
from d/rules without relying on shady strings.


I didn't find a branch on the salsa repo, where would I find the 
current 6.x state to send patches against?
I don't like pushing broken/incomplete branches but yeah this is gonna 
take a while so I pushed my Draft to debian/experimental salsa branch 
(also pristine-tar and new upstream-6).


The upstream package is well tested, but it diverged quite far from 
debian package and syncing them is non-trivial - my mission is to fix that.


git clone -b 6.0 https://gitlab.nic.cz/knot/knot-resolver
meld knot-resolver/distro/pkg/deb ~/debian/knot-resolver/debian

IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian 
should be as close as possible.


Of course the changes can flow both ways - I'm happy to update the 
upstream packaging as well.


Feel free to push your changes (if any) to debian/experimental or use 
your branch as you prefer, I'm always eager to learn how other DDs do 
things.


I'd be especially interested about how you translate the 
distro/pkg/deb/rules to debian/rules without using the static build_deb 
dir 樂 There might be variable already defined for this purpose, but I 
just don't know how to find it.




Regards,
Daniel



Cheers,
Jakub



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069719: [ITP] wireviz - Easily document cables and wiring harnesses.

[Angel]

Package: wnpp
Severity: wishlist

Hello, I am looking to pacakge WireViz for debian.
Upstream source: https://github.com/wireviz/WireViz
License: GPLv3

WireViz is a tool for easily documenting cables, wiring harnesses and
connector pinouts. It takes plain text, YAML-formatted files as input
and produces beautiful graphical output (SVG, PNG, ...) thanks to
GraphViz. It handles automatic BOM (Bill of Materials) creation and
has a lot of extra features.

Regards,
Angel Yankov

Bug#1069718: ldc: add build support for loongarch64

[zhangdandan]

Source: ldc
Version: 1:1.36.0-2
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

I have added build support for loongarch in ldc package.

Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

diff --git a/../org/ldc-1.36.0/debian/control b/debian/control
index ef38a72..c63b587 100644
--- a/../org/ldc-1.36.0/debian/control
+++ b/debian/control
@@ -27,7 +27,7 @@ Vcs-Git: https://salsa.debian.org/d-team/ldc.git
 Vcs-Browser: https://salsa.debian.org/d-team/ldc
 
 Package: ldc
-Architecture: amd64 arm64 armhf i386 riscv64
+Architecture: amd64 arm64 armhf i386 riscv64 loong64
 Provides: d-compiler,
   d-v2-compiler
 Depends: libphobos2-ldc-shared-dev (= ${binary:Version}),
@@ -42,7 +42,7 @@ Description: LLVM D Compiler
 
 Package: libphobos2-ldc-shared106
 Section: libs
-Architecture: amd64 arm64 armhf i386 riscv64
+Architecture: amd64 arm64 armhf i386 riscv64 loong64
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends}
@@ -57,7 +57,7 @@ Description: LLVM D Compiler - Standard and runtime libraries
 
 Package: libphobos2-ldc-shared-dev
 Section: libdevel
-Architecture: amd64 arm64 armhf i386 riscv64
+Architecture: amd64 arm64 armhf i386 riscv64 loong64
 Depends: libphobos2-ldc-shared106 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}

Bug#1041415: details

[David Edmondson]

I was not able to reproduce this failure.

Is there anything interesting about the filesystem underlying the chroot
used during the install?

Is root able to write files with impunity in the relevant directories?

Are you able to reproduce the failure?
-- 
Time is waiting to explain, why refuse?

Bug#1069717: dh-dlang: add build support for loongarch64

[zhangdandan]

Source: dh-dlang
Version: 0.6.6
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

I have added build support for loongarch in dh-dlang package.

Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

diff -Nru dh-dlang-0.6.6/debian/control dh-dlang-0.6.6/debian/control
--- dh-dlang-0.6.6/debian/control   2024-02-18 21:52:28.0 +
+++ dh-dlang-0.6.6/debian/control   2024-02-18 21:52:28.0 +
@@ -25,9 +25,9 @@
  for the current architecture.
 
 Package: default-d-compiler
-Architecture: amd64 arm64 i386 armhf s390x riscv64 ppc64el x32
+Architecture: amd64 arm64 i386 armhf s390x riscv64 loong64 ppc64el x32
 Depends: gdc (>= 4:12) [armhf s390x ppc64el x32],
- ldc (>= 1:1.36) [amd64 arm64 i386 riscv64],
+ ldc (>= 1:1.36) [amd64 arm64 i386 riscv64 loong64],
  ${misc:Depends}
 Description: Default D compiler (metapackage)
  This is a metapackage installing the default D compiler in Debian
diff -Nru dh-dlang-0.6.6/dlang-flags.mk dh-dlang-0.6.6/dlang-flags.mk
--- dh-dlang-0.6.6/dlang-flags.mk   2024-02-18 21:13:50.0 +
+++ dh-dlang-0.6.6/dlang-flags.mk   2024-02-18 21:52:28.0 +
@@ -24,7 +24,7 @@
 
 # set DC to the LDC compiler on platforms where we should use it,
 # and also set the right D flags on those architectures (since LDC uses 
different flag names)
-ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 i386 riscv64))
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 i386 riscv64 loong64))
 # only set LDC build flags if our compiler is LDC
 ifeq ($(DC_LDC_FOUND),yes)
 DC = ldc2

Bug#1069716: rust-opendal: please upgrade to v0.45.1

[Jonas Smedegaard]

Source: rust-opendal
Version: 0.44.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separatety provide, branch v0.45, and for that
branch please provide at least release version v0.45.1.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYnqGUACgkQLHwxRsGg
ASGF8g//QcZJnJMLCsQLsYZ9rbv4AF6OyMq08PpiyhgevWOL7V08pDObQtu/Yjdt
yEBcC3JL3OIU7DWQK8JsEp3OTbldPW/EonolLLH6zaDxcoZUQYITH6VAxMXineeT
/ZfsYzdmu+LjmENL+NmsZ0B+q7fb9Hq8lqwttU/Qj2/ep40FLNIENyx1HXkAZrJU
KkOV61aiqyaN83nsAY6HKXmzCP8qQPfnV2E7+WDOlNSNEpeLfxpqlTBNCdFuYCXM
5W85nibsZ+/qXMYeaZiE/NHrJ/2ZG7HB/gmlxCdo+KTHONLKOt3mfWXshCnQCxku
OczFcbxjbr4m2uwcvzMTTT+Eu48StyKvgxCbc4FuWgOzXaN7ZePLcGGdgq+/rNWy
i5dQiu9nScmjTJe5qhUjVCYqyFkrqEGTw3th5db9+BuCipQq1TJxzhKTINHLagD9
fydV6G+9S/i0R39BxdpYXHE90GgOrYTiqMZa8cTujLYPYNoexMFSdmzkxXTxLVUJ
anVAO1R0kMXU20PS4+PHzthIAodsYF3JA3vCGzj9vnorE2qqwXUBNBprF7BYxsUZ
zE/DdU+Cu/kG5TwZbKCu9wESFLrZOt0dl9cij65DE3dzgj/J/BZ7DhjtEyiTElIN
SzZ0eBOXFt4jd9hBuUqPOw/jygnsyrTL/053NUDED+JIhZs2TJc=
=5tn1
-END PGP SIGNATURE-

Bug#1069715: librust-opendal-dev: package is impossible to install

[Jonas Smedegaard]

Package: librust-opendal-dev
Version: 0.44.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package is impossible to install due to numerous missing
dependencies including librust-async-backtrace-0.2+default-dev and
librust-atomic-lib-0.34+default-dev.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYnqBAACgkQLHwxRsGg
ASF41xAAohZlp8Nw70zjFGCWsSyPWc/MC7Ur3g7dKlcX5Dwf1zPgnghzBZ8Xragp
+P+9wz9KFvM5G+qbTirV6LbjFKGPe+A/3H1UGch7fSf4XkUP1kUY5cei6jOdZLjv
guA7ctdEhzx1xfmfs++rE1+FQdMs6EL4r/9mfVC7/x2Y63tpObucMqersCfLJIrC
1W0sj9+1N9RJxiIl2HSTPjafOfnzYgY0RSLbgRj4PP92gAJDZpPKpjZjLxFMOyt2
ZTrCpIDMvDGF8YAqhcz5pymvUSiW7/T2SlYNGw5ZuCwlE0lwAYXS6N5YuM1moedG
Esu/gFQzlflCw/N2dSPaZeQnlQp5FhGn+NSS0RLc37N9kqWYlUKjo6WZ47EXMl+E
ukTuSL2xXU9BWoie3VjKfaf09TWvzhLYBThIBsZW3SUmHqn688G8A83TXVDfOTIX
pNpnbICFSFBszfBEGcbyLpZA/lhJF07jKlysBejlBwlaP12UjKBjYE89u7BG8Zj6
OEyGzL/9OxNiPDoP1LEdDgQyXmcYddry8i0fa18jZo5jAdtWM1KOqbLec1woc4WC
NudRlKfEqqySv10Yadbe5RzCk7NpM3V8ZQnNV2jpzzEP7wsisHckudQ6jSNnO2ks
l9qtIoYQVndkKg9thfPhvVqEeULXC1Uy6NRsfqBatDI6RCLu5xc=
=quVH
-END PGP SIGNATURE-

Bug#1069710: [Pkg-utopia-maintainers] Bug#1069710: network-manager: WWAN adapter (Modem) is not found after update of stable Debian

[Michael Biebl]

Control: tags -1 + moreinfo

Am 23.04.2024 um 12:09 schrieb Serge Polyakov:

Package: network-manager
Version: 1.42.4-1
Severity: important
X-Debbugs-Cc: beer-b...@yandex.ru

Dear Maintainer,

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

* What led up to the situation?

After updating stable Debian to the latest version my laptop losts modem
device.


From which version did you upgrade?
What was the last working version?
Did the upgrade involve other components like the kernel?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069714: gcc-defaults: enable build gdc and gm2 for loong64

[zhangdandan]

Source: gcc-defaults
Version: 1.217
Severity: normal
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

For loong64, the D, Ada, Modula-2 modules have been supported in gcc-14 
14-20240330-1.
I duploaded the gdc-14, gnat-14 and other packages built from gcc-14 
14-20240330-1 that support the loong64 architecture for the first time 
to debian ports.


Due to "default to GCC 13" is used in gcc-defaults 1.214, we need to 
enable build gdc and gm2 for loong64 in gcc-defaults 1.217.

Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

diff -Nru gcc-defaults-1.217/debian/control gcc-defaults-1.217/debian/control
--- gcc-defaults-1.217/debian/control   2024-01-31 13:17:32.0 +
+++ gcc-defaults-1.217/debian/control   2024-01-31 13:17:32.0 +
@@ -2740,6 +2740,39 @@
  This is a dependency package providing the default GNU Fortran 95
  cross-compiler for the loong64 architecture.
 
+Package: gdc-loongarch64-linux-gnu
+Priority: optional
+Architecture: loong64 
+Multi-Arch: foreign
+Depends: cpp-loongarch64-linux-gnu (>= ${version:cpp}),
+  gdc-${pv:gdc}-loongarch64-linux-gnu ${reqv:gdc},
+  ${misc:Depends}
+Breaks: gdc (<< 4:13.2.0-3)
+Replaces: gdc (<< 4:13.2.0-3)
+Description: GNU D compiler (based on GCC) for the loong64 architecture
+ This is the GNU D compiler, which compiles D on platforms supported by
+ the gcc compiler. It uses the gcc backend to generate optimized code.
+ .
+ This is a dependency package providing the default GNU D cross-compiler
+ for the loong64 architecture.
+
+Package: gm2-loongarch64-linux-gnu
+Priority: optional
+Architecture: loong64 
+Multi-Arch: foreign
+Depends: cpp-loongarch64-linux-gnu (= ${version:cpp}),
+  gm2-${pv:gm2}-loongarch64-linux-gnu ${reqv:gm2},
+  ${misc:Depends}
+Breaks: gm2 (<< 4:13.2.0-3)
+Replaces: gm2 (<< 4:13.2.0-3)
+Description: GNU Modula-2 compiler (based on GCC) for the loong64 architecture
+ This is the GNU Modula-2 compiler, which compiles Modula-2 on platforms
+ supported by the gcc compiler. It uses the gcc backend to generate optimized
+ code.
+ .
+ This is a dependency package providing the default GNU Modula-2 cross-compiler
+ for the loong64 architecture.
+
 Package: cpp-powerpc-linux-gnu
 Priority: optional
 Architecture: powerpc
diff -Nru gcc-defaults-1.217/debian/rules gcc-defaults-1.217/debian/rules
--- gcc-defaults-1.217/debian/rules 2024-01-31 13:17:32.0 +
+++ gcc-defaults-1.217/debian/rules 2024-01-31 13:17:32.0 +
@@ -231,11 +231,11 @@
$(all_archs_mips)
 
 gcc13_archs =
-gcc14_archs  = alpha arc amd64 armel armhf arm64 hppa i386 ia64 m68k or1k 
powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 x32 hurd-amd64 
hurd-i386 kfreebsd-amd64 kfreebsd-i386 \
+gcc14_archs  = alpha arc amd64 armel armhf arm64 hppa i386 ia64 loong64 m68k 
or1k powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 x32 hurd-amd64 
hurd-i386 kfreebsd-amd64 kfreebsd-i386 \
 $(all_archs_mips)
 
 gnat13_archs  =
-gnat14_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k or1k powerpc 
ppc64 ppc64el s390 s390x sh4 sparc sparc64 x32 hurd-amd64 hurd-i386 
kfreebsd-amd64 kfreebsd-i386 \
+gnat14_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 loong64 m68k or1k 
powerpc ppc64 ppc64el s390 s390x sh4 sparc sparc64 x32 hurd-amd64 hurd-i386 
kfreebsd-amd64 kfreebsd-i386 \
 $(all_archs_mips)
 
 # CV_XXX is the complete version number, including the release, without epoch
@@ -338,7 +338,7 @@
$(all_archs_mips) \
powerpc ppc64 ppc64el riscv64 s390 s390x sparc sparc64 x32
 
-d_archs = amd64 arm64 armel armhf i386 \
+d_archs = amd64 arm64 armel armhf i386 loong64 \
$(all_archs_mips) \
powerpc ppc64 ppc64el riscv64 s390x x32
 phobos_archs = $(filter-out powerpc ppc64 ppc64el, $(d_archs))
@@ -347,7 +347,7 @@
 
 d_multilib_archs = $(filter $(d_archs), $(filter-out armel sparc64, 
$(multilib_archs)))
 
-ada_archs = alpha amd64 arm64 armel armhf hppa i386 ia64 m68k \
+ada_archs = alpha amd64 arm64 armel armhf hppa i386 ia64 m68k loong64 \
$(all_archs_mips) \
powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 \
kfreebsd-amd64 kfreebsd-i386 hurd-amd64 hurd-i386
@@ -357,7 +357,7 @@
 
 hppa64_archs = amd64 hppa i386 x32
 
-m2_archs = alpha arc amd64 arm64 armel armhf i386 ia64 \
+m2_archs = alpha arc amd64 arm64 armel armhf i386 ia64 loong64 \
$(all_archs_mips) \
ppc64el riscv64 s390 s390x sparc64
 
@@ -368,6 +368,7 @@
   HOST_ARCHS_arm64 = amd64 i386 x32 ppc64el s390x
   HOST_ARCHS_armhf = amd64 i386 x32 arm64 ppc64el s390x
   HOST_ARCHS_i386 = amd64 arm64 ppc64el x32 s390x
+  HOST_ARCHS_loong64 = amd64 i386 x32 arm64 ppc64el s390x
   ifeq ($(vendor),Ubuntu)
 HOST_ARCHS_powerpc = amd64 arm64 i386 x32 ppc64el s390x
   endif
@@ -517,13 +518,11 @@
gccgo-multilib-arm-linux-gnueabihf \
gdc-alpha-linux-gnu \

Bug#1068951: new upstream (6.x)

[Daniel Baumann]

Hi,

On 4/23/24 13:58, Jakub Ružička wrote:
but we've agreed the time has come to get extra testing & feedback 
through Debian experimental.


yay, thanks!

[ we use knot-resolver at work for the central resolvers for the 
university, and we love it. kresd 6 offers some nice improvements for 
us, so looking forward testing it (via local bookworm-backports we 
maintain) ]


The only blocker for that is missing python3-json-schema-for-humans 
needed for docs build which I intend to package later - for now I guess 
I'll just disable the docs build.


(just as an offer) I'll maintain a bunch of python modules already and 
don't mind another, so I can upload that later today if this is any help.



I'm hitting boundaries of my Debian knowledge so it's slow.


I'm happy to help if you want.

For example, upstream package uses meson directly and builds in 
meson_deb dir, but debian package uses debhelper with 
obj-x86_64-linux-gnu dir and I don't know howto properly reference it 
from d/rules without relying on shady strings.


I didn't find a branch on the salsa repo, where would I find the current 
6.x state to send patches against?


Regards,
Daniel

Bug#1068951: new upstream (6.x)

[Jakub Ružička]

Hello,

we have a working upstream packages for knot-resolver 6.x alpha at

https://pkg.labs.nic.cz/doc/?project=knot-resolver

but we've agreed the time has come to get extra testing & feedback 
through Debian experimental.


The only blocker for that is missing python3-json-schema-for-humans 
needed for docs build which I intend to package later - for now I guess 
I'll just disable the docs build.


I'm working on deep-cleaning the knot-resolver package (silencing the 
many cries of lintian and such) and syncing it closer with upstream but 
I'm hitting boundaries of my Debian knowledge so it's slow.


For example, upstream package uses meson directly and builds in 
meson_deb dir, but debian package uses debhelper with 
obj-x86_64-linux-gnu dir and I don't know howto properly reference it 
from d/rules without relying on shady strings.


I'll take some more time to clean the package properly so that it starts 
its 6.x life with a clean slate but it's going to hit experimental in 
upcoming weeks :)



Thanks for indicating interest, I'll get it done.


Cheers,
Jakub Ružička

On 4/14/24 08:39, Daniel Baumann wrote:

Package: knot-resolver
Severity: wishlist

Hi,

it would be nice if you could upload knot-resolver 6.x to experimental.

Regards,
Daniel


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066327: chmlib: FTBFS: chm_http.c:167:32: error: implicit declaration of function ‘inet_addr’ [-Werror=implicit-function-declaration]

[Kartik Mistry]

On Tue, Apr 23, 2024 at 12:48 AM Zixing Liu 
wrote:

> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * debian/patches/implicit-declarations.patch: Add missing includes and
> fix large file support. (LP: #2062947).
>

Thanks!

Patch builds package locally, but seems failing with Salsa CI. See:
https://salsa.debian.org/debian/chmlib/-/jobs/5630940

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#1017834: analysis

[David Edmondson]

The failure to build elpa-cider is caused by:

> In toplevel form:
> cider.el:218:1: Error: Wrong number of arguments: (3 . 4), 2

In the source, this corresponds to:

> (define-obsolete-variable-alias 'cider-default-repl-command 
> 'cider-jack-in-default)

In recent versions of emacs, the definition of this (macro) is:

> (define-obsolete-variable-alias OBSOLETE-NAME CURRENT-NAME WHEN  
> DOCSTRING)

So the call from cider.el is missing the third argument, leading to the error.

Examining emacs' history, we can find in NEWS.28:

> ** The WHEN argument of 'make-obsolete' and related functions is mandatory.
> The use of those functions without a WHEN argument was marked obsolete
> back in Emacs 23.1.  The affected functions are: 'make-obsolete',
> 'define-obsolete-function-alias', 'make-obsolete-variable',
> 'define-obsolete-variable-alias'.

So this is indeed caused by a change in emacs 28, where the third
argument to define-obsolete-variable-alias is now mandatory.

Upstream cider removed this call to define-obsolete-variable-alias in
version 1.1, changeset 4b6c0e9936d125102c2dd0bb1dedbd80fb4907a6, in
December 2020.

What to do?

Debian could carry a patch to fix version 0.19 of cider to address this
failure. This would be straightforward, but given how old the packaged
version of cider is, it's not clear that it would really be a useful way
forward.

It seems like either:
- the Debian packaged version of cider should be updated to something
  more current, and kept updated,
- the package should be removed, leaving Debian without a packaged
  version of cider.

New versions of cider appear quite frequently - sometimes
weekly. Keeping them up to date in Debian would be an ongoing
commitment.

Given how old the packaged version of cider is and how apparently little
used (it has been broken for a couple of years, and popcon lists 7
installs), removing it seems the more sensible approach.
-- 
I've been waiting for so long, to come here now and sing this song.

Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml

[Stéphane Glondu]

Dear Bo,

On Mon, 4 Mar 2024 16:40:29 +0800 Bo YU  wrote:

I am looking for a sponsor for my package "ocaml-linenoise":


Here is my review of the packaging:

- There is a comment about ocaml-parany in debian/salsa-ci.yml I don't 
understand.


- In debian/liblinenoise-ocaml.install.in, the *.cma should not be 
prefixed by "OPT: " and the *.cmxs should be prefixed by "DYN: ".



Cheers,

--
Stéphane

Bug#1068174: Upstream yosys 0.40 works for me

[Philipp Klaus Krause]

I have done a quick test of the latest upstream release, yosys 0.40 on
my Debian GNU/Linux (mixture of testing and unstable) amd64 system.

* I built yosys using plain "make" (worked fine, unlike 0.38, where I
ran into https://github.com/YosysHQ/yosys/issues/4244, and had to use a
workaround)
* The upstream tests via "make test" passed
* I installed as root via "make install"
* I synthesized some Verilog code for the iCE40UP5, and put it on an
iCEBreaker board: Two f8-based SoC (one using a single-cycle f8, one
using a multi-cycle f8), and ran both an LED blink program and a "Hello,
world!" via soft-UART. Both worked for me.
* I was also able to synthesize for the GateMate, but did not test on
the FPGA board yet. Just like in 0.38, I had to use -nomx8, as the
defaults generate MX8 cells that haven't been supported by the P tool
for many months: https://github.com/YosysHQ/yosys/issues/4355

Philipp

Bug#1069706: systemd unit files lack ordering wrt nss-user-lookup.target

[Colin Watson]

On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote:
> According to systemd.special(7)
> 
> nss-user-lookup.target
> 
> A target that should be used as synchronization point for all
> regular UNIX user/group name service lookups. [...] All
> services for which the availability of the full user/group
> database is essential should be ordered after this target, but
> not pull it in. All services which provide parts of the
> user/group database should be ordered before this target, and
> pull it in.
> 
> I have a custom .service that does exactly as described in the second
> part, i.e. provides part of the user/group database and says
> Before=nss-user-lookup.target, Wants=nss-user-lookup.target
> (concretely, it modifies /etc/shadow to update a default password, but
> that's not really important). I believe sshd definitely belongs in the
> former category, i.e. sshd should not be started until any such
> service that updates the user/group database, such as updating
> /etc/shadow, have run.
> 
> Hence the ssh.service and ssh.socket files should add
> 
> After=nss-user-lookup.target
> 
> in their [Unit] sections. This is a no-op on systems that do not have
> any service pulling in that target, but required for correctness on
> systems that do.
> 
> Of course, I could, and currently do, handle this via a drop-in config
> fragment in some ssh.service.d/ directory. But this, and other similar
> synchronization targets, exist so that one does not necessarily need
> to know about every other service running on the system.

This sounds like a reasonable proposal to me.  I'm just CCing Debian's
systemd maintainers for a quick review to make sure I'm not missing
anything subtle.

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

Bug#1069236: openssh-server: X over ssh fails with "cannot open display"

[allan]

I'm not using a hostname with ssh, I'm sshing directly to an IPv4 address.

*How* was it disabled?  net.ipv6.conf.all.disable_ipv6 = 1 in /etc/sysctl.conf

My point is that "AddressFamily any" should not fail to set $DISPLAY
if IPv6 is not available.

On Tue, Apr 23, 2024 at 5:38 AM Jonathan Dowland  wrote:
>
> On Thu, Apr 18, 2024 at 06:33:00AM -0500, allan wrote:
> > Resolved the issue by editing /etc/ssh/sshd_config and changing
> > #AddressFamily any
> > to
> > AddressFamily inet
>
> This is not a reasonable change to make to the default configuration,
> because it would mean that ssh did not work out of the box in IPv6
> environments.
>
> On Thu, Apr 18, 2024 at 07:53:52AM -0500, allan wrote:
> > More info - IPv6 is disabled on all four machines.  I think
> > "AddressFamily any" should have supported an IPv4 connection.
>
> *How* is it disabled? More information will be needed to figure out
> exactly what's gone on in your environment.
>
> I speculate that the hostnames you were trying to connect to were
> resolving as IPv6 addresses, and the connection failing because the
> hosts are rejecting IPv6 traffic. If that's right, the ultimate fix
> is to correct whatever name resolution is giving you the wrong
> addresses in your environment.
>
> If you are prepared to experiment, we might be able to drill down and
> check that. If so, can you
>
> 1) reverse the sshd_config change you made on at least one of the
>hosts, and restart that sshd
>
> 2) assuming the troublesome host is named "myhost" in your environment
>(substitute as appropriate), from your client machine, report the
>result of running
>
> getent hosts myhost
> dig +short myhost
> nslookup myhost
> ping -c 1 myhost
>
> (one or more of these commands may not exist on your machine)
>
> 2) re-attempt to connect from your client, this time passing -vv or
>-vvv, and capture the logging output

Bug#1069713: pidgin crashes when trying to configure guifications plugin

[Иван Фарленков]

Package: pidgin-guifications
Version: 2.16-2+b3

When trying to configure module guifications that was downloaded from debian 
repository pidgin (Pidgin 2.14.12 (libpurple 2.14.12)) crahses.
I have attached result of command "pidgin -dn >pidgindebug"

I am using debian testing and my lang is ru_RU.UTF-8.
Kernel is  6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) 
x86_64 GNU/Linux
libc6 is 2.37-15(15:19:52) prefs: Reading /home/ivan/.purple/prefs.xml
(15:19:52) prefs: Finished reading /home/ivan/.purple/prefs.xml
(15:19:52) prefs: Unable to find rename pref for /core/plugins
(15:19:52) prefs: Renaming /core to /purple
(15:19:52) prefs: removing pref /core/plugins/core-plugin_pack-google/domain
(15:19:52) prefs: removing pref /core/plugins/core-plugin_pack-google
(15:19:52) prefs: removing pref /core/plugins
(15:19:52) prefs: removing pref /core
(15:19:52) prefs: purple_prefs_get_path: Unknown pref /pidgin/browsers/command
(15:19:52) dbus: okkk
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/transparency.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/gestures.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/timestamp_format.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/pidginrc.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/xmppdisco.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/iconaway.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/notify.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/ticker.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/convcolors.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/sendbutton.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/xmppconsole.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/timestamp.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/history.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/spellchk.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/libpidgin_pp.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/themeedit.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/cap.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/gtkbuddynote.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/vvconfig.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/musicmessaging.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/extplacement.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/pidgin/markerline.so
(15:19:52) plugins: probing /usr/lib/pidgin/album.so
(15:19:52) plugins: probing /usr/lib/pidgin/sepandtab.so
(15:19:52) plugins: probing /usr/lib/pidgin/switchspell.so
(15:19:52) plugins: probing /usr/lib/pidgin/plonkers.so
(15:19:52) plugins: probing /usr/lib/pidgin/blistops.so
(15:19:52) plugins: probing /usr/lib/pidgin/mystatusbox.so
(15:19:52) plugins: probing /usr/lib/pidgin/irssi.so
(15:19:52) plugins: probing /usr/lib/pidgin/gRIM.so
(15:19:52) plugins: probing /usr/lib/pidgin/lastseen.so
(15:19:52) plugins: probing /usr/lib/pidgin/difftopic.so
(15:19:52) plugins: probing /usr/lib/pidgin/enhancedhist.so
(15:19:52) plugins: probing /usr/lib/pidgin/timelog.so
(15:19:52) plugins: probing /usr/lib/pidgin/listlog.so
(15:19:52) plugins: probing /usr/lib/pidgin/convbadger.so
(15:19:52) plugins: probing /usr/lib/pidgin/schedule.so
(15:19:52) plugins: probing /usr/lib/pidgin/icon-override.so
(15:19:52) plugins: probing /usr/lib/pidgin/guifications.so
(15:19:52) plugins: probing /usr/lib/pidgin/nicksaid.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libirc.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/tcl.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libbonjour.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libsimple.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/buddynote.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/psychic.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libnovell.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/log_reader.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/nss-prefs.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/ssl.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libzephyr.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/offlinemsg.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/dbus-example.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/perl.so
(15:19:52) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so
(15:19:52) plugins: /usr/lib/x86_64-linux-gnu/purple-2/libjabber.so is not 
usable because the 'purple_init_plugin' symbol could not be found.  Does the 
plugin call the PURPLE_INIT_PLUGIN() macro?
(15:19:52) plugins: probing 

Bug#1069236: openssh-server: X over ssh fails with "cannot open display"

[Jonathan Dowland]

On Thu, Apr 18, 2024 at 06:33:00AM -0500, allan wrote:
> Resolved the issue by editing /etc/ssh/sshd_config and changing
> #AddressFamily any
> to
> AddressFamily inet

This is not a reasonable change to make to the default configuration,
because it would mean that ssh did not work out of the box in IPv6
environments.

On Thu, Apr 18, 2024 at 07:53:52AM -0500, allan wrote:
> More info - IPv6 is disabled on all four machines.  I think
> "AddressFamily any" should have supported an IPv4 connection.

*How* is it disabled? More information will be needed to figure out
exactly what's gone on in your environment.

I speculate that the hostnames you were trying to connect to were
resolving as IPv6 addresses, and the connection failing because the
hosts are rejecting IPv6 traffic. If that's right, the ultimate fix
is to correct whatever name resolution is giving you the wrong
addresses in your environment.

If you are prepared to experiment, we might be able to drill down and
check that. If so, can you

1) reverse the sshd_config change you made on at least one of the
   hosts, and restart that sshd

2) assuming the troublesome host is named "myhost" in your environment
   (substitute as appropriate), from your client machine, report the
   result of running

getent hosts myhost
dig +short myhost
nslookup myhost
ping -c 1 myhost

(one or more of these commands may not exist on your machine)

2) re-attempt to connect from your client, this time passing -vv or
   -vvv, and capture the logging output