Bug#1076533: src:dask.distributed: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: dask.distributed
Version: 2023.12.1+ds-4
Severity: serious
Control: close -1 2024.5.2+ds.1-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=dask.distributed



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076534: src:importlib-resources: fails to migrate to testing for too long: autopkgtest regression on s390x

[Paul Gevers]

Source: importlib-resources
Version: 6.0.1-1
Severity: serious
Control: close -1 6.4.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:importlib-resources has been trying to 
migrate for 31 days [2]. Hence, I am filing this bug. The version in 
unstable fails its own autopkgtest on s390x. Looking at the error, I'll 
note that s390x is the only big endian architecture that's supported by 
autopkgtest on ci.d.n.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=importlib-resources



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076535: src:node-websocket: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: node-websocket
Version: 1.0.34+~cs10.0.25-2
Severity: serious
Control: close -1 1.0.35+~cs11.0.28-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=node-websocket



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076536: wireshark: Please ignore tests on big-endian architectures in Debian Ports

[John Paul Adrian Glaubitz]

Source: wirkshark
Version: 4.2.6-1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello,

like on s390x, some tests are failing on powerpc, ppc64 and sparc64:

> https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=powerpc&ver=4.2.6-1&stamp=1720790838&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=ppc64&ver=4.2.6-1&stamp=1720785055&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=wireshark&arch=sparc64&ver=4.2.6-1&stamp=1720858739&raw=0

Could you ignore the tests on all big-endian architectures in Debian Ports?

These are:

- hppa
- m68k
- powerpc
- ppc64
- sparc64

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1076537: src:ucx: fails to migrate to testing for too long: unhandled architecture drop

[Paul Gevers]

Source: ucx
Version: 1.16.0+ds-5
Severity: serious
Control: close -1 1.17.0+ds-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: affects -1 src:openmpi

Dear maintainer(s),

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


When you drop support for an architecture, this isn't picked up 
automatically by dak (one might consider that a feature) and you need to 
file a removal bug manually. I was about to do that for you, but before 
that removal can be processed, all reverse (build) dependencies need to 
be resolved too (either also removed, requiring individual bugs) or by 
dropping their dependency. In this case, src:openmpi still builds 
libopenmpi3t64 with a Depends on libucx0 on ppc64el, but seeing that 
other architectures build successfully, the Build-Depends seems 
optional. If I didn't make a mistake, only src:openmpi is still blocking 
removal.


Given the history with 1.16.0 I guess you're not wanting to wait for 
upstream and I can understand that. But have you considered contacting 
the ppc64el porters? Please be aware of our rc-bug policy [3]:

"""
Packages must be supported on as many architectures as is *reasonably* 
possible.

"""
Emphasis in that quote is mine and a very important detail of that 
policy. I would hope everybody contacts porters before dropping an 
architecture. Porters commit themselves to help with architectures 
specific issues. If they don't, the release team wants to know because 
that's a strong reason to no longer support the architecture.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ucx
[3] https://release.debian.org/testing/rc_policy.txt

elbrus@coccia:~$ dak rm --no-action -RB -a ppc64el ucx
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libucx-dev | 1.16.0+ds-5 | ppc64el
   libucx0 | 1.16.0+ds-5 | ppc64el
 ucx-utils | 1.16.0+ds-5 | ppc64el

Maintainer: Debian Science Maintainers 



--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
openmpi: libopenmpi3t64

# Broken Build-Depends:
adios2: libucx-dev
mpich: libucx-dev
openmpi: libucx-dev
pmix: libucx-dev

Dependency problem found.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076491: base-files: file clash with libc6

[Oswald Buddenhagen]

On Wed, Jul 17, 2024 at 04:28:16PM +0200, Chris Hofstaedtler wrote:

in the meantime, please provide more details:

- full upgrade log


attached


- dpkg and apt versions used to upgrade


if i'm reading the log correctly, apt 2.7.6 and dpkg 1.22.1.


- sources.list and priorities
- selected/installed (foreign) architectures
- package versions before the upgrade


the relevant parts are in the original report.


Maybe date of the last full upgrade.


2023-11-07



history.log.1.gz
Description: application/gzip


term.log.1.gz
Description: application/gzip
2024-07-16 23:14:03 startup archives unpack
2024-07-16 23:14:04 upgrade libtirpc-common:all 1.3.3+ds-1 1.3.4+ds-1.3
2024-07-16 23:14:04 status half-configured libtirpc-common:all 1.3.3+ds-1
2024-07-16 23:14:04 status unpacked libtirpc-common:all 1.3.3+ds-1
2024-07-16 23:14:04 status half-installed libtirpc-common:all 1.3.3+ds-1
2024-07-16 23:14:05 status triggers-pending man-db:amd64 2.12.0-1
2024-07-16 23:14:05 status unpacked libtirpc-common:all 1.3.4+ds-1.3
2024-07-16 23:14:06 upgrade kbd:amd64 2.5.1-1+b1 2.6.4-2
2024-07-16 23:14:06 status half-configured kbd:amd64 2.5.1-1+b1
2024-07-16 23:14:06 status unpacked kbd:amd64 2.5.1-1+b1
2024-07-16 23:14:06 status half-installed kbd:amd64 2.5.1-1+b1
2024-07-16 23:14:06 status triggers-pending doc-base:all 0.11.1
2024-07-16 23:14:07 status unpacked kbd:amd64 2.6.4-2
2024-07-16 23:14:08 upgrade texinfo-lib:amd64 7.1-1 7.1-3+b1
2024-07-16 23:14:08 status half-configured texinfo-lib:amd64 7.1-1
2024-07-16 23:14:08 status unpacked texinfo-lib:amd64 7.1-1
2024-07-16 23:14:08 status half-installed texinfo-lib:amd64 7.1-1
2024-07-16 23:14:08 status unpacked texinfo-lib:amd64 7.1-3+b1
2024-07-16 23:14:09 upgrade zlib1g-dev:amd64 1:1.2.13.dfsg-3 
1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:09 status half-configured zlib1g-dev:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:09 status unpacked zlib1g-dev:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:09 status half-installed zlib1g-dev:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:09 status unpacked zlib1g-dev:amd64 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:10 upgrade zlib1g:amd64 1:1.2.13.dfsg-3 
1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:10 status triggers-pending libc-bin:amd64 2.37-12
2024-07-16 23:14:10 status half-configured zlib1g:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:10 status unpacked zlib1g:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:10 status half-installed zlib1g:amd64 1:1.2.13.dfsg-3
2024-07-16 23:14:11 status unpacked zlib1g:amd64 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:11 install zlib1g:i386  1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:11 status half-installed zlib1g:i386 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:11 status unpacked zlib1g:i386 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:12 startup packages configure
2024-07-16 23:14:12 configure zlib1g:amd64 1:1.3.dfsg+really1.3.1-1 
2024-07-16 23:14:12 status unpacked zlib1g:amd64 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:12 status half-configured zlib1g:amd64 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:12 status installed zlib1g:amd64 1:1.3.dfsg+really1.3.1-1
2024-07-16 23:14:13 startup archives unpack
2024-07-16 23:14:13 upgrade libnsl-dev:amd64 1.3.0-3 1.3.0-3+b2
2024-07-16 23:14:13 status half-configured libnsl-dev:amd64 1.3.0-3
2024-07-16 23:14:13 status unpacked libnsl-dev:amd64 1.3.0-3
2024-07-16 23:14:13 status half-installed libnsl-dev:amd64 1.3.0-3
2024-07-16 23:14:14 status unpacked libnsl-dev:amd64 1.3.0-3+b2
2024-07-16 23:14:15 upgrade libcrypt-dev:amd64 1:4.4.36-2 1:4.4.36-4
2024-07-16 23:14:15 status half-configured libcrypt-dev:amd64 1:4.4.36-2
2024-07-16 23:14:15 status unpacked libcrypt-dev:amd64 1:4.4.36-2
2024-07-16 23:14:15 status half-installed libcrypt-dev:amd64 1:4.4.36-2
2024-07-16 23:14:15 status unpacked libcrypt-dev:amd64 1:4.4.36-4
2024-07-16 23:14:16 upgrade libc6-dev:amd64 2.37-12 2.39-4
2024-07-16 23:14:16 status half-configured libc6-dev:amd64 2.37-12
2024-07-16 23:14:16 status unpacked libc6-dev:amd64 2.37-12
2024-07-16 23:14:16 status half-installed libc6-dev:amd64 2.37-12
2024-07-16 23:14:18 status unpacked libc6-dev:amd64 2.39-4
2024-07-16 23:14:18 upgrade libc-dev-bin:amd64 2.37-12 2.39-4
2024-07-16 23:14:18 status half-configured libc-dev-bin:amd64 2.37-12
2024-07-16 23:14:18 status unpacked libc-dev-bin:amd64 2.37-12
2024-07-16 23:14:18 status half-installed libc-dev-bin:amd64 2.37-12
2024-07-16 23:14:19 status unpacked libc-dev-bin:amd64 2.39-4
2024-07-16 23:14:19 upgrade libnss-nisplus:i386 1.3-4 1.3-5+b1
2024-07-16 23:14:19 status half-configured libnss-nisplus:i386 1.3-4
2024-07-16 23:14:19 status unpacked libnss-nisplus:i386 1.3-4
2024-07-16 23:14:19 status half-configured libnss-nisplus:amd64 1.3-4
2024-07-16 23:14:19 status half-installed libnss-nisplus:i386 1.3-4
2024-07-16 23:14:20 status unpacked libnss-nisplus:i386 1.3-5+b1
2024-07-16 23:14:20 upgrade libnss-nisplus:amd64 1.3-4 1.3-5+b1
2024-07-16 23:14:20 status unpacked libnss-nisplus:amd64 1.3-4
2024-07-16 23:14:20 status half-instal

Bug#1076538: centreon-plugins: Synology check reports failing disk as OK

[Adam Cecile]

Package: centreon-plugins
Version: 0.0~20230118-1
Severity: important
Tags: patch upstream

Hello,

Current check for Synology is quite broken as it reports failing disks as OK,
due to a typo in code.

Upstream fix is here: https://github.com/centreon/centreon-plugins/pull/4750

I updated manually the Debian package to version 20240711 and it worked
flawlessly, so I guess it is the way to go.

Best regards, Adam.


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

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

Versions of packages centreon-plugins depends on:
ii  libjs-sphinxdoc  5.3.0-4
ii  perl 5.36.0-7+deb12u1

Versions of packages centreon-plugins recommends:
pn  libdbd-mysql-perl   
pn  libdbd-pg-perl  
ii  libdbi-perl 1.643-4
ii  libjson-perl4.1-1
pn  libmemcached-libmemcached-perl  
pn  libnet-dns-perl 
pn  libnet-ntp-perl 
pn  libnet-telnet-perl  
ii  libsnmp-perl5.9.3+dfsg-2
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
pn  libxml-xpath-perl   

centreon-plugins suggests no packages.

Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"

[Bastian Venthur]

Package: plymouth
Version: 24.004.60-2
Severity: important
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

trying to update plymouth fails with "No space left on device":

sudo aptitude -u
Performing actions...
Setting up initramfs-tools (0.142) ...
update-initramfs: deferring update (trigger activated)
Setting up plymouth (24.004.60-2) ...
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_cap.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_14_0_3_sos.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_14_0_2_sos.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_toc.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes1.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for 
module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vcn_5_0_0.bin for module 
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/smu_14_0_2.bin for module 
amdgpu
zstd: error 70 : Write error : cannot write block : No space left on device 
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
dpkg: error processing package plymouth (--configure):
 installed plymouth package post-installation script subprocess returned error 
exit status 1
dpkg: dependency problems prevent configuration of plymouth-label:
 plymouth-label depends on plymouth (= 24.004.60-2); however:
  Package plymouth is not configured yet.


/boot still has 170MB free:

# df -h /boot
Filesystem  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  471M  275M  172M  62% /boot

# du -h /boot
12K ./lost+found
4,0K./efi/EFI/debian/fw
4,5M./efi/EFI/debian
4,5M./efi/EFI
4,5M./efi
5,1M./grub/locale
2,4M./grub/fonts
3,2M./grub/x86_64-efi
13M ./grub
279M.


# ls -lh /boot
total 262M
-rw-r--r-- 1 root root 270K 13. Jul 17:45 config-6.9.9-amd64
drwx-- 3 root root 4,0K  1. Jan 1970  efi
drwxr-xr-x 5 root root 1,0K 16. Jul 08:37 grub
-rw-r--r-- 1 root root 251M 16. Jul 12:47 initrd.img-6.9.9-amd64
drwx-- 2 root root  12K 26. Jan 2021  lost+found
-rw-r--r-- 1 root root   83 13. Jul 17:45 System.map-6.9.9-amd64
-rw-r--r-- 1 root root 9,2M 13. Jul 17:45 vmlinuz-6.9.9-amd64


Cheers,

Bastian


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

Kernel: Linux 6.9.9-amd64 (SMP w/16 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 plymouth depends on:
ii  init-system-helpers  1.66
ih  initramfs-tools  0.142
ii  libc62.39-4
ii  libdrm2  2.4.121-2
ii  libplymouth5 24.004.60-2
ii  systemd  256.2-1
ii  udev 256.2-1

plymouth recommends no packages.

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

-- no debconf information

Bug#1076532: weechat: Crash when exiting app

[Sébastien Helleu]

On Thu, Jul 18, 2024 at 08:54:52AM +0200, Laurent Cheylus wrote:
> Package: weechat
> Version: 4.3.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> when leaving weechat (version 4.3.1 on testing/trixie, arch amd64) via "/quit"
> command, I have a backtrace of a crash:
> 
> === WeeChat backtrace ===
> (written by WeeChat 4.3.1, compiled on Jun 24 2024 20:17:40)
> 001  ??:0 [function ??]
> 002  ??:0 [function ??]
> 003  libc_sigaction.c:? [function __restore_rt]
> addr2line: '0x31a4c1': No such file
> addr2line: '0x1d73e0': No such file
> addr2line: '0x1d695d': No such file
> addr2line: '0x1c8b50': No such file
> addr2line: '0x1d878c': No such file
> addr2line: '0x2e4ece': No such file
> addr2line: '0x2e8a48': No such file
> addr2line: '0xbe6b': No such file
> addr2line: '0xbf2d': No such file
> addr2line: '0x2e640': No such file
> addr2line: '0xd585': No such file
> 015  ??:0 [function ??]
> 016  ??:0 [function ??]
> 017  ??:0 [function ??]
> 018  ??:0 [function ??]
> 019  ??:0 [function ??]
> 020  ./csu/../sysdeps/nptl/libc_start_call_main.h:74 [function 
> __libc_start_call_main]
> 021  ./csu/../csu/libc-start.c:128 [function call_init]
> 022  ??:0 [function ??]
> === End of  backtrace ===
> Aborted
> 
> 
> regards, Laurent
> 

Hi,

I'm not sure as the backtrace is incomplete, but if you're using Python 3.12
and you have some Python scripts loaded, this is a known issue, which is in
Python 3.12 and not in WeeChat itself.

But a workaround has been implemented in version 4.3.4 (see issues:
https://github.com/weechat/weechat/issues/2046 for the workaround and
https://github.com/python/cpython/issues/116510 for the upstream issue).

Emmanuel, could you please upload the latest version (4.3.5), which should
hopefully fix this crash?

Thanks.

-- 
Sébastien Helleu

web: weechat.org / flashtux.org
irc: FlashCode @ irc.libera.chat

Bug#1037346: How to prevent this bug

[Vladislav Kurz]

Hello,

I also got hit by this bug - old mailboxes were still in the place, but 
new empty mailboxes started to appear in uuid folders. And mailboxes.db 
got corrupted/erased.


The easy way is to add to /etc/imapd.conf

mailbox_legacy_dirs: yes

BEFORE starting the upgrade. See:
https://www.cyrusimap.org/3.6/imap/download/upgrade.html#storage-changes

So the easy way would be to add this information to NEWS.Debian.gz

More complicated (but more secure) way, would be to add this option 
automatically if upgrading from version < 3.6.0



--
Best regards
Vladislav Kurz

Bug#1076540: virt-install: --cloud-init option is ignored when used in conjunction with --location

[Olivier Gayot]

Package: virt-manager
Version: 1:4.1.0-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

When running virt-install with both --location and --cloud-init options,
the latter is silently ignored. Although the --cloud-init option is
properly honored when used with --cdrom instead of --location ; but
--cdrom is incompatible with --extra-args ; which is useful as well.

There is an upstream bug report [1] with an open PR [2]. I have added
the patch from the PR as a quilt patch (refreshed) in the attached
debdiff.

[1] https://github.com/virt-manager/virt-manager/issues/469
[2] https://github.com/virt-manager/virt-manager/pull/485

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/virtinstall-Fix-location-and-cloud-init-conflict.patch: do not ignore
virt-install's --cloud-init option when used in conjunction with
--location. (LP: #2073461)

Thanks for considering the patch.


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

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

Versions of packages virt-manager is related to:
ii  libvirt-clients  10.0.0-2ubuntu8.2
ii  libvirt-daemon   10.0.0-2ubuntu8.2
ii  libvirt0 10.0.0-2ubuntu8.2
ii  osinfo-db0.20240523-0ubuntu0.24.04.1
diff -Nru virt-manager-4.1.0/debian/patches/series 
virt-manager-4.1.0/debian/patches/series
--- virt-manager-4.1.0/debian/patches/series2024-05-09 09:45:01.0 
+0200
+++ virt-manager-4.1.0/debian/patches/series2024-07-18 09:54:44.0 
+0200
@@ -3,3 +3,4 @@
 upstream_tests-Fix-host-copy-XML-with-libvirt-10.1.0.patch
 upstream_build-use-super.patch
 upstream_build-use-setuptools.command.build-when-available.patch
+virtinstall-Fix-location-and-cloud-init-conflict.patch
diff -Nru 
virt-manager-4.1.0/debian/patches/virtinstall-Fix-location-and-cloud-init-conflict.patch
 
virt-manager-4.1.0/debian/patches/virtinstall-Fix-location-and-cloud-init-conflict.patch
--- 
virt-manager-4.1.0/debian/patches/virtinstall-Fix-location-and-cloud-init-conflict.patch
1970-01-01 01:00:00.0 +0100
+++ 
virt-manager-4.1.0/debian/patches/virtinstall-Fix-location-and-cloud-init-conflict.patch
2024-07-18 09:54:44.0 +0200
@@ -0,0 +1,208 @@
+Description: virtinstall: Fix --location and --cloud-init conflict
+ So far, --cloud-init is ignored when --location is specified.
+ .
+ Resolves: virt-manager#469
+Author: Patrice Lacouture 
+Origin: upstream, https://github.com/virt-manager/virt-manager/pull/485
+Bug: https://github.com/virt-manager/virt-manager/issues/469
+Bug-Ubuntu: https://launchpad.net/bugs/2073461
+Applied-Upstream: no
+Last-Update: 2024-07-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- /dev/null
 b/tests/data/cli/compare/virt-install-location-iso-and-cloud-init.xml
+@@ -0,0 +1,172 @@
++
++  fedora17
++  ----
++  
++http://libosinfo.org/xmlns/libvirt/domain/1.0";>
++  http://fedoraproject.org/fedora/17"/>
++
++  
++  65536
++  65536
++  2
++  
++hvm
++/VIRTINST-TESTSUITE/vmlinuz
++/VIRTINST-TESTSUITE/initrd.img
++
++  
++  
++
++
++
++  
++  
++  
++
++
++
++  
++  
++
++
++  
++  
++/usr/bin/qemu-system-x86_64
++
++  
++  
++  
++
++
++  
++  
++  
++  
++
++
++
++  
++
++
++  
++
++
++  
++
++
++
++  
++  
++
++
++  
++
++
++
++  
++
++
++
++  
++
++
++
++
++
++  /dev/urandom
++
++
++  
++  
++  
++  
++
++  
++  
++
++  ds=nocloud
++
++  
++  destroy
++
++
++  fedora17
++  ----
++  
++http://libosinfo.org/xmlns/libvirt/domain/1.0";>
++  http://fedoraproject.org/fedora/17"/>
++
++  
++  65536
++  65536
++  2
++  
++hvm
++
++  
++  
++
++
++
++  
++  
++  
++
++
++
++  
++  
++
++
++  
++  
++/usr/bin/qemu-system-x86_64
++
++  
++  
++  
++
++
++  
++  
++  
++  
++
++
++
++  
++
++
++  
++
++
++  
++
++
++
++  
++  
++
++
++  
++
++
++
++  
++
++
++
++  
++
++
++
++
++
++  /dev/urandom
++
++
++  
++  
++
++  
++
+--- a/tests/test_cli.py
 

Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"

[Laurent Bigonville]

reassign 1076539 firmware-misc-nonfree 20240610-1
severity 1076539 serious
affects 1076539 + plymouth
thanks

Le 18/07/24 à 09:43, Bastian Venthur a écrit :

Dear Maintainer,

trying to update plymouth fails with "No space left on device":


Hello, I also had the problem this morning, but it's not related to 
plymouth.


It's related to firmware-misc-nonfree that is now pulling 
firmware-nvidia-graphics that contains a lot of (non-free) firmwares.


With firmware-nvidia-graphics installed, my initramfs grows to something 
like 200M compared to 64M without it.


I'm reassigning this to firmware-misc-nonfree

Kind regards,

Laurent Bigonville

Bug#1076541: orthanc-wsi: autopkgtest failures (binNMU needed)

[Gianfranco Costamagna]

Source: orthanc-wsi
Version: 2.0+dfsg-3
Severity: serious


Hello, looks like orthanc-wsi detects the path of the dicom dictionary at build 
time.

So, it needs to be tied to a specific libdcmtk library, and needs a binNMU 
every time dcmtk changes version.


 43s autopkgtest [14:07:35]: test run-dicom-image-transcode-test: 
[---
293
 43s User 'orthanc' exists.
294
 43s Starting orthanc (via systemctl): orthanc.service.
295
 43s Orthanc is active.
296
 43s W0717 14:07:35.290296 88465020 FromDcmtkBridge.cpp:383] Loading external 
DICOM dictionary: "/usr/share/libdcmtk17/dicom.dic"
297
 43s E: DcmDataDictionary: Cannot open file: /usr/share/libdcmtk17/dicom.dic
298
 43s terminate called after throwing an instance of 'Orthanc::OrthancException'
299
 43s 
/tmp/autopkgtest-lxc.o3sgzx4o/downtmp/build.fsM/src/debian/tests/run-dicom-image-transcode-test:
 line 38:  2311 Aborted OrthancWSIDicomizer 
CMU-1-Small-Region.tiff --orthanc=$orthanc_server
300


https://ci.debian.net/packages/o/orthanc-wsi/testing/arm64/49182297/

The failure happens only when the package was built with an older dcmtk


G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076542: nodejs: autopkgtest failures

[Gianfranco Costamagna]

Source: nodejs
Version: 20.15.1+dfsg-1
Severity: serious

Hello, two tests are now failing:
https://ci.debian.net/packages/n/nodejs/testing/amd64/49188413/

 45s not ok 253 parallel/test-cli-permission-multiple-allow
 45s   ---
 45s   duration_ms: 715.29500
 45s   severity: fail
 45s   exitcode: 1
 45s   stack: |-
 45s node:assert:126
 45s   throw new AssertionError(obj);
 45s   ^
 45s
 45s AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
 45s + actual - expected
 45s
 45s + 'true'
 45s - 'false'
 45s at Object. 
(/tmp/autopkgtest-lxc.voqp2vqz/downtmp/build.4lW/src/test/parallel/test-cli-permission-multiple-allow.js:27:10)
 45s at Module._compile (node:internal/modules/cjs/loader:1358:14)
 45s at Module._extensions..js 
(node:internal/modules/cjs/loader:1416:10)
 45s at Module.load (node:internal/modules/cjs/loader:1208:32)
 45s at Module._load (node:internal/modules/cjs/loader:1024:12)
 45s at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:174:12)
 45s at node:internal/main/run_main_module:28:49 {
 45s   generatedMessage: true,
 45s   code: 'ERR_ASSERTION',
 45s   actual: 'true',
 45s   expected: 'false',
 45s   operator: 'strictEqual'
 45s }
 45s

 46s not ok 261 parallel/test-cli-permission-deny-fs
 46s   ---
 46s   duration_ms: 911.79900
 46s   severity: fail
 46s   exitcode: 1
 46s   stack: |-
 46s node:assert:126
 46s   throw new AssertionError(obj);
 46s   ^
 46s
 46s AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
 46s + actual - expected
 46s
 46s + 'true'
 46s - 'false'
 46s at Object. 
(/tmp/autopkgtest-lxc.voqp2vqz/downtmp/build.4lW/src/test/parallel/test-cli-permission-deny-fs.js:45:10)
 46s at Module._compile (node:internal/modules/cjs/loader:1358:14)
 46s at Module._extensions..js 
(node:internal/modules/cjs/loader:1416:10)
 46s at Module.load (node:internal/modules/cjs/loader:1208:32)
 46s at Module._load (node:internal/modules/cjs/loader:1024:12)
 46s at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:174:12)
 46s at node:internal/main/run_main_module:28:49 {
 46s   generatedMessage: true,
 46s   code: 'ERR_ASSERTION',
 46s   actual: 'true',
 46s   expected: 'false',
 46s   operator: 'strictEqual'
 46s }
 46s
 46s Node.js v20.15.1
 46s   ...


Not sure what happened

Also, please add strace to test dependencies to also run strace tests
 68s ok 2483 parallel/test-strace-openat-openssl # skip missing strace

Note: to make it work you probably need the following patches:

diff -Nru 
nodejs-20.15.1+dfsg/debian/patches/ubuntu-openssl-fix-strace-openat-test.patch 
nodejs-20.15.1+dfsg/debian/patches/ubuntu-openssl-fix-strace-openat-test.patch
--- 
nodejs-20.15.1+dfsg/debian/patches/ubuntu-openssl-fix-strace-openat-test.patch  
1970-01-01 00:00:00.0 +
+++ 
nodejs-20.15.1+dfsg/debian/patches/ubuntu-openssl-fix-strace-openat-test.patch  
2024-06-28 12:25:37.0 +
@@ -0,0 +1,36 @@
Index: nodejs-20.13.1+dfsg/test/parallel/test-strace-openat-openssl.js
===
--- nodejs-20.13.1+dfsg.orig/test/parallel/test-strace-openat-openssl.js
+++ nodejs-20.13.1+dfsg/test/parallel/test-strace-openat-openssl.js
@@ -5,6 +5,7 @@ const { spawn, spawnSync } = require('no
 const { createInterface } = require('node:readline');
 const assert = require('node:assert');
 
+process.env.OPENSSL_CONF="/usr/lib/ssl/openssl.cnf"

 if (!common.hasCrypto)
   common.skip('missing crypto');
 if (!common.isLinux)
@@ -17,7 +18,7 @@ if (spawnSync('strace').error !== undefi
 
 {

   const allowedOpenCalls = new Set([
-'/etc/ssl/openssl.cnf',
+'/usr/lib/ssl/openssl.cnf',
   ]);
   const strace = spawn('strace', [
 '-f', '-ff',
@@ -42,6 +43,14 @@ if (spawnSync('strace').error !== undefi
 if (file.match(/\/proc\/.+/) !== null) {
   return;
 }
+// skip zoneinfo
+if (file.match(/zoneinfo64.res/) !== null) {
+  return;
+}
+// skip /dev/z90crypt, new in openssl 3.2*
+if (file.match(/z90crypt/) !== null) {
+  return;
+}
 
 assert(allowedOpenCalls.delete(file), `${file} is not in the list of allowed openat calls`);

   });

diff -Nru nodejs-20.15.1+dfsg/debian/tests/control 
nodejs-20.15.1+dfsg/debian/tests/control
--- nodejs-20.15.1+dfsg/debian/tests/control2024-07-09 08:02:04.0 
+
+++ nodejs-20.15.1+dfsg/debian/tests/control2024-07-09 21:53:29.0 
+
@@ -1,2 +1,2 @@
 Test-Command: ./debian/rules override_dh_auto_test-arch
-Depends: @, ca-certificates, python3, procps, curl, build-essential
+Depends: @, ca-certificates, python3, procps, curl, build-essential, 
tzdata-icu, strace


thanks,

Gianfranco


OpenPGP_signature.asc
Description: OpenPGP digital

Bug#1073289: Bug#1073983: transition: ocaml

[Stéphane Glondu]

Hi,

Le 17/07/2024 à 21:56, Adrian Bunk a écrit :

Other than that, I'm happy with the current state and we could go ahead. So
if you can get those bindings disabled, then I think we can go ahead.


I tried looking at that, but this "ideally" is in level 15 of the ocaml
transition.

The bindings are already enabled only on some architectures, uploads to
disable them everywhere are trivial while it's a pain to test any changes
without the first 14 levels of the transition.


I've made a repository with all packages compiled with OCaml 5.2.0:

  http://ocaml.debian.net/transitions/ocaml-5.2.0/

You can use it to test your changes.


It would really be much easier to have the binNMUs scheduled and then
fix LLVM.


Do I have a go from the Release Team to upload OCaml 5.2.0 to unstable? 
As usual, I will take care of the binNMUs.



Cheers,

--
Stéphane

Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"

[Diederik de Haas]

Control: severity -1 minor

On 18 Jul 2024 09:43:38 +0200 Bastian Venthur  wrote:
> Package: plymouth
> Version: 24.004.60-2
> Severity: important
> X-Debbugs-Cc: vent...@debian.org
> 
> Dear Maintainer,
> 
> trying to update plymouth fails with "No space left on device":
> 
> sudo aptitude -u
> Performing actions...
> Setting up initramfs-tools (0.142) ...
> update-initramfs: deferring update (trigger activated)
> Setting up plymouth (24.004.60-2) ...
> update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
> ...
> W: Possible missing firmware /lib/firmware/amdgpu/smu_14_0_2.bin for module 
> amdgpu
> zstd: error 70 : Write error : cannot write block : No space left on device 
> E: mkinitramfs failure zstd -q -9 -T0 70
> update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
> dpkg: error processing package plymouth (--configure):
>  installed plymouth package post-installation script subprocess returned 
> error exit status 1
> dpkg: dependency problems prevent configuration of plymouth-label:
>  plymouth-label depends on plymouth (= 24.004.60-2); however:
>   Package plymouth is not configured yet.
> 
> 
> /boot still has 170MB free:
> 
> # df -h /boot
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/nvme0n1p2  471M  275M  172M  62% /boot

I fail to see how this is any package's problem.
Your boot partition is too small to perform the requested operation.

During compression it needs the space for the uncompressed files and
the space needed for the compressed archive, so it generally needs
(much) more space then it finally needs as the uncompressed files will
be removed again once the compressed archive is complete.

Solution: make your boot partition larger. Or remove older/other
kernels, but IMO this will only delay the inevitable.

Reducing severity to minor, but I actually think it should just be closed.

On 18 Jul 2024 10:17:20 +0200 Laurent Bigonville  wrote:
> It's related to firmware-misc-nonfree that is now pulling 
> firmware-nvidia-graphics that contains a lot of (non-free) firmwares.
> 
> With firmware-nvidia-graphics installed, my initramfs grows to something 
> like 200M compared to 64M without it.

The firmware-nvidia-graphics package was created exactly because its size
got big(ger) and (partially therefor) deserved its own package instead of
making the firmware-misc-nonfree extremely large. That package is meant
for 'the other' firmware which don't deserve their own package.
The firmware-nvidia-graphics is recommended by firmware-misc-nonfree as
the nvidia graphics firmware files were moved from the latter to the former.

Solution: If you don't need firmware-nvidia-graphics, don't install it.
If you do need it, but don't have the space for it, then increase your
storage size.

> I'm reassigning this to firmware-misc-nonfree

As said above, this is IMO not any package's problem.

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

Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"

[Laurent Bigonville]

Le 18/07/24 à 10:54, Diederik de Haas a écrit :

Control: severity -1 minor

[...]
I fail to see how this is any package's problem.
Your boot partition is too small to perform the requested operation.

During compression it needs the space for the uncompressed files and
the space needed for the compressed archive, so it generally needs
(much) more space then it finally needs as the uncompressed files will
be removed again once the compressed archive is complete.

Solution: make your boot partition larger. Or remove older/other
kernels, but IMO this will only delay the inevitable.

Reducing severity to minor, but I actually think it should just be closed.

On 18 Jul 2024 10:17:20 +0200 Laurent Bigonville  wrote:

It's related to firmware-misc-nonfree that is now pulling
firmware-nvidia-graphics that contains a lot of (non-free) firmwares.

With firmware-nvidia-graphics installed, my initramfs grows to something
like 200M compared to 64M without it.

The firmware-nvidia-graphics package was created exactly because its size
got big(ger) and (partially therefor) deserved its own package instead of
making the firmware-misc-nonfree extremely large. That package is meant
for 'the other' firmware which don't deserve their own package.
The firmware-nvidia-graphics is recommended by firmware-misc-nonfree as
the nvidia graphics firmware files were moved from the latter to the former.

Solution: If you don't need firmware-nvidia-graphics, don't install it.
If you do need it, but don't have the space for it, then increase your
storage size.


Well you change expectation from users that have firmware-misc-nonfree 
installed by pulling that huge package


IMVHO, a lot of people with firmware-misc-nonfree installed will 
experience an issue when updating.


The /boot partition size I've here is the default one from the 
debian-installer

Bug#1075858: mesa-vulkan-drivers > 24.1 should include NVK driver on amd64

[Paul Cercueil]

I'd love to see NVK packaged in Debian too. Patiently waiting for it.

Cheers,
-Paul

Bug#1076543: RM: librm -- RoQA; RC-buggy; end-of-life

[Bastian Germann]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:librm
Control: block -1 by 1070701

Please remove librm. It is end-of-life and no longer needed when roger-router 
is removed.

Bug#894906: linux-cpupower: provide a systemd service and a default config file

[jim_p]

Package: linux-cpupower
Version: 6.9.8-1
Followup-For: Bug #894906
X-Debbugs-Cc: pitsior...@outlook.com

Hello everyone and thank you for your great work. I am a former user of the
obsolete cpufrequtils and of the unmaintained (by debian) cpupower-gui. I was
using those tools until 2021 to set my governor to powersave the summmer
months. Then I discovered linux-cpupower, which I used by running "cpupower
frequency-set -g powersave" on every boot.

I was also annoyed by the lack of a systemd service and a config file in
debian, until I tried the attached files here. I am having the following issue.
The service sometimes fails to start on boot. I added the -x parameter and
removed the "> /dev/null || ESTATUS=1" from line 20 of /usr/libexec/cpupower so
as to get a better error output, but all I get is this

$ sudo journalctl -b -u cpupower.service
Jul 14 19:50:41 pc systemd[1]: Starting cpupower.service - Apply cpupower
configuration...
Jul 14 19:50:41 pc cpupower[337]: + ESTATUS=0
Jul 14 19:50:41 pc cpupower[337]: + test  !=
Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave
Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave
Jul 14 19:50:41 pc cpupower[337]: + test  -g powersave !=
Jul 14 19:50:41 pc cpupower[337]: + cpupower frequency-set -g powersave
Jul 14 19:50:41 pc cpupower[343]: Setting cpu: 0
Jul 14 19:50:41 pc cpupower[343]: Error setting new values. Common errors:
Jul 14 19:50:41 pc cpupower[343]: - Do you have proper administration rights?
(super-user?)
Jul 14 19:50:41 pc cpupower[343]: - Is the governor you requested available and
modprobed?
Jul 14 19:50:41 pc cpupower[343]: - Trying to set an invalid policy?
Jul 14 19:50:41 pc cpupower[343]: - Trying to set a specific frequency, but
userspace governor is not available,
Jul 14 19:50:41 pc cpupower[343]:for example because of hardware which
cannot be set to a specific frequency
Jul 14 19:50:41 pc cpupower[343]:or because the userspace governor isn't
loaded?
Jul 14 19:50:41 pc cpupower[337]: + PARS=
Jul 14 19:50:41 pc cpupower[337]: + test  !=
Jul 14 19:50:41 pc cpupower[337]: + exit 0
Jul 14 19:50:41 pc systemd[1]: Finished cpupower.service - Apply cpupower
configuration.

Any ideas?


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

Kernel: Linux 6.9.8-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 linux-cpupower depends on:
ii  libc6 2.38-14
ii  libcap2   1:2.66-5
ii  libcpupower1  6.9.8-1
ii  libpci3   1:3.13.0-1

linux-cpupower recommends no packages.

linux-cpupower suggests no packages.

-- no debconf information

Bug#1076539: plymouth: Updating plymouth fails with "No space left on device"

[Diederik de Haas]

On Thursday, 18 July 2024 11:11:23 CEST Laurent Bigonville wrote:
> Well you change expectation from users that have firmware-misc-nonfree
> installed by pulling that huge package

I fail to see how. If those files weren't split into their own packages, the 
updated/new firmware-misc-nonfree would've contained the firmware of
the 'old' misc-nonfree + nvidia-graphics + intel-graphics + mediatek/ralink + 
new files that would otherwise have been added for misc-nonfree.

See also https://bugs.debian.org/1057786

> IMVHO, a lot of people with firmware-misc-nonfree installed will
> experience an issue when updating.

You should've seen a NEWS entry informing you of the changes.
If that didn't happen, that's a problem/bug.

On donderdag 18 juli 2024 11:14:35 CEST you wrote:
> On 18.07.24 11:11, Laurent Bigonville wrote:
> > The /boot partition size I've here is the default one from the
> > debian-installer
> 
> This seems to be the core of the problem. In my case it is 500MB, and
> was the default from the install. So many users will be affected by default.

I do agree with that. And the kernel size growing bigger contributed to that 
becoming a (bigger) problem. (There are bug reports about that)

When I set up my system, I made /boot 2G because I foresaw this problem
(and I intended to do a bit more with kernels then the average user).

I think a very valid argument can be made to change the default in d-i,
but to be blunt: you *accepted* the *defaults*.

But most people are probably not as experienced with Debian as the two of you 
which in turn would make me point out the same problem, but be more subtle/
gentle about it.

Still, "No space left on device" is not a packaging problem.

Cheers,
  Diederik

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

Bug#1076544: Built with wrong SSL lib, won't talk to iOS 5

[Adam Goldman]

Package: libimobiledevice6
Version: 1.3.0-6+b3

On Debian Bookworm, idevice* will communicate with an iOS 17 device, but 
not with an iOS 5 device.

When running usbmuxd in the foreground, it prints the following error 
when the iOS 5 device is plugged in:

[15:58:20.277][1] preflight_worker_handle_device_add: ERROR StartSession failed 
on device 6e8c5ae7c41b3fc71a6be705f1303343c7db53c6, lockdown error -5

>From that point, "idevice_id -l" produces no output, and ideviceinfo 
says "ERROR: No device found!".

Apparently this is because iOS 5 uses SSLv3 to encrypt communications 
over the USB cable, but OpenSSL has intentionally removed SSLv3 
interoperability.

I installed libgnutls28-dev and libgcrypt20-dev, downloaded the 
libimobiledevice source package, added --disable-openssl to 
configure_flags, and built the libimobiledevice6 package. After I 
installed the modified libimobiledevice6 package and restarted usbmuxd, 
it no longer printed an error when the iOS 5 device was plugged in, and 
I was able to back up the device with idevicebackup2. I also tested the 
modified libimobiledevice6 with an iOS 17 device, and I was able to see 
that device with idevice_id, mount it with ifuse and copy files from the 
camera roll.

I believe this is a regression that was introduced in 1.3.0-4 by 
changing from GnuTLS to OpenSSL. The corresponding 1.3.0-4 change should 
be reverted. To prevent this from happening again, a comment should be 
added to debian/rules above configure_flags, explaining why we build 
against GnuTLS instead of OpenSSL.

-- Adam

Bug#1076545: websockify: Make optional token plugins actually optional

[James Page]

Package: websockify
Version: 0.12.0+dfsg1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: james.p...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/control,d/p/optional-runtime-depends.patch:
Drop python3-{redis,jwcrypto} from Depends to Suggests as these
features are optional, patch setup.py to reflect this.

I've submitted this change to the upstream project as well.

I also dropped a duplicated dependency on python3-numpy -
python3-websockify depends on this already so no need to also do
it for websockify itself.

Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru websockify-0.12.0+dfsg1/debian/control 
websockify-0.12.0+dfsg1/debian/control
--- websockify-0.12.0+dfsg1/debian/control  2024-07-16 02:31:21.0 
+0100
+++ websockify-0.12.0+dfsg1/debian/control  2024-07-18 11:04:29.0 
+0100
@@ -60,12 +60,13 @@
 Package: websockify
 Architecture: any
 Depends:
- python3-jwcrypto,
- python3-numpy,
  python3-websockify (>= ${source:Version}),
  ${misc:Depends},
  ${python3:Depends},
  ${shlibs:Depends},
+Suggests:
+ python3-jwcrypto,
+ python3-redis,
 Description: WebSockets support for any application/server
  websockify was formerly named wsproxy and was part of the noVNC project.
  .
diff -Nru websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch 
websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch
--- websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch   
1970-01-01 01:00:00.0 +0100
+++ websockify-0.12.0+dfsg1/debian/patches/optional-runtime-depends.patch   
2024-07-18 10:47:28.0 +0100
@@ -0,0 +1,22 @@
+Description: Make optional depends optional
+ Redis and JWCryto are both optional dependencies;
+ update setuptools configuration to this effect.
+Author: James Page 
+Forwarded: https://github.com/novnc/websockify/pull/582
+
+--- a/setup.py
 b/setup.py
+@@ -31,9 +31,11 @@
+   include_package_data=True,
+   install_requires=[
+ 'numpy', 'requests',
+-'jwcrypto',
+-'redis',
+ ],
++  extras_requires={
++'redis': ['redis'],
++'jwt': ['jwcrypto'],
++},
+   zip_safe=False,
+   entry_points={
+ 'console_scripts': [
diff -Nru websockify-0.12.0+dfsg1/debian/patches/series 
websockify-0.12.0+dfsg1/debian/patches/series
--- websockify-0.12.0+dfsg1/debian/patches/series   2024-07-16 
02:31:21.0 +0100
+++ websockify-0.12.0+dfsg1/debian/patches/series   2024-07-18 
10:47:40.0 +0100
@@ -3,3 +3,4 @@
 remove-testing-RSA1_5-now-deprecated-in-jwcrypto.patch
 workaround-using-too-much-resource.patch
 py3.12-avoid-raw-string-warning.patch
+optional-runtime-depends.patch

Bug#1076546: ITP: arianna -- Arianna is an ebook reader.

[Scarlett Moore]

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

* Package name: arianna
  Version : 24.05.2
  Upstream Contact:  Tobias Fella 
* URL : https://invent.kde.org/graphics/arianna
* License : GPL3
  Programming Lang: C++
  Description : Arianna is an ebook reader.

An ebook reader and library management app supporting ".epub" files. Arianna 
discovers your books automatically, and sorts them by categories, genres and 
authors.

This is a KDE application maintained by the KDE/QT team.


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

Bug#1076547: iraf-wcstools: Potential vulnerability due to similarity with CVE-2021-33797 in MuJS project

[Garnik Khroyan]

Package: iraf-wcstools
Version: 3.9.6-1
Severity: important
X-Debbugs-Cc: garnik...@gmail.com

Dear Maintainer,

I would like to report a potential security issue related to the iraf-wcstools
project.
The project currently includes a code fragment in the libwcs/str2dsun.c file
that is very similar to a vulnerable code fragment from the mujs project,
identified as CVE-2021-33797.

CVE-2021-33797 involves a buffer overflow in jsdtoa.c in the mujs project.
Given the similarity in codebases, it is possible that iraf-wcstools might also
be affected by this vulnerability.

My report is primarily based on a static analysis tool developed at CAST, which
flagged the potential vulnerability due to similarities in the codebase.

Thank you for your attention to this matter and for your dedication to ensuring
the security and stability of the project.


-- 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-35-generic (SMP w/16 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 iraf-wcstools depends on:
ii  iraf  2.17-1
ii  wcstools  3.9.6-1

iraf-wcstools recommends no packages.

iraf-wcstools suggests no packages.

-- no debconf information

Bug#1076548: RFS: opustags/1.10.1-1 -- view and edit Ogg Opus comments

[Dale Richards]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "opustags". This is a minor update to 
fix compilation errors with gcc-14, closing #1075349. [1]

 * Package name : opustags
   Version  : 1.10.1-1
   Upstream contact : Frédéric Mangano 
 * URL  : https://github.com/fmang/opustags
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/doge-tech/opustags
   Section  : utils

The source builds the following binary packages:

  opustags - view and edit Ogg Opus comments

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opustags/opustags_1.10.1-1.dsc

Changes since the last upload:

 opustags (1.10.1-1) unstable; urgency=medium
 .
   * New upstream version 1.10.1
 - Include algorithm library in src/cli.cc and src/opus.cc to
   fix errors when building with gcc-14. (Closes: #1075349)


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


Many thanks,
-- 
  Dale Richards

Bug#1068620: rust-nix: please add support for loong64

[wuruilong]

Source: rust-nix
Followup-For: Bug #1068620
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Can anyone merge this patch ?

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1074404: apt-cacher-ng: 302 Location redirect fails for snapshot.debian.org

[Eduard Bloch]

Control: tags 1074404 +confirmed

Hallo,

yeah, right. And there are even more things fishy in combination with
relative/absolute/protocol rewriting.

I need to judge them all individually, later today. Current draft:

https://salsa.debian.org/blade/apt-cacher-ng/-/merge_requests/new?merge_request%5Bsource_branch%5D=WIP

Thanks,
Eduard.

* Tj [Fri, Jun 28 2024, 05:18:19AM]:
> Package: apt-cacher-ng
> Followup-For: Bug #1074404
> X-Debbugs-Cc: tj.iam...@proton.me
>
> As soon as I re-read the proposed patch I realised it is wrong in two
> ways:
>
>  1. it would be triggered by // protocol specificier
>  2. there is already a later stanza to deal with path-only
>
>  However the existing path-only is pre-empted by the // protocol
>  detection.
>
>  This revised patch moves the existing path detection before // protocol
>  but ensures the second character is not also '/'.

> From dcedac77092b08c358cb9017767c70025f92aee4 Mon Sep 17 00:00:00 2001
> From: Tj 
> Date: Wed, 26 Jun 2024 01:39:16 +0100
> Subject: [PATCH] Location: handle /path/ redirects
>
> Fixes 302 Location redirects on snapshot.debian.org.
>
> Signed-off-by: Tj 
> ---
>  src/dlcon.cc | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/dlcon.cc b/src/dlcon.cc
> index 935e41f..978118e 100644
> --- a/src/dlcon.cc
> +++ b/src/dlcon.cc
> @@ -209,6 +209,11 @@ struct tDlJob
>
>   auto sLocationDecoded = UrlUnescape(pNewUrl);
>
> + if (startsWithSz(sLocationDecoded, "/") && sLocationDecoded[1] 
> != '/')
> + {
> + m_remoteUri.sPath = sLocationDecoded;
> + return true;
> + }
>   tHttpUrl newUri;
>   if (newUri.SetHttpUrl(sLocationDecoded, false))
>   {
> @@ -237,11 +242,6 @@ struct tDlJob
>   m_remoteUri.sPath += sPathBackup;
>   }
>
> - if (startsWithSz(sLocationDecoded, "/"))
> - {
> - m_remoteUri.sPath = sLocationDecoded;
> - return true;
> - }
>   // ok, must be relative
>   m_remoteUri.sPath += (sPathSepUnix + sLocationDecoded);
>   return true;
> --
> 2.39.2
>


--
 cite: man mutt; /hook - Pattern not found
 con-fuse: F1 hilft.
 In mutt selbst.
 cite: die ist von meinem WM bereits vergeben.
 con-fuse: Du stellst Dich irgendwie an wie der erste Mensch beim
Scheißen ;) /usr/share/doc/mutt/manual.txt.gz

Bug#1076350: simple way to reproduce segfault in nodejs when using browserify in i386

[Сергей Сёмин]

I found a very simple way to reproduce segfault in nodejs when using browserify.

Take Debian Bookworm i386, upgraded in to last versions of packages
with this repos:
deb http://deb.debian.org/debian bookworm contrib main non-free-firmware
deb-src http://deb.debian.org/debian bookworm contrib main non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security contrib
main non-free-firmware
deb-src http://deb.debian.org/debian-security/ bookworm-security
contrib main non-free-firmware
deb http://deb.debian.org/debian bookworm-updates contrib main non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates contrib main
non-free-firmware

Install node-browserify:
apt install node-browserify

In my case these packages were installed among others:
nodejs/stable,now 18.19.0+dfsg-6~deb12u2 i386 [installed,automatic]
node-browserify/stable,now 17.0.0+ds-5 all [installed]

We will use helloworld from official site https://browserify.org/, so
it is necessary also to install package node-uniq:
apt install node-uniq

Then create new folder called for example browserify_helloworld:
mkdir browserify_helloworld

Go into this folder:
cd browserify_helloworld

Create here new folder node_modules:
mkdir node_modules

Go into this folder:
cd node_modules

Create here symlink to folder with uniq module of nodejs:
ln -s /usr/share/nodejs/uniq

Go to level up:
cd ..

Create new file main.js with this content:
var unique = require('uniq');
var data = [1, 2, 2, 3, 4, 5, 5, 5, 6];
console.log(unique(data));

And call browserify:
browserify main.js -o bundle.js

Actual result is segfault, but it is not expected.

Install then gdb and systemd-coredump:
apt install gdb systemd-coredump

Repeat call of browserify script:
browserify main.js -o bundle.js

Actual unexpected result is segfault again. With core dumped.

Then run "coredumpctl debug" in console and bt command in gdb. Result
looks like this:
root@debian-bookworm-i386:~/browserify_helloworld# coredumpctl debug
  PID: 7002 (node)
  UID: 0 (root)
  GID: 0 (root)
   Signal: 11 (SEGV)
Timestamp: Thu 2024-07-18 13:43:32 MSK (8min ago)
 Command Line: node /usr/bin/browserify main.js -o bundle.js
   Executable: /usr/bin/node
Control Group: /user.slice/user-0.slice/session-1.scope
 Unit: session-1.scope
Slice: user-0.slice
  Session: 1
Owner UID: 0 (root)
  Boot ID: fce3c1f6d57c4899a2db912dc3f41a2b
   Machine ID: bb88a0eb919c40a690e344da5d477cfb
 Hostname: debian-bookworm-i386
  Storage: 
/var/lib/systemd/coredump/core.node.0.fce3c1f6d57c4899a2db912dc3f41a2b.7002.172129941200.zst
(present)
 Size on Disk: 3.9M
  Message: Process 7002 (node) of user 0 dumped core.

   Stack trace of thread 7002:
   #0  0xb5858507 _ZN4node2fs9FSReqBaseD1Ev
(libnode.so.108 + 0x858507)
   #1  0xb5871a4d _ZN4node2fs13FSReqCallbackD0Ev
(libnode.so.108 + 0x871a4d)
   #2  0xb584bc52
_ZN4node24MakeLibuvRequestCallbackI7uv_fs_sPFvPS1_EE7WrapperES2_
(libnode.so.108 + 0x84bc52)
   #3  0xb7c4f620 n/a (libuv.so.1 + 0x9620)
   #4  0xb7c5324a n/a (libuv.so.1 + 0xd24a)
   #5  0xb7c6899b n/a (libuv.so.1 + 0x2299b)
   #6  0xb7c53c83 uv_run (libuv.so.1 + 0xdc83)
   #7  0xb577424a
_ZN4node13SpinEventLoopEPNS_11EnvironmentE (libnode.so.108 + 0x77424a)
   #8  0xb58a185c
_ZN4node16NodeMainInstance3RunEPiPNS_11EnvironmentE (libnode.so.108 +
0x8a185c)
   #9  0xb58a1cb9 _ZN4node16NodeMainInstance3RunEv
(libnode.so.108 + 0x8a1cb9)
   #10 0xb5807951
_ZN4node22LoadSnapshotDataAndRunEPPKNS_12SnapshotDataEPKNS_20InitializationResultE
(libnode.so.108 + 0x807951)
   #11 0xb580b70e _ZN4node5StartEiPPc
(libnode.so.108 + 0x80b70e)
   #12 0x00412087 main (node + 0x1087)
   #13 0xb7cbc2d5 __libc_start_call_main
(libc.so.6 + 0x232d5)
   #14 0xb7cbc398 __libc_start_main_impl
(libc.so.6 + 0x23398)
   #15 0x004120c7 _start (node + 0x10c7)

   Stack trace of thread 7007:
   #0  0xb7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
   #1  0xb7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
   #2  0xb7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
   #3  0xb7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
   #4  0xb7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
   #5  0xb58ce222 n/a (libnode.so.108 + 0x8ce222)
   #6  0xb7d2135d start_thread (libc.so.6 + 0x8835d)
   #7  0xb7dbc688 __clone3 (libc.so.6 + 0x123688)

   Stack trace of thread 7005:
   #0  0xb7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x55

Bug#1076541: [Debian-med-packaging] Bug#1076541: orthanc-wsi: autopkgtest failures (binNMU needed)

[Sébastien Jodogne]

Dear Gianfranco,

Thanks for your report. From my understanding, this issue is related
to the creation of the "dcmtk-data" package by the following changeset
in the "dcmtk" package:
https://salsa.debian.org/med-team/dcmtk/-/commit/f0f9dfaa22ad85fe8d3cee302fb6ba766f703c8e

This changeset has the effect to move the file
"/usr/share/libdcmtk17/dicom.dic" you mentioned out of the "dcmtk"
package and into the "dcmtk-data" package. According to the changelog,
this modification was brought to unstable on version 3.6.8-5 of the
dcmtk package:
https://salsa.debian.org/med-team/dcmtk/-/blob/master/debian/changelog

I guess the proper fix consists in adding a dependency on the
"dcmtk-data" package (with a fixed version of dcmtk) in the
"orthanc-wsi" package. I fear that the same issue will be detected on
other DCMTK-related packages. I will now try to add this dependency,
in the hope it will solve the issue.

Kind Regards,
Sébastien-


On Thu, 18 Jul 2024 at 10:51, Gianfranco Costamagna
 wrote:
>
> Source: orthanc-wsi
> Version: 2.0+dfsg-3
> Severity: serious
>
>
> Hello, looks like orthanc-wsi detects the path of the dicom dictionary at 
> build time.
>
> So, it needs to be tied to a specific libdcmtk library, and needs a binNMU 
> every time dcmtk changes version.
>
>
>   43s autopkgtest [14:07:35]: test run-dicom-image-transcode-test: 
> [---
> 293
>   43s User 'orthanc' exists.
> 294
>   43s Starting orthanc (via systemctl): orthanc.service.
> 295
>   43s Orthanc is active.
> 296
>   43s W0717 14:07:35.290296 88465020 FromDcmtkBridge.cpp:383] Loading 
> external DICOM dictionary: "/usr/share/libdcmtk17/dicom.dic"
> 297
>   43s E: DcmDataDictionary: Cannot open file: /usr/share/libdcmtk17/dicom.dic
> 298
>   43s terminate called after throwing an instance of 
> 'Orthanc::OrthancException'
> 299
>   43s 
> /tmp/autopkgtest-lxc.o3sgzx4o/downtmp/build.fsM/src/debian/tests/run-dicom-image-transcode-test:
>  line 38:  2311 Aborted OrthancWSIDicomizer 
> CMU-1-Small-Region.tiff --orthanc=$orthanc_server
> 300
>
>
> https://ci.debian.net/packages/o/orthanc-wsi/testing/arm64/49182297/
>
> The failure happens only when the package was built with an older dcmtk

Bug#1076549: libarccommon3v5: Outdated cJSON sources with potential missing fixes

[Garnik Khroyan]

Package: libarccommon3v5
Version: 6.17.0
Severity: important
X-Debbugs-Cc: garnik...@gmail.com

Dear Maintainer,

nordugrid-arc-6.17.0 project includes outdated cJSON sources
(src/external/cJSON/cJSON.c), which might be missing important updates and bug
fixes. I recommend updating the cJSON sources to the latest version available.
My report is primarily based on a static analysis tool developed at CAST, which
flagged the potential vulnerability due to similarities in the codebase.

Thank you for your dedication to ensuring the security and stability of the
project.


-- 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-35-generic (SMP w/16 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 libarccommon3v5 depends on:
ii  libc6   2.35-0ubuntu3.8
pn  libdb5.3++  
ii  libgcc-s1   12.3.0-1ubuntu1~22.04
ii  libglib2.0-02.72.4-0ubuntu2.3
ii  libglibmm-2.4-1v5   2.66.2-2
ii  libnspr42:4.35-0ubuntu0.22.04.1
ii  libnss3 2:3.98-0ubuntu0.22.04.2
ii  libsigc++-2.0-0v5   2.10.4-2ubuntu3
ii  libsqlite3-03.37.2-2ubuntu0.3
ii  libssl3 3.0.2-0ubuntu1.16
ii  libstdc++6  12.3.0-1ubuntu1~22.04
ii  libuuid12.37.2-4ubuntu3.4
ii  libxml2 2.9.13+dfsg-1ubuntu0.4
ii  libxmlsec1  1.2.33-1build2
pn  libxmlsec1-openssl  
ii  openssl 3.0.2-0ubuntu1.16
ii  python3 3.10.6-1~22.04
ii  zlib1g  1:1.2.11.dfsg-2ubuntu9.2

libarccommon3v5 recommends no packages.

libarccommon3v5 suggests no packages.

Bug#1076436: Hopefully the final patch

[Nathan Teodosio]

Andrew kindly catched the bug (in my program, not in GCC, of course) so I'm
sending the hopefully final patch here.
diff -Nru highway-1.2.0/debian/changelog highway-1.2.0/debian/changelog
--- highway-1.2.0/debian/changelog	2024-06-10 17:52:26.0 +0200
+++ highway-1.2.0/debian/changelog	2024-07-16 13:00:51.0 +0200
@@ -1,3 +1,9 @@
+highway (1.2.0-7) oracular; urgency=medium
+
+  * d/tests: Add basic autopkgtest to compile and execute a simple program.
+
+ -- Nathan Pratta Teodosio   Tue, 16 Jul 2024 13:00:51 +0200
+
 highway (1.2.0-2) unstable; urgency=medium
 
   * d/patches: Import upstream fix to fix failing test
diff -Nru highway-1.2.0/debian/tests/compile-and-execute highway-1.2.0/debian/tests/compile-and-execute
--- highway-1.2.0/debian/tests/compile-and-execute	1970-01-01 01:00:00.0 +0100
+++ highway-1.2.0/debian/tests/compile-and-execute	2024-07-16 13:00:51.0 +0200
@@ -0,0 +1,63 @@
+#!/bin/sh
+set -ex
+trap 'rm o' 0
+cflags=$(pkg-config --cflags --libs libhwy)
+c++ -x c++ - -o o -fsanitize=address -Wall -Wextra -Wpedantic $cflags <
+#include 
+#include 
+#include 
+#include 
+
+namespace hn = hwy::HWY_NAMESPACE;
+using T = int;
+void MulAddLoop(const T* HWY_RESTRICT mul_array,
+const T* HWY_RESTRICT add_array,
+const size_t size, T* HWY_RESTRICT x_array) {
+  const hn::ScalableTag d;
+  for (size_t i = 0; i < size; i += hn::Lanes(d)) {
+const auto mul = hn::Load(d, mul_array + i);
+const auto add = hn::Load(d, add_array + i);
+auto x = hn::Load(d, x_array + i);
+x = hn::MulAdd(mul, x, add);
+hn::Store(x, d, x_array + i);
+  }
+}
+int main(){
+  /* Initialize arrays with random small integers. */
+  srand(time(NULL));
+  const hn::ScalableTag d;
+  size_t size = hn::Lanes(d)*3;
+  T *a  = (T*)malloc(size*sizeof(T));
+  T *b  = (T*)malloc(size*sizeof(T));
+  T *c  = (T*)malloc(size*sizeof(T));
+  T *c_orig = (T*)malloc(size*sizeof(T));
+  for(size_t i=0; i

Bug#1076550: ITP: squashfs-mount -- setuid utility instead of FUSE for mounting squashfs files

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: squashfs-mount
  Version : 1.0.0
  Upstream Author : Ben Cumming  Simon Pintarelli 
 Harmen Stoppels 
* URL : https://github.com/eth-cscs/squashfs-mount
* License : BSD-3-clause
  Programming Lang: C
  Description : setuid utility instead of FUSE for mounting squashfs files

squashfs-mount is a small setuid binary that effectively runs

mount -n -o loop,nosuid,nodev,ro -t squashfs [image] [mountpoint]

in a mount namespace and then executes the given command as the
invoking user.

squashfs-mount is used within the CSCS and the motivation for this utility is
described in the upstream README.

1. Bad performance compared to the Linux kernel. Using a 700MB gzip compressed
squashfs file containing GCC, the time to build a subset (2k targets) of LLVM
14.0.5:

squashfs-mount: 8m 9.52s;
squashfuse 0.1.103 / fuse 3.9.0: 12m 49.00s.

squashfuse has about 57% overhead compiling LLVM.

2. Inconvenient when scripting.

Bug#1076551: mirror submission for mirror.raiolanetworks.com

[Raiola Networks]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.raiolanetworks.com
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: pub/debian/
Maintainer: Raiola Networks 
Country: ES Spain
Location: Madrid
Sponsor: Raiola Networks https://raiolanetworks.com/
Comment: Sync from syncproxy.eu.debian.org using ftpsync




Trace Url: http://mirror.raiolanetworks.com/debian/project/trace/
Trace Url: 
http://mirror.raiolanetworks.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.raiolanetworks.com/debian/project/trace/mirror.raiolanetworks.com

Bug#1076552: ITP: libxpertmass -- Mass spectrometry-oriented libraries

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 
X-Debbugs-Cc: debian-de...@lists.debian.org, lopi...@debian.org

* Package name: libxpertmass
  Version : 1.0.0 
  Upstream Contact: Filippo Rusconi 
* URL : BLOCKEDmsxpertsuite[.]org/BLOCKED
* License : GPL
  Programming Lang: C++
  Description: GUI and non-GUI libraries for mass spectrometry (development 
files)
 .
 The libXpertMass and the libXpertMassGui shared libraries are designed to 
enshrine the non-GUI
 and the GUI functionalities needed by the following two mass spectrometry 
projects:
 .
 * msXpertSuite/massXpert2;
 * msXpertSuite/mineXpert2.
 .
 libXpertMass contains abstractions for all the chemical entities required to 
fully
 characterize a polymer chemistry definition, as shown below:
 .
 * Isotope
 * IsotopicData
 * Formula
 * Monomer
 * Oligomer
 * Polymer
 * Modif
 * CrossLinker
 * CrossLink
 * Aqueous chemical reactions (cleavages, enzymatic and non-enzymatic)
 * Gas-phase chemical reactions (fragmentations, with a sophisticated grammar 
to describe complex
   fragmentation patterns)
 * Isotopic cluster modelling/calculations for any chemical entity 
representable by an element
   composition formula and a charge.
 .
 libXpertMassGui contains classes useful:
 .
 * to display and manage isotopic data,
 * to configure isotopic cluster calculations,
 * to configure mass peak shaping processes (GAUSSIAN and LORENTZIAN),
 * to configure network communications between massXpert2 and mineXpert2.

  Description : Mass spectrometry-oriented libraries

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Researcher at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  BLOCKEDmsxpertsuite[.]orgBLOCKED
  http://www.debian.org


book: 
https://secure-web.cisco.com/1UXOc5OF7dQkkLfrbik_zF02sKC5moBbiSWQhbIT07wR1gpFPsme-ax3YAt213f9QN-H8KXn-ChehdH2Yt0N-QVDcMjZyAr5X1y4YaB-8s8J1BkZaYUfs6bLz1xfI3j6iOCrfNuna1_xTVJGqA-x6lFG_DH1ZpSBrJYPZ5hdxcPCvInFrvNbWfYQZeZAhMlPqBpayD7mTECYUGYUP1vmgHr5lI7e8uJ11-g-ba567jx7GbdBO9EV7X_JggplZq4h1Wi7SLbjVpBxhbQ3kn1TxlY564rZFWeAfMcYjzshyTE8GPJuZl6RbRVJJNjHhAiyH9bRQenVnSihuTQ_8YV23dV-IFwFtc8-FSKzMrarUw0iPm0Wi18vIk_2zEuBlmRAYwhYw5STKggDtKDsWEEVI_dpWH86xuhCrUZc-J_Dy7ouilGgY7cqbgMKkDEvtA35H/https%3A%2F%2Fwww.lavoisier.fr%2Flivre%2Fchimie%2Fmanuel-de-spectrometrie-de-masse-a-l-usage-des-biochimistes%2Frusconi%2Fdescriptif-9782743013417%3Fcombien%3D1
http://books.google.fr/books?id=2NmguxmEI1sC&printsec=frontcover&dq=rusconi+f+lavoisier&hl=fr&sa=X&ei=nGGOUt2SH_Ly0gX0uIHoBQ&ved=0CDUQ6AEwAA#v=onepage&q&f=false

Institut Diversité, Écologie et Évolution du Vivant
Unité Génétique Quantitative et Évolution
Plateforme PAPPSO

Université Paris-Saclay, INRAE, UMR CNRS 8120, AgroParisTech
12, route 128, Bâtiment 680
91272 Gif-sur-Yvette
France

http://moulon.inrae.fr/ & http://pappso.inrae.fr/
Tel : +33 (0)1 69 33 23 54
Fax : +33 (0)1 69 33 23 40

Bug#1073001: fixed upstream

[Hans-Christoph Steiner]

It is fixed upstream:
https://github.com/buildbot/buildbot/commit/291df50dc3f27adb47a001fc154cf4c55490687e

Bug#1076512: Info received (Bug#1076512: Acknowledgement (glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails))

[John David Anglin]

There are more problems of the same nature in glibc source:

dave@atlas:~/gnu/glibc/glibc$ find . -type f|xargs grep _STACK_GROWS|grep ifdef
./malloc/memusage.c:#ifdef _STACK_GROWS_UP
./include/stackinfo.h:# ifdef _STACK_GROWS_UP
./include/stackinfo.h:# ifdef _STACK_GROWS_DOWN
./sysdeps/unix/sysv/linux/longjmp_chk.c:#ifdef _STACK_GROWS_DOWN

./include/stackinfo.h is okay but the other two usages of these defines look 
wron.

Dave
--

John David Anglin  dave.ang...@bell.net

Bug#1076547: Fwd: Bug#1076547: iraf-wcstools: Potential vulnerability due to similarity with CVE-2021-33797 in MuJS project

[Ole Streicher]

Dear Jessica,

I just received a bug report about a potential security issue in the 
wcstools package (resp. the libwcs library), which is attached below. 
The URL for the bug report is .


The issue war originally covered in 
, with a fix in 
.


I think that the file libwcs/str2dsun.c is unused and not even compiled 
in libwcs. It was introduced in the source code of version 3.7.8 
(together with libwcs/str2dcpp.c) but was never mentioned in 
libwcs/Makefile. It therefore should just be removed, right?


If not, the fix could be just taken over by wcstools. What do you think?

Best regards

Ole


 Forwarded Message 
Subject: Bug#1076547: iraf-wcstools: Potential vulnerability due to
similarity with CVE-2021-33797 in MuJS project
Resent-Date: Thu, 18 Jul 2024 11:03:02 +
Resent-From: Garnik Khroyan 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: garnik...@gmail.com, Debian Astro Team

Date: Thu, 18 Jul 2024 14:59:05 +0400
From: Garnik Khroyan 
Reply-To: Garnik Khroyan , 1076...@bugs.debian.org
To: Debian Bug Tracking System 

Package: iraf-wcstools
Version: 3.9.6-1
Severity: important
X-Debbugs-Cc: garnik...@gmail.com

Dear Maintainer,

I would like to report a potential security issue related to the
iraf-wcstools project.
The project currently includes a code fragment in the libwcs/str2dsun.c 
file that is very similar to a vulnerable code fragment from the mujs 
project, identified as CVE-2021-33797.


CVE-2021-33797 involves a buffer overflow in jsdtoa.c in the mujs 
project. Given the similarity in codebases, it is possible that 
iraf-wcstools might also be affected by this vulnerability.


My report is primarily based on a static analysis tool developed at
CAST, which flagged the potential vulnerability due to similarities in 
the codebase.


Thank you for your attention to this matter and for your dedication to
ensuring the security and stability of the project.

Bug#1076547: iraf-wcstools: Potential vulnerability due to similarity with CVE-2021-33797 in MuJS project

[Ole Streicher]

Control: forwarded -1 jm...@cfa.harvard.edu

Dear Garnick,

I forwarded the bug to upstream. However, I think this does actually not 
affect the wcstools package because this file is unused in the code. If 
there is no contradicting reaction from upstream, I would just close 
this bug (maybe while also explicitly removing there files in d/clean).


Best

Ole

Bug#1058649: ffcall: Add patch

[wuruilong]

Source: ffcall
Version: 2.4-2.1
Followup-For: Bug #1058649
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The current version of the patch was made according to the upstream and 
compiled successfully on loongarch.
Tried to add the patch using the attachment, but was unsuccessful. The link to 
the patch is here: 
https://github.com/loongarchlinux/extra/blob/main/ffcall/libffcall-la64-2.4.patch

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1060545: drbd-utils: Please switch Build-Depends to systemd-dev

[Michael Biebl]

Control: tags -1 + patch pending

I've uploaded an updated package to DELAYED/14.

Please find a debdiff attached.

Regards,
Michael
diff -Nru drbd-utils-9.22.0/debian/changelog drbd-utils-9.22.0/debian/changelog
--- drbd-utils-9.22.0/debian/changelog  2023-01-09 15:51:18.0 +0100
+++ drbd-utils-9.22.0/debian/changelog  2024-07-17 19:22:06.0 +0200
@@ -1,3 +1,27 @@
+drbd-utils (9.22.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Build-Depends on pkgconf and systemd-dev to get the proper paths for
+udev rules and systemd service files. (Closes: #1060545, #921153)
+  * Rely on systemd.pc and udev.pc to get the correct paths and do not
+override it in debian/rules.
+  * Do not set sbindir in debian/rules and use the default instead, which is
+/usr/sbin.
+  * Install drdb.conf modules-load config into /usr/lib/modules-load.d/ which
+is the canonical location.
+  * Drop debian/patches/0005-initscript-remove-path.patch which is no longer
+applicable.
+  * Drop debian/drbd-utils.dirs, it is not actually needed and creates
+unneeded directories like lib/udev/rules.d.
+  * Add debian/patches/0009-no-hard-coded-paths.patch which ensures that all
+scripts and binaries are installed into /usr.
+  * The changes above ensure that all files are installed into non-aliased
+locations. (Closes: #1073716)
+  * Drop debian/drbd-utils.postinst which is no longer needed.
+  * Drop dependency on obsolete package lsb-base.
+
+ -- Michael Biebl   Wed, 17 Jul 2024 19:22:06 +0200
+
 drbd-utils (9.22.0-1) unstable; urgency=medium
 
   * New upstream version 9.22.0
diff -Nru drbd-utils-9.22.0/debian/control drbd-utils-9.22.0/debian/control
--- drbd-utils-9.22.0/debian/control2023-01-09 15:50:35.0 +0100
+++ drbd-utils-9.22.0/debian/control2024-07-17 19:22:06.0 +0200
@@ -9,7 +9,9 @@
docbook-xsl,
docbook-xml,
asciidoctor,
+   pkgconf,
udev,
+   systemd-dev,
bash-completion,
po4a
 Standards-Version: 4.6.1
@@ -19,8 +21,7 @@
 
 Package: drbd-utils
 Architecture: linux-any
-Depends: lsb-base (>= 3.0-6),
- ${shlibs:Depends},
+Depends: ${shlibs:Depends},
  ${misc:Depends}
 Breaks: drbd8-utils (<< 2:8.9.0)
 Replaces: drbd8-utils (<< 2:8.9.0)
diff -Nru drbd-utils-9.22.0/debian/drbd-utils.dirs 
drbd-utils-9.22.0/debian/drbd-utils.dirs
--- drbd-utils-9.22.0/debian/drbd-utils.dirs2020-08-24 15:35:36.0 
+0200
+++ drbd-utils-9.22.0/debian/drbd-utils.dirs1970-01-01 01:00:00.0 
+0100
@@ -1,4 +0,0 @@
-etc
-etc/init.d
-etc/ha.d/resource.d
-lib/udev/rules.d
diff -Nru drbd-utils-9.22.0/debian/drbd-utils.postinst 
drbd-utils-9.22.0/debian/drbd-utils.postinst
--- drbd-utils-9.22.0/debian/drbd-utils.postinst2020-08-24 
15:35:36.0 +0200
+++ drbd-utils-9.22.0/debian/drbd-utils.postinst1970-01-01 
01:00:00.0 +0100
@@ -1,13 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# Cleanup the old systemd unit state, if applicable
-if dpkg --compare-versions "$2" lt-nl "8.9.5-1~"; then
-   if deb-systemd-helper debian-installed drbd.service; then
-   deb-systemd-helper purge drbd.service >/dev/null
-   deb-systemd-helper unmask drbd.service >/dev/null
-   fi
-fi
-
-#DEBHELPER#
diff -Nru drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch 
drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch
--- drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch  
2022-07-19 12:24:50.0 +0200
+++ drbd-utils-9.22.0/debian/patches/0005-initscript-remove-path.patch  
1970-01-01 01:00:00.0 +0100
@@ -1,26 +0,0 @@
-From: Apollon Oikonomopoulos 
-Date: Mon, 18 Nov 2019 22:27:25 +0200
-Subject: Remove /usr from the initscript's PATH
-
-All utilities reside on /sbin. Furthermore, the declaration of
-/usr/sbin makes lintian complain about a missing dependency on $remote_fs,
-which is strictly not necessary.
-Last-Update: 2014-06-13
-Forwarded: no

- scripts/drbd | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/scripts/drbd b/scripts/drbd
-index fbed28f..333eedb 100755
 a/scripts/drbd
-+++ b/scripts/drbd
-@@ -41,7 +41,7 @@ RMMOD="/sbin/rmmod"
- UDEV_TIMEOUT=10
- ADD_MOD_PARAM=""
- 
--PATH=/usr/sbin:/sbin:$PATH
-+PATH=/sbin:/bin
- 
- if [ -f $DEFAULTFILE ]; then
-   . $DEFAULTFILE
diff -Nru drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch 
drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch
--- drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch 
1970-01-01 01:00:00.0 +0100
+++ drbd-utils-9.22.0/debian/patches/0009-no-hard-coded-paths.patch 
2024-07-17 19:22:06.0 +0200
@@ -0,0 +1,91 @@
+Description: Do not hard-code paths to install scripts and helper binaries
+ Instead use $LIBDIR everywhere consistently.
+Author: Michael Biebl 
+
+---
+Bug-Debian: http

Bug#929825: Version 7 available upstream

[Morten Kjeldgaard]

This bug has been dormant for quite a while. Anything we can do to help it 
along?

/Morten

Bug#1066313: torsocks upstream fix

[Clément Hermann]

Hi Micah,





Le 11 juillet 2024 13:06:48 UTC, micah anderson  a écrit :
>
>Hello,
>
>In April you had said that you were going to try and upload a new
>version of torsocks, which fixes the FTBFS, but you were trying to fix a
>few lintian issues first.

Sorry about that, the issues that prevented upload are fixed but it slipped my 
mind...
I'll take care of it next week at the latest.

Best,

-- 
nodens

Bug#1076418: FTBFS: undeclared type `TestClient`

[Jonas Smedegaard]

Quoting Reinhard Tartler (2024-07-18 06:44:00)
> Reinhard Tartler  writes:
> > Why does this error not reproduce outside of autopkgtest? -- either some
> > dependency mismatch in debian, or somethign really subtle in
> > autopkgtest. In either case, I'd like to keep my suggestion to disable
> > the failing tests in in debian/tests/control and keep the one that runs
> > the default features.
> 
> Okay, I now managed to reproduce it outside of autopkgtest. I chose the
> wrong working directory for the invocation. Since this is a workspace
> build, I forgot that 'cargo test' is invoked in the 'axum'
> subdirectory. So this invocation now reproduces the autopkgtest failure
> just fine:
> 
>   cd axum && cargo test --all-targets --no-default-features --features json
> 
> 
> Here is a patch that adds the missing dependency:
> 
> diff --git a/axum/Cargo.toml b/axum/Cargo.toml
> index e8cba15..3fef728 100644
> --- a/axum/Cargo.toml
> +++ b/axum/Cargo.toml
> @@ -13,10 +14,10 @@
>  
>  [features]
>  default = ["form", "http1", "json", "matched-path", "original-uri", "query", 
> "tokio", "tower-log"]
>  form = ["dep:serde_urlencoded"]
>  http1 = ["hyper/http1"]
>  http2 = ["hyper/http2"]
> -json = ["dep:serde_json", "dep:serde_path_to_error"]
> +json = ["dep:serde_json", "dep:serde_path_to_error", "original-uri", "tokio"]
>  macros = ["dep:axum-macros"]
>  matched-path = []
>  multipart = ["dep:multer"]

Great.

Thanks also for your guided tour into your debugging process, that was a
learning experience for me.

> I guess it's worth discussing this issue upstream at 
> https://github.com/tokio-rs/axum/issues

I sure will.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1076350: simple way to reproduce segfault in nodejs when using browserify in i386

[Сергей Сёмин]

I built source package nodejs_18.19.0+dfsg-6~deb12u2 in Debian
Bookworm i386 and installed result deb packages into system.
Packages with dbgsym were also installed.
Then I tried to reproduce segfault with simple way explained earlier
and now I see better more informative backtrace with mentioned source
files because of available debug symbols:

root@debian-bookworm-i386:~/browserify_helloworld# coredumpctl -1 debug
   PID: 22462 (node)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Thu 2024-07-18 17:42:19 MSK (43s ago)
  Command Line: node /usr/bin/browserify main.js -o bundle.js
Executable: /usr/bin/node
 Control Group: /user.slice/user-0.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-0.slice
   Session: 1
 Owner UID: 0 (root)
   Boot ID: aabb14f30d9d467d9389c47f962245e5
Machine ID: bb88a0eb919c40a690e344da5d477cfb
  Hostname: debian-bookworm-i386
   Storage:
/var/lib/systemd/coredump/core.node.0.aabb14f30d9d467d9389c47f962245e5.22462.172131373900.zst
(present)
  Size on Disk: 4.0M
   Message: Process 22462 (node) of user 0 dumped core.

Stack trace of thread 22462:
#0  0xb5858507
_ZNKSt14default_deleteIN4node2fs18FSContinuationDataEEclEPS2_
(libnode.so.108 + 0x858507)
#1  0xb5871a4d _ZN4node2fs13FSReqCallbackD4Ev
(libnode.so.108 + 0x871a4d)
#2  0xb584bc52
_ZN4node17BaseObjectPtrImplINS_7ReqWrapI7uv_fs_sEELb0EED4Ev
(libnode.so.108 + 0x84bc52)
#3  0xb7c67620 n/a (libuv.so.1 + 0x9620)
#4  0xb7c6b24a n/a (libuv.so.1 + 0xd24a)
#5  0xb7c8099b n/a (libuv.so.1 + 0x2299b)
#6  0xb7c6bc83 uv_run (libuv.so.1 + 0xdc83)
#7  0xb577424a
_ZN4node13SpinEventLoopEPNS_11EnvironmentE (libnode.so.108 + 0x77424a)
#8  0xb58a185c
_ZN4node16NodeMainInstance3RunEPiPNS_11EnvironmentE (libnode.so.108 +
0x8a185c)
#9  0xb58a1cb9
_ZN4node16NodeMainInstance3RunEv (libnode.so.108 + 0x8a1cb9)
#10 0xb5807951
_ZN4node22LoadSnapshotDataAndRunEPPKNS_12SnapshotDataEPKNS_20InitializationResultE
(libnode.so.108 + 0x807951)
#11 0xb580b70e _ZN4node5StartEiPPc
(libnode.so.108 + 0x80b70e)
#12 0x00439087 main (node + 0x1087)
#13 0xb7cd42d5 __libc_start_call_main
(libc.so.6 + 0x232d5)
#14 0xb7cd4398 __libc_start_main_impl
(libc.so.6 + 0x23398)
#15 0x004390c7 _start (node + 0x10c7)

Stack trace of thread 22465:
#0  0xb7ee3559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1  0xb7dc6bd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2  0xb7d355b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3  0xb7d3880e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4  0xb7c7a69c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5  0xb58ce222
_ZN4node16LibuvMutexTraits9cond_waitEP14pthread_cond_tP15pthread_mutex_t
(libnode.so.108 + 0x8ce222)
#6  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
#7  0xb7dd4688 __clone3 (libc.so.6 + 0x123688)

Stack trace of thread 22464:
#0  0xb7ee3559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1  0xb7dc6bd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2  0xb7d355b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3  0xb7d3880e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4  0xb7c7a69c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5  0xb58ce222
_ZN4node16LibuvMutexTraits9cond_waitEP14pthread_cond_tP15pthread_mutex_t
(libnode.so.108 + 0x8ce222)
#6  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
#7  0xb7dd4688 __clone3 (libc.so.6 + 0x123688)

Stack trace of thread 22463:
#0  0xb7ee3559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1  0xb7dd2bc3 epoll_wait (libc.so.6 + 0x121bc3)
#2  0xb7c80c8e n/a (libuv.so.1 + 0x22c8e)
#3  0xb7c6bc83 uv_run (libuv.so.1 + 0xdc83)
#4  0xb58d3378
_ZN4node23WorkerThreadsTaskRunner20DelayedTaskScheduler3RunEv
(libnode.so.108 + 0x8d3378)
#5  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
#6  0xb7dd4688 __clone3 (libc.so.6 + 0x123688)

Stack trace of thread 22470:
#0  0xb7ee3559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1  0xb7dc6bd2 __libc_do_syscall (libc.so.6 + 

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Blair Noctis]

On 18/07/2024 04:47, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2024-07-17 16:49:12)
>> Quoting Blair Noctis (2024-07-16 23:14:59)
>>> On Thu, 25 Jan 2024 10:00:57 +0100 "Andrej Shadura"  
>>> wrote:
 Hi,

 On Sun, 21 Jan 2024, at 21:06, Jonas Smedegaard wrote:
> Just a notice that I am still working on this.  If you want to follow my
> work more closely, then I can put up my fork of the git repo somewhere,
> but if you won't be looking closely anyway, then I will not bother
> setting that up, and instead simply shout out when I have something
> more substantially working.
(...)
>>> Jonas, how's your fork going? If you don't mind using a hand, would you set 
>>> it
>>> public? Or with Andrej's go-ahead, continue work in salsa:debian/resvg?
>>
>> I am refreshing my work now - hope to have something to show (or perhaps
>> even release) later tonight.
> 
> Sorry, I didn't get it into a working state yet - will continue poking
> at it tomorrow.

No worries, and no hurry, consider my request urgent=low :p

-- 
Sdrager,
Blair Noctis


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076350: [Pkg-javascript-devel] Bug#1076350: simple way to reproduce segfault in nodejs when using browserify in i386

[Jérémy Lal]

Le jeu. 18 juil. 2024 à 17:03, Сергей Сёмин  a
écrit :

> I built source package nodejs_18.19.0+dfsg-6~deb12u2 in Debian
> Bookworm i386 and installed result deb packages into system.
> Packages with dbgsym were also installed.
> Then I tried to reproduce segfault with simple way explained earlier
> and now I see better more informative backtrace with mentioned source
> files because of available debug symbols:
>
> root@debian-bookworm-i386:~/browserify_helloworld# coredumpctl -1 debug
>PID: 22462 (node)
>UID: 0 (root)
>GID: 0 (root)
> Signal: 11 (SEGV)
>  Timestamp: Thu 2024-07-18 17:42:19 MSK (43s ago)
>   Command Line: node /usr/bin/browserify main.js -o bundle.js
> Executable: /usr/bin/node
>  Control Group: /user.slice/user-0.slice/session-1.scope
>   Unit: session-1.scope
>  Slice: user-0.slice
>Session: 1
>  Owner UID: 0 (root)
>Boot ID: aabb14f30d9d467d9389c47f962245e5
> Machine ID: bb88a0eb919c40a690e344da5d477cfb
>   Hostname: debian-bookworm-i386
>Storage:
>
> /var/lib/systemd/coredump/core.node.0.aabb14f30d9d467d9389c47f962245e5.22462.172131373900.zst
> (present)
>   Size on Disk: 4.0M
>Message: Process 22462 (node) of user 0 dumped core.
>
> Stack trace of thread 22462:
> #0  0xb5858507
> _ZNKSt14default_deleteIN4node2fs18FSContinuationDataEEclEPS2_
> (libnode.so.108 + 0x858507)
> #1  0xb5871a4d _ZN4node2fs13FSReqCallbackD4Ev
> (libnode.so.108 + 0x871a4d)
> #2  0xb584bc52
> _ZN4node17BaseObjectPtrImplINS_7ReqWrapI7uv_fs_sEELb0EED4Ev
> (libnode.so.108 + 0x84bc52)
> #3  0xb7c67620 n/a (libuv.so.1 + 0x9620)
> #4  0xb7c6b24a n/a (libuv.so.1 + 0xd24a)
> #5  0xb7c8099b n/a (libuv.so.1 + 0x2299b)
> #6  0xb7c6bc83 uv_run (libuv.so.1 + 0xdc83)
> #7  0xb577424a
> _ZN4node13SpinEventLoopEPNS_11EnvironmentE (libnode.so.108 + 0x77424a)
> #8  0xb58a185c
> _ZN4node16NodeMainInstance3RunEPiPNS_11EnvironmentE (libnode.so.108 +
> 0x8a185c)
> #9  0xb58a1cb9
> _ZN4node16NodeMainInstance3RunEv (libnode.so.108 + 0x8a1cb9)
> #10 0xb5807951
>
> _ZN4node22LoadSnapshotDataAndRunEPPKNS_12SnapshotDataEPKNS_20InitializationResultE
> (libnode.so.108 + 0x807951)
> #11 0xb580b70e _ZN4node5StartEiPPc
> (libnode.so.108 + 0x80b70e)
> #12 0x00439087 main (node + 0x1087)
> #13 0xb7cd42d5 __libc_start_call_main
> (libc.so.6 + 0x232d5)
> #14 0xb7cd4398 __libc_start_main_impl
> (libc.so.6 + 0x23398)
> #15 0x004390c7 _start (node + 0x10c7)
>
> Stack trace of thread 22465:
> #0  0xb7ee3559 __kernel_vsyscall
> (linux-gate.so.1 + 0x559)
> #1  0xb7dc6bd2 __libc_do_syscall (libc.so.6 +
> 0x115bd2)
> #2  0xb7d355b5 __futex_abstimed_wait_common32
> (libc.so.6 + 0x845b5)
> #3  0xb7d3880e __pthread_cond_wait_common
> (libc.so.6 + 0x8780e)
> #4  0xb7c7a69c uv_cond_wait (libuv.so.1 + 0x1c69c)
> #5  0xb58ce222
> _ZN4node16LibuvMutexTraits9cond_waitEP14pthread_cond_tP15pthread_mutex_t
> (libnode.so.108 + 0x8ce222)
> #6  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
> #7  0xb7dd4688 __clone3 (libc.so.6 + 0x123688)
>
> Stack trace of thread 22464:
> #0  0xb7ee3559 __kernel_vsyscall
> (linux-gate.so.1 + 0x559)
> #1  0xb7dc6bd2 __libc_do_syscall (libc.so.6 +
> 0x115bd2)
> #2  0xb7d355b5 __futex_abstimed_wait_common32
> (libc.so.6 + 0x845b5)
> #3  0xb7d3880e __pthread_cond_wait_common
> (libc.so.6 + 0x8780e)
> #4  0xb7c7a69c uv_cond_wait (libuv.so.1 + 0x1c69c)
> #5  0xb58ce222
> _ZN4node16LibuvMutexTraits9cond_waitEP14pthread_cond_tP15pthread_mutex_t
> (libnode.so.108 + 0x8ce222)
> #6  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
> #7  0xb7dd4688 __clone3 (libc.so.6 + 0x123688)
>
> Stack trace of thread 22463:
> #0  0xb7ee3559 __kernel_vsyscall
> (linux-gate.so.1 + 0x559)
> #1  0xb7dd2bc3 epoll_wait (libc.so.6 + 0x121bc3)
> #2  0xb7c80c8e n/a (libuv.so.1 + 0x22c8e)
> #3  0xb7c6bc83 uv_run (libuv.so.1 + 0xdc83)
> #4  0xb58d3378
> _ZN4node23WorkerThreadsTaskRunner20DelayedTaskScheduler3RunEv
> (libnode.so.108 + 0x8d3378)
> #5  0xb7d3935d start_thread (libc.so.6 + 0x8835d)
>

Bug#1069425: uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure!

[Drew Parsons]

forwarded 1069425 https://bugzilla.samba.org/show_bug.cgi?id=15445
thanks

see also https://bugzilla.samba.org/show_bug.cgi?id=15448

Please skip test_syscall (at least on arm-32) as suggested in the 
upstream issue if you think it's not a meaningful test.


This bug is holding up a long chain of packages needed by cluster 
installations, which we need to run performance testing of our MPI 
libraries.


Drew

Bug#1076553: RFS: django-anymail/11.0.1-1 -- Django email backend for multiple ESPs (Python 3)

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "django-anymail":

 * Package name : django-anymail
   Version  : 11.0.1-1
   Upstream contact : Mike Edmunds 
 * URL  : https://github.com/anymail/django-anymail
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/debian/django-anymail
   Section  : python

The source builds the following binary packages:

  python3-django-anymail - Django email backend for multiple ESPs 
(Python 3)


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


  https://mentors.debian.net/package/django-anymail/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/django-anymail/django-anymail_11.0.1-1.dsc


Changes since the last upload:

 django-anymail (11.0.1-1) unstable; urgency=medium
 .
   * New upstream version 11.0.1

Regards,
--
  Akash Doppalapudi


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069425: uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure!

[Drew Parsons]

I should be more specific. "long chain" is subjective.

Cluster installations need autofs,
which is blocked by sssd
which is blocked by this arm-32 issue with uid-wrapper.

Bug#1076554: Regression: error parsing URL //: Invalid host/port

[Sylvain Beucler]

Package: apache2
Version: 2.4.61-1~deb12u1
Severity: important

Dear Maintainer,

Following DSA 5729-1 (2.4.61-1~deb12u1), access to Sympa broke.
User error: Bad Request
Log error: AH01059: error parsing URL //: Invalid host/port

I believe the issue is related to this line:
  SetHandler "proxy:unix:/run/sympa/wwsympa.socket|fcgi://"
This is the default configuration from the sympa Debian package.

I get the same result when compiling the debdiff from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076531
(2.4.62)

I can work-around the issue by appending 'localhost':
  SetHandler "proxy:unix:/run/sympa/wwsympa.socket|fcgi://localhost"
(but this is still a regression in the stable release :))

-- Package-specific info:

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

Kernel: Linux 6.1.0-23-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages apache2 depends on:
ii  apache2-bin2.4.62-1~deb12u1~local
ii  apache2-data   2.4.62-1~deb12u1~local
ii  apache2-utils  2.4.62-1~deb12u1~local
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  media-types10.0.0
ii  perl   5.36.0-7+deb12u1
ii  procps 2:4.0.2-3
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
ii  apache2-suexec-pristine  2.4.62-1~deb12u1~local
pn  www-browser  

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.2-3
ii  libaprutil1  1.6.3-1
ii  libaprutil1-dbd-sqlite3  1.6.3-1
ii  libaprutil1-ldap 1.6.3-1
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-9+deb12u7
ii  libcrypt11:4.4.33-2
ii  libcurl4 7.88.1-10+deb12u6
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-5
ii  liblua5.3-0  5.3.6-2
ii  libnghttp2-141.52.0-1+deb12u1
ii  libpcre2-8-0 10.42-1
ii  libssl3  3.0.13-1~deb12u1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  perl 5.36.0-7+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
ii  apache2-suexec-pristine  2.4.62-1~deb12u1~local
pn  www-browser  

Versions of packages apache2 is related to:
ii  apache2  2.4.62-1~deb12u1~local
ii  apache2-bin  2.4.62-1~deb12u1~local

-- no debconf information

Bug#1069425: Info received (Bug#1069425 uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure!)

[Drew Parsons]

Looking more closely at the fine print in the upstream issues, the issue 
here refers to a different line number (and in test_syscall not 
test_syscall_swap).  But I guess the same principle applies for dealing 
with it.

Bug#1072274: ITP: fcitx5-varnam -- Fcitx5 wrapper for Varnam input method.

[Anoop M S]

Hi,
On Mon, 15 Jul 2024 00:43:38 +0530 Anoop M S  wrote:
> Hi,
> On Sun, 14 Jul 2024 14:44:59 -0400 Boyuan Yang  wrote:
> > Hi,
> >
> > 在 2024-07-14星期日的 20:59 +0530，Anoop M S写道：
> > > On Fri, 31 May 2024 10:48:21 -0400 Boyuan Yang 
> wrote:
> > >  > Hi,
> > >  >
> > >  > 在 2024-05-31星期五的 08:19 +，Anoop M S写道：
> > >  > > Package: wnpp
> > >  > > Severity: wishlist
> > >  > > Owner: Anoop M S 
> > >  > > X-Debbugs-Cc: debian-de...@lists.debian.org, 
anoo...@disroot.org

> > >  > >
> > >  > > * Package name    : fcitx5-varnam
> > >  > >   Version : 0.0.1
> > >  > >   Upstream Contact: Anoop M S 
> > >  > > * URL : 
https://github.com/varnamproject/varnam-fcitx5

> > >  > > * License : GPL
> > >  > >   Programming Lang: C++
> > >  > >   Description : Fcitx5 wrapper for Varnam input method.
> > >  > >
> > >  > > Fcitx5 wrapper for Varnam(https://www.varnamproject.com) Input
> > > Method Engine.
> > >  > > Easily type Indian languages on Linux desktops.
> > >  > >
> > >  > > I would like to join Debian Input Method Team, and package and
> > > maintain it.
> > >  > > And I would need a sponsor to upload it as well.
> > >  >
> > >  > Please prepare an initial version first. You can host it on your
> own
> > > Salsa git repo
> > >  > or via mentors.debian.net , or choose whichever platform that is
> more
> > > convenient to you.
> > >  > Please submit a regular RFS request and notify me once you are
> prepared.
> > >  >
> > >  > If it looks good, I can help to move your git packaging repo 
to the

> > > Salsa Input Method
> > >  > Team namespace, sponsor the upload and add you into the Salsa 
Input

> > > Method Team group.
> > >  >
> > >  > Thanks,
> > >  > Boyuan Yang
> > >
> > > I've prepared an initial release and sent RFS (#1076334).
> > >
> > > Kindly review at your convenience.
> >
> > The following issues are critical and must be fixed:
> >
> > *
> 
https://github.com/varnamproject/varnam-fcitx5/blob/a2c9412461f68a5293cec24609076951e28a3b27/meson.build#L11-L29

> > is unacceptable. The build system is only targeting on x86_64 (amd64)
> architecture, which is
> > not reasonable since Debian and Fedora both support multiple hardware
> architectures.

I've addressed the raised issues in the upstream. And made few changes 
in the package as well (haven't pushed the code yet).

Lintian currently showing following issues
* newer-standards-version 4.7.0
* debian-watch-does-not-check-openpgp-signature
* prefer-uscan-symlink

full text : https://paste.debian.net/plain/1323647

Are these ignorable? And is there anything else I need to follow to do 
the version update

 or can I create a fresh setup with only the new version?

Thanks and Regards,
Anoop


OpenPGP_0xDC6CE985B8F95651.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074303: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[pham...@bluewin.ch]

Hello,
The command line you asked me to enter is invalid ?!?!
sudo nmcli general logging level LEVEL domains ALL
root@station:~# nmcli general logging level LEVEL domains ALL
Erreur : accès refusé pour définir la journalisation : Niveau de journalisation 
« LEVEL » inconnu
This is the third time you've asked me to do a job that ultimately serves no 
purpose or doesn't work !?
On top of that you closed my previous bug for no reason and I had to reopen it.
Forgive me for being blunt, but what's the problem? You don't have time to deal 
with it? If that's it, there are other maintainers who are most certainly ready 
to take over, don't you think? I just feel like I'm wasting my time with not 
motivated people ;-(
Regards.

Bug#1010445: mono-complete: Mono package in Debian is very outdated (6.8 but should be 6.12)

[Paul Gevers]

Hi all,

On Mon, 3 Jun 2024 23:06:45 +0500 Andrey Rakhmatullin  
wrote:

> keeping the current outdated build is much more useful than not having
> access to Mono at all from Debian repositories.
Considering the amount of packages depending on mono, removing it from
testing is probably out of question anyway, but that's up tio the Release
and Security teams. Also, "keeping the outdated unmaintained package is
better than not keeping it" is overturned by one of those teams quite
often.


Release Team member here. mono is a key package [1], meaning it's hard 
to remove. I note that src:mono is at least needed for src:gdcm which is 
at least needed for src:opencv which is at least needed for src:ffmpeg. 
If mono should be removed (I haven't investigated yet if that's 
appropriate from the Release Team point of view) then somebody should 
work out how to remove it from the key package set.


Without more substantiation why the current version of mono is broken 
(not just old and unmaintained), this bug will very likely not block the 
release.


Paul

[1] https://release.debian.org/key-packages.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076541: [Debian-med-packaging] Bug#1076541: orthanc-wsi: autopkgtest failures (binNMU needed)

[Gianfranco Costamagna]

Hello,

>I guess the proper fix consists in adding a dependency on the
>"dcmtk-data" package (with a fixed version of dcmtk) in the
>"orthanc-wsi" package. I fear that the same issue will be detected on
>other DCMTK-related packages. I will now try to add this dependency,
>in the hope it will solve the issue.

It will fix because a rebuild will fix it, until the next transition
./Resources/Graveyard/CMakeLists.txt:SET(DCMTK_DICTIONARY_DIR "" CACHE PATH 
"Directory containing the DCMTK dictionaries \"dicom.dic\" and \"private.dic\" 
(only when using system version of DCMTK)")
and from orthanc
./OrthancFramework/Resources/CMake/DcmtkConfiguration.cmake:  
DICTIONARY_DICOM   ${DCMTK_SOURCES_DIR}/dcmdata/data/dicom.dic
./OrthancFramework/Sources/DicomParsing/FromDcmtkBridge.cpp:  
LoadEmbeddedDictionary(*locker, FrameworkResources::DICTIONARY_DICOM);

https://autopkgtest.ubuntu.com/packages/orthanc-wsi/oracular/amd64

You can see, I tried 
2.0+dfsg-3orthanc-wsi/2.0+dfsg-3 against itself fail
2.0+dfsg-2build5orthanc/1.12.4+dfsg-3build1 pass
then I rebuilt orthanc

2.0+dfsg-3orthanc-wsi/2.0+dfsg-3 orthanc/1.12.4+dfsg-3build1   FAIL

Then I rebuilt orthanc-wsi
2.0+dfsg-3build1orthanc-wsi/2.0+dfsg-3build1
and it succeeded.

So please double check, but I guess also wsi package needed a rebuild.

thanks for caring/fixing!

G.

Bug#874763: Ability to install local debs (or volatile sources) not documented in manpage

[Richard]

It would be great if this could get fixed. Handling all Debian packages through 
apt - even those not coming from repos - is the most user- and especially 
beginner-friendly way there is. This way dependencies are automatically handled 
instead of dpkg just spitting out errors the average beginner will have trouble 
with understanding. While there are many guides online about how to install 
.deb packages and while most beginners probably will use the graphical tools 
anyway coming from Windows where you install things too with a double click, 
official acknowledgements of this being a thing would probably still be 
appreciated.

Bug#1073255: Qt 6 bindings for gpgme

[Patrick Franz]

Hi Andreas,

On Wed, 17 Jul 2024 08:03:58 +0200 Andreas Metzler  
wrote:
> Hello Patrick,
> 
> I am sorry I cannot give you an estimate there. I will not upload
> without approval/review by the main maintainters.
> 
> An upload would go to experimental first. Splitting of the qt devel
> packages (#863149) will require an intermediate upload to unstable 
> with
> just adding a Provides: libqgpgme-dev to libgpgmepp-dev, followed by
> changing all packagages (build)-depending on QT gpgme to add a
> (build)-dep on the new package name. Only once that is finished gpgme
> with qt5/6-dev as separate packages could be uploaded to unstable.

Thank you for the update. We will plan accordingly.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1010445: mono-complete: Mono package in Debian is very outdated (6.8 but should be 6.12)

[Chris Hofstaedtler]

On Thu, Jul 18, 2024 at 06:55:03PM +0200, Paul Gevers wrote:
> Release Team member here. mono is a key package [1], meaning it's hard to
> remove. I note that src:mono is at least needed for src:gdcm which is at
> least needed for src:opencv which is at least needed for src:ffmpeg.

src:gdcm could likely easily drop its -cil packages.

> If mono should be removed

That's the question that needs to be answered somehow, first.

Chris

Bug#1076026: elpa: FTBFS with mpich as default MPI on i386: FAIL validate_complex_2stage_banded_default.sh (exit status: 15)

[Adrian Bunk]

On Tue, Jul 09, 2024 at 07:41:11PM +0200, Sebastian Ramacher wrote:
> Source: elpa
> Version: 2022.11.001-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
>...
> GetSockInterfaceAddr(369)..: gethostbyname failed, x86-conova-02 
> (errno 4)
> Fatal error in internal_Init: Other MPI error, error stack:
> internal_Init(48301)...: MPI_Init(argc=(nil), argv=(nil)) failed
>...

Regarding this error that seems to happen with elpa and mpi4py (and arpack?)
on some buildds only:

Is it possible that mpich has a problem when no IPV4 is available?

I have no idea if I am looking at the right place, but I wonder 
whether something like for example
  src/mpi/romio/mpl/src/sock/mpl_sockaddr.c:static int af_type = AF_INET;
is the problem?

cu
Adrian

Bug#1076555: linux-image-6.9.9-amd64: boot crash RIP: 0010:kmem_cache_alloc

[Patrice Duroux]

Package: src:linux
Version: 6.9.9-1
Severity: minor

Dear Maintainer,

I just faced this boot problem on my sid system for the first time
since I updated the Linux kernel a few days ago.

I do not know if it could be something related to some hardware failure
or a possible software bug in the linux kernel or a service.

Regards,
Patrice

-- Package-specific info:
** Version:
Linux version 6.9.9-amd64 (debian-ker...@lists.debian.org)
(x86_64-linux-gnu-gcc-13 (Debian 13.3.0-3) 13.3.0, GNU ld (GNU
Binutils for Debian) 2.42.50.20240710) #1 SMP
PREEMPT_DYNAMIC Debian 6.9.9-1 (2024-07-13)

** Command line:
initrd=\be351e757dc049ffa300ddbaf0f4856a\6.9.9-amd64\initrd.img-6.9.9-amd64
root=UUID=2b8c6592-0954-4ecd-977d-738c855f3dff ro quiet splash
systemd.machine_id=be351e757d
c049ffa300ddbaf0f4856a

** Not tainted

** Kernel log:
[   12.039117] usb 1-11: Found UVC 1.50 device Integrated_Webcam_HD (1bcf:28c4)
[   12.059706] Intel(R) Wireless WiFi driver for Linux
[   12.059850] iwlwifi :6f:00.0: enabling device ( -> 0002)
[   12.068383] iwlwifi :6f:00.0: Detected crf-id 0x3617, cnv-id
0x100530 wfpm id 0x8000
[   12.068487] iwlwifi :6f:00.0: PCI dev 2723/4080, rev=0x340, rfid=0x10a100
[   12.073697] iwlwifi :6f:00.0: TLV_FW_FSEQ_VERSION: FSEQ
Version: 89.3.35.37
[   12.074053] iwlwifi :6f:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[   12.074160] iwlwifi :6f:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[   12.074162] iwlwifi :6f:00.0: loaded firmware version
77.a20fb07d.0 cc-a0-77.ucode op_mode iwlmvm
[   12.080445] Bluetooth: Core ver 2.22
[   12.080462] NET: Registered PF_BLUETOOTH protocol family
[   12.080463] Bluetooth: HCI device and connection manager initialized
[   12.080466] Bluetooth: HCI socket layer initialized
[   12.080468] Bluetooth: L2CAP socket layer initialized
[   12.080470] Bluetooth: SCO socket layer initialized
[   12.113923] usb 1-11: Found UVC 1.50 device Integrated_Webcam_HD (1bcf:28c4)
[   12.131467] usbcore: registered new interface driver uvcvideo
[   12.277127] iwlwifi :6f:00.0: Detected Intel(R) Wi-Fi 6 AX200
160MHz, REV=0x340
[   12.277169] thermal thermal_zone10: failed to read out thermal zone (-61)
[   12.351469] EXT4-fs (sda): mounted filesystem
cd65fcb3-29d2-4aa9-9283-c5779d95a14f r/w with ordered data mode. Quota
mode: none.
[   12.388912] audit: type=1400 audit(1721324237.855:2):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/lxc-start" pid=776 comm="apparmo
r_parser"
[   12.388933] audit: type=1400 audit(1721324237.855:3):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/lxc-copy" pid=775 comm="apparmor
_parser"
[   12.389739] audit: type=1400 audit(1721324237.859:4):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="torbrowser_tor" pid=772 comm="apparmor_pa
rser"
[   12.389938] audit: type=1400 audit(1721324237.859:5):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="nvidia_modprobe" pid=769 comm="apparmor_p
arser"
[   12.389942] audit: type=1400 audit(1721324237.859:6):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="nvidia_modprobe//kmod" pid=769 comm="appa
rmor_parser"
[   12.389943] audit: type=1400 audit(1721324237.859:7):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="lsb_release" pid=767 comm="apparmor_parse
r"
[   12.390294] audit: type=1400 audit(1721324237.859:8):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="/usr/bin/man" pid=777 comm="apparmor_pars
er"
[   12.390297] audit: type=1400 audit(1721324237.859:9):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="man_filter" pid=777 comm="apparmor_parser
"
[   12.390299] audit: type=1400 audit(1721324237.859:10):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="man_groff" pid=777 comm="apparmor_parser
"
[   12.390943] audit: type=1400 audit(1721324237.859:11):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="passt" pid=778 comm="apparmor_parser"
[   12.426669] iwlwifi :6f:00.0: Detected RF HR B3, rfid=0x10a100
[   12.497639] iwlwifi :6f:00.0: base HW address: 5c:80:b6:e9:d7:d9
[   12.568334] input: ACPI Virtual Keyboard Device as
/devices/virtual/input/input22
[   12.683306] input: HDA Intel PCH Headphone Mic as
/devices/pci:00/:00:1f.3/sound/card0/input23
[   12.683354] input: HDA Intel PCH HDMI/DP,pcm=3 as
/devices/pci:00/:00:1f.3/sound/card0/input24
[   12.684214] input: HDA Intel PCH HDMI/DP,pcm=7 as
/devices/pci:00/:00:1f.3/sound/card0/input25
[   12.684261] input: HDA Intel PCH HDMI/DP,pcm=8 as
/devices/pci:00/:00:1f.3/sound/card0/input26
[   12.705467] usb 1-14: USB disconnect, device number 4
[   12.718264] block nvme0n1: No UUID available providing old NGUID
[   12.718973] iwlwifi :6f:00.0 wlp111s0: renamed from wlan0
[   12.727856] usbcore: registered new interface driver btusb
[

Bug#1072274: ITP: fcitx5-varnam -- Fcitx5 wrapper for Varnam input method.

[Boyuan Yang]

在 2024-07-18星期四的 22:00 +0530，Anoop M S写道：
> Hi,
> On Mon, 15 Jul 2024 00:43:38 +0530 Anoop M S  wrote:
>  > Hi,
>  > On Sun, 14 Jul 2024 14:44:59 -0400 Boyuan Yang  wrote:
>  > > Hi,
>  > >
>  > > 在 2024-07-14星期日的 20:59 +0530，Anoop M S写道：
>  > > > On Fri, 31 May 2024 10:48:21 -0400 Boyuan Yang 
>  > wrote:
>  > > >  > Hi,
>  > > >  >
>  > > >  > 在 2024-05-31星期五的 08:19 +，Anoop M S写道：
>  > > >  > > Package: wnpp
>  > > >  > > Severity: wishlist
>  > > >  > > Owner: Anoop M S 
>  > > >  > > X-Debbugs-Cc: debian-de...@lists.debian.org, 
> anoo...@disroot.org
>  > > >  > >
>  > > >  > > * Package name    : fcitx5-varnam
>  > > >  > >   Version : 0.0.1
>  > > >  > >   Upstream Contact: Anoop M S 
>  > > >  > > * URL : 
> https://github.com/varnamproject/varnam-fcitx5
>  > > >  > > * License : GPL
>  > > >  > >   Programming Lang: C++
>  > > >  > >   Description : Fcitx5 wrapper for Varnam input method.
>  > > >  > >
>  > > >  > > Fcitx5 wrapper for Varnam(https://www.varnamproject.com) Input
>  > > > Method Engine.
>  > > >  > > Easily type Indian languages on Linux desktops.
>  > > >  > >
>  > > >  > > I would like to join Debian Input Method Team, and package and
>  > > > maintain it.
>  > > >  > > And I would need a sponsor to upload it as well.
>  > > >  >
>  > > >  > Please prepare an initial version first. You can host it on your
>  > own
>  > > > Salsa git repo
>  > > >  > or via mentors.debian.net , or choose whichever platform that is
>  > more
>  > > > convenient to you.
>  > > >  > Please submit a regular RFS request and notify me once you are
>  > prepared.
>  > > >  >
>  > > >  > If it looks good, I can help to move your git packaging repo 
> to the
>  > > > Salsa Input Method
>  > > >  > Team namespace, sponsor the upload and add you into the Salsa 
> Input
>  > > > Method Team group.
>  > > >  >
>  > > >  > Thanks,
>  > > >  > Boyuan Yang
>  > > >
>  > > > I've prepared an initial release and sent RFS (#1076334).
>  > > >
>  > > > Kindly review at your convenience.
>  > >
>  > > The following issues are critical and must be fixed:
>  > >
>  > > *
>  > 
> https://github.com/varnamproject/varnam-fcitx5/blob/a2c9412461f68a5293cec24609076951e28a3b27/meson.build#L11-L29
>  > > is unacceptable. The build system is only targeting on x86_64 (amd64)
>  > architecture, which is
>  > > not reasonable since Debian and Fedora both support multiple hardware
>  > architectures.
> 
> I've addressed the raised issues in the upstream. And made few changes 
> in the package as well (haven't pushed the code yet).
> Lintian currently showing following issues
> * newer-standards-version 4.7.0
> * debian-watch-does-not-check-openpgp-signature
> * prefer-uscan-symlink
> 
> full text : https://paste.debian.net/plain/1323647
> 
> Are these ignorable? And is there anything else I need to follow to do 
> the version update
>   or can I create a fresh setup with only the new version?

They are of low priority and you can revisit them later. If you would like,
you can try to solve them following the text description you just saw
in that terminal output.

Please prepare a fresh setup with updated source code and version numbers so
that Debian Developers can review.

Thanks,
Boyuan Yang


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

Bug#1076556: opensc: egk-tool shows no data

[Axel Stammler]

Package: opensc
Version: 0.23.0-0.3+deb12u1
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

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

The output never shows any data even though the card is valid and functional:

$ egk-tool -v
Using reader with a card: Lenovo Lenovo USB Smartcard Keyboard [Lenovo Keyboard 
Smartcard Reader] (0911040045) 00 00
Connecting to card in reader Lenovo Lenovo USB Smartcard Keyboard [Lenovo 
Keyboard Smartcard Reader] (0911040045) 00 00...
Using card driver STARCOS.
$ egk-tool --pd
Using reader with a card: Lenovo Lenovo USB Smartcard Keyboard [Lenovo Keyboard 
Smartcard Reader] (0911040045) 00 00
$ egk-tool --vd
Using reader with a card: Lenovo Lenovo USB Smartcard Keyboard [Lenovo Keyboard 
Smartcard Reader] (0911040045) 00 00
$ egk-tool -v --vd
Using reader with a card: Lenovo Lenovo USB Smartcard Keyboard [Lenovo Keyboard 
Smartcard Reader] (0911040045) 00 00
Connecting to card in reader Lenovo Lenovo USB Smartcard Keyboard [Lenovo 
Keyboard Smartcard Reader] (0911040045) 00 00...
Using card driver STARCOS.
$ egk-tool --gvd
Using reader with a card: Lenovo Lenovo USB Smartcard Keyboard [Lenovo Keyboard 
Smartcard Reader] (0911040045) 00 00
$

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

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

Versions of packages opensc depends on:
ii  libc6  2.36-9+deb12u7
ii  libreadline8   8.2-1.3
ii  libssl33.0.13-1~deb12u1
ii  opensc-pkcs11  0.23.0-0.3+deb12u1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages opensc recommends:
ii  pcscd  1.9.9-2

opensc suggests no packages.

-- debconf-show failed

Bug#1076516: libsndfile: Build dependency loop between libsndfile and lame

[Samuel Thibault]

Samuel Thibault, le mer. 17 juil. 2024 17:57:06 +0200, a ecrit:
> That being said, I now notice a loop between libsndfile, mpg123,
> jack-audio-connection-kit, and libsndfile.

The attached patch looks like a reasonable way, just disabling mp3
temporarily, and the loops are small to get mp3 support back in
libsndfile.

Samuel
diff -ur libsndfile-1.2.2/debian/control libsndfile-1.2.2.fixed/debian/control
--- libsndfile-1.2.2/debian/control 2023-08-30 12:34:05.0 +
+++ libsndfile-1.2.2.fixed/debian/control   2024-07-18 06:55:49.0 
+
@@ -9,8 +9,8 @@
  debhelper-compat (= 13),
  libasound2-dev [linux-any],
  libflac-dev,
- libmp3lame-dev,
- libmpg123-dev,
+ libmp3lame-dev ,
+ libmpg123-dev ,
  libogg-dev,
  libopus-dev,
  libspeex-dev,
@@ -30,7 +30,7 @@
 Multi-Arch: same
 Depends:
  libflac-dev,
- libmpg123-dev,
+ libmpg123-dev ,
  libopus-dev,
  libsndfile1 (= ${binary:Version}),
  libvorbis-dev,

Bug#1073661: google-guest-agent: diff for NMU version 20211116.00-6.1

[Chris Hofstaedtler]

Control: tags 1073661 + pending


Dear maintainer,

I've prepared an NMU for google-guest-agent (versioned as 2026.00-6.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru google-guest-agent-2026.00/debian/changelog google-guest-agent-2026.00/debian/changelog
--- google-guest-agent-2026.00/debian/changelog	2022-05-16 11:40:29.0 +0200
+++ google-guest-agent-2026.00/debian/changelog	2024-07-18 20:34:42.0 +0200
@@ -1,3 +1,10 @@
+google-guest-agent (2026.00-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install all files into /usr. (Closes: #1073661)
+
+ -- Chris Hofstaedtler   Thu, 18 Jul 2024 20:34:42 +0200
+
 google-guest-agent (2026.00-6) unstable; urgency=medium
 
   * Don't try to start any services on installation.  (closes: #1010991)
diff -Nru google-guest-agent-2026.00/debian/google-guest-agent.install google-guest-agent-2026.00/debian/google-guest-agent.install
--- google-guest-agent-2026.00/debian/google-guest-agent.install	2022-05-16 11:40:29.0 +0200
+++ google-guest-agent-2026.00/debian/google-guest-agent.install	2024-07-18 20:34:42.0 +0200
@@ -1,5 +1,5 @@
 instance_configs.cfg etc/default
-google-guest-agent.service lib/systemd/system
-google-shutdown-scripts.service lib/systemd/system
-google-startup-scripts.service lib/systemd/system
-90-google-guest-agent.preset lib/systemd/system-preset
+google-guest-agent.service usr/lib/systemd/system
+google-shutdown-scripts.service usr/lib/systemd/system
+google-startup-scripts.service usr/lib/systemd/system
+90-google-guest-agent.preset usr/lib/systemd/system-preset

Bug#1073734: ndctl: diff for NMU version 77-2.1

[Chris Hofstaedtler]

Control: tags 1073734 + pending


Dear maintainer,

I've prepared an NMU for ndctl (versioned as 77-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ndctl-77/debian/changelog ndctl-77/debian/changelog
--- ndctl-77/debian/changelog	2023-06-11 20:35:11.0 +0200
+++ ndctl-77/debian/changelog	2024-07-18 20:46:07.0 +0200
@@ -1,3 +1,11 @@
+ndctl (77-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units into /usr. (Closes: #1073734)
+  * Update Build-Depends: pkg-config to pkgconf.
+
+ -- Chris Hofstaedtler   Thu, 18 Jul 2024 20:46:07 +0200
+
 ndctl (77-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru ndctl-77/debian/control ndctl-77/debian/control
--- ndctl-77/debian/control	2023-05-03 17:24:14.0 +0200
+++ ndctl-77/debian/control	2024-07-18 20:46:07.0 +0200
@@ -4,7 +4,7 @@
 Priority: optional
 Standards-Version: 4.6.2
 Build-Depends: debhelper-compat (= 13),
-   pkg-config,
+   pkgconf,
libkmod-dev,
libudev-dev,
uuid-dev,
diff -Nru ndctl-77/debian/ndctl.install ndctl-77/debian/ndctl.install
--- ndctl-77/debian/ndctl.install	2023-05-03 12:10:06.0 +0200
+++ ndctl-77/debian/ndctl.install	2024-07-18 20:46:07.0 +0200
@@ -1,7 +1,7 @@
 etc/ndctl
 etc/ndctl.conf.d
 etc/modprobe.d/nvdimm-security.conf
-ndctl/*.service lib/systemd/system
+ndctl/*.service usr/lib/systemd/system
 usr/bin/ndctl
 usr/share/bash-completion/completions/ndctl
 usr/share/man/man1/ndctl*

Bug#1076491: base-files: file clash with libc6

[Chris Hofstaedtler]

On Thu, Jul 18, 2024 at 09:37:54AM +0200, Oswald Buddenhagen wrote:
> On Wed, Jul 17, 2024 at 04:28:16PM +0200, Chris Hofstaedtler wrote:
> > in the meantime, please provide more details:
> > 
> > - full upgrade log
> attached

Thanks.

> > - sources.list and priorities
> > - selected/installed (foreign) architectures
> > - package versions before the upgrade
> > 
> the relevant parts are in the original report.

This is not just a problem between base-files and libc6. 
The state of all packages previously installed is relevant.

> > Maybe date of the last full upgrade.
> > 
> 2023-11-07

Chris

Bug#1073693: src:nbd: move aliased files from / to /usr (DEP17)

[Chris Hofstaedtler]

Hi,

thanks for making progress on this!

There is one file left in nbd-client:
  * /lib/systemd/system/nbd-client.service

nbd-server is apparently fully merged now.

Chris

Bug#1076557: transition: libgpiod

[賴建宇]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: libgp...@packages.debian.org
Control: affects -1 + src:libgpiod

Dear release team,

I want to upload the libgpiod v2.1.2 to unstable.
This upload changes API and soname.
Some of the packages that depend on this package need to change.

https://release.debian.org/transitions/html/auto-libgpiod.html

The following list is the status of reverse dependency packages:
- eg25-manager:   FTBFS / BTS: #1070812
  There are patches on the upstream that are under review.
- openfpgaloader: Build OK
- openocd:FTBFS / BTS: #1070885
  There are patches for review around adding proper support,
  but they're all currently works in progress.
- swupdate:   Build OK
- svxlink:Build OK


Ben file:

title = "libgpiod";
is_affected = .depends ~ "libgpiod3" | .depends ~ "libgpiod2t64";
is_good = .depends ~ "libgpiod3";
is_bad = .depends ~ "libgpiod2t64";


Please suggest an appropriate time for the transition.
Thank you.

(This is my first library transition, please let me know if I've missed
anything!)

Bug#1076558: gitlab: install fails to build tree-sitter because of missing g++

[Ondrej Zary]

Package: gitlab
Version: 16.11.6-3~bpo12+1
Severity: important
X-Debbugs-Cc: z...@gsystem.sk

Dear Maintainer,
upgrading failed because of missing g++. Maybe it should be included in 
dependencies?

warning Error running install script for optional dependency: 
"/var/lib/gitlab/node_modules/tree-sitter: Command failed.
Exit code: 127
Command: prebuild-install || node-gyp rebuild
Arguments:
Directory: /var/lib/gitlab/node_modules/tree-sitter
Output:
[-/4] ⠂ waiting...
[-/4] ⠁ waiting...
[-/4] ⠁ waiting...
[3/4] ⠁ tree-sitter-json
[-/4] ⠈ waiting...
[-/4] ⠈ waiting...
[3/4] ⠁ tree-sitter-json
warning Error running install script for optional dependency: 
"/var/lib/gitlab/node_modules/tree-sitter-yaml: Command failed.
Exit code: 1
Command: node-gyp rebuild
Arguments:
Directory: /var/lib/gitlab/node_modules/tree-sitter-yaml
Output:
gyp info it worked if it ends with ok
gyp info using node-gyp@10.2.0
gyp info using node@18.19.0 | linux | x64
gyp info find Python using Python version 3.11.2 found at \"/usr/bin/python3\"

gyp http GET 
https://nodejs.org/download/release/v18.19.0/node-v18.19.0-headers.tar.gz
gyp http 200 
https://nodejs.org/download/release/v18.19.0/node-v18.19.0-headers.tar.gz
gyp http GET https://nodejs.org/download/release/v18.19.0/SHASUMS256.txt
gyp http 200 https://nodejs.org/download/release/v18.19.0/SHASUMS256.txt
gyp info spawn /usr/bin/python3
gyp info spawn args [
gyp info spawn args 
'/var/lib/gitlab/.config/yarn/global/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args 
'/var/lib/gitlab/node_modules/tree-sitter-yaml/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args 
'/var/lib/gitlab/.config/yarn/global/node_modules/node-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args 
'/var/lib/gitlab/.cache/node-gyp/18.19.0/include/node/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/var/lib/gitlab/.cache/node-gyp/18.19.0',
gyp info spawn args 
'-Dnode_gyp_dir=/var/lib/gitlab/.config/yarn/global/node_modules/node-gyp',
gyp info spawn args 
'-Dnode_lib_file=/var/lib/gitlab/.cache/node-gyp/18.19.0/<(target_arch)/node.lib',
gyp info spawn args 
'-Dmodule_root_dir=/var/lib/gitlab/node_modules/tree-sitter-yaml',
gyp info spawn args '-Dnode_engine=v8',
gyp info spawn args '--depth=.',
gyp info spawn args '--no-parallel',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory '/var/lib/gitlab/node_modules/tree-sitter-yaml/build'
  CXX(target) 
Release/obj.target/tree_sitter_yaml_binding/bindings/node/binding.o
make: g++: No such file or directory
make: *** [tree_sitter_yaml_binding.target.mk:117: 
Release/obj.target/tree_sitter_yaml_binding/bindings/node/binding.o] Error 127
make: Leaving directory '/var/lib/gitlab/node_modules/tree-sitter-yaml/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack at ChildProcess. 
(/var/lib/gitlab/.config/yarn/global/node_modules/node-gyp/lib/build.js:216:23)
gyp ERR! System Linux 6.1.0-22-amd64
gyp ERR! command \"/usr/bin/node\" \"/var/lib/gitlab/.yarn/bin/node-gyp\" 
\"rebuild\"
gyp ERR! cwd /var/lib/gitlab/node_modules/tree-sitter-yaml
gyp ERR! node -v v18.19.0


-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-22-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.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 gitlab depends on:
ii  apache2 [httpd]2.4.61-1~deb12u1
ii  asciidoctor2.0.18-2
ii  bc 1.07.1-3+b1
ii  bundler2.3.15-2
ii  bzip2  1.0.8-5+b1
ii  dbconfig-pgsql 2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-font-awesome [node-font-awesome  5.0.10+really4.7.0~dfsg-4.1
]
ii  gitlab-common  16.11.6+ds1-2~bpo12+1
ii  gitlab-workhorse   16.11.6-3~bpo12+1
ii  katex [node-katex] 0.16.4+~cs6.1.0-1
ii  libjs-bootstrap4 [node-bootstrap]  4.6.1+dfsg1-4
ii  libjs-pdf [node-pdfjs-dist]2.14.305+dfsg-2
ii  libjs-popper.js [node-popper.js]   1.16.

Bug#1076559: gitlab: install fails to build cssbundling-rails

[Ondrej Zary]

Package: gitlab
Version: 16.11.6-3~bpo12+1
Severity: important
X-Debbugs-Cc: z...@gsystem.sk

Dear Maintainer,
upgrading failed because cssbundling-rails tries to run 'yarn" which is not in 
PATH.
Workaround: ln -s /usr/share/nodejs/yarn/bin/yarn /usr/bin/yarn

rake aborted!
cssbundling-rails: Command build failed, ensure `yarn build:css` runs without 
errors
/usr/share/rubygems-integration/all/gems/cssbundling-rails-1.4.0/lib/tasks/cssbundling/build.rake:14:in
 `block (2 levels) in '
Tasks: TOP => assets:precompile => css:build
(See full trace by running task with --trace)



-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-22-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.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 gitlab depends on:
ii  apache2 [httpd]2.4.61-1~deb12u1
ii  asciidoctor2.0.18-2
ii  bc 1.07.1-3+b1
ii  bundler2.3.15-2
ii  bzip2  1.0.8-5+b1
ii  dbconfig-pgsql 2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-font-awesome [node-font-awesome  5.0.10+really4.7.0~dfsg-4.1
]
ii  gitlab-common  16.11.6+ds1-2~bpo12+1
ii  gitlab-workhorse   16.11.6-3~bpo12+1
ii  katex [node-katex] 0.16.4+~cs6.1.0-1
ii  libjs-bootstrap4 [node-bootstrap]  4.6.1+dfsg1-4
ii  libjs-pdf [node-pdfjs-dist]2.14.305+dfsg-2
ii  libjs-popper.js [node-popper.js]   1.16.1+ds-6
ii  libruby3.1 [ruby-rexml]3.1.2-7+deb12u1
ii  libssl-dev 3.0.13-1~deb12u1
ii  lsb-base   11.6
ii  node-autosize  4.0.4~dfsg1+~4.0.0-2
ii  node-axios 1.2.1+dfsg-1
ii  node-babel-loader  9.1.0-3
ii  node-babel-plugin-lodash   3.3.4+~cs2.0.1-6
ii  node-babel77.20.15+ds1+~cs214.269.168-3+deb12u2
ii  node-brace-expansion   2.0.1-2
ii  node-cache-loader  4.1.0+~cs2.0.0-4
ii  node-clipboard 2.0.11+ds+~cs9.6.11-1
ii  node-compression-webpack-plugin10.0.0-2
ii  node-copy-webpack-plugin   11.0.0-3
ii  node-core-js   3.26.1-3
ii  node-core-js-compat3.26.1-3
ii  node-core-js-pure  3.26.1-3
ii  node-cron-validator1.3.1-3
ii  node-css-loader6.7.2+~cs14.0.11-1
ii  node-d35.16.0-10
ii  node-d3-selection  1.4.0-8
ii  node-dateformat5.0.3-5
ii  node-dompurify 2.4.1+dfsg+~2.4.0-1
ii  node-exports-loader4.0.0-1
ii  node-file-loader   6.2.0-3
ii  node-fuzzaldrin-plus   0.6.0+dfsg+~0.6.2-3
ii  node-glob  8.0.3+~cs8.4.15-1
ii  node-imports-loader0.8.0-6
ii  node-jed   1.1.1-4
ii  node-jquery3.6.1+dfsg+~3.5.14-1
ii  node-jquery-ujs1.2.3-2
ii  node-js-cookie 3.0.1+~3.0.0-3
ii  node-js-yaml   4.1.0+dfsg+~4.0.5-7
ii  node-jszip 3.10.1+dfsg-1
ii  node-jszip-utils   0.1.0+dfsg-1
ii  node-lodash4.17.21+dfsg+~cs8.31.198.20210220-9
ii  node-marked4.2.3+ds+~4.0.7-2
ii  node-minimatch 5.1.1+~5.1.2-1
ii  node-miragejs  0.1.46+~cs5.6.11-1
ii  node-mousetrap 1.6.5~ds+~1.6.8-1
ii  node-postcss   8.4.20+~cs8.0.23-1
ii  node-prismjs   1.29.0+dfsg+~1.26.0-1
ii  node-prosemirror-markdown  1.8.0-1
ii  node-prosemirror-model 1.16.1+~cs1.1.5-2
ii  node-prosemirror-state 1.3.4-2
ii  node-prosemirror-view  1.23.13-2
ii  node-raven-js  3.22.1+dfsg-7
ii  node-raw-loader4.0.2-3
ii  node-style-loader  3.3.1-2
ii  node-three-orbit-controls  82.1.0-3
ii  node-three-stl-loader  1.0.6-4
ii  node-timeago.js4.0.2-7
ii  node-underscore   

Bug#1076560: pfstools: FTBFS in experimental: ImageMagick silently replaced by GraphicsMagick

[Yavor Doganov]

Source: pfstools
Version: 2.2.0-7
Severity: minor
Tags: sid trixie experimental ftbfs

While build-testing this package for the forthcoming GSL transition, I
encountered a build failure which might be worth fixing.  The precise
command used was:

$ sbuild --extra-repository='deb http://deb.debian.org/debian
  experimental main' --build-dep-resolver=aspcud
  --add-depends='libgsl-dev (>= 2.8)' --arch-any --no-arch-all --no-clean

From the build log:

Get:178 http://deb.debian.org/debian unstable/main amd64 
libgraphicsmagick-q16-3t64 amd64 1.4+really1.3.43-1+b2 [1200 kB]
...
Get:219 http://deb.debian.org/debian unstable/main amd64 libgraphicsmagick1-dev 
amd64 1.4+really1.3.43-1+b2 [1451 kB]
Get:220 http://deb.debian.org/debian unstable/main amd64 
libgraphicsmagick++-q16-12t64 amd64 1.4+really1.3.43-1+b2 [119 kB]
Get:221 http://deb.debian.org/debian unstable/main amd64 
libgraphicsmagick++1-dev amd64 1.4+really1.3.43-1+b2 [308 kB]
Get:222 http://deb.debian.org/debian unstable/main amd64 
libgraphics-magick-perl amd64 1.4+really1.3.43-1+b2 [64.1 kB]
Get:223 http://deb.debian.org/debian unstable/main amd64 
graphicsmagick-libmagick-dev-compat all 1.4+really1.3.43-1 [18.8 kB]
...
-- Could NOT find ImageMagick (missing: ImageMagick_Magick++_LIBRARY 
ImageMagick_MagickCore_LIBRARY)
-- ImageMagick not found. The following commands will not be
compiled: pfsinimgmagick pfsoutimgmagick pfsouthdrhtml.
...
dh_install: warning: Cannot find (any matches for) 
"usr/share/pfstools/hdrhtml_*" (tried in ., debilan/tmp)

dh_install: warning: pfstools missing files: usr/share/pfstools/hdrhtml_*
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:55: override_dh_install] Error 255


I had to replace libmagick++-dev with libmagick++-6.q16-dev in
debian/control to obtain a successful build.  Since the former is a
dummy package, I would suggest to do that change.

This is unlikely to cause any trouble with sid uploads (most probably
the different behavior is due to the aspcud resolver) but it would be
nice to fix so that pfstools can be build-tested against libraries in
experimental.

Bug#1050237: transition: mutter/gnome-shell 46

[Jeremy Bícha]

On Wed, Jul 10, 2024 at 12:03 PM Jeremy Bícha
 wrote:
> The Debian GNOME team requests approval to do this transition now.
>
> Unfortunately, magpie has still not been accepted through Debian NEW
> despite the original upload being 11 months ago. The Debian GNOME team
> has sponsoring uploads to try to help. Practically, budgie-desktop is
> not yet in tasksel so it's not a first tier Debian desktop that shows
> in the Debian Installer and Budgie has far less Debian users than
> GNOME does. Therefore, budgie-desktop will need to be removed from
> Testing for this transition.
>
> There are no other known blocking bugs.
>
> Packages requiring sourceful uploads already staged in Experimental
> ---
> gnome-remote-desktop
> gnome-shell
> gnome-shell-extensions
> mutter
> xdg-desktop-portal-gnome
> yaru-theme
> gnome-shell-extension-arc-menu
> gnome-shell-extension-blur-my-shell
> gnome-shell-extension-caffeine
> gnome-shell-extension-dashtodock
> gnome-shell-extension-dash-to-panel
> gnome-shell-extension-desktop-icons-ng
> gnome-shell-extension-easyscreencast
> gnome-shell-extension-espresso
> gnome-shell-extension-freon
> gnome-shell-extension-gsconnect
> gnome-shell-extension-hard-disk-led
> gnome-shell-extension-hide-activities
> gnome-shell-extension-impatience
> gnome-shell-extension-runcat
> gnome-shell-extension-tiling-assistant
>
> Other packages staged in Experimental not maintained by Debian GNOME
> team members
> --
> gnome-shell-extension-autohidetopbar
> gnome-shell-extension-kimpanel
> gnome-shell-extension-shortcuts
> gnome-shell-pomodoro
> gpaste
>
> Packages that will need to be removed from Testing
> These already have Debian bugs which will be bumped to Serious once
> the transition starts
> -
> budgie-desktop
> budgie-desktop-environment
> budgie-extras
> budgie-indicator-applet
> gnome-shell-extension-flypie
> gnome-shell-extension-gamemode
> gnome-shell-extension-hamster
> gnome-shell-extension-no-annoyance
> gnome-shell-extension-panel-osd
> gnome-shell-extension-system-monitor
> gnome-shell-extension-vertical-overview

Release Team, we have finished the uploads to Unstable we were
planning to do for the GNOME Shell 46 transition. Here is my guess on
the hints to remove incompatible packages:

force-badtest budgie-desktop/10.8.2-3
remove budgie-desktop/10.8.2-3
remove gnome-shell-extension-gamemode/8-3
remove gnome-shell-extension-hamster/0.10.0+git20230901-1
remove gnome-shell-extension-no-annoyance/0+20220925-c6804a4-3.1
remove gnome-shell-extension-panel-osd/1.0.50.gc032923-4
remove gnome-shell-extension-system-monitor/40-6
remove gnome-shell-extension-vertical-overview/10-2

A few GNOME Shell extensions also need to age a few more days before
this transition can migrate to Testing.

Thank you,
Jeremy Bícha

Bug#1076561: linux-image-6.9.9-amd64: Kernel 6.9.9 (amd64) results in huge initramfs size

[Celejar]

Package: src:linux
Version: 6.9.9-1
Severity: normal

Hello,

I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
running out of space on /boot:

*
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
*

It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8:

*
~$ ls -l /boot/initrd.img*
-rw-r--r-- 1 root root  27491557 Jul  8 13:45 /boot/initrd.img-6.9.8-amd64
-rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64
*

Diffing the two initrd files suggests that the problem stems from the
fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP)
firmware in the initrd:

https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html

Arch Linux dealt with this 6 months ago - they claim that the problem
actually began in kernel 6.7:

https://bbs.archlinux.org/viewtopic.php?id=291900
https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238

I suggest that we either figure out a mechanism for reducing the size of
the initrd, or else document the change, as users with modest /boot
partitions will otherwise be in for an unpleasant surprise.

Discussion on debian-user:

https://lists.debian.org/debian-user/2024/07/msg00614.html

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20E2CTO1WW
product_version: ThinkPad W550s
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N11ET54W (1.30 )
board_vendor: LENOVO
board_name: 20E2CTO1WW
board_version: SDK0J40705 WIN

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Lenovo Device [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:2225]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller 
[8086:160c] (rev 09)
Subsystem: Lenovo Device [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI 
Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo Device [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI 
Controller #1 [8086:9cba] (rev 03)
Subsystem: Lenovo Device [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) 
I218-V [8086:15a3] (rev 03)
Subsystem: Lenovo Device [17aa:2226]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition 
Audio Controller [8086:9ca0] (rev 03)
Subsystem: Lenovo Device [17aa:2223]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #6 [8086:9c9a] (rev e3) (prog-if 00 [Normal decode])
Subsystem: Lenovo Device [17aa:2223]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Steppin

Bug#1073641: debomatic: diff for NMU version 0.26-3.1

[Chris Hofstaedtler]

Control: tags 1073641 + pending


Dear maintainer,

I've prepared an NMU for debomatic (versioned as 0.26-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru debomatic-0.26/debian/changelog debomatic-0.26/debian/changelog
--- debomatic-0.26/debian/changelog	2023-11-05 12:22:24.0 +0100
+++ debomatic-0.26/debian/changelog	2024-07-18 21:29:35.0 +0200
@@ -1,3 +1,10 @@
+debomatic (0.26-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rervert workaround for bug #1034219. (Closes: #1073641)
+
+ -- Chris Hofstaedtler   Thu, 18 Jul 2024 21:29:35 +0200
+
 debomatic (0.26-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru debomatic-0.26/debian/patches/bug1034219.patch debomatic-0.26/debian/patches/bug1034219.patch
--- debomatic-0.26/debian/patches/bug1034219.patch	2023-11-03 11:39:33.0 +0100
+++ debomatic-0.26/debian/patches/bug1034219.patch	1970-01-01 01:00:00.0 +0100
@@ -1,20 +0,0 @@
-Index: debomatic/setup.py
-===
 debomatic.orig/setup.py
-+++ debomatic/setup.py
-@@ -72,7 +72,14 @@ class InstallData(install_data):
- self.data_files.extend([('share/doc/debomatic',
-  ['docs/_build/latex/Deb-o-Matic.pdf'])])
- self.install_files('etc')
--self.install_files('usr')
-+
-+# Temporary workaround for https://bugs.debian.org/1034219
-+# self.install_files('usr')
-+os.symlink('usr/lib', 'lib')
-+self.install_files('lib')
-+os.unlink('lib')
-+# End of workaround
-+
- self.install_files('modules', 'share/debomatic')
- with SbuildCommands():
- self.install_files('sbuildcommands', 'share/debomatic', True)
diff -Nru debomatic-0.26/debian/patches/series debomatic-0.26/debian/patches/series
--- debomatic-0.26/debian/patches/series	2023-11-03 11:39:33.0 +0100
+++ debomatic-0.26/debian/patches/series	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-bug1034219.patch

Bug#1074303: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[Marco Moock]

Am 18.07.2024 um 18:30:44 Uhr schrieb pham...@bluewin.ch:

> The command line you asked me to enter is invalid ?!?!
> sudo nmcli general logging level LEVEL domains ALL

LEVEL must be replaced by the level, e.g. INFO or DEBUG.

sudo nmcli general logging level DEBUG domains all

After that please check if the change has been applied:

sudo nmcli general logging

This must show DEBUG for all domains. If not, no debug logs will be
produced.

If that is the case, help can continue.

> On top of that you closed my previous bug for no reason and I had to
> reopen it.

This wasn't me.

> Forgive me for being blunt, but what's the problem? You
> don't have time to deal with it? If that's it, there are other
> maintainers who are most certainly ready to take over, don't you
> think?

I can understand that you are annoyed, but unless your system produces
DEBUG logs, nobody can further investigate that.

-- 
kind regards
Marco

Bug#1076562: bullseye-pu: package imagemagick/8:6.9.11.60+dfsg-1.3+deb11u4

[Bastien Roucariès]

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

[ Reason ]

  * CVE-2023-34151 fix was incomplete (Closes: #1070340)
  * Fix variation of CVE-2023-1289 found by testing.

[ Impact ]

  * CVE are still open is not fixed


[ Tests ]

Manual test of CVE-2023-34151, automatic of CVE-2023-1289.
Cross checked by santiago

[ Risks ]

Risk are low, crosscheck done by santiago.

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

[Other changes]

Update d/changelog for old fixed CVE. Investigated status with carnil
diff -Nru imagemagick-6.9.11.60+dfsg/debian/changelog imagemagick-6.9.11.60+dfsg/debian/changelog
--- imagemagick-6.9.11.60+dfsg/debian/changelog	2024-02-17 15:31:24.0 +
+++ imagemagick-6.9.11.60+dfsg/debian/changelog	2024-07-11 16:52:37.0 +
@@ -1,3 +1,12 @@
+imagemagick (8:6.9.11.60+dfsg-1.3+deb11u4) bullseye; urgency=medium
+
+  * CVE-2023-34151 fix was incomplete (Closes: #1070340)
+  * Fix variation of CVE-2023-1289 found by testing.
+  * Fix CVE-2021-20312: Fix a divide by zero (Closes: #1013282)
+  * Fix CVE-2021-20313: Fix a divide by zero
+
+ -- Bastien Roucari??s   Thu, 11 Jul 2024 16:52:37 +
+
 imagemagick (8:6.9.11.60+dfsg-1.3+deb11u3) bullseye-security; urgency=medium
 
   * Fix CVE-2021-3610 heap buffer overflow vulnerability in TIFF coder
@@ -33,7 +42,7 @@
 was found in coders/tiff.c in ImageMagick. This issue
 may allow a local attacker to trick the user into opening
 a specially crafted file, resulting in an application crash
-and denial of service.
+and denial of service. Fix also CVE-2022-3213.
   * Fix CVE-2023-5341: A heap use-after-free flaw was found in
 coders/bmp.c
 
@@ -57,8 +66,11 @@
   * Fix CVE-2022-28463: Buffer overflow in cin coder.
   * Fix CVE-2022-32545: Value outside the range of unsigned char
 (Closes: #1016442)
+  * Fix CVE-2021-40211: Division by zero in function ReadEnhMetaFile
+of coders/emf.c.
   * Fix CVE-2022-32546: Value outside the range of representable
-values of type 'unsigned long' at coders/pcl.c,
+values of type 'unsigned long' at coders/pcl.c
+  * Fix CVE-2022-32547: fix a misaligned address access.
   * Use Salsa CI
 
  -- Bastien Roucari??s   Fri, 29 Dec 2023 11:18:56 +
diff -Nru imagemagick-6.9.11.60+dfsg/debian/control imagemagick-6.9.11.60+dfsg/debian/control
--- imagemagick-6.9.11.60+dfsg/debian/control	2024-02-12 19:54:48.0 +
+++ imagemagick-6.9.11.60+dfsg/debian/control	2024-07-11 16:46:06.0 +
@@ -1,4 +1,4 @@
-# Autogenerated Mon Jul 27 10:33:31 CEST 2020 from make -f debian/rules update_pkg
+# Autogenerated Tue Jun 25 18:15:31 UTC 2024 from make -f debian/rules update_pkg
 Source: imagemagick
 Section: graphics
 Priority: optional
diff -Nru imagemagick-6.9.11.60+dfsg/debian/patches/0068-CVE-2021-20312-CVE-2021-20313-possible-divide-by-zer.patch imagemagick-6.9.11.60+dfsg/debian/patches/0068-CVE-2021-20312-CVE-2021-20313-possible-divide-by-zer.patch
--- imagemagick-6.9.11.60+dfsg/debian/patches/0068-CVE-2021-20312-CVE-2021-20313-possible-divide-by-zer.patch	1970-01-01 00:00:00.0 +
+++ imagemagick-6.9.11.60+dfsg/debian/patches/0068-CVE-2021-20312-CVE-2021-20313-possible-divide-by-zer.patch	2024-07-11 16:46:06.0 +
@@ -0,0 +1,166 @@
+From: Cristy 
+Date: Thu, 25 Feb 2021 17:03:18 -0500
+Subject: CVE-2021-20312/CVE-2021-20313 possible divide by zero + clear
+ buffers
+
+---
+ coders/thumbnail.c  |  3 ++-
+ magick/cipher.c | 12 ++--
+ magick/colorspace.c | 16 
+ magick/memory.c | 21 -
+ magick/signature.c  |  2 +-
+ 5 files changed, 33 insertions(+), 21 deletions(-)
+
+diff --git a/coders/thumbnail.c b/coders/thumbnail.c
+index f456faa..3833341 100644
+--- a/coders/thumbnail.c
 b/coders/thumbnail.c
+@@ -198,7 +198,8 @@ static MagickBooleanType WriteTHUMBNAILImage(const ImageInfo *image_info,
+   break;
+ q++;
+   }
+-  if ((q+length) > (GetStringInfoDatum(profile)+GetStringInfoLength(profile)))
++  if ((q > (GetStringInfoDatum(profile)+GetStringInfoLength(profile))) ||
++  (length > (GetStringInfoDatum(profile)+GetStringInfoLength(profile)-q)))
+ ThrowWriterException(CoderError,"ImageDoesNotHaveAThumbnail");
+   thumbnail_image=BlobToImage(image_info,q,length,&image->exception);
+   if (thumbnail_image == (Image *) NULL)
+diff --git a/magick/cipher.c b/magick/cipher.c
+index a6d90fc..e7b5a81 100644
+--- a/magick/cipher.c
 b/magick/cipher.c
+@@ -485,8 +485,8 @@ static void EncipherAESBlock(AESInfo *aes_info,const unsigned char *plaintext,
+ Reset registers.
+   */
+   alpha=0;
+-  (void) memset(key,0,sizeof(key));
+-  (void) memset(text

Bug#1076562: forcemerge

[Bastien Roucariès]

control: forcemerge 1076158 -1 



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

Bug#1076034: linux-image-6.1.0-22-amd64: Frequent system lockups with "timed out waiting for forcewake ack request"

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Thu, Jul 11, 2024 at 09:50:18AM -0500, S. wrote:
> Had the same thing happen with the 6.1.0-21 kernel, so I tried the 6.7.12 
> kernel from Backports. Then while booted into that kernel it happened again, 
> but this time I SSHed into the system from another computer and found a 
> coredump from i915:
> 
> 
> 
> Jul 10 15:17:01 IntelNUC9 CRON[44323]: pam_unix(cron:session): session opened 
> for user root(uid=0) by (uid=0)
> Jul 10 15:17:01 IntelNUC9 CRON[44325]: (root) CMD (cd / && run-parts --report 
> /etc/cron.hourly)
> Jul 10 15:17:01 IntelNUC9 CRON[44323]: pam_unix(cron:session): session closed 
> for user root
> Jul 10 15:18:18 IntelNUC9 kernel: i915 :00:02.0: [drm] *ERROR* media: 
> timed out waiting for forcewake ack request.
> Jul 10 15:18:18 IntelNUC9 kernel: i915 :00:02.0: [drm:add_taint_for_CI 
> [i915]] CI tainted:0x9 by fw_domains_get_with_fallback+0x1f5/0x250 [i915]
> Jul 10 15:18:18 IntelNUC9 kernel: i915 :00:02.0: [drm] Resetting rcs0 for 
> preemption time out
> Jul 10 15:18:18 IntelNUC9 kernel: i915 :00:02.0: [drm] *ERROR* GT0: rcs0 
> reset request timed out: {request: 0001, RESET_CTL: 0001}
> Jul 10 15:18:18 IntelNUC9 kernel: i915 :00:02.0: [drm] GPU HANG: ecode 
> 9:1:eedf, in zoom.real [39829]
> Jul 10 15:18:28 IntelNUC9 kernel: Asynchronous wait on fence 
> :00:02.0:cinnamon[1948]:137a40 timed out (hint:intel_atomic_commit_ready 
> [i915])
> Jul 10 15:18:31 IntelNUC9 wpa_supplicant[1392]: wlan0: 
> CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-69 noise= txrate=1000
> Jul 10 15:18:34 IntelNUC9 kernel: BUG: kernel NULL pointer dereference, 
> address: 0270
> Jul 10 15:18:34 IntelNUC9 kernel: #PF: supervisor read access in kernel mode
> Jul 10 15:18:34 IntelNUC9 kernel: #PF: error_code(0x) - not-present page
> Jul 10 15:18:34 IntelNUC9 kernel: PGD 80018e8a8067 P4D 80018e8a8067 
> PUD 6bf133067 PMD 6bf041067 PTE 0
> Jul 10 15:18:34 IntelNUC9 kernel: Oops:  [#1] PREEMPT SMP PTI
> Jul 10 15:18:34 IntelNUC9 kernel: CPU: 5 PID: 264 Comm: kworker/5:1H Tainted: 
> GW  6.7.12+bpo-amd64 #1  Debian 6.7.12-1~bpo12+1
> Jul 10 15:18:34 IntelNUC9 kernel: Hardware name: Intel(R) Client Systems 
> LAPQC71A/LAPQC71A, BIOS QCCFL357.0144.2022.0124.1433 01/24/2022
> Jul 10 15:18:34 IntelNUC9 kernel: Workqueue: events_highpri heartbeat [i915]
> Jul 10 15:18:34 IntelNUC9 kernel: RIP: 0010:__i915_gpu_coredump+0x227/0x760 
> [i915]
> Jul 10 15:18:34 IntelNUC9 kernel: Code: 44 24 08 85 c0 79 37 49 8b 74 24 08 
> 48 8b 44 24 20 49 8d 54 24 18 48 8b 36 48 8b 48 20 4c 8b 40 28 48 8b 7e 08 48 
> 8b 74 24 18 <44> 0f b7 8e 70 02 00 00 48 c7 c6 50 88 38 c1 e8 95 29 85 d1 48 
> 8b
> Jul 10 15:18:34 IntelNUC9 kernel: RSP: :b08580793c88 EFLAGS: 00010286
> Jul 10 15:18:34 IntelNUC9 kernel: RAX: 9980db2e2680 RBX: 9983fa32ac00 
> RCX: 1155
> Jul 10 15:18:34 IntelNUC9 kernel: RDX: 997e80f74018 RSI:  
> RDI: 997e81fb70c0
> Jul 10 15:18:34 IntelNUC9 kernel: RBP:  R08: 398c 
> R09: 
> Jul 10 15:18:34 IntelNUC9 kernel: R10:  R11: e164 
> R12: 997e80f74000
> Jul 10 15:18:34 IntelNUC9 kernel: R13: 997f10e63000 R14: 9980030df000 
> R15: 997f10e63c00
> Jul 10 15:18:34 IntelNUC9 kernel: FS:  () 
> GS:99861db4() knlGS:
> Jul 10 15:18:34 IntelNUC9 kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jul 10 15:18:34 IntelNUC9 kernel: CR2: 0270 CR3: 000415a66004 
> CR4: 003706f0
> Jul 10 15:18:34 IntelNUC9 kernel: Call Trace:
> Jul 10 15:18:34 IntelNUC9 kernel:  
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __die+0x23/0x70
> Jul 10 15:18:34 IntelNUC9 kernel:  ? page_fault_oops+0x171/0x4e0
> Jul 10 15:18:34 IntelNUC9 kernel:  ? intel_gt_mcr_lock+0x42/0x140 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  ? exc_page_fault+0x77/0x170
> Jul 10 15:18:34 IntelNUC9 kernel:  ? asm_exc_page_fault+0x26/0x30
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __i915_gpu_coredump+0x227/0x760 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __i915_gpu_coredump+0x1fc/0x760 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  i915_capture_error_state+0x61/0xd0 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  intel_gt_handle_error+0x3c7/0x3e0 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  ? execlists_submission_tasklet+0xfd/0x1740 
> [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  heartbeat+0x3c2/0x3d0 [i915]
> Jul 10 15:18:34 IntelNUC9 kernel:  process_one_work+0x17c/0x350
> Jul 10 15:18:34 IntelNUC9 kernel:  worker_thread+0x27b/0x3a0
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __pfx_worker_thread+0x10/0x10
> Jul 10 15:18:34 IntelNUC9 kernel:  kthread+0xe5/0x120
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __pfx_kthread+0x10/0x10
> Jul 10 15:18:34 IntelNUC9 kernel:  ret_from_fork+0x31/0x50
> Jul 10 15:18:34 IntelNUC9 kernel:  ? __pfx_kth

Bug#1071381: linux-image-6.1.0-15-amd64: (regression) spontaneous freezing on Thinkpad

[Salvatore Bonaccorso]

Conrol: tags -1 + moreinfo

Hi,

On Mon, Jul 15, 2024 at 02:16:51PM +0200, Manny wrote:
> * Bastian Blank  [2024-05-18 10:03]:
> > 
> > You run with modules that modify low level system characteristics.  Do
> > the freezes also happen without?
> 
> Sorry I missed this reply. It did not make it to my inbox for some
> reason and I am just noticing it today. This msg answers that
> question:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071520#5
> 
> Specifically:
> 
>   “The tp-smapi-dkms modules were initially suspect, but kernel
>version 6.1.90-1 still froze when tp_smapi and thinkpad_ec modules
>were removed.”

Now, with the OOT modules removed and the most recent 6.1.y kernel
(6.1.99-1) are those freezes still reproducible? Any change that
something get logged and you could provide the logs?

Is the issue reproducible still as well with recent kernels from the
upper suites? Ideally est 6.9,9-1 in unstable and/or 6.10-1~exp1 in
experimental.

If that is the case and there is a regression between the 5.10.y
series and 6.1.y onwards, then it might be worth to report to the
upstream regression list, in which case having some more identifying
points would be helpful. 

Regards,
Salvatore

Bug#1076512: Info received (Bug#1076512: Info received (Bug#1076512: Acknowledgement (glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails)))

[John David Anglin]

Upstream patch:
https://sourceware.org/pipermail/libc-alpha/2024-July/158419.html

BZ:
https://sourceware.org/bugzilla/show_bug.cgi?id=31989

Regard,
Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1076538: centreon-plugins: Synology check reports failing disk as OK

[Baptiste Beauplat]

Hi Adam,

On Thu, 2024-07-18 at 09:34 +0200, Adam Cecile wrote:
> Current check for Synology is quite broken as it reports failing disks as OK,
> due to a typo in code.
> 
> Upstream fix is here: https://github.com/centreon/centreon-plugins/pull/4750
> 
> I updated manually the Debian package to version 20240711 and it worked
> flawlessly, so I guess it is the way to go.

Yeah, I've had an update of centreon-plugins in my todo for a couple of
weeks now (actually, since sebastic made me realized they changed their
tag naming scheme and uscan wasn't picking up on new version...).

Should be done in the next few days, I'll let you known.

-- 
Baptiste Beauplat



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

Bug#1072495: (no subject)

[Arnaud Gomes-do-Vale]

Dear Maintainer,

This bug is still current with kernel 6.9.7-1~bpo12+1.

Regards,
-- 
Arnaud

Bug#1073679: gdisk: move aliased files from / to /usr (DEP17)

[Michael Biebl]

Hi Jonathan,

would be great if the version from experimental is uploaded to unstable.
Thanks in advance!

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076563: gtk+2.0: FTBFS on hurd-any

[Samuel Thibault]

Source: gtk+2.0
Version: 2.24.33-5
Severity: important
Tags: patch ftbfs

Hello,

gtk+2.0 currently FTBFS on hurd-any because of a missing function
declaration. Considering the EOL status upstream, it's probably simpler
to just patch over in Debian, could you add the attached patch to fix
it?

Thanks,
Samuel

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

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

-- 
Samuel
 M.  MIMRAM  Samuel Antonin
 en voila un qui etait predestiné
 -+- #ens-mim - Quelles gueules qu'ils ont les ptits nouveaux ? -+-
Index: gtk+2.0-2.24.33/modules/printbackends/cups/gtkprintbackendcups.c
===
--- gtk+2.0-2.24.33.orig/modules/printbackends/cups/gtkprintbackendcups.c
+++ gtk+2.0-2.24.33/modules/printbackends/cups/gtkprintbackendcups.c
@@ -19,7 +19,7 @@
  * Boston, MA 02111-1307, USA.
  */
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__GNU__)
 #define _GNU_SOURCE
 #endif
 

Bug#1073654: zsh: patch

[Chris Hofstaedtler]

Control: tags 1073654 + patch

Please find a patch attached.

Chris

diff -Nru zsh-5.9/debian/changelog zsh-5.9/debian/changelog
--- zsh-5.9/debian/changelog	2024-01-09 11:15:01.0 +0100
+++ zsh-5.9/debian/changelog	2024-07-18 21:50:11.0 +0200
@@ -1,3 +1,10 @@
+zsh (5.9-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install into /usr-merged layout. (Closes: #1073654)
+
+ -- Chris Hofstaedtler   Thu, 18 Jul 2024 21:50:11 +0200
+
 zsh (5.9-6) unstable; urgency=medium
 
   * [c366ecc] Cherry pick upstream commit ecd3f9c9 to fix FTBFS issue with
diff -Nru zsh-5.9/debian/rules zsh-5.9/debian/rules
--- zsh-5.9/debian/rules	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/rules	2024-07-18 21:50:11.0 +0200
@@ -16,7 +16,6 @@
 
 CONFIGFLAGS =  --prefix=/usr
 CONFIGFLAGS += --mandir=/usr/share/man
-CONFIGFLAGS += --bindir=/bin
 CONFIGFLAGS += LDFLAGS="-g $(H_LDFLAGS)"
 
 CONFIGFLAGS += --infodir=/usr/share/info
@@ -140,20 +139,20 @@
 override_dh_auto_install-arch:
 	cd obj && $(MAKE) install.bin install.modules \
 	DESTDIR=$(CURDIR)/debian/zsh INSTALL_PROGRAM='$(INSTALL_PROGRAM)'
-	rm debian/zsh/bin/zsh-5.[0-9]*
+	rm debian/zsh/usr/bin/zsh-5.[0-9]*
 
 override_dh_shlibdeps-arch:
 	dh_shlibdeps -pzsh -- \
-		-dDependsdebian/zsh/bin/*   \
+		-dDependsdebian/zsh/usr/bin/*   \
 		-dRecommends debian/zsh/usr/lib/*/zsh/*/zsh/*.so
 
 execute_after_dh_installdocs-arch:
 	awk 'BEGIN { print "The following modules are statically-compiled into the static zsh binary:\n"; } /link=static/ { printf "%s (%s %s)\n", substr($$1,6), $$4, $$5; }' obj-static/config.modules >debian/zsh-static/usr/share/doc/zsh-static/README.Debian
 
 execute_after_dh_install-arch:
-	mv debian/zsh-static/bin/zsh  debian/zsh-static/bin/zsh-static
-	mv debian/zsh-static/bin/zsh5 debian/zsh-static/bin/zsh5-static
-	sed -e 's:#!/bin/zsh:#!/bin/zsh-static:' -i debian/zsh-static/bin/zsh5-static
+	mv debian/zsh-static/usr/bin/zsh  debian/zsh-static/usr/bin/zsh-static
+	mv debian/zsh-static/usr/bin/zsh5 debian/zsh-static/usr/bin/zsh5-static
+	sed -e 's:#!/bin/zsh:#!/bin/zsh-static:' -i debian/zsh-static/usr/bin/zsh5-static
 
 	find debian/zsh-dev/usr/include/zsh -name '*.h' -o -name '*.mdh' | \
 	  xargs sed -e 's@\.\./config\.h@config.h@;s@#\(\s*\)include "\([^"]\+\)"@#\1include @' -i
diff -Nru zsh-5.9/debian/zsh.dirs zsh-5.9/debian/zsh.dirs
--- zsh-5.9/debian/zsh.dirs	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.dirs	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-bin
diff -Nru zsh-5.9/debian/zsh.install zsh-5.9/debian/zsh.install
--- zsh-5.9/debian/zsh.install	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.install	2024-07-18 21:50:11.0 +0200
@@ -1,2 +1,2 @@
-debian/zsh5 bin
+debian/zsh5 usr/bin
 debian/shells.d/zsh usr/share/debianutils/shells.d/
diff -Nru zsh-5.9/debian/zsh.links zsh-5.9/debian/zsh.links
--- zsh-5.9/debian/zsh.links	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.links	2024-07-18 21:50:11.0 +0200
@@ -1,4 +1,4 @@
-/bin/zsh /bin/rzsh
+/usr/bin/zsh /usr/bin/rzsh
 /usr/share/doc/zsh-common /usr/share/doc/zsh/doc
 /usr/share/doc/zsh-common/NEWS.gz /usr/share/doc/zsh/NEWS.gz
 /usr/share/doc/zsh-common/README.Debian /usr/share/doc/zsh/README.Debian
diff -Nru zsh-5.9/debian/zsh.lintian-overrides zsh-5.9/debian/zsh.lintian-overrides
--- zsh-5.9/debian/zsh.lintian-overrides	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.lintian-overrides	2024-07-18 21:50:11.0 +0200
@@ -1,11 +1,4 @@
 # Only two of many files affected -> likely a false positive
 zsh: hardening-no-fortify-functions [usr/lib*/zsh/*/zsh/zleparameter.so]
 # Migration wrapper which is not meant to be used
-zsh: no-manual-page [bin/zsh5]
-# Code either adding all path variants to /etc/shells or fixing
-# usrmerge crap which would not be in the maintainer scripts if we
-# could just simply ship those symlinks inside the .deb.
-zsh: bin-sbin-mismatch usr/bin/zsh -> bin/zsh [postinst]
-zsh: bin-sbin-mismatch usr/bin/zsh -> bin/zsh [postrm]
-# It's a comment.
-zsh: bin-sbin-mismatch usr/bin/zsh -> bin/zsh [bin/zsh5]
+zsh: no-manual-page [usr/bin/zsh5]
diff -Nru zsh-5.9/debian/zsh.postinst zsh-5.9/debian/zsh.postinst
--- zsh-5.9/debian/zsh.postinst	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.postinst	2024-07-18 21:50:11.0 +0200
@@ -12,12 +12,6 @@
 
 case "$1" in
 (configure)
-	# New hardcoded symlinks which unfortunately can't be shipped inside
-	# the package itself since some people want to merge /bin and /usr/bin
-	# against FHS and all Unix tradition.
-	if [ ! -e /usr/bin/zsh -a ! -L /usr/bin/zsh ]; then
-	  ln -s /bin/zsh /usr/bin/zsh
-	fi
 ;;
 (abort-upgrade|abort-remove|abort-deconfigure)
 	exit 0
diff -Nru zsh-5.9/debian/zsh.postrm zsh-5.9/debian/zsh.postrm
--- zsh-5.9/debian/zsh.postrm	2024-01-09 11:14:12.0 +0100
+++ zsh-5.9/debian/zsh.postrm	1970-01-01 01:00:00.0 +0100
@@ -1,15 +0,0 @@
-#!/bin/sh
-
-set -

Bug#1076135: reptyr: FTBFS: add support for loongarch64

[Evan Broder]

Hi -

Can you please work with the upstream project (
https://github.com/nelhage/reptyr) to add support for loongarch64? I would
prefer to not carry a patch local to the Debian packaging for a new arch
given that upstream is generally responsive to new architectures.

- Evan

Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

[Aurelien Jarno]

Hi,

On 2024-05-06 23:14, Aurelien Jarno wrote:
> Dear maintainers,
> 
> glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in
> order to support math vector functions. This unfortunately caused the
> FTBFS of your packages.
> 
> The change has been temporarily reverted in version 2.38-8 until a fix
> is found, and I have opened #1070668 on the glibc side to track the
> issue, with a Cc: to the arm64 porters.
> 
> I am therefore downgrading the bugs to severity important. However this
> should not prevent working on a solution to the problem with the arm64
> porters, and depending on the case either at the package level, or at
> the upstream glibc/gcc/llvm level.

With glibc 2.39, the revert is not possible anymore, therefore I
rocm-hipamd FTBFS again. I have therefore upgraded the severity to
serious.

Emanuele Rocca is working on a solution on the upstream LLVM side. In
the meantime we might have to remove the rocm-hipamd arm64 binaries to
let glibc and future rocm-hipamd migrate to testing.

Regards
Aurelien

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

Bug#1076564: pahole BTF processing seems flaky on powerpc

[Ben Hutchings]

Package: pahole
Version: 1.27-1
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

Several kernel builds on powerpc have failed recently:

6.8.12-1:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1
6.9.9-1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1
6.10-1~exp1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1

Note, these log files are up to 270 MB in size and should be
downloaded; at least Firefox becomes unresponsive when trying to
display them.

For each of these, the failure seems to start with an error from
pahole such as:

[102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error 
emitting BTF type
Encountered error while encoding BTF.

This does *not* happen consistently.  Compare these successful
builds:

6.8.12-1:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717278092&raw=1
- This same version failed to build on the first try.
6.9.7-1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.7-1&stamp=1719538806&raw=1
- Earlier and later 6.9.x versions failed to build.

Both pahole versions 1.26-1 and 1.27-1 have been used in both
successful and failing builds.

Ben.

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

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

Versions of packages pahole depends on:
ii  libbpf1 1:1.4.3-1
ii  libc6   2.39-4
ii  libdw1t64   0.191-2
ii  libelf1t64  0.191-2
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

pahole recommends no packages.

pahole suggests no packages.

-- debconf-show failed

Bug#1076565: build-essential: unable to install build-essential (binutils is not installable)

[Anthony Anthor]

Package: build-essential
Version: 12.10
Severity: important
X-Debbugs-Cc: anthony.anthor@gmail.com

I want to install build-essential on debian sid, but i got this error with apt
"apt install build-essential

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 dpkg-dev : Depends: binutils but it is not installable
Recommends: fakeroot
Recommends: libalgorithm-merge-perl but it is not going to be
installed
 gcc-13 : Depends: binutils (>= 2.42.50.20240710) but it is not installable
Error: Unable to correct problems, you have held broken packages."

I tried to install binutils-x86-64-linux-gnu thinking it would fix the
dependency problem, but it didn't.

Anthony


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

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

Versions of packages build-essential depends on:
pn  dpkg-dev  
pn  g++   
pn  gcc   
ii  libc6-dev [libc-dev]  2.39-4
ii  make  4.3-4.1

build-essential recommends no packages.

build-essential suggests no packages.

Bug#1076566: sssd: removed from testing (trixie) breaks authentication on local network entirely

[Ingo]

Package: sssd
Version: 2.9.5-3
Severity: important
Tags: upstream

Dear Maintainer,

* What led up to the situation?
Doing full-upgrade on my testing (trixie) workstation.

* What exactly did you do (or not do) that was effective (or
* ineffective)?
~$ sudo apt full-upgrade

* What was the outcome of this action?
The sssd package and all its dependent packages are removed, e.g.
sssd-common, sssd-krb5, sssd-krb5-common, sssd-ldap, and so on (not a
complete list). This breaks authentication on all my testing
workstations on the local network. I cannot login anymore.

* What outcome did you expect instead?
Even if migration from unstable to testing fails the package should not
be removed entirely from testing. The latest migrated package should be
preserved. In this case it is sssd 2.9.4-1.
https://tracker.debian.org/pkg/sssd

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

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

Bug#1076567: ffmpeg: Please break build dependency loop through libcaca

[Samuel Thibault]

Package: ffmpeg
Version: 7:6.1.1-4+b4
Severity: important

Hello,

We have a build dependency loop:

ffmpeg <- libcaca-dev <- libcaca <- libimlib2-dev <- imlib2 <-
libheif-dev <- libheif <- libavcodec-dev <- ffmpeg

Could you make the libcaca-dev build-dependency  to
break this loop?

Thanks,
Samuel

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

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

Versions of packages ffmpeg depends on:
ii  libavcodec607:6.1.1-4+b4
ii  libavdevice60   7:6.1.1-4+b4
ii  libavfilter97:6.1.1-4+b4
ii  libavformat60   7:6.1.1-4+b4
ii  libavutil58 7:6.1.1-4+b4
ii  libc6   2.38-14
ii  libpostproc57   7:6.1.1-4+b4
ii  libsdl2-2.0-0   2.30.4+dfsg-1
ii  libswresample4  7:6.1.1-4+b4
ii  libswscale7 7:6.1.1-4+b4

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

-- 
Samuel
"c'est pas nous qui sommes à la rue, c'est la rue qui est à nous"

Bug#1075991: please upgrade to v0.30

[Peter Michael Green]

> Please upgrade to, or separately provide, sysinfo branch v0.30.

I've uploaded the new version of rust-sysinfo to experimental.

There are four reverse dependencies,  btm, git-delta, 
rust-process-viewer and rust-vergen.


rust-process-viewer and rust-vergen are rust-team packages:

rust-process-viewer already uses 0.30 upstream and is currently 
downpatched in Debian.


rust-vergen has a new 8.x release that uses sysinfo 0.30, which I have 
packaged

and uploaded to experimental.

btm and git-delta are Jonas's packages. Jonas can you take a look at them
and tell me when you are ready for an upload to unstable?

Bug#1076331: kwayland-integration: The package depends on old Qt5/KDE5 packages.

[Justin Geibel]

Dear Maintainer,

I'm another user attempting to try out the bleeding edge bits in
experimental, and I think I'm running into this issue as well.

What I'm seeing is:
* kwayland-integration 6.1.0-1 depends on libkf5waylandclient5
=4:5.115.0-2+b1 which depends on kwayland-data =4:5.115.0-2
* libkwayland-client6 4:6.1.0-2 depends on kwayland-data =4:6.1.0-2

I think this is probably because kwayland 6.1.0-3 (which appears to address
this co-installability issue) was rejected as a source-only upload to NEW.

https://lists.debian.org/debian-qt-kde/2024/07/msg00131.html

Happy Hacking,
Justin

Bug#1076568: dpkg: no longer evaluates variables in DEB_CPPFLAGS_MAINT_APPEND

[Andreas Beckmann]

Package: dpkg
Version: 1.22.7
Severity: important
X-Debbugs-Cc: Graham Inggs 

I suspect dpkg 1.22.7 to cause a regression when building
nvidia-cuda-toolkit, e.g.

https://buildd.debian.org/status/fetch.php?pkg=nvidia-cuda-toolkit&arch=amd64&ver=12.1.1-2&stamp=1721290167&raw=0

debian/rules has

DEB_BUILD_MAINT_OPTIONS  = hardening=+all
DEB_CPPFLAGS_MAINT_APPEND= 
-I$(CURDIR)/nvidia-cuda-tree-$(DEB_HOST_ARCH)/cuda_cudart/include
DEB_LDFLAGS_MAINT_APPEND = -pthread

include /usr/share/dpkg/architecture.mk
include /usr/share/dpkg/buildflags.mk
include /usr/share/dpkg/pkg-info.mk

and the build log now contains

/bin/sh: 1: CURDIR: not found
/bin/sh: 1: DEB_HOST_ARCH: not found

(and a subsequent failure since some header could not be found)

which makes me suspect that the variables in DEB_CPPFLAGS_MAINT_APPEND
are no longer evaluated and passed on into sh context.

(If I'm not using DEB_CPPFLAGS_MAINT_APPEND correctly, please suggest
what I should do instead)

Andreas

Bug#1052385: st: Add patch

[wuruilong]

Source: st
Version: 1.9-3.4
Followup-For: Bug #1052385
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The patch that supports the loongarch architecture was created with reference 
to riscv's code, and has been tested to compile successfully on loongarch.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 st (1.9-3.4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * debian/patches/02-implicit-declarations.patch: Fix an improper macro
 feature check. Thanks to Zixing Liu .
 (Closes: #1065797, #1066287, LP: #2060973)
   * debian/patches/1032955_riscv_support.patch: Add support for RISC-V
 CPU. Thanks to Steven Liu .
 (Closes: #1032955, LP: #2061639)
   * Switch from transitional pkg-config to pkgconf.
   * Whitespace cleanup.
Author: Andreas Beckmann 
Bug-Debian: https://bugs.debian.org/1032955
Bug-Debian: https://bugs.debian.org/1065797
Bug-Debian: https://bugs.debian.org/1066287
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2060973
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2061639

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-07-18

--- st-1.9.orig/md.S
+++ st-1.9/md.S
@@ -507,5 +507,77 @@ _st_md_cxt_restore:
 
 //
 
+#elif defined(__loongarch__)
+   
+//
+/*
+ * Internal __jmp_buf layout
+ * loongarch-asm: 
https://docs.kernel.org/translations/zh_CN/arch/loongarch/introduction.html
+ */
+#define JB_SP  0/* A0, SP, Stack pointer */
+#define JB_RA  1/* RA, Return address */
+#define JB_FP  2/* FP/S0 Frame pointer */
+#define JB_S1  3/* S1 Saved register*/
+#define JB_S2  4/* S2-S9,  Saved register */
+#define JB_S3  5/* S2-S9,  Saved register */
+#define JB_S4  6/* S2-S9,  Saved register */
+#define JB_S5  7/* S2-S9,  Saved register */
+#define JB_S6  8/* S2-S9,  Saved register */
+#define JB_S7  9/* S2-S9,  Saved register */
+#define JB_S8  10/* S2-S9,  Saved register */
+#define JB_S9  11   /* S2-S9,  Saved register */
+
+
+   .file "md.S"
+   .text
+
+   /* _st_md_cxt_save(__jmp_buf env) */ 
+   .globl _st_md_cxt_save
+   .type _st_md_cxt_save, %function
+   .align 2
+_st_md_cxt_save:
+   st.d$sp,  $a0, JB_SP  * 8
+   st.d$ra,  $a0, JB_RA  * 8
+   st.d$s0,  $a0, JB_FP  * 8
+   st.d$s1,  $a0, JB_S1  * 8
+   st.d$s2,  $a0, JB_S2  * 8
+   st.d$s3,  $a0, JB_S3  * 8
+   st.d$s4,  $a0, JB_S4  * 8
+   st.d$s5,  $a0, JB_S5  * 8
+   st.d$s6,  $a0, JB_S6  * 8
+   st.d$s7,  $a0, JB_S7  * 8
+   st.d$s8,  $a0, JB_S8  * 8
+   st.d$s9,  $a0, JB_S9  * 8
+   li.w$a0,  0
+   jr  $ra
+   .size _st_md_cxt_save, .-_st_md_cxt_save
+
+//
+
+   /* _st_md_cxt_restore(__jmp_buf env, int val) */
+   .globl _st_md_cxt_restore
+   .type _st_md_cxt_restore, %function
+   .align 2
+_st_md_cxt_restore:
+   ld.d$sp,  $a0, JB_SP  * 8 
+   ld.d$ra,  $a0, JB_RA  * 8 
+   ld.d$s0,  $a0, JB_FP  * 8 
+   ld.d$s1,  $a0, JB_S1  * 8 
+   ld.d$s2,  $a0, JB_S2  * 8 
+   ld.d$s3,  $a0, JB_S3  * 8 
+   ld.d$s4,  $a0, JB_S4  * 8 
+   ld.d$s5,  $a0, JB_S5  * 8 
+   ld.d$s6,  $a0, JB_S6  * 8 
+   ld.d$s7,  $a0, JB_S7  * 8 
+   ld.d$s8,  $a0, JB_S8  * 8 
+   ld.d$s9,  $a0, JB_S9  * 8 
+   li.w$a0,  1
+   jr  $ra
+   .size _st_md_cxt_restore, .-_st_md_cxt_restore
+
+//
+
 #endif
 
--- st-1.9.orig/md.h
+++ st-1.9/md.h
@@ -447,6 +447,11 @@
 #define MD_USE_BUILTIN_SETJMP
 #define MD_GET_S

Bug#1076569: When called for dh-sequence-kf6 (or --with=kf6) CMAKE Qt6 should be enforced

[Nicholas D Steeves]

Package: pkg-kde-tools
Version: 0.17.4
Severity: serious

I just started working towards updating one of my packages to Qt6 and
KF6 and I was shocked to find that dh-sequence-kf6 doesn't append
"-DQT_MAJOR_VERSION=6" to cmake configure arguments.

KF6 + "-DQT_MAJOR_VERSION=5" is nonsensical, so the Qt6 variant should
be enforced.

Best,
Nicholas

Bug#1022747: RFS: prismlauncher/8.4+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Ben Westover]

Control: tags -1 - moreinfo

Hi Phil, thanks for reviewing my package!

On 7/15/24 2:19 AM, Phil Wyett wrote:
> I: prismlauncher: hardening-no-bindnow [usr/bin/prismlauncher]
 >
 > [snip]
> 
> Note: See previous mail regarding add hardening. Also see[6].

Strange, I never received your previous email. Found it in the bug 
webpage, though. Hardening options have been added to my new upload.

> I: prismlauncher: spelling-error-in-binary Abborted Aborted
> I: prismlauncher: spelling-error-in-binary overriden overridden

My new upload has the typos patched out and I submitted a PR upstream.

> 3. Licenses (lrc[3]): Issue
> 
> Note: Not all may be wrong, but a few checked are.

All issues are fixed in the new upload, only false positives remain now.

> Additional...
> 
> A. Please update the 'Standards-Version' in 'debian/control' to 4.7.0 as per
> Debian policy[5].

Done.

> 
> Summary...
> 
> I believe prismlauncher is not yet ready for sponsorship/upload. Could the
> contributor rectify one of more of the rasied issues. Once updated to your
> satisfaction and a new upload done, please remove the 'moreinfo' on the
> Request For Sponsorship (RFS) bug report.

Thanks again for doing a very thorough review of my package, Phil. I 
believe I have resolved all of the issues found within.

--
Ben Westover


OpenPGP_signature.asc
Description: PGP signature

Bug#1076483: this bug also exist in 6.10-rt-amd64

[肖盛文]

Control: found -1 6.10-1~exp1


dmesg -l warn output is:

[1.815536] hpet_acpi_add: no address or irqs in _CRS
[1.860770] Modules linked in:
[1.860772] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10-rt-amd64 
#1  Debian 6.10-1~exp1
[1.860773] Hardware name: LENOVO 21HD0078CD/21HD0078CD, BIOS 
N3QET46W (1.46 ) 06/04/2024

[1.860774] Call Trace:
[1.860776]  
[1.860778]  dump_stack_lvl+0x64/0x80
[1.860782]  __schedule_bug+0x56/0x70
[1.860784]  __schedule+0x92b/0xb50
[1.860787]  schedule_rtlock+0x1e/0x40
[1.860788]  rtlock_slowlock_locked+0x21b/0xcf0
[1.860790]  rt_spin_lock+0x42/0x60
[1.860791]  notify_hwp_interrupt+0x85/0x100
[1.860794]  intel_thermal_interrupt+0x17/0x2e0
[1.860796]  __sysvec_thermal+0x20/0xd0
[1.860798]  sysvec_thermal+0x6c/0x90
[1.860800]  
[1.860800]  
[1.860801]  asm_sysvec_thermal+0x1a/0x20
[1.860802] RIP: 0010:cpuidle_enter_state+0xcc/0x430
[1.860804] Code: 7a c0 4d ff e8 b5 f0 ff ff 8b 53 04 49 89 c5 0f 1f 
44 00 00 31 ff e8 13 ce 4c ff 45 84 ff 0f 85 4f 02 00 00 fb 0f 1f 44 00 
00 <45> 85 f6 0f 88 81 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d

[1.860805] RSP: :b966001bfe90 EFLAGS: 0246
[1.860807] RAX: 8b721118 RBX: d965ff79eb80 RCX: 
0017
[1.860807] RDX: 0003 RSI: 6ee8fe52 RDI: 

[1.860808] RBP: 0003 R08: ffc2f70b R09: 

[1.860808] R10: 0006 R11: 8b72111b4c64 R12: 
a2bbb0a0
[1.860809] R13: 6ee8fe52 R14: 0003 R15: 


[1.860810]  cpuidle_enter+0x2d/0x40
[1.860812]  do_idle+0x1d9/0x260
[1.860814]  cpu_startup_entry+0x29/0x30
[1.860815]  start_secondary+0x11c/0x140
[1.860817]  common_startup_64+0x13e/0x141
[1.860819]  
[1.860830] Modules linked in:
[1.860832] CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW 
 6.10-rt-amd64 #1  Debian 6.10-1~exp1
[1.860833] Hardware name: LENOVO 21HD0078CD/21HD0078CD, BIOS 
N3QET46W (1.46 ) 06/04/2024

[1.860833] Call Trace:
[1.860834]  
[1.860834]  dump_stack_lvl+0x64/0x80
[1.860835]  __schedule_bug+0x56/0x70
[1.860836]  __schedule+0x92b/0xb50
[1.860838]  ? __wrmsr_on_cpu+0x2d/0x40
[1.860840]  ? __flush_smp_call_function_queue+0x95/0x400
[1.860842]  schedule_idle+0x20/0x40
[1.860844]  do_idle+0x15f/0x260
[1.860845]  cpu_startup_entry+0x29/0x30
[1.860847]  start_secondary+0x11c/0x140
[1.860848]  common_startup_64+0x13e/0x141
[1.860850]  
[1.874615] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 
操作系统
Debian QA page: 
https://qa.debian.org/developer.php?login=atzlinux%40sina.com

Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075931: llvm-toolchain-18: Broken symbolic links in llvm packages

[Xiangyu Liu]

Dear Maintainer,

Seems that the broken symbolic links mentioned above have been fixed in
*1:18.1.8-4*,  so please close this issue (#1075931). Thanks for the
attention.


Install llvm-toochain-18 packages ( 1:18.1.8-4 ) in an AMD64 schroot:

# apt-get -V --auto-remove --purge --no-install-recommends install bolt-18
clang-18 clangd-18 clang-format-18 clang-tidy-18 clang-tools-18 flang-18
libbolt-18-dev libc++1-18 libc++-18-dev libc++abi1-18 libc++abi-18-dev
libclang1-18 libclang-18-dev libclang-common-18-dev libclang-cpp18
libclang-cpp18-dev libclang-rt-18-dev libflang-18-dev libfuzzer-18-dev
liblld-18 liblld-18-dev liblldb-18 liblldb-18-dev libllvm18
libllvm-18-ocaml-dev libllvmlibc-18-dev libmlir-18 libmlir-18-dev
libomp-18-dev libomp5-18 libpolly-18-dev libunwind-18 libunwind-18-dev
lld-18 lldb-18 llvm-18 llvm-18-dev llvm-18-linker-tools llvm-18-runtime
llvm-18-tools mlir-18-tools python3-clang-18 python3-lldb-18
...
...


$ find -L /usr -type l
find: '/usr/lib/ssl/private': Permission denied
find: File system loop detected; '/usr/lib/llvm-18/build/Debug+Asserts' is
part of the same file system loop as '/usr/lib/llvm-18'.
find: File system loop detected; '/usr/lib/llvm-18/build/Release' is part
of the same file system loop as '/usr/lib/llvm-18'.

or

$ find /usr -xtype l




liuxiangyu  于2024年7月8日周一 09:09写道：

> Source: llvm-toolchain-18
> Version: 1:18.1.8-2~exp2
> Severity: important
> X-Debbugs-Cc: u122...@gmail.com
>
> Dear Maintainer,
>
> Some of broken symbolic links are found in full installation of
> llvm-toolchain-18, in a sid + experimental schroot for amd64.
>
> (In sid + experimental schroot for x86_64)
> # apt-get -V -t experimental --auto-remove --purge --no-install-recommends
> install bolt-18 clang-18 clang-18-doc clang-18-examples clangd-18
> clang-format-18 clang-tidy-18 clang-tools-18 flang-18 libbolt-18-dev
> libc++1-18 libc++-18-dev libc++-18-dev-wasm32 libc++abi1-18
> libc++abi-18-dev libc++abi-18-dev-wasm32 libclang1-18 libclang-18-dev
> libclang-common-18-dev libclang-cpp18 libclang-cpp18-dev libclang-rt-18-dev
> libclang-rt-18-dev-wasm32 libclang-rt-18-dev-wasm64 libclc-18 libclc-18-dev
> libflang-18-dev libfuzzer-18-dev liblld-18 liblld-18-dev liblldb-18
> liblldb-18-dev libllvm18 libllvm-18-ocaml-dev libllvmlibc-18-dev libmlir-18
> libmlir-18-dev libomp-18-dev libomp-18-doc libomp5-18 libpolly-18-dev
> libunwind-18 libunwind-18-dev lld-18 lldb-18 llvm-18 llvm-18-dev
> llvm-18-doc llvm-18-examples llvm-18-linker-tools llvm-18-runtime
> llvm-18-tools mlir-18-tools python3-clang-18 python3-lldb-18
> 
> 
>
> $ find -L /usr -type l
> /usr/lib/x86_64-linux-gnu/libc++.a
> /usr/lib/x86_64-linux-gnu/libc++experimental.a
> /usr/lib/x86_64-linux-gnu/libc++abi.so
> /usr/lib/x86_64-linux-gnu/libc++.so
> find: ‘/usr/lib/ssl/private’: Permission denied
> /usr/lib/python3/dist-packages/lldb/libLLVM-18.1.8.so.1
> /usr/lib/python3/dist-packages/lldb/libLLVM-18.so.1
> find: File system loop detected; ‘/usr/lib/llvm-18/build/Debug+Asserts’ is
> part of the same file system loop as ‘/usr/lib/llvm-18’.
> find: File system loop detected; ‘/usr/lib/llvm-18/build/Release’ is part
> of the same file system loop as ‘/usr/lib/llvm-18’.
> /usr/lib/llvm-18/build/lib/python3/dist-packages/lldb/libLLVM-18.1.8.so.1
> /usr/lib/llvm-18/build/lib/python3/dist-packages/lldb/libLLVM-18.so.1
> /usr/lib/llvm-18/lib/python3/dist-packages/lldb/libLLVM-18.1.8.so.1
> /usr/lib/llvm-18/lib/python3/dist-packages/lldb/libLLVM-18.so.1
>
>
> or
>
> $ find /usr -xtype l
> /usr/lib/x86_64-linux-gnu/libc++.a
> /usr/lib/x86_64-linux-gnu/libc++experimental.a
> /usr/lib/x86_64-linux-gnu/libc++abi.so
> /usr/lib/x86_64-linux-gnu/libc++.so
> /usr/lib/llvm-18/lib/python3/dist-packages/lldb/libLLVM-18.1.8.so.1
> /usr/lib/llvm-18/lib/python3/dist-packages/lldb/libLLVM-18.so.1
>
>
> Seems that the links in libc++abi-X.Y-dev.links.in, libc++-
> X.Y-dev.links.in and python3-lldb-X.Y.links.in are not pointing to the
> correct targets after closing #1067699, #1067005.
>
> There should be some updates for links.in files above.
>
> diff -Narup a/libc++abi-X.Y-dev.links.in b/libc++abi-X.Y-dev.links.in
> --- a/libc++abi-X.Y-dev.links.in2024-07-07 06:39:39.0
> +0800
> +++ b/libc++abi-X.Y-dev.links.in2024-07-07 17:40:02.800193502
> +0800
> @@ -1 +1 @@
> -usr/lib/llvm-@LLVM_VERSION@/lib/libc++abi.so
> /usr/lib/@DEB_HOST_MULTIARCH@/libc++abi.so
> +usr/lib/llvm-@LLVM_VERSION@/lib/@DEB_HOST_MULTIARCH_LLVM@/libc++abi.so
> /usr/lib/@DEB_HOST_MULTIARCH@/libc++abi.so
> diff -Narup a/libc++-X.Y-dev.links.in b/libc++-X.Y-dev.links.in
> --- a/libc++-X.Y-dev.links.in   2024-07-07 06:39:39.0 +0800
> +++ b/libc++-X.Y-dev.links.in   2024-07-07 17:41:27.170194537 +0800
> @@ -1,4 +1,4 @@
> -usr/lib/llvm-@LLVM_VERSION@/lib/libc++.so /usr/lib/@DEB_HOST_MULTIARCH@
> /libc++.so
> -usr/lib/llvm-@LLVM_VERSION@/lib/libc++.a /usr/lib/@DEB_HOST_MULTIARCH@
> /libc++.a
> +usr/lib/llvm-@LLVM_VERSION@/lib/@DEB_HOST_