Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

[Philipp Marek]

With the update to 115.0.2 it works again - even in the profile that was 
broken before.


Thanks!

Bug#1041016: RM: pkg-mozilla-archive-keyring -- ROM; Outdated and useless

[Mike Hommey]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

As per the RC bug against the package, the key it contains is expired,
and the repository that was signed by the key has not been in use
for years. It's time to retire the package completely.

Mike

Bug#1041015: Drivers for Dell Wireless 380 Bluetooth Card wanted

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
In the journal I see red lines
firmware_class: See https://wiki.debian.org/Firmware 
https://wiki.debian.org/Firmware for information about missing firmware
bluetooth hci0: firmware: failed to load brcm/BCM20702A1-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
Bluetooth: hci0: BCM: firmware Patch file not found, tried:
Bluetooth: hci0: BCM: 'brcm/BCM20702A1-413c-8197.hcd'
Bluetooth: hci0: BCM: 'brcm/BCM-413c-8197.hcd'
More errors/warnings concerning bluetooth follow later. The card is a built-in 
“Dell Wireless 380 Bluetooth Card” on a Dell Mobile Precision M6700. I failed 
to find the requested files myself. Any help/remedy/fix?
(As opposed to #1013895, no USB dongles are plugged into our machine; all the 
USB ports are free.)
Gratefully,
AlMa

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Tentative fix, for what it's worth:

https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Helge Deller]

On 7/14/23 01:56, Thorsten Glaser wrote:

Dixi quod…


My guess here is that it’s, as usual, the fault of qemu-user,


Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)


what does this show?:
QEMU_STRACE=1 qemu-arm-static -d cpu ./fstype --help

I still believe, that the problem is that qemu's brk(NULL) doesn't return
a page-aligned address, which will have lots of other side-effects.
(see Andreas' RISC-V crash here: 
https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg00645.html)

Helge

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

Control: fixed -1 4.3.0+git20221007.a3a1cc6-3

On Thu, 13 Jul 2023 23:49:56 +0800 Shengjing Zhu  
wrote:

> You look at the wrong log, it's golang-github-hhatto-gorst, not
> golang-github-go-enry-go-license-detector.
> It FTBFS on buildd currently.

After increasing the timeout to 150m, the build is now succeeding on 
armel and mipsel.


https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=armel=4.3.0%2Bgit20221007.a3a1cc6-3=1689278197=0

https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-3=1689281650=0

Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?

[Christoph Anton Mitterer]

Control: tags -1 - moreinfo

On Tue, 2023-07-11 at 14:20 +0200, Michael Biebl wrote:
> Please provide a debug log of udisksd (run it with --debug) which
> shows 
> the mount/unmount.

Did the following just after the upgrade to 2.10.0-3:

In the unit file:
ExecStart=/usr/libexec/udisks2/udisksd --debug

# systemctl daemon-reload
# systemctl restart udisks2.service

# ps ax | grep udisksd
 505610 ?Ssl0:00 /usr/libexec/udisks2/udisksd --debug



Right after restarting it (every time) the kernel shows me:
Jul 14 05:26:00 heisenberg kernel: BTRFS: device label system-meta devid 1 
transid 16 /dev/nvme0n1p3 scanned by udisksd (505610)
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c 
(crc32c-intel) checksum algorithm
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using free 
space tree
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd 
optimizations
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling 
async discard


journalctl _SYSTEMD_UNIT=udisks2.service -f gives:
Jul 14 05:25:59 heisenberg udisksd[505215]: udisks daemon version 2.10.0 exiting
Jul 14 05:25:59 heisenberg udisksd[505610]: udisks daemon version 2.10.0 
starting
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: 
Failed to get status of the device loop3: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: 
Failed to get status of the device loop4: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: 
Failed to get status of the device loop5: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: 
Failed to get status of the device loop3: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: 
Failed to get status of the device loop4: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: 
Failed to get status of the device loop5: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: 

Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied

[Al Ma]

Package: systemd-timesyncd
Version: 252.6-1
`systemctl restart systemd-timesyncd` says that the control process exited with 
error code. Status says, "Failed at step EXEC spawning 
/lib/systemd/systemd-timesyncd: Permission denied".
In the `output of journal  -xeu systemd-timesyncd.service` we see
systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: 
Permission dienied
systemd-timesyncd.service: Failed at step EXEC spawning 
/lib/systemd/systemd-timesyncd: Permission dienied
…
The error number returned by this process is ERRNO.
However,
-rwxr-xr-x 1 root root 55520 28. Feb 12:15 /lib/systemd/system-timesyncd
The error appeared after upgrading from Debian 11 to Debian 12.

Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1

[Aaron M. Ucko]

u...@debian.org (Aaron M. Ucko) writes:

>> The fix itself looks fine, so please feel free to go ahead (with the
>> Closes: removed and possibly with .gitignore restored if appropriate).
>
> Will do, thanks!

Uploaded, final debdiff confirmed not to touch .gitignore.  Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1041010: [Pkg-javascript-devel] Bug#1041010: Please include nbconvert-css

[Yadd]

On 7/14/23 01:40, Julian Gilbey wrote:

Package: node-jupyterlab
Version: 4.0.0~rc1+ds1+~1.0.2-1
Severity: wishlist

Hi Yadd!

Thanks for building this package!

I'm in the process of trying to upgrade (python3-)nbconvert (it's a
dependency of Spyder), and the new version tries to use
https://unpkg.com/@jupyterlab/nbconvert-css@3.6.1/style/index.css
during the build process.  I obviously need to replace this by a local
file, so the node-jupyterlab is the obvious place to look.

For some reason, nbconvert-css is excluded from the package.  Might it
be possible to include it?

Best wishes,


Hi,

I put node-jupyterlab into experimental because it's still WIP. For now 
I'm not able to build all @jupyterlab/* components due to missing 
dependencies. I'll continue this during autumn.


Regards,
Yadd

Bug#1040975: CW font disabled in groff-base v1.23

[Andrew Ruthven]

Control: reassign -1 groff-base
Control: affects -1 perl

Hey,

I think a change in groff-base to re-enable the CW font alias might be
reasonable. This affects a number of other packages, not just perl (via
pod2man), for example:

puck@dirk:~$ man --warnings /usr/share/man/man1/strace.1.gz > /dev/null
troff::88: warning: macro 'IX' not defined
troff::119: warning: cannot select font 'CW'
troff::124: warning: cannot select font 'CW'
...

(Lintian excludes the IX macro which is why that is present)

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |



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

Bug#1026118: thunderbird: please add support for riscv64

[Bo YU]

Source: thunderbird
Version: 1:115.0~b6-1
Followup-For: Bug #1026118

Dear Maintainer,

I have updated the patch that supported riscv64 target. And I think it
should work because we got firefox package now[0].

This time I rebased on 115.0~b6 on experimentail.
Could you give a try when you upload it next time?
Please let me know any issues.
TIA.


[0]: https://buildd.debian.org/status/logs.php?pkg=firefox=riscv64

-- 
Regards,
--
  Bo YU

diff -Nru thunderbird-115.0~b6/debian/changelog 
thunderbird-115.0~b6/debian/changelog
--- thunderbird-115.0~b6/debian/changelog   2023-06-30 02:13:46.0 
+0800
+++ thunderbird-115.0~b6/debian/changelog   2023-07-14 09:29:49.0 
+0800
@@ -1,3 +1,10 @@
+thunderbird (1:115.0~b6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support riscv64. (Closes: #1026118)
+
+ -- Bo YU   Fri, 14 Jul 2023 09:29:49 +0800
+
 thunderbird (1:115.0~b6-1) experimental; urgency=medium
 
   * [1d7c51d] New upstream version 115.0~b6
diff -Nru thunderbird-115.0~b6/debian/control 
thunderbird-115.0~b6/debian/control
--- thunderbird-115.0~b6/debian/control 2023-06-23 04:02:03.0 +0800
+++ thunderbird-115.0~b6/debian/control 2023-07-13 21:53:37.0 +0800
@@ -62,7 +62,7 @@
 Standards-Version: 4.6.2
 
 Package: thunderbird
-Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64
+Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64 riscv64
 Depends:
  debianutils (>= 1.16),
  fontconfig,
diff -Nru thunderbird-115.0~b6/debian/rules thunderbird-115.0~b6/debian/rules
--- thunderbird-115.0~b6/debian/rules   2023-06-23 04:02:03.0 +0800
+++ thunderbird-115.0~b6/debian/rules   2023-07-13 21:56:03.0 +0800
@@ -108,6 +108,9 @@
 ifeq (32,$(DEB_BUILD_ARCH_BITS))
echo 'ac_add_options --disable-debug-symbols' >> mozconfig.default
 endif
+ifeq (riscv64,$(DEB_BUILD_ARCH))
+   echo 'ac_add_options --disable-debug-symbols' >> mozconfig.default
+endif
echo 'mk_add_options MOZ_OBJDIR=$(CURDIR)/obj-thunderbird' >> 
mozconfig.thunderbird
echo 'ac_add_options --prefix=$(CURDIR)/debian/tmp/usr' >> 
mozconfig.default
# configure the various build settings for thunderbird


signature.asc
Description: PGP signature

Bug#1012859: Info received (Syslog)

[Nicholas D Steeves]

Dear Leslie,

I'm sorry no one noticed your bug.  Reply follows inline:

Jeremy, thank you for following up on this bug!  This brought the bug to
my attention :)

Leslie Rhorer  writes:

> On 7/13/2023 5:18 PM, Jeremy Davis wrote:
>> [Just a random passer-by that might have an idea?]
>>
>> It looks to me like you are missing the firmware-realtek[1][2] 
>> (non-free) package?!
>
>      No, I am not missing it.  The package is broken in Bullseye. The 
> firmware is there, but does not work.  It worked just fine in Buster, 
> but when I upgraded to Bullseye, the 10G NIC completely quit working.  
> It's been over a year, so I don't recall everything I did, but I spent 
> many, many hours trying to get the new firmware working, and many more 
> hours trying to extract the firmware from the oldstable package, and 
> then quite a few more hours trying  to compile from source, but nothing 
> worked.  I could not even get the source code to compile.

Given your intention to upgrade from buster to bullseye, here is what
you can try (please read to the end of this email first, because an
alternative method is a better use of your time):

1a. Enable bullseye-backports (non-free), and 'apt install -t
bullseye-backports firmware-linux firmware-misc-nonfree' which is
currently 20230210-4~bpo11+1

2a. Reboot

3a. If both your NICs work, then it's a firmware bug.  If this is the
case, please report a bug against firmware-linux-nonfree 20210315-3.

--

1b. If the steps above are insufficient, 'apt install -t
bullseye-backports linux-image-amd64' which is currently
6.1.20-2~bpo11+1

2b. Reboot.  GRUB should automatically choose the backports kernel.

3b. Your NICs should work at this point.  If they do, and you'd like to
report a bug against the linux-image-amd64 version in bullseye, then
please go ahead and do so, but please make sure that you've tested
5.10.178-3 before doing so:)

>      The bottom line is the firmware from the Buster non-free distro 
> works perfectly well, but noone has come forth with a fix for Bullseye, 
> and I have no reason to believe the firmware from Bookworm will work.  
> The NIC is an Asus PEB-10G/57811-1S 10GbE SFP+ Network Adapter which 
> employs a BCM 57811S controller.

Maybe nobody knows that this specific hardware is broken?  It may be
that the Asus PEB-10G/57811-1S has some hardware quirks that Broadcom
doesn't know about.  In your original bug log you'll notice this snippet

 RTL8211E Gigabit Ethernet

which is the Realtek one, Gibabit, RJ45 copper.  I wonder if this one is
a completely different NIC built into your motherboard.  ie: the
historically very buggy Realtek 8111E?

Alternatively, if the 10GbE SFP+ PCIe adapter NIC uses a Realtek for
gigabit PHY, then the nature of the bug could be that both both Realtek
and Broadcom broke your NIC (either in the firmware on in the driver, or
both).

>> If you haven't already tried, I'd suggest that you try a clean 
>> bookworm install from ISO. FWIW bookworm now includes a separate 
>> "non-free-firmware" repo that is enabled by default. So the official 
>> installer should "just work".
>      I can try, but I really would not be well advised to do so until I 
> can get the dead system working again.

Jeremy is right about how bookworm includes non-free-firmware by
default, and also that the state of your hardware with bookworm should
be tested first.

The best use of your time will be to test with live media (USB or DVD).
If you'd like to have a GUI for your test, please choose a variant you
recognise and are comfortable with.  The "standard" flavour is CLI only,
which--alternatively--might be what you want (it's a smaller download ).

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

If the problem still exists in bookworm, then it needs to be fixed in
bookworm before the fix can be backported to buster, and the live media
is the fastest way to test this.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1041013: RFS: woof/20220202 -- File sharing utility through http protocol

[Hector Cao]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : woof
   Version  : 20220202
   Upstream contact : Simon Budig
 * URL  : https://github.com/simon-budig/woof
 * License  : GPL-3.0+
 * Vcs  : [fill in URL of packaging vcs]
   Section  : net

The source builds the following binary packages:

  woof - File sharing utility through http protocol

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/w/woof/woof_20220202.dsc

Changes since the last upload:

 woof (20220202) unstable; urgency=medium
 .
   * Initial release.

Regards,
-- 
  Hector CAO



-- 
Hector CAO
Software Engineer – Partner Engineering Team
hector@canonical.com
https://launc hpad.net/~hectorcao

Bug#1029502: ftp.debian.org: changelog of libreoffice is unavailable

[Vincent Lefevre]

This is occurring again (after an "apt update"):

zira:~> apt changelog libreoffice
Err:1 https://metadata.ftp-master.debian.org libreoffice 4:7.5.5~rc1-5 Changelog
  Changelog unavailable for libreoffice=4:7.5.5~rc1-5 (404  Not Found [IP: 
2a04:4e42:6a::644 443])
E: Failed to fetch 
https://metadata.ftp-master.debian.org/changelogs/main/libr/libreoffice/libreoffice_7.5.5%7erc1-5_changelog
  Changelog unavailable for libreoffice=4:7.5.5~rc1-5 (404  Not Found [IP: 
2a04:4e42:6a::644 443])

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

Bug#1004238:

[Nilson Silva]

Hello

Konstantinos Margaritis!

Seeing that his package has the adoption request, I decided to adopt him. Can 
you upload it when I'm done?



Nilson F. Silva

Bug#980141:

[Nilson Silva]

Hello Christoph Berg!
Seeing that his package has the adoption request, I decided to adopt him.

Can you upload it when I'm done?


Nilson F. Silva

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,

Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/qemu-arm-static...
Downloading separate debug info for /usr/bin/qemu-arm-static...
Reading symbols from 
/home/tglase/.cache/debuginfod_client/5a14d0155c981c94a528d6468ded2c203f1e1908/debuginfo...
(gdb) r
Starting program: /usr/bin/qemu-arm-static ./fstype --help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77ff8700 (LWP 27273)]

Thread 1 "qemu-arm-static" received signal SIGSEGV, Segmentation fault.
0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at 
./include/qemu/bswap.h:329
Download failed: Invalid argument.  Continuing without source file 
./b/user-static/./include/qemu/bswap.h.
329 ./include/qemu/bswap.h: No such file or directory.
(gdb) bt
#0  0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) 
at ./include/qemu/bswap.h:329
#1  0x0045c9ac in translator_lduw_swap (do_swap=false, pc=, env=0xcbed30)
at ./include/exec/translator.h:178
#2  arm_lduw_code (sctlr_b=false, addr=, env=0xcbed30) at 
../../target/arm/arm_ldst.h:44
#3  thumb_tr_translate_insn (dcbase=0x7fffdd50, cpu=) at 
../../target/arm/translate.c:9054
#4  0x004bc1e9 in translator_loop (ops=0xa7f180 , 
db=db@entry=0x7fffdd50,
cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../accel/tcg/translator.c:103
#5  0x00463eb3 in gen_intermediate_code (cpu=cpu@entry=0xcb6a60,
tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../target/arm/translate.c:9283
#6  0x00512d75 in tb_gen_code (cpu=cpu@entry=0xcb6a60, pc=3670264, 
cs_base=0, flags=1196288,
cflags=-16777216, cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
#7  0x004b4734 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, 
cpu=0xcb6a60)
at ../../accel/tcg/cpu-exec.c:414
#8  cpu_exec (cpu=cpu@entry=0xcb6a60) at ../../accel/tcg/cpu-exec.c:770
#9  0x00422608 in cpu_loop (env=env@entry=0xcbed30) at 
../../linux-user/arm/cpu_loop.c:237
#10 0x00402949 in main (argc=, argv=0x7fffe230, 
envp=)
at ../../linux-user/main.c:882
(gdb) info r
rax0x40d94000  1087979520
rbx0x7fffdd50  140737488346448
rcx0xd9a72814264104
rdx0xc64d6012995936
rsi0x3800f83670264
rdi0xcbed3013364528
rbp0x0 0x0
rsp0x7fffdc48  0x7fffdc48
r8 0xc64d6012995936
r9 0xc656e812998376
r100x0 0
r110x0 0
r120xcbed3013364528
r130x0 0
r140x0 0
r150x7fffdd50  140737488346448
rip0x4c5cb60x4c5cb6 
eflags 0x10246 [ PF ZF IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) disas
Dump of assembler code for function cpu_lduw_code:
   0x004c5ca0 <+0>: movQWORD PTR fs:0xff58,0x1
   0x004c5cad <+13>:movesi,esi
   0x004c5caf <+15>:movrax,QWORD PTR [rip+0x79efa2]# 
0xc64c58 
=> 0x004c5cb6 <+22>:movzx  eax,WORD PTR [rax+rsi*1]
   0x004c5cba <+26>:movQWORD PTR fs:0xff58,0x0
   0x004c5cc7 <+39>:ret
End of assembler dump.


The content of rax (guest_base) looks legit:

$ cat /proc/27269/maps
0040-00401000 r--p  fd:00 2624234
/usr/bin/qemu-arm-static
00401000-0071e000 r-xp 1000 fd:00 2624234

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Hi Helge,

>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
>Schwab)

I doubt it, klibc malloc uses mmap(2) normally.

(And given I tested it on a bullseye system, the mmap bug in the
bookworm kernel is also not applicable.)

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

Bug#993849: authenticator

[Matthias Geiger]

> If someone wants to help, feel contribute in the debian-rust team.

I meant feel free :)

---

Matthias Geiger



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012859: Info received (Syslog)

[Leslie Rhorer]

On 7/13/2023 5:18 PM, Jeremy Davis wrote:

[Just a random passer-by that might have an idea?]

On 14/7/23 07:14, Leslie Rhorer wrote:
 I filed report 1012859 to the Debian BTS over a year ago. 
Nothing has been done so far, and I have one cripped system and one 
dead system that needs to be upgraded to the most recent version, but 
I can't really proceed until the proper files get included into the 
Debian distro.  Can someone please help?


It looks to me like you are missing the firmware-realtek[1][2] 
(non-free) package?!


    No, I am not missing it.  The package is broken in Bullseye. The 
firmware is there, but does not work.  It worked just fine in Buster, 
but when I upgraded to Bullseye, the 10G NIC completely quit working.  
It's been over a year, so I don't recall everything I did, but I spent 
many, many hours trying to get the new firmware working, and many more 
hours trying to extract the firmware from the oldstable package, and 
then quite a few more hours trying  to compile from source, but nothing 
worked.  I could not even get the source code to compile.


    The bottom line is the firmware from the Buster non-free distro 
works perfectly well, but noone has come forth with a fix for Bullseye, 
and I have no reason to believe the firmware from Bookworm will work.  
The NIC is an Asus PEB-10G/57811-1S 10GbE SFP+ Network Adapter which 
employs a BCM 57811S controller.





[1] https://packages.debian.org/bullseye/firmware-realtek
[2] https://packages.debian.org/bookworm/firmware-realtek

If you haven't already tried, I'd suggest that you try a clean 
bookworm install from ISO. FWIW bookworm now includes a separate 
"non-free-firmware" repo that is enabled by default. So the official 
installer should "just work".
    I can try, but I really would not be well advised to do so until I 
can get the dead system working again.


If not, then I would suggest opening a new bug against the current 
installer. In the meantime, try manually installing the package (e.g. 
copy the deb via a USB stick).


Hope that helps.

Regards,
Jeremy

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Helge Deller]

Can you check if this patch fixes the problem:
https://patchew.org/QEMU/mvmpm55qnno@suse.de/
(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
Schwab)
 Ursprüngliche Nachricht Von: Thorsten Glaser  
Datum: 14.07.23  00:48  (GMT+01:00) An: venkata.p...@toshiba-tsip.com, 
1040...@bugs.debian.org, pkg-qemu-de...@lists.alioth.debian.org Cc: 
dinesh.ku...@toshiba-tsip.com Betreff: Bug#1040981: klibc-utils: Segmentation 
fault while executin klibc binaries in armhf architecture under qemu-user 
retitle 1040981 klibc-utils: segfault executing armhf binaries under 
qemu-userthanksvenkata.p...@toshiba-tsip.com dixit:>Follow below steps to 
reproduce this issue>```>$ sudo debootstrap --arch=arm bookworm 
arm-bookworm-rootfs/ http://deb.debian.org/debian/>$ sudo chroot arm-bookworm/ 
apt-update && apt install -y klibc-utils>$ sudo chroot arm-bookworm/ 
/usr/lib/klibc/bin/fstype --help>qemu: uncaught target signal 11 (Segmentation 
fault) - core dumped>Segmentation fault>```Same when just copying 
klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so outof libklibc_2.0.12-1_armhf.deb into 
/lib/ and extracting fstypefrom klibc-utils_2.0.12-1_armhf.deb… however it 
works both on areal-metal ARM box (amdahl.d.o) and a statically(!) linked 
mkshagainst klibc :/My guess here is that it’s, as usual, the fault of 
qemu-user,which has multiple outstanding emulation bugs, some of whichaffecting 
klibc-built binaries especially, though this, sincea statically linked mksh 
works, is probably an issue with howqemu-user handles .interp *shrug*Since your 
one-stage debootstrap succeeds, can you not do theremaining steps booting into 
the image-under-preparation andrun them there? Here, qemu-system-armhf should 
probably suffice.I know, it’s just as a workaround, until the people in 
questionfigure out why this happens.bye,//mirabilos-- Solange man keine 
schmutzigen Tricks macht, und ich meine *wirklich*schmutzige Tricks, wie bei 
einer doppelt verketteten Liste beidePointer XORen und in nur einem Word 
speichern, funktioniert Boehm ganzhervorragend.   -- Andreas Bogk über 
boehm-gc in d.a.s.r

Bug#993849: RE. authenticator

[Matthias Geiger]

I uploaded the rust-gtk stack into debian which was the major missing 
chunk. If my tracking spreadsheet is correct (rust) authenticator is 
still missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm. Some 
of them have more reverse dependencies. I haven't looked into it further 
and I'm a bit busy atm.


If bug #1017905 gets resolved libadwaita can enter debian; this is being 
worked on by myself and jbicha. The rest of the dependencies look 
straightforward to tackle.



If someone wants to help, feel contribute in the debian-rust team. The 
"new" application should go under the gnome teams' umbrella imho.



regards,


Matthias Geiger





OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*

An interesting data point (here on a bullseye/amd64 system):

$ /usr/lib/klibc/bin/fstype --help
--help: No such file or directory
$ /lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so  /usr/lib/klibc/bin/fstype --help
Segmentation fault (core dumped)

So running the interpreter directly is already not supported.
I’m guessing that that is what qemu-user tries, though.

Wild shoot into the blue but maybe it helps…

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1041003: clang-15: Crash in PowerPC DAG->DAG Pattern Instruction Selection

[Sylvestre Ledru]

Hello,

Le 13/07/2023 à 22:21, Cordell Bloor a écrit :

Package: clang-15
Version: 1:15.0.7-6
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

On ppc64el, the clang compiler crashed on buildd [1] during the
compilation of test_block_sort.cpp in the rocprim package. We're only
compiling HIP programs for ppc64el on a best-effort basis, as it is not
an officially supported architecture upstream. Nevertheless, a compiler
crash seemed to be worth reporting. I've reproduced this problem on my
local machine in a QEMU VM.

There were also linking errors related to half-floats in the build log
(__truncdfhf2), but that is unrelated. I fixed that bug in rocm-hipamd
locally before reproducing the crash.

The full log is linked below, but I'll include a snippet inline:

Stack dump:
0.  Program arguments: /usr/lib/llvm-15/bin/clang -cc1
-triple powerpc64le-unknown-linux-gnu -aux-triple amdgcn-amd-amdhsa
<>
/<>/test/rocprim/test_block_sort.cpp
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module 
'/<>/test/rocprim/test_block_sort.cpp'.
4.  Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on 
function
'@_ZN53RocprimBlockSortTestsFloating_CustomSortKeyValue_TestI12block_paramsI6__halfS1_Lj64EEE8TestBodyEv'

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=rocprim=ppc64el=5.3.3-6=1689203881=0


Does it happen with clang-16 ?

could you please try to provide a testcase with creduce ?

thanks

S

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Thorsten Glaser]

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

venkata.p...@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

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

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[José Miguel Gonçalves]

Hi Jeremy,

On 13/07/23 23:01, Jeremy Davis wrote:
Can you confirm that the current default bookworm fail2ban 
config/regex works with sshd with just this change (to 'backend' in 
/etc/fail2ban/jail.conf)? Or are further adjustments required? 


Yes, I can confirm that fail2ban sshd jail works fine using the default 
config and just changing the 'backend' to 'systemd'.


Best regards,
José Gonçalves

Bug#1041011: Acknowledgement (RFP: clash-meta -- A rule-based tunnel / proxy in Go)

[4tn223y6zity]

Also, have to add that Clash.Meta is a fork of Clash, but fully open-source 
(original Clash has closed source premium version) and with more features.

Clash is already packaged by official Arch, Fedora, FreeBSD, OpenSUSE repos, 
see https://pkgs.org/download/clash

Bug#1041011: Acknowledgement (RFP: clash-meta -- A rule-based tunnel / proxy in Go)

[4tn223y6zity]

This Clash Debian package might help with packaging: 
https://gitlab.com/xdeb/clash (see also .gitlab-ci.yml file)

Bug#951200: base-files: unable to upgrade, conffile error

[Guillem Jover]

Control: tags -1 moreinfo unreproducible

Hi!

On Wed, 2020-02-12 at 11:31:35 +, Luca Koroll wrote:
> Package: base-files
> Version: 9.9+deb9u11
> Severity: important

> after rebooting my system and trying to update my packages an error with
> the base-files package occured which brought me into the situation that
> I am unable to install any new packages.
> There must be a problem with the conffile that is temporarily created
> when installing base-files.

> The error line states
> "new info file "/var/lib/dpkg/tmp.ci/conffiles" can't be installed: incorrect 
> message

Hmm, weird I cannot see an error message in the dpkg history that
matches this message. Can you paste the exact message, even if it is
localized.

The only error messages that are close to that one are either:

  "unable to install (supposed) new info file '%.250s'"
  "unable to install new info file '%.250s' as '%.250s'"

both are related to a failed rename of the new info file, but that
would not explain either the error message (from errno) which I cannot
find either in glibc.

> -- Configuration Files:
> /etc/issue changed:
> --
> Welcome to the Proxmox Virtual Environment. Please use your web browser to·
> configure this server - connect to:
>   https://192.168.178.51:8006/
> --

I assume this is from the system where the problem was found? Perhaps
there's an issue with Proxmox?

I've marked this moreinfo and unreproducible, because the error
message does not make sense to me given the code history, so if I
don't hear anything in a while, I guess I'll just have to close this
as a non-actionable report.

Thanks,
Guillem

Bug#1012859: Info received (Syslog)

[Jeremy Davis]

[Just a random passer-by that might have an idea?]

On 14/7/23 07:14, Leslie Rhorer wrote:
     I filed report 1012859 to the Debian BTS over a year ago. Nothing 
has been done so far, and I have one cripped system and one dead system 
that needs to be upgraded to the most recent version, but I can't really 
proceed until the proper files get included into the Debian distro.  Can 
someone please help?


It looks to me like you are missing the firmware-realtek[1][2] 
(non-free) package?!


[1] https://packages.debian.org/bullseye/firmware-realtek
[2] https://packages.debian.org/bookworm/firmware-realtek

If you haven't already tried, I'd suggest that you try a clean bookworm 
install from ISO. FWIW bookworm now includes a separate 
"non-free-firmware" repo that is enabled by default. So the official 
installer should "just work".


If not, then I would suggest opening a new bug against the current 
installer. In the meantime, try manually installing the package (e.g. 
copy the deb via a USB stick).


Hope that helps.

Regards,
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040943: systemd-logind: 'HandlePowerKey=ignore' works in logind.conf, not in logind.conf.d/custom.conf

[Diederik de Haas]

On Thursday, 13 July 2023 20:07:25 CEST Michael Biebl wrote:
> Am 13.07.23 um 20:03 schrieb Debian Bug Tracking System:
> 
> > So it's mostly a PEBKAC issue, although adding the "[Login]" header part
> > to the docs may be useful as that wasn't clear to me.
> 
> Hm, man logind.conf.d says:
> 
> OPTIONS
> All options are configured in the [Login] section:
> ...

"Use 'systemd-analyze cat-config systemd/logind.conf' to display the full 
config." is stated in logind.conf ... which implies that the main file and the 
(various) file snippets are `cat`-ed together.

So when things didn't work, I thought that maybe it got confused by having 2 
"[Login]" header sections and thus I tried removing that as it would still end 
up under the original "[Login]" header (after `cat`).

Keep in mind that if you already know the right answer, it becomes easy to 
reason back and conclude correctly what the documentation was intended to mean 
(iow you have the right context). If you don't know the right answer (yet), 
then it becomes more difficult to interpret things the correct way.

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

Bug#1041008: RFP: libetebase

[4tn223y6zity]

There are also RFPs for other Etebase/Etesync projects:
- #1024885: etesync-dav -- DAV-bridge for etesync
- #951273: etesync-server

Bug#1041006:

[Robert Senger]

This problem can be worked around (if configuration allows this) by
changing:

  mail_attribute_dict = file:%h/dovecot-attributes

to e.g.

  mail_attribute_dict = file:/path/to/mails/%d/%n/dovecot-attributes  

This avoids missing %h value. Bug can be closed.

NOTE: Examples in dovecot documentation all use: 

  mail_attribute_dict = file:%h/Maildir/dovecot-attributes

This triggered the error I've observed.

-- 
Robert Senger 
PGP/GPG Public Key ID: 8714E1A3

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[Jeremy Davis]

FWIW it appears that this bug is essentially a duplicate of #770171:

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

On 7/7/23 19:04, José Miguel Gonçalves wrote:

As Debian opted by systemd journal as the default logging mechanism for 
bookworm, maybe a better option would be to change the default 
configuration in '/etc/fail2ban/jail.conf' to select journal as the 
logging source, i.e., instead of setting 'backend = auto', set 'backend 
= systemd'.


That seems like a sensible suggestion to me.

Can you confirm that the current default bookworm fail2ban config/regex 
works with sshd with just this change (to 'backend' in 
/etc/fail2ban/jail.conf)? Or are further adjustments required?


Regards,
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040991: gcc-13: consider stripping lto1 / cc1 / cc1plus

[Matthias Klose]

On 13.07.23 20:15, Mateusz Łukasik wrote:

Source: gcc-13
Version: 13.1.0-8
Severity: minor


Dear Maintainer,

Like it was before in #783876 #894014 #1015185 gcc-13 package in contain 
unstripped debug

info.


we will do that after a while

Bug#1041012: /usr/bin/add-apt-repository: add-apt-repository silently fails to install the repository on the first run

[Monty Solomon]

Package: software-properties-common
Version: 0.99.30-4
Severity: important
File: /usr/bin/add-apt-repository
X-Debbugs-Cc: mo...@roscom.com




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

Kernel: Linux 5.10.25-linuxkit (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
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: unable to detect

Versions of packages software-properties-common depends on:
ii  ca-certificates  20230311
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-packagekitglib-1.01.2.6-5
ii  packagekit   1.2.6-5
ii  python-apt-common2.6.0
ii  python3  3.11.2-1+b1
ii  python3-dbus 1.3.2-4+b1
ii  python3-gi   3.42.2-3+b1
ii  python3-software-properties  0.99.30-4

software-properties-common recommends no packages.

software-properties-common suggests no packages.

-- no debconf information

The first run of add-apt-repository creates an empty list file and the
package can't be found by apt-get-install. Running add-apt-repository a
second time creates the correct list file.

add-apt-repository "$(curl 
https://packages.microsoft.com/config/debian/11/prod.list)"
  More info: https://packages.microsoft.com/debian/11/prod
  Adding repository.
  Adding deb entry to 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list
  Adding disabled deb-src entry to 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list

ls -al 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list
  -rw-r--r-- 1 root root 0 Jul 13 21:41 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list

add-apt-repository "$(curl 
https://packages.microsoft.com/config/debian/11/prod.list)"
 More info: https://packages.microsoft.com/debian/11/prod
 Adding repository.
 Adding deb entry to 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list
 Adding disabled deb-src entry to 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list

ls -al 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list
 -rw-r--r-- 1 root root 184 Jul 13 21:41 
/etc/apt/sources.list.d/archive_uri-https_packages_microsoft_com_debian_11_prod-bookworm.list


Here is a docker file that can be run to reproduce the problem. It uses
a single add-apt-repository and fails with
E: Unable to locate package msodbcsql17


FROM debian AS base 

# Install MSSQL ODBC driver.  
RUN apt-get update && apt-get install --fix-missing --yes curl apt-utils gnupg2 
software-properties-common \  
&& curl -sSL https://packages.microsoft.com/keys/microsoft.asc > 
/etc/apt/trusted.gpg.d/microsoft.asc \
&& add-apt-repository -d "$(curl 
https://packages.microsoft.com/config/debian/11/prod.list)" \
&& add-apt-repository -d -L \
&& ls -al /etc/apt/sources.list.d/ \
&& apt-get update \ 
&& apt-get install --yes --fix-missing \
&& apt-get install --yes unixodbc-dev \
&& ACCEPT_EULA=Y apt-get install --yes msodbcsql17 \
&& apt-get autoremove --purge --yes \
&& apt-get clean \
&& apt-get autoclean

Bug#1041011: RFP: clash-meta -- A rule-based tunnel / proxy in Go

[A]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: 4tn223y6z...@opayq.com

* Package name: clash-meta
  Version : 1.15.0
* URL : https://github.com/MetaCubeX/Clash.Meta
* License : GPL-3.0
  Programming Lang: Go
  Description : A rule-based tunnel / proxy in Go

This provides local HTTP/HTTPS/SOCKS proxy server or tunnel. What features make 
it stand out:
- support for lots of types of upstream connections: SOCKS, VMess, Shadowsocks, 
Wireguard, etc. -- which is crucial to
  fight internet censorship in countries like China, Iran, Russia, etc.
- rule-based routing based on domain, geoip, process name, etc. -- which makes 
it easy to proxy / route via tunnel
  only what is censored or what you need, not all your traffic
- it also has rules subscription feature, similar to what ad blockers have -- 
which again makes it useful to
  fight censorship, since lists of blocked sites change often, and it's hard to 
keep up for regular users

Bug#1041010: Please include nbconvert-css

[Julian Gilbey]

Package: node-jupyterlab
Version: 4.0.0~rc1+ds1+~1.0.2-1
Severity: wishlist

Hi Yadd!

Thanks for building this package!

I'm in the process of trying to upgrade (python3-)nbconvert (it's a
dependency of Spyder), and the new version tries to use
https://unpkg.com/@jupyterlab/nbconvert-css@3.6.1/style/index.css
during the build process.  I obviously need to replace this by a local
file, so the node-jupyterlab is the obvious place to look.

For some reason, nbconvert-css is excluded from the package.  Might it
be possible to include it?

Best wishes,

   Julian

Bug#1041009: ITP: minetest-mod-colour-chat-56-csm -- Minetest mod - colour chat client side mod

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: minetest-mod-colour-chat-56-csm
  Version : 0.0~git20200507.1ed6284
  Upstream Contact: BenjieFiftysix 
<31968410+benjiefifty...@users.noreply.github.com>
* URL : https://github.com/BenjieFiftysix/colour_chat
* License : Expat
  Programming Lang: Lua
  Description : Minetest mod - colour chat client side mod
 This package is a colour chat module of client side of minetest. It provides
 a set of commands that can chat with colour text.



OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012859: Info received (Syslog)

[Leslie Rhorer]

    I filed report 1012859 to the Debian BTS over a year ago. Nothing 
has been done so far, and I have one cripped system and one dead system 
that needs to be upgraded to the most recent version, but I can't really 
proceed until the proper files get included into the Debian distro.  Can 
someone please help?


On 6/15/2022 3:12 PM, Debian Bug Tracking System wrote:

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Install Team

If you wish to submit further information on this problem, please
send it to1012...@bugs.debian.org.

Please do not send mail toow...@bugs.debian.org  unless you wish
to report a problem with the Bug-tracking system.

Bug#1041008: RFP: libetebase -- C library for Etebase, an end-to-end encrypted open source backend as a service

[A]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: 4tn223y6z...@opayq.com

* Package name: libetebase
  Version : 0.5.5
  Upstream Contact: cont...@etebase.com
* URL : https://github.com/etesync/libetebase
* License : BSD 3-Clause
  Programming Lang: Rust, C
  Description : C API library for Etebase, an end-to-end encrypted open 
source backend as a service

Etebase is a base for EteSync, which is open source end-to-end encrypted sync 
for calendars, contacts, tasks and notes.
It is fully open source and can be self-hosted (which is what I do). It is 
supported by KDE Akonadi and GNOME,
and this support relies on this library. It is already packaged and shipped by 
KDE Neon, and kdepim-runtime depends on
it, see https://invent.kde.org/neon/neon-packaging/libetebase -- this should 
help make a package for Debian.

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[jflf_kernel]

Package: src:linux
Version: 6.1.20-2~bpo11+1
Severity: normal
X-Debbugs-Cc: jflf_ker...@gmx.com

Dear Maintainer,

Currently no Debian kernel enables support for TPM hardware RNG. On one of my
systems:

$ uname -a
Linux XXX 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux

$ cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device

$ ls /dev/tpm*
/dev/tpm0  /dev/tpmrm0

$ sudo tpm2_getrandom 16 | xxd -p
7ba65632453b191385a3989485ac80a3

$ grep HW_RANDOM_TPM /boot/config-$(uname -r)


$ find /lib/modules/$(uname -r) -iname \*tpm\*rng\*


$ ls /dev/hwrng
ls: cannot access '/dev/hwrng': No such file or directory


I have checked the current bookworm and trixie kernel debs, and they don't
include it either. It should be enabled there too.

I manage multiple older amd64 machines that have discrete TPM chips, but no
RDRAND instruction or any other hardware RNG. Enabling support for the TPM RNG
would provide the kernel with additional entropy earlier in the boot process.

Thank you very much!


-- Package-specific info:
** Version:
Linux version 6.1.0-0.deb11.7-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP PREEMPT_DYNAMIC Debian 6.1.20-2~bpo11+1 (2023-04-23)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-0.deb11.7-amd64 
root=UUID=0c206836-a588-4a57-9c6d-92d3f3e20d01 ro quiet nmi_watchdog=0

** Tainted: PUOE (12353)
 * proprietary module was loaded
 * taint requested by userspace application
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Jul 13 07:19:40 silverpad kernel: ACPI: SSDT 0xD7FFA000 0004B7 (v02 
LENOVO Tpm2Tabl 1000 INTL 20141107)
Jul 13 07:19:40 silverpad kernel: ACPI: TPM2 0xD7FF8000 34 (v03 
LENOVO TP-R0C   1370 PTEC 0002)
Jul 13 07:19:40 silverpad kernel: ACPI: Reserving TPM2 table memory at [mem 
0xd7ff8000-0xd7ff8033]

** Model information
sys_vendor: LENOVO
product_name: 20GJCTO1WW
product_version: ThinkPad 13
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: R0CET49W (1.37 )
board_vendor: LENOVO
board_name: 20GJCTO1WW
board_version: SDK0J40709 WIN

** Loaded modules:
isofs
cdrom
uas
usb_storage
uinput
ctr
ccm
rfcomm
nft_fib_inet
nft_fib_ipv4
nft_fib_ipv6
nft_fib
nft_reject_inet
nf_reject_ipv4
vboxnetadp(OE)
nf_reject_ipv6
vboxnetflt(OE)
nft_reject
nft_ct
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
vboxdrv(OE)
ip_set
nf_tables
nfnetlink
zstd
zstd_compress
cmac
algif_hash
algif_skcipher
zram
af_alg
zsmalloc
bnep
zfs(POE)
zunicode(POE)
zzstd(OE)
zlua(OE)
zavl(POE)
icp(POE)
zcommon(POE)
znvpair(POE)
spl(OE)
hid_logitech
ff_memless
hid_generic
snd_usb_audio
usbhid
snd_usbmidi_lib
snd_rawmidi
hid
snd_seq_device
cdc_ether
usbnet
r8152
mii
btusb
btrtl
btbcm
btintel
btmtk
bluetooth
jitterentropy_rng
uvcvideo
videobuf2_vmalloc
drbg
videobuf2_memops
videobuf2_v4l2
ansi_cprng
videobuf2_common
ecdh_generic
ecc
videodev
crc16
mc
snd_sof_pci_intel_skl
intel_rapl_msr
intel_rapl_common
snd_sof_intel_hda_common
snd_hda_codec_hdmi
x86_pkg_temp_thermal
intel_powerclamp
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
coretemp
snd_sof_intel_hda
crc32_pclmul
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
soundwire_bus
ghash_clmulni_intel
sha512_ssse3
sha512_generic
snd_soc_skl
snd_soc_hdac_hda
snd_ctl_led
snd_hda_ext_core
snd_soc_sst_ipc
snd_hda_codec_realtek
snd_soc_sst_dsp
snd_soc_acpi_intel_match
snd_soc_acpi
snd_hda_codec_generic
snd_soc_core
snd_compress
iwlmvm
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
snd_hda_codec
intel_xhci_usb_role_switch
roles
snd_hda_core
aesni_intel
mac80211
crypto_simd
snd_hwdep
xhci_pci
cryptd
xhci_hcd
snd_pcm
mei_hdcp
ee1004
nls_ascii
rapl
libarc4
iwlwifi
e1000e
thinkpad_acpi
usbcore
nls_cp437
i2c_i801
mei_me
ptp
snd_timer
nvram
think_lmi
intel_lpss_pci
intel_cstate
platform_profile
vfat
intel_lpss
ledtrig_audio
fat
cfg80211
intel_uncore
intel_wmi_thunderbolt
wmi_bmof
firmware_attributes_class
pps_core
mei
i2c_smbus
usb_common
snd
idma64
intel_pch_thermal
battery
soundcore
rfkill
ac
button
intel_pmc_core
acpi_pad
joydev
sg
msr
sunrpc
ecryptfs
fuse
efi_pstore
configfs
ip_tables
x_tables
xfs
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
i915
i2c_algo_bit
drm_buddy
drm_display_helper
sd_mod
t10_pi
drm_kms_helper
crc64_rocksoft
crc64
crc_t10dif
cec
crct10dif_generic
rc_core
ahci
crct10dif_pclmul
libahci
ttm
crct10dif_common
libata
drm
crc32c_intel
psmouse
scsi_mod
evdev
serio_raw
scsi_common
video
wmi

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

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/4 CPU threads; 

Bug#1041006: dovecot: Setting ACLs through IMAP fails with mail-crypt-plugin enabled

[Robert Senger]

Source: dovecot
Severity: normal

This bug was observed in dovecot 2.3.4 on Debian 10 and in dovecot 2.3.20 on
FreeBSD 13.

The following plugins are enabled: mail-crypt, mail-crypt-acl, imap-acl and
acl. We are using encrypted folder keys for mail encryption. Encryption is
enabled or disabled for each user individually by storing the
mail_crypt_save_version option in userdb.

Sharing a user's mailbox to another user works fine if sharing is enabled on
the command line using doveadm. If the sharing user's mails are encrypted, the
password can be supplied on the command line.

But sharing by using e.g. Roundcube as MUA throws an error in the dovecot logs,
regardless if the sharing user has encryption enabled or not. This is the error
message:

Jul 13 18:15:34 prokyon dovecot: 
imap(administra...@mydomain.de)<23701><8f41pGAAkIL9EChC8NEBAQAC>: 
Error: mail-crypt-acl-plugin: Cannot initialize destination user 
some...@mydomain.de: userdb didn't return a home directory, but 
mail_attribute_dict used it (%h): file:%h/dovecot-attributes
Jul 13 18:15:34 prokyon dovecot: 
imap(administra...@mydomain.de)<23701><8f41pGAAkIL9EChC8NEBAQAC>: 
Error: Mailbox INBOX: Failed to set ACL

After that, sharing is configured only halfway.

It looks like mail-crypt-acl plugin fails to determine the receiving user's
home directory. I cannot see any attemps to query userdb in advance of this
error. The configured userdb query definitely returns the home directory
(otherwise nothing would work at all...).

This is independent whether the sharing user has encryption enabled or
not. I cannot run any tests with unencrypted folder keys, or global keys, or
encryption disabled globally with mail-crypt plugin enabled but unused. I would 
expect
that this error will occur in all these configurations.

Expected result is that folder sharing at least can be enabled by using a
capable MUA (like Roundcube), if the sharing user is using unencrypted folder
keys, if global keys are used or encryption is disabled for the sharing user
(this is the configuration where I see this error). I don't know what happens
if the sharing user uses encrypted folder keys and the password is needed for
sharing.


-- 
Robert Senger 
PGP/GPG Public Key ID: 8714E1A3

Bug#1041005: libamdhip64-dev: compiler_rt not linked on ppc64el

[Cordell Bloor]

Package: libamdhip64-dev
Version: 5.2.3-10
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

The rocprim-tests package FTBFS on ppc64el in part due to a failure to
link compiler_rt for half-float operations [1]. This results in the
errors:

/usr/bin/ld: CMakeFiles/test_block_reduce.dir/test_block_reduce.cpp.o: in 
function `__half::__half(double)':
/usr/include/hip/amd_detail/amd_hip_fp16.h:101: undefined reference to 
`__truncdfhf2'
/usr/bin/ld: /usr/include/hip/amd_detail/amd_hip_fp16.h:101: undefined 
reference to `__truncdfhf2'

rocm-hipamd does not search correctly for compiler_rt on ppc64el. I'd
thought the architecture name would be `uname -m` (ppc64le) but it's
actually `dpkg-architecture -qDEB_HOST_GNU_CPU` (powerpc64le).
Until this is fixed in rocm-hipamd, users can work around this problem
by adding -lclang_rt.builtins-powerpc64le to their build flags.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=rocprim=ppc64el=5.3.3-6=1689203881=0

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

Kernel: Linux 6.3.0-1-powerpc64le (SMP w/4 CPU threads)
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 libamdhip64-dev depends on:
ii  libamd-comgr-dev 5.2.3-2
ii  libamdhip64-55.2.3-10
ii  libhiprtc-builtins5  5.2.3-10
ii  libhsa-runtime-dev   5.2.3-4

libamdhip64-dev recommends no packages.

libamdhip64-dev suggests no packages.

-- no debconf information

Bug#1041004: firmware-b43-installer: Drivers in this package are not available in debian-12.0.0-amd64-netinst.iso at time of writing.

[David Peacock]

Package: firmware-b43-installer
Severity: normal
X-Debbugs-Cc: david.j.peac...@gmail.com

Dear Maintainer,

Upon attempting to install Debian 12 using [0] on my early 2013 Retina
Macbook Pro, I discovered that the drivers needed to operate the
Broadcom wireless card included were not available.  It was my
understanding that these drivers should be included in the newly
established non-free-firmware repository.

I'm raising this bug report purely to bring this to attention in hope
that it's possible to add these drivers to the Bookworm netinst image to
avoid having to deal with this when installing on various models of
Macbook Pro.

Thank you
David

[0] 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.0.0-amd64-netinst.iso

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

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

Versions of packages firmware-b43-installer depends on:
pn  b43-fwcutter 
ii  bzip21.0.8-5+b1
ii  ca-certificates  20230311
ii  pciutils 1:3.9.0-4
ii  wget 1.21.3-1+b2

firmware-b43-installer recommends no packages.

firmware-b43-installer suggests no packages.

Bug#1040868: glibc 2.36-9+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: glibc
Version: 2.36-9+deb12u1

Explanation: fix a buffer overflow in gmon; fix a deadlock in getaddrinfo 
(__check_pf) with deferred cancellation; fix y2038 support in strftime on 
32-bit architectures; fix corner case parsing of /etc/gshadow which can return 
bad pointers, causing segfaults in applications; fix a deadlock in system() 
when called concurrently from multiple threads; cdefs: limit definition of 
fortification macros to __FORTIFY_LEVEL > 0 to support old C90 compilers

Bug#1041003: clang-15: Crash in PowerPC DAG->DAG Pattern Instruction Selection

[Cordell Bloor]

Package: clang-15
Version: 1:15.0.7-6
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

On ppc64el, the clang compiler crashed on buildd [1] during the
compilation of test_block_sort.cpp in the rocprim package. We're only
compiling HIP programs for ppc64el on a best-effort basis, as it is not
an officially supported architecture upstream. Nevertheless, a compiler
crash seemed to be worth reporting. I've reproduced this problem on my
local machine in a QEMU VM.

There were also linking errors related to half-floats in the build log
(__truncdfhf2), but that is unrelated. I fixed that bug in rocm-hipamd
locally before reproducing the crash.

The full log is linked below, but I'll include a snippet inline:

Stack dump:
0.  Program arguments: /usr/lib/llvm-15/bin/clang -cc1
-triple powerpc64le-unknown-linux-gnu -aux-triple amdgcn-amd-amdhsa
<>
/<>/test/rocprim/test_block_sort.cpp
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module 
'/<>/test/rocprim/test_block_sort.cpp'.
4.  Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on 
function
'@_ZN53RocprimBlockSortTestsFloating_CustomSortKeyValue_TestI12block_paramsI6__halfS1_Lj64EEE8TestBodyEv'

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=rocprim=ppc64el=5.3.3-6=1689203881=0

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

Kernel: Linux 6.3.0-1-powerpc64le (SMP w/4 CPU threads)
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 clang-15 depends on:
ii  binutils2.40.90.20230705-1
ii  libc6   2.37-5
ii  libc6-dev   2.37-5
ii  libclang-common-15-dev  1:15.0.7-6
ii  libclang-cpp15  1:15.0.7-6
ii  libclang1-151:15.0.7-6
ii  libgcc-12-dev   12.3.0-6
ii  libgcc-s1   13.1.0-8
ii  libllvm15   1:15.0.7-6
ii  libobjc-12-dev  12.3.0-6
ii  libstdc++-12-dev12.3.0-6
ii  libstdc++6  13.1.0-8
ii  llvm-15-linker-tools1:15.0.7-6

Versions of packages clang-15 recommends:
ii  llvm-15-dev  1:15.0.7-6
ii  python3  3.11.4-5

Versions of packages clang-15 suggests:
pn  clang-15-doc  
pn  wasi-libc 

-- no debconf information

Bug#1040901: linux modules must not be signed with CA key, bump ABI every upload

[Ben Hutchings]

On Wed, 12 Jul 2023 10:05:03 +0200 Julian Andres Klode 
wrote:
[...]
> A reasonable compromise at a first step for a limited time is to
> ensure that
> 
> 1) the kernel refuses to load modules for a different ABI in
lockdown,
>    for example, the modprobe --force-vermagic does not work anymore.
[...]

I already implemented that in 2016.  Did it break?

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



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

Bug#1038463: cegui-mk2: Is this library still useful to have in Debian?

[Olek Wojnar]

Control: tag -1 + moreinfo

On 6/18/23 11:55, Simon McVittie wrote:

While opening bugs for packages that depend on libsdl1.2, I noticed
that cegui-mk2 seems to be a library that is not depended on by anything
in Debian. Is it still useful to have in the distribution?


That's a very fair question. I would submit that the value of continuing 
to maintain CEGUI is as a programming and development tool for our 
users; especially if I ever have a spare moment to package CEED [1]. 
That is a well-featured editor for creating GUIs (using CEGUI) in 
developmental programs.


However, the latest stable release *IS* very old at this point and is 
becoming difficult to maintain. I messaged the developers to ask about 
their plans for a newer release. Once they respond, I will update this bug.



Looking at https://qa.debian.org/popcon.php?package=cegui-mk2, there
were a relatively large number of installations in the 2008-2010 period,
and a dramatic drop after 2010. I assume this is a result of some game
that used to use cegui-mk2 either switching away from it or being removed
from Debian.


I believe that's when Ember (which I also previously maintained) went 
into heavy development and we ultimately decided to remove it from 
Debian. I'm not aware of any other programs that use (or have used) 
CEGUI. Oh, wait. That was more recent. In the 2010 timeframe I believe 
there was a temporary loss of momentum upstream. I may be misremembering 
that. In any case, too much development or not enough, Ember 
installations likely impacted CEGUI installations in Debian.



If cegui-mk2 is no longer useful, we could remove it from the archive to
avoid it taking up QA time.


I agree in principle. However, we might not have the same definition of 
"useful." :) I will say that if upstream is not open to releasing an 
updated version then my willingness to devote extensive time to keeping 
this package current will likely diminish. As will my perception of its 
usefulness in Debian.



If it's removed, as far as I can see, we could also remove irrlicht (which
was previously a dependency for minetest, but minetest has switched to
a vendored fork of irrlicht).


I don't know much about that package but if there isn't a strong 
argument to keep it as a resource for software developers who use 
Debian, then I agree it would no longer be useful.


Also, thanks for bringing this up! It's a tough conversation to have but 
it *IS* a conversation that we should be having.



-Olek

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962308

Bug#1033791: #1033791: check_running_kernel fails to find version on bookworm/armhf as well

[Holger Levsen]

control: retitle -1 check_running_kernel fails to find version on 
bookworm/(arm64|armhf)
thanks

hi,

I can confirm this bug affects armhf as well:

holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@jtx1a:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname -a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux jtx1a 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 GNU/Linux

I can also confirm the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1033791;filename=0001-Extend-fix-for-on-disk-version-detection-on-Bookworm.patch;msg=15
to be working:

holger@jtx1a:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

And this also affects armhf systems running with an arm64 kernel:

holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname 
-a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux virt64c 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 
GNU/Linux


-- 
cheers,
Holger

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

We can send billionaires to space but not kids to fully funded public schools.


signature.asc
Description: PGP signature

Bug#1041002: easy-format FTBFS with ocaml-dune 3.9.0

[Adrian Bunk]

Source: easy-format
Version: 1.3.4-1
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/trixie/arm64/easy-format.html

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/easy-format-1.3.4'
dune install --destdir=/build/easy-format-1.3.4/debian/tmp --prefix=/usr 
--libdir=../usr/lib/ocaml
dune: option '--libdir': the path must be absolute to avoid ambiguity
Usage: dune install [OPTION]… [PACKAGE]…
Try 'dune install --help' or 'dune --help' for more information.
make[1]: *** [debian/rules:22: override_dh_auto_install] Error 1

Bug#1041001: cryptokit FTBFS with ocaml-dune 3.9.0

[Adrian Bunk]

Source: cryptokit
Version: 1.18-1
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cryptokit.html

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/1st/cryptokit-1.18'
dune install --destdir=/build/1st/cryptokit-1.18/debian/tmp --prefix=/usr 
--libdir=../usr/lib/ocaml
dune: option '--libdir': the path must be absolute to avoid ambiguity
Usage: dune install [OPTION]… [PACKAGE]…
Try 'dune install --help' or 'dune --help' for more information.
make[1]: *** [debian/rules:20: override_dh_auto_install] Error 1

Bug#1041000: cppo FTBFS with ocaml-dune 3.9.0

[Adrian Bunk]

Source: cppo
Version: 1.6.9-1
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cppo.html

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/1st/cppo-1.6.9'
dune install --destdir=/build/1st/cppo-1.6.9/debian/tmp --prefix=/usr 
--libdir=../usr/lib/ocaml
dune: option '--libdir': the path must be absolute to avoid ambiguity
Usage: dune install [OPTION]… [PACKAGE]…
Try 'dune install --help' or 'dune --help' for more information.
make[1]: *** [debian/rules:19: override_dh_auto_install] Error 1

Bug#1040999: camlimages FTBFS with ocaml-dune 3.9.0

[Adrian Bunk]

Source: camlimages
Version: 1:5.0.4-2
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/camlimages.html

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/1st/camlimages-5.0.4'
dune install --destdir=/build/1st/camlimages-5.0.4/debian/tmp --prefix=/usr 
--libdir=../usr/lib/ocaml
dune: option '--libdir': the path must be absolute to avoid ambiguity
Usage: dune install [OPTION]… [PACKAGE]…
Try 'dune install --help' or 'dune --help' for more information.
make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

On Fri, 14 Jul 2023 00:33:25 +0500
Roman Mamedov  wrote:

> There isn't really an image per board, but at least a clever system of
> concatenating a board-specific bootloader and a board-agnostic rest of the
> image. That looks reasonable enough, and I suppose building the current
> 12 bootloaders is automated. Maybe add all 42 to that automation for now?

Or actually, that was 42 just for Allwinner, and much much more if you include
other vendors. So adding them all to the regular build might not be as
feasible after all. I remember now, that's why I proposed building them all
not daily, but at least once per month.

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

Hello,

On Thu, 13 Jul 2023 21:27:09 +0200
Emanuele Rocca  wrote:

> On 2023-07-01 04:18, Roman Mamedov wrote:
> > There are 42 DTBs shipped with the installer for Allwinner alone:
> > https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
> > 
> > But for the bootloader aka firmware aka u-boot:
> > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
> > it is an extremely weird and arbitrary list of 12 random boards. For 
> > instance
> > supporting "Orange Pi Zero Plus2" of all things specifically, not even just
> > "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).
> 
> The choice of 12 boards does indeed look a little puzzling. Having no
> historical background on this, I can try and guess that they were added
> on a case-by-case basis every time someone needed to boot the installer
> on their system. Out of interest: do you have a board that's not among
> the lucky 12? :-)

Yes, as a weird coincidence with my initial message, I have an Orange Pi Prime
and Orange Pi Win. :)

> > So despite having all the other DTBs, the system is not installable on those
> > boards. Unless the user is sent to find and compile their own u-boot, but if
> > so, what is the purpose of randomly providing it for 12 random niche boards 
> > to
> > begin with, might as well make everyone do that.
> > 
> > Instead, I suggest a better solution: maybe not even daily, but at least 
> > once
> > per month, could you build a bootloader part for ALL the supported boards, 
> > and
> > not just a handful of them.
> 
> In an ideal world we would have just one single image that works on all
> systems! That's one of the ideas behind the Arm SystemReady
> certification program at least: making sure that the board can boot a
> regular, unmodified distro ISO without any additional blobs.
> 
> We don't live in such a world unfortunately, at least not yet and not
> for all boards. I'm not sure we should have one different image for each
> DTB honestly. I'd rather go for having no custom images at all, but a
> very simple procedure to build your own image for your board. Maybe in
> the form of documentation, or a script, or both.

There isn't really an image per board, but at least a clever system of
concatenating a board-specific bootloader and a board-agnostic rest of the
image. That looks reasonable enough, and I suppose building the current
12 bootloaders is automated. Maybe add all 42 to that automation for now?

-- 
With respect,
Roman

Bug#1040998: chromaprint FTBFS with googletest 1.13.0

[Adrian Bunk]

Source: chromaprint
Version: 1.5.1-2
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chromaprint.html

...
In file included from 
/usr/src/googletest/googletest/include/gtest/gtest-message.h:57,
 from 
/usr/src/googletest/googletest/include/gtest/gtest-assertion-result.h:46,
 from /usr/src/googletest/googletest/include/gtest/gtest.h:64,
 from /usr/src/googletest/googletest/src/gtest-all.cc:38:
/usr/src/googletest/googletest/include/gtest/internal/gtest-port.h:270:2: 
error: #error C++ versions less than C++14 are not supported.
  270 | #error C++ versions less than C++14 are not supported.
  |  ^
...


This can be fixed by setting CMAKE_CXX_STANDARD to 14 in CMakeLists.txt

Bug#1040915: dbus 1.14.8-2~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dbus
Version: 1.14.8-2~deb12u1

Explanation: stop trying to take DPKG_ROOT into account, restoring copying of 
systemd's /etc/machine-id in preference to creating an entirely new machine ID

Bug#1040860: mrtg 2.17.10-5+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: mrtg
Version: 2.17.10-5+deb12u1

Explanation: handle relocated configuration file; translation updates

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

Graham,

On 13 July 2023 at 18:59, Graham Inggs wrote:
| I believe the attached patch should do the trick.  It's basically
| Paul's list from message #210, plus r-cran-interval and
| r-cran-maldiquant.  I've also used a << relationship against the
| versions in unstable, and appended a tilde at the end.  I believe this
| will work better for derivatives and make backports easier.

Almost done building, will upload shortly.

Thanks, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1040644: [INTL:ro] Translation-revision of "apt" to Romanian

[Remus-Gabriel Chelu]

Hi David,

Thanks for everything, understanding, explanations and help;
a pleasure to talk with you!

I have attached, complete with the missing/new string, the file in question.


Best regards,
Remus-Gabriel




ro.po.gz
Description: GNU Zip compressed data

Bug#1040010: [debian-installer] Please support more arm64 boards

[Emanuele Rocca]

Hello Roman,

On 2023-07-01 04:18, Roman Mamedov wrote:
> There are 42 DTBs shipped with the installer for Allwinner alone:
> https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
> 
> But for the bootloader aka firmware aka u-boot:
> https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
> it is an extremely weird and arbitrary list of 12 random boards. For instance
> supporting "Orange Pi Zero Plus2" of all things specifically, not even just
> "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).

The choice of 12 boards does indeed look a little puzzling. Having no
historical background on this, I can try and guess that they were added
on a case-by-case basis every time someone needed to boot the installer
on their system. Out of interest: do you have a board that's not among
the lucky 12? :-)
 
> So despite having all the other DTBs, the system is not installable on those
> boards. Unless the user is sent to find and compile their own u-boot, but if
> so, what is the purpose of randomly providing it for 12 random niche boards to
> begin with, might as well make everyone do that.
> 
> Instead, I suggest a better solution: maybe not even daily, but at least once
> per month, could you build a bootloader part for ALL the supported boards, and
> not just a handful of them.

In an ideal world we would have just one single image that works on all
systems! That's one of the ideas behind the Arm SystemReady
certification program at least: making sure that the board can boot a
regular, unmodified distro ISO without any additional blobs.

We don't live in such a world unfortunately, at least not yet and not
for all boards. I'm not sure we should have one different image for each
DTB honestly. I'd rather go for having no custom images at all, but a
very simple procedure to build your own image for your board. Maybe in
the form of documentation, or a script, or both.

  Emanuele

Bug#1040997: tzdata: remove country name symlinks from top-level directory for better organization

[sovicw+cpd2f9f84xyt8]

Package: tzdata
Version: 2023c-7
Severity: normal

Dear Maintainer,

These directories are names of countries and contain only symlinks to elsewhere:
/usr/share/zoneinfo/Brazil/
/usr/share/zoneinfo/Canada/
/usr/share/zoneinfo/Chile/
/usr/share/zoneinfo/Mexico/
/usr/share/zoneinfo/US/

These country names exist in the "top-level" directory /usr/share/zoneinfo/ and 
are only symlinks to elsewhere:
Cuba
Egypt
Eire
GB
GB-Eire
Hongkong
Iceland
Iran
Israel
Jamaica
Japan
Kwajalein
Libya
NZ
NZ-CHAT
Navajo
PRC
Poland
Portugal
ROC
ROK
Singapore
Turkey
W-SU

There are around 200 recognized countries in the world, and there probably is a 
historical reason for the above countries to be mentioned by name and receive 
special treatment in tzdata.

If this historical reason is no longer relevant, please start gradually moving 
towards using as few country names in tzdata as possible, and instead use a 
directory for geographical region (continent or ocean) and city name inside 
that directory.

Please keep the top-level directory /usr/share/zoneinfo/ clean and organized. 
Thank you.

https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2008076 has already taken 
some steps towards better organizing of the tzdata files in /usr/share/zoneinfo/

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Graham Inggs]

Hi Dirk

On Thu, 13 Jul 2023 at 16:25, Dirk Eddelbuettel  wrote:
> Sounds good, and thanks for the assist! I should be able to provide a pretty
> quick turn-around.

I believe the attached patch should do the trick.  It's basically
Paul's list from message #210, plus r-cran-interval and
r-cran-maldiquant.  I've also used a << relationship against the
versions in unstable, and appended a tilde at the end.  I believe this
will work better for derivatives and make backports easier.

Regards
Graham
--- a/debian/control
+++ b/debian/control
@@ -52,31 +52,17 @@
 Provides: r-api-4.0, r-graphics-engine-${graphicsengine:Version}
 Recommends: r-recommended, r-base-dev, r-doc-html
 Suggests: elpa-ess, r-doc-info | r-doc-pdf, r-mathlib, r-base-html
-Breaks: r-bioc-graph (<< 1.62.0-1~),
-r-cran-bbmle (<< 1.0.20-5~),
-r-cran-biocmanager (<< 1.30.4+dfsg-2~),
-r-cran-caret (<< 6.0-84-2~),
-r-cran-cmprsk (<< 2.2-8-1~),
-r-cran-coin (<< 1.3-0-1~),
-r-cran-dendextend (<< 1.12.0+dfsg-1~),
-r-cran-fields (<< 9.8-3-1~),
-r-cran-filehash (<< 2.4-2-2~),
-r-cran-future (<< 1.14.0+dfsg-1~),
-r-cran-genetics (<< 1.3.8.1.2-1~),
-r-cran-haplo.stats (<< 1.7.9-4~),
-r-cran-igraph (<< 1.2.4.1-1~),
-r-cran-lava (<< 1.6.5-1~),
-r-cran-libcoin (<< 1.0-4-1~),
-r-cran-msm (<< 1.6.7-1~),
-r-cran-permute (<< 0.9-5-1~),
-r-cran-phangorn (<< 2.5.5-1~),
-r-cran-popepi (<< 0.4.7-1~),
-r-cran-recipes (<< 0.1.6-1~),
-r-cran-sp (<< 1:1.3-1-2~),
-r-cran-spam (<< 2.2-2-1~),
-r-cran-units (<< 0.6-3-1~),
-r-cran-vegan (<< 2.5-5+dfsg-1~),
-r-cran-zelig (<< 5.1.6.1-1~)
+Breaks: r-cran-cairo (<< 1.6-0-4~),
+r-cran-intervals (<< 0.15.3-1~),
+r-cran-fnn (<< 1.1.3.2-1~),
+r-cran-magick (<< 2.7.4+dfsg-2~),
+r-cran-maldiquant (<< 1.22.1-1~),
+r-cran-ps (<< 1.7.5-1~),
+r-cran-ragg (<< 1.2.5-3~),
+r-cran-svglite (<< 2.1.1-3~),
+r-cran-tibble (<< 3.2.1+dfsg-2~),
+r-cran-tikzdevice (<< 0.12.4-3~),
+r-cran-vdiffr (<< 1.0.5-3~)
 Description: GNU R core of statistical computation and graphics system
  R is a system for statistical computation and graphics.  It consists 
  of a language plus a run-time environment with graphics, a debugger, 

Bug#1040996: Davical defines a Content-Security-Policy without scoping it to its own resources

[Alain Knaff]

Package: davical
Version: 1.1.12-2

Hi,

At the end of its example / reference configuration file 
/etc/apache2/sites-available/davical.conf,
davical defines a Content-Security-Policy, but forgets to bracket it with 
 instructions
to scope it to its own resources.

Should be:



  Header set Content-Security-Policy "default-src 'none'; img-src 'self' data:; 
media-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' data:; 
font-src 'self' data:; object-src 'self'; base-uri 'self'; connect-src 'self'; 
form-action 'self' sis.redsys.es; frame-ancestors 'self'"



... or even better, move it up to the existing  scope on
top of the file, along with all the other items.

Without such scoping, the Content-Security-Policy applies to *all* resources on 
the server,
including those of other, unrelated web applications. In our case, this broke 
nextcloud by
interfering with nextcloud's own Content-Security-Policy.

Similar issue may exist with the RewriteRules, we noticed that nextcloud failed 
to correctly locate
its .well-known resources. Davical should only rewrite those .well-known 
resources that it specifically
supplies, rather than (.*)

Thanks for fixing this,

Alain

Bug#1040995: librust-kv-log-macro-dev is no longer installable

[Adrian Bunk]

Package: librust-kv-log-macro-dev
Version: 1.0.8-2
Severity: serious
Tags: trixie sid

The following packages have unmet dependencies:
 librust-kv-log-macro-dev : Depends: librust-log-0.4+kv-unstable-dev (>= 0.4.8)

Bug#1040994: python3-skimage must build depend on python3-imageio (>= 2.31.1-1)

[Adrian Bunk]

Package: python3-skimage
Version: 0.21.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/s/skimage/35740206/log.gz

...
 66s _ ERROR collecting io/tests/test_collection.py 
_
 66s ImportError while importing test module 
'/usr/lib/python3/dist-packages/skimage/io/tests/test_collection.py'.
 66s Hint: make sure your test modules/packages have valid Python names.
 66s Traceback:
 66s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
 66s return _bootstrap._gcd_import(name[level:], package, level)
 66s /usr/lib/python3/dist-packages/skimage/io/tests/test_collection.py:5: in 

 66s import imageio.v3 as iio3
 66s E   ModuleNotFoundError: No module named 'imageio.v3'
 66s === warnings summary 
===
 66s ../../../../usr/lib/python3/dist-packages/pkg_resources/__init__.py:121
 66s   /usr/lib/python3/dist-packages/pkg_resources/__init__.py:121: 
DeprecationWarning: pkg_resources is deprecated as an API
 66s warnings.warn("pkg_resources is deprecated as an API", 
DeprecationWarning)
 66s 
 66s ../../../../usr/lib/python3/dist-packages/pkg_resources/__init__.py:2870
 66s   /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2870: 
DeprecationWarning: Deprecated call to 
`pkg_resources.declare_namespace('mpl_toolkits')`.
 66s   Implementing implicit namespace packages (as specified in PEP 420) is 
preferred to `pkg_resources.declare_namespace`. See 
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
 66s declare_namespace(pkg)
 66s 
 66s ../../../../usr/lib/python3/dist-packages/pywt/__init__.py:14
 66s   /usr/lib/python3/dist-packages/pywt/__init__.py:14: DeprecationWarning: 
The distutils package is deprecated and slated for removal in Python 3.12. Use 
setuptools or check PEP 632 for potential alternatives
 66s from distutils.version import LooseVersion
 66s 
 66s ../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:433
 66s   /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:433: 
PytestCacheWarning: could not create cache path 
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/nodeids
 66s config.cache.set("cache/nodeids", sorted(self.cached_nodeids))
 66s 
 66s ../../../../usr/lib/python3/dist-packages/_pytest/cacheprovider.py:387
 66s   /usr/lib/python3/dist-packages/_pytest/cacheprovider.py:387: 
PytestCacheWarning: could not create cache path 
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/lastfailed
 66s config.cache.set("cache/lastfailed", self.lastfailed)
 66s 
 66s ../../../../usr/lib/python3/dist-packages/_pytest/stepwise.py:56
 66s   /usr/lib/python3/dist-packages/_pytest/stepwise.py:56: 
PytestCacheWarning: could not create cache path 
/usr/lib/python3/dist-packages/skimage/.pytest_cache/v/cache/stepwise
 66s session.config.cache.set(STEPWISE_CACHE_DIR, [])
 66s 
 66s -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 66s === short test summary info 

 66s ERROR 
../../../../usr/lib/python3/dist-packages/skimage/io/tests/test_collection.py
 66s  Interrupted: 1 error during collection 

 66s === 5 skipped, 6 warnings, 1 error in 3.69s 

 67s autopkgtest [00:30:25]: test python3: ---]
 67s autopkgtest [00:30:25]: test python3:  - - - - - - - - - - results - - - - 
- - - - - -
 67s python3  FAIL non-zero exit status 2




This is due to

skimage (0.21.0-2) unstable; urgency=medium

  * Drop Don-t-import-unavailable-imageio.v3.patch: package is available now
...
 -- Ole Streicher   Mon, 10 Jul 2023 15:39:10 +0200


Updating the build dependency to python3-imageio (>= 2.31.1-1)
(which will also version the runtime dependency) will ensure
that a recent enough version of python3-imageio is installed
when building or running skimage.

Bug#1040993: libcbor: New upstream release (0.10.2, 2023-01-31)

[Florian Ernst]

Source: libcbor
Version: 0.8.0-2
Severity: wishlist

Dear maintainer,

there are several new upstream releases available at
, their changes read

| 0.10.2 (2023-01-31)
| - Fixed minor test bug causing failures for x86 Linux (discovered by
|   trofi)
|   - Actual libcbor functionality not affected, bug was in the test suite
| - Made tests platform-independent
| 
| 0.10.1 (2022-12-30)
| - Fix a regression in cbor_serialize_alloc that caused serialization of
|   zero-length strings and bytestrings or byte/strings with zero-length
|   chunks to fail (discovered by martelletto)
| 
| 0.10.0 (2022-12-29)
| - Make the buffer_size optional in cbor_serialize_alloc [#205] (by
|   hughsie)
| - BREAKING: Improved half-float encoding for denormalized numbers.
|   [#208] (by ranvis)
|   - Denormalized half-floats will now preserve data in the mantissa
|   - Note: Half-float NaNs still lose data (#215)
| - BUILD BREAKING: Minimum CMake version is 3.0 [#201] (by thewtex@)
|   - See https://repology.org/project/cmake/versions for support; the
| vast majority of users should not be affected.
| - Fix a potential memory leak when the allocator fails during array or
|   map decoding [#224] (by James-ZHANG)
| - Fix a memory leak when the allocator fails when adding chunks to
|   indefinite bytestrings. (discovered by James-ZHANG)
| - Fix a memory leak when the allocator fails when adding chunks to
|   indefinite strings
| - Potentially BUILD BREAKING: Add nodiscard attributes to most functions
|   - Warning: This may cause new build warnings and (in rare cases,
| depending on your configuration) errors
| - BREAKING: Fix cbor_copy leaking memory and creating invalid items when
|   the allocator fails.
|   - Previously, the failures were not handled in the interface. Now,
| cbor_copy may return NULL upon failure; clients should check the
| return value
| - Fix cbor_build_tag illegal memory behavior when the allocator fails
| - Add a new cbor_serialized_size API
| - Reworked cbor_serialize_alloc to allocate the exact amount of memory
|   necessary upfront
|   - This should significantly speed up cbor_serialize_alloc for large
| items by avoiding multiple reallocation iterations
|   - Clients should not use the return value of cbor_serialize_alloc. It
| may be removed in the future.
| - BUILD BREAKING: Deprecate CBOR_CUSTOM_ALLOC
|   - cbor_set_allocs will always be enabled from now on
|   - Note: The flag will be kept as a no-op triggering a warning when
| used for one version and then removed completely
| 
| 0.9.0 (2021-11-14)
| - Improved pkg-config paths handling [#164] (by jtojnar@)
| - Use explicit math.h linkage [#170]
| - BREAKING: Fixed handling of items that exceed the host size_t range
|   [#186]
|   - Callbacks for bytestrings, strings, arrays, and maps use uint64_t
| instead of size_t to allow handling of large items that exceed
| size_t even if size_t < uint64_t
|   - cbor_decode explicitly checks size to avoid overflows (previously
| broken, potentially resulting in erroneous decoding on affected
| systems)
|   - The change should be a noop for 64b systems
| - Added a Bazel build example [#196] (by andyjgf@)

Well, those contain quite some changes marked as BREAKING which might
complicate things.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040945: tiff: CVE-2023-3618

[Salvatore Bonaccorso]

Hi László,

On Wed, Jul 12, 2023 at 10:12:50PM +0200, László Böszörményi wrote:
> Hi Salvatore,
> 
> On Wed, Jul 12, 2023 at 9:39 PM Salvatore Bonaccorso  
> wrote:
> > Source: tiff
> > Version: 4.5.1-1
> > CVE-2023-3618[0]:
> > | A flaw was found in libtiff. A specially crafted tiff file can lead
> > | to a segmentation fault due to a buffer overflow in the Fax3Encode
> > | function in libtiff/tif_fax3.c, resulting in a denial of service.
> [...]
> > Please adjust the affected versions in the BTS as needed.
>  Done my quick testing. My experience is the following.
> 1) libtiff6 and libtiff-tools are both 4.5.1-1 (ie, Trixie): the tool
> reports several warnings, exists with 1 (non-zero) but doesn't
> segfault. Even tried with valgrind, still no segfault.
> 2) libtiff6 is 4.5.1-1 backported to Bookworm and libtiff-tools are
> not, ie it's 4.5.0-6 : the tool reports the same warnings like above,
> but this time it _does_ segfault.
> 3) If libtiff-tools also updated to 4.5.1-1 on Bookworm: it's like the
> first case, several warnings, non-zero exit code without a segfault.
> 
> In short, it seems:
> - it's a non-dsa as only a crash in a CLI tool (which has end of life now),
> - doesn't affect the library,
> - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable,
> 4.5.1-1 fixed this issue.
> 
> But you may find it otherwise, I do not alter this report in the BTS.

Thanks for coming back that quickly, impressive :).

I do completely agree, it's a no-dsa issue similar to the others, was
done already.

For about having the issue fixed: The problem I have is that upstream
has not yet closed the issue. Is it completely fixed and what is the
fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is
slight unhelpful on that front.

Are you able to identify the fixing commit confirming it is done in
4.5.1-1?

Regards,
Salvatore

Bug#967941: Bug appeared again

[fred]

On Mon, 23 Jan 2023 12:04:59 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?=
 wrote:
> On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-
1?Q?Verb=FCcheln?=  wrote:
> > This bug appears back some time ago. For some months, video
thumbnails
> > failed to generate on multiple of my machines. Since then, I was
trying
> > to figure out the cause.
> > 
> > It only seemed to affect h264, but not all videos were affected. I
even
> > had multiple videos saved from Youtube, some were generating
> > thumbnails, others were not. I could not find any difference in the
> > codec parameters.
> > 
> > Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer
> > worked to prevent this bug. Does this option have any downsides?
> > 
> > Regards
> 
> 
> Hello,
> it looks like this option makes it not setting the process limits [1]
[2].
> 
> Simon wrote it that way before:
>    totem-video-thumbnailer sets a resource limit ... to avoid a
runaway
>    thumbnailing process consuming disproportionate system resources.
> 
> Kind regards,
> Bernhard
> 
> [1]
https://sources.debian.org/src/totem/43.0-2/src/totem-video-thumbnailer.c/#L587
>  587  { "no-limit", 'l', G_OPTION_FLAG_REVERSE,
G_OPTION_ARG_NONE, _limit, "Don't limit the thumbnailing time to
30 seconds", NULL },
> 
> [2]
https://sources.debian.org/src/totem/43.0-2/src/totem-resources.c/?hl=111#L111
> 
> 

Still encountering this annoying bug on my testing (trixie) system
(main computer)

However I am unable to remove the libopenblas0-pthread:amd64 0.3.23+ds-
2 package without destroying my operating system (too many programs
depend on it)

so I use the "-l" thumbnailer option workaround as mentioned earlier in
this thread, which works.

I also confirm that the bug is not found in a vanilla Gnome desktop
Debian 12 installation.

Greetings

Fred.

Bug#1040992: Add support for oldoldstable

[Baptiste Beauplat]

Package: distro-info
Severity: wishlist

Dear Maintainer,

It would be nice to have support for getting the associated codename
for oldoldstable as already implemented for oldstable, stable, testing
and unstable.

Let me know if you would be willing to include this feature into
distro-info, I would be interested in providing the associated
patch/MR.

Best,
-- 
Baptiste Beauplat



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

Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

[Simon McVittie]

On Mon, 10 Jul 2023 at 17:27:50 +0200, yogg wrote:
> After installation was finished and the system has been restarted the
> files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked
> in any way (no soft or hardlink) and the ID inside the files differ from
> each other.

This was a regression in bookworm, thank you for reporting it. A fix is
in unstable, and on its way into testing and a future bookworm stable
update (hopefully as soon as 12.1, which is due in just over a week).

What user-visible symptoms, if any, did this cause for you? The machine
ID can be used by almost anything (in the same way that almost anything
can use the hostname), so it's difficult to get a clear picture of how
bad this is, or how much risk it would be acceptable to take when fixing
this up on existing systems.

> Workaround:
> rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen 
> --ensure=/etc/machine-id && dbus-uuidgen --ensure

"rm /var/lib/dbus/machine-id && dbus-uuidgen --ensure" would be enough,
in fact.

smcv

Bug#1040991: gcc-13: consider stripping lto1 / cc1 / cc1plus

[Mateusz Łukasik]

Source: gcc-13
Version: 13.1.0-8
Severity: minor


Dear Maintainer,

Like it was before in #783876 #894014 #1015185 gcc-13 package in contain 
unstripped debug
info.

--
.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member -mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#1040990: chromium: switch package from master_preferences to initial_preferences & warn users

[Andres Salomon]

Package: chromium
Version: 114.0.5735.198-1

Upstream chromium switched away from master_preferences to 
initial_preferences for their first run config override file - I think 
sometime around chromium 105. We had been hardcoding 
/etc/chromium/master_preferences in the old version of the 
debianization/master-preferences patch, and had only noticed that the 
the default changed circa chromium 112. We adjusted the patch to accept 
both config file locations.


However, with chromium 115, the logic to check for both config file 
locations moved from the same function that our 
master-preferences.patch modifies, to a completely different directory 
& file. Thus, when upstream finally drops support for 
master_preferences, we're likely not going to even notice until users 
start complaining.


Our packaging also still creates /etc/chromium/master_preferences. So 
the first thing we need to do is switch that to initial_preferences. 
The next thing we need to do is to warn users about the change, in case 
they're supplying their own initial config override. A NEWS entry seems 
like overkill considering the vast majority of users don't care about 
it, so I'm thinking what would make the most sense would be to either 
modify debianization/master-preferences.patch to spit out a warning if 
master_preferences is detected, or have the package's postinst script 
check for the file and spit out a warning. The former option would only 
be seen the first time chromium is run, while the latter would be seen 
every time an upgrade is done (and could automatically rename 
master_preferences to initial_preferences if initial_preferences 
doesn't already exist).

Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1

[Aaron M. Ucko]

"Adam D. Barratt"  writes:

> If you were intending to close this p-u request there, please don't.
> The bug will get closed once the updated package is in stable as part
> of a point release.

Ah, right, I'll leave that off, then.

> Is the removal of .gitignore intentional?

No, that was an artifact of using an atypical build procedure; sorry for
the noise.  (I'd held off on committing these tentative changes, so gbp
would have required a special flag; I substituted plain debuild but
evidently didn't get its flags quite right.)

> The fix itself looks fine, so please feel free to go ahead (with the
> Closes: removed and possibly with .gitignore restored if appropriate).

Will do, thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1

[Aurelien Jarno]

Hi Adam,

On 2023-07-13 17:01, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote:
> > The upstream stable branch got a few fixes during the bookworm freeze
> > period, and this update pulls them into the debian package. In short:
> >  - Fix a buffer overflow and memory corruption in the gmon
> >functionality.
> >  - Fix a deadlock in getaddrinfo() and system() functions
> >  - Fix y2038 support in strftime on 32-bit architectures.
> >  - Fix possible segmentation fault in applications using sgetsgent()
> >when /etc/gshadow contains very long lines
> >  - Fix support for old C90 compilers.
> > 
> > In addition this include a Slovak translation update fixing typos,
> > that
> > 
> 
> Please go ahead, bearing in mind that the window for 12.1 closes over
> the coming weekend.

Thanks for the review, I have just uploaded it.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1021428: weston: debian/watch is obsolete

[Patrice Duroux]

Dear weston maintainers,

If I follow well, this request is already closed by this commit:
https://salsa.debian.org/xorg-team/wayland/weston/-/commit/a3edbe19bd55b8eee64e0a40c459c25e22afb4a9
that is included in 11.0.0-2 (rc-buggy).

Dear QA team,

My trouble was that its Debian Package Tracker page does not report such a
possible new upstream version. And neither any of the Dashboard with weston
package in the lists.

Could this be interesting as an improvement to address to DPT to display the new
upstream corresponding to each Debian release (at least for sid and rc-buggy)?

And checking UDD, it have already the upstream version 12.0.1 in its data.

Thanks,
Patrice

Bug#1040943: marked as done (systemd-logind: 'HandlePowerKey=ignore' works in logind.conf, not in logind.conf.d/custom.conf)

[Michael Biebl]

Am 13.07.23 um 20:03 schrieb Debian Bug Tracking System:

So it's mostly a PEBKAC issue, although adding the "[Login]" header part to
the docs may be useful as that wasn't clear to me.


Hm, man logind.conf.d says:

OPTIONS
   All options are configured in the [Login] section:
...


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040989: libcdr: New upstream release (0.1.7, 26-Mar-2021)

[Florian Ernst]

Source: libcdr
Version: 0.1.6-2
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
, containing various fixes.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040875: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2023-07-11 at 23:18 +0300, Michael Tokarev wrote:
> 2 upstream stable/bugfix releases of qemu 7.2 series has been
> releases since the version of qemu in bookworm, - 7.2.3 and 7.2.4,
> with a good set of fixes each.  See
>   https://salsa.debian.org/qemu-team/qemu/-/commits/stable-7.2/
> for the stable-7.2 branch mirrored on salsa.d.o, or on gitlab.com.
> There are many fixes in there, some of which already affected
> debin users and even debian infrastructure (like qemu-based buildds).
> 
> Many various crashes has been fixed too, including some which can
> cauese data corruption in some cases (an unexpected crash of qemu
> with not all guest data written to permanent storage).
> 
> Among the changes there's 2 security fixe too, CVE-2023-0330
> (LSI controller reentrancy issue) and CVE-2023-2861 (opening
> special files in 9pfs).
> 
> I believe every bit of this is worth having in debian stable.
> 
> Besides that, there's one debian-specific bug being fixed by this
> release, - when I split out xen-specifx bits into a separate
> package, I forgot to enable USB devices support. This update
> re-enables usb support for Xen HVM domUs again (#1037341).
> 

Please go ahead.

Regards,

Adam

Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-07-12 at 22:37 -0400, Aaron M. Ucko wrote:
> Per #1039621, the new libngs-jni package accidentally wound up with
> bad content (unexpanded variables in the key symlink's source *and*
> target) that rendered it useless.

+sra-sdk (3.0.3+dfsg-6~deb12u1) bookworm; urgency=medium
+
+  * Reupload to bookworm (stable).  (Closes: #10n).

If you were intending to close this p-u request there, please don't.
The bug will get closed once the updated package is in stable as part
of a point release.

--- sra-sdk-3.0.3+dfsg/debian/.gitignore2023-02-24 05:52:27.0 
-0500
+++ sra-sdk-3.0.3+dfsg/debian/.gitignore1969-12-31 19:00:00.0 
-0500
@@ -1,16 +0,0 @@

Is the removal of .gitignore intentional?

The fix itself looks fine, so please feel free to go ahead (with the
Closes: removed and possibly with .gitignore restored if appropriate).

Regards,

Adam

Bug#1040979: write_files: defer not working any more

[Noah Meyerhans]

Control: tags -1 + moreinfo

On Thu, Jul 13, 2023 at 05:30:52PM +0200, Sven Strickroth wrote:
> starting with the shipped version in Debian 12 the write_files feature with 
> defer option does not work any more.

I'm not able to reproduce the behavior you describe.  defer seems to
work as expected.  For example:

admin@ip-10-0-0-87:~$ ec2-metadata --ami-id
ami-id: ami-0544719b13af6edc3
admin@ip-10-0-0-87:~$ sudo cat /var/lib/cloud/instance/user-data.txt
#cloud-config
write_files:
- content: |
testing. this file should be owned by the dynamically created user
  path: /test-file
  owner: admin:admin
  defer: true
admin@ip-10-0-0-87:~$ ls -l /test-file 
-rw-r--r-- 1 admin admin 67 Jul 13 16:59 /test-file

And in /var/log/cloud-init.log we see it being handled as expected:
2023-07-13 16:59:53,893 - modules.py[DEBUG]: Running module 
write-files-deferred () 
with frequency once-per-instance
2023-07-13 16:59:53,893 - handlers.py[DEBUG]: start: 
modules-final/config-write-files-deferred: running config-write-files-deferred 
with frequency once-per-instance
2023-07-13 16:59:53,893 - util.py[DEBUG]: Writing to 
/var/lib/cloud/instances/i-016aa1a2f2e89c783/sem/config_write_files_deferred - 
wb: [644] 24 bytes
2023-07-13 16:59:53,893 - helpers.py[DEBUG]: Running 
config-write-files-deferred using lock ()
2023-07-13 16:59:53,893 - util.py[DEBUG]: Writing to /test-file - wb: [644] 67 
bytes
2023-07-13 16:59:53,894 - util.py[DEBUG]: Changing the ownership of /test-file 
to 1000:1001
2023-07-13 16:59:53,894 - handlers.py[DEBUG]: finish: 
modules-final/config-write-files-deferred: SUCCESS: config-write-files-deferred 
ran successfully

I note that your cloud-config attempts to set the locale:

> #cloud-config
> locale: de_DE.UTF-8

I suspect that that's failing (see #955733) and interfering with
subsequent module execution.  If you remove the `locale` setting, does
your userdata work as expected?

noah

Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Simon McVittie]

On Thu, 13 Jul 2023 at 16:58:54 +0100, Adam D. Barratt wrote:
> On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > > [ Reason ]
> > > https://bugs.debian.org/1040790
> 
> Please go ahead, bearing in mind that the window for 12.1 closes over
> the coming weekend.

I uploaded it already, it's in
. The
corresponding unstable update should reach testing tomorrow.

I'm sorry for the timing. I fixed it as fast as I was able, as soon as
I was aware of the issue (I know both should have happened quicker).

smcv

Bug#606825: mingw triplets/ostable

[Guillem Jover]

Hi!

Just noticed this change to the GNU config project which I wanted to
add a reference here:

  
https://git.savannah.gnu.org/cgit/config.git/commit/?id=91f6a7f616b161c25ba2001861a40e662e18c4ad

Thanks,
Guillem

Bug#1037100: cpp-httplib: CVE-2023-26130

[Salvatore Bonaccorso]

Hi Andrea,

On Thu, Jul 13, 2023 at 12:11:07PM +0200, Bastian Germann wrote:
> Am 13.07.23 um 12:09 schrieb Andrea Pappacoda:
> > Il giorno gio 13 lug 2023 alle 12:08:28 +02:00:00, Bastian Germann
> >  ha scritto:
> > > 2.: Please email the security team with the debdiff instead.
> > 
> > Ok, so they'll push it to the archive for me? Perfect!
> 
> They will tell you what to do. Sometimes they say to hand in a stable update
> (for point release) instead.

The issue (CVE-2023-26130) in fact does not warrant a DSA, cf. as well
already the status in
https://security-tracker.debian.org/tracker/CVE-2023-26130 .

Can you fix it please via an upcoming point release? If you are fast
enough it can make it as well even for the 12.1 release.

Regards,
Salvatore

Bug#982456: lintian: systemd SystemCallArchitectures directive incompatible with M-A:foreign

[Guillem Jover]

Hi!

On Wed, 2021-02-10 at 15:18:31 +0100, Helmut Grohne wrote:
> Control: tags -1 + moreinfo

> On Wed, Feb 10, 2021 at 01:42:59PM +0100, Guillem Jover wrote:
> > The systemd unit file directive SystemCallArchitectures is
> > incompatible with Multi-Arch:foreign markings in a package, as that
> > means once you install such foreign package, systemd will refuse to let
> > it run.
> > 
> > Please tag this as an error.
> 
> I think this is an interesting aspect, but less clear than you picture
> it.
> 
> If my foo:amd64 package ships a .service file with
> SystemCallArchitectures=x86-64 and calls a binary from the same package,
> then M-A:foreign can very well make sense. Thus far, this case is not
> practically relevant, because no upstream .service file works this way.

Having thought about this more, I think even the arch-specific value
is still potentially problematic, as things this service depends on,
calls directly or links against might change under its feet, and
end up calling programs for the "wrong" arch.

> If my foo:amd64 package ships a .service with
> SystemCallArchitectures=native, then this is a problem, because native
> here refers to the architecture of systemd and since systemd is
> M-A:foreign, that can be any architecture. So we'd have to restrict this
> error being signalled explicitly to the value native.

See above.

> Unfortunately, that's the most likely value for upstreams to put there.
> 
> That puts us in a difficult situation. It's essentially Multi-Arch
> versus hardening. What we'd want is "it just works".

I guess perhaps an option could be to generate overrides that check
for the architectures enabled in dpkg and generate appropriate
SystemCallArchitectures directives for services.

> I think we can do better with a little bit of support from debhelper.
> debhelper already ships a dh_installsystemd that specially handles
> .service units. How about extending it? Let me propose some pseudo-code:

It's not clear to me whether you mean that these would be done at
package build time or installation time. I think some parts, make
sense at build time, because those are properties of the package, and
others at run-time, because those are properties of the system.

> if the .service unit contains SystemCallArchitectures:
> if the relevant binary package is Architecture: all:
> if the package is Multi-Arch: foreign:
> die with an error

Ack (at build-time).

> else:
> Let systemd_arch be the systemd name of the relevant package
>   architecture.
> if the value of SystemCallArchitectures is native:
> Replace it with systemd_arch.
>   if the value of SystemCallArchitectures is not systemd_arch:
>   die with an error

These would need to be done at "run-time", and they would depend on
whether foreign arches have been enabled, as mentioned above.

> In this setting, packages would likely not have to change as debhelper
> would take care of the fixups. So I wonder whether a lintian tag is
> really necessary (assuming that debhelper can be changed). Tagging the
> bug moreinfo for now.

I still think a lintian tag makes sense, regardless of the level, as
that gives visibility over the problem, and covers things that might
not be using debhelper?

Thanks,
Guillem

Bug#1040907: aerc: Freeze when pasting to body on email compose

[Nilesh Patra]

Hi,

On Wed, 12 Jul 2023 11:09:03 +0200 Pelle  wrote:
> Package: aerc
> Version: 0.15.2-1
> Severity: normal
> 
> I find that aerc almost always freezes when pasting into the compose area.
> 
> It can easily be reproduced here:
>* Open aerc.
>* Compose an email.
>* Move cursor from headers onto the email body compose area.
>* In another window, open a text editor, enter "hello world" 100 times and 
> copy it.
>* Back in aerc, paste into the compose area by `SHIFT+INSERT`
>* Some of the text will be pasted, but then aerc will get stuck, sometimes 
> like "hell|"
>* Aerc stops responding to any input, including `CTRL+C`
> 
> I have tested an confirmed this is an issue whether using vim or nvim text 
> editor, and whether using kitty, alacritty or foot terminal emulator.

Thanks for reporting this, and I can confirm the behavior. @Robin, is
this an issue known to you as upstream?
Could you please take a look at this?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1040988: Clashes with existing composite manager

[Michael Biebl]

Package: picom
Version: 10.2-1
Severity: serious

picom adds an autostart file which makes it automatically start on
session login.

Today I noticed that journald/rsyslog ran while and my logs were flodded
with the following messages (I was logged into a GNOME session at that
time):

Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 
redirect_start FATAL ERROR ] Another composite manager is already running (and 
does not handle _NET_WM_CM_Sn correctly)
Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 
redirect_start FATAL ERROR ] Another composite manager is already running (and 
does not handle _NET_WM_CM_Sn correctly)
Jul 13 19:18:11 pluto picom.desktop[2236]: [ 13.07.2023 19:18:11.510 
redirect_start FATAL ERROR ] Another composite manager is already running (and 
does not handle _NET_WM_CM_Sn correctly)

Within minutes, my disk was filled with hundreds of megabytes of log
data (/var/log/syslog was over 1GB), before I killed the rogue picom
process.




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

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

Versions of packages picom depends on:
ii  libc62.37-5
ii  libconfig9   1.5-0.4
ii  libdbus-1-3  1.14.8-2
ii  libegl1  1.6.0-1
pn  libev4   
ii  libgl1   1.6.0-1
ii  libpcre3 2:8.39-15
ii  libpixman-1-00.42.2-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-composite01.15-1
ii  libxcb-damage0   1.15-1
ii  libxcb-glx0  1.15-1
ii  libxcb-image00.4.0-2
ii  libxcb-present0  1.15-1
ii  libxcb-randr01.15-1
ii  libxcb-render-util0  0.3.9-1+b1
ii  libxcb-render0   1.15-1
ii  libxcb-shape01.15-1
ii  libxcb-sync1 1.15-1
ii  libxcb-xfixes0   1.15-1
ii  libxcb-xinerama0 1.15-1
ii  libxcb1  1.15-1
ii  python3  3.11.4-5

picom recommends no packages.

picom suggests no packages.

Bug#1040987: cabextract: New upstream release (1.11, 24 February 2023)

[Florian Ernst]

Source: cabextract
Version: 1.9-3
Severity: wishlist

Dear maintainer,

there is a two new upstream releases available at
, their changes include

| Changes in cabextract 1.11
| - A bug introduced in cabextract 1.10 was fixed: it did not create
|   directory paths when extracting files
| Changes in cabextract 1.10
| - Multiple --filter options can be given. cabextract will extract files
|   matching any of the filters
| - cabextract now overwrites symlinks by default, both directories and
|   files. This is to be consistent with other archive tools. This does
|   not affect symlinks that are part of the --directory option
| - New --keep-symlinks option for the old behaviour of keeping symlinks
|   and following them when extracting files
| - New --interactive option to prompt you whether to overwrite existing
|   files
| - New --no-overwrite option to never overwrite existing files. The
|   default behaviour remains that existing files are overwritten
|   automatically

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

On Thu, Jul 13 2023 at 11:49:56 PM +08:00:00 +08:00:00, Shengjing Zhu 
 wrote:

Control: reopen -1



Thanks, I noticed the failure on buildd and was going to reopen it and 
found you did it aready.



Hi,

On Thu, Jul 13, 2023 at 6:09 PM Pirate Praveen 
 wrote:


 On Thu, 9 Feb 2023 14:40:48 +0100 Sebastian Ramacher
  wrote:
  > Source: golang-github-go-enry-go-license-detector
  > Version: 4.3.0+git20221007.a3a1cc6-1
  > Severity: serious
  > Tags: ftbfs
  > Justification: fails to build from source (but built 
successfully in

 the past)
  >
  >
 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-1%2Bb2=1675941345=0

  >

 This looks like a temporary error, last build was passing

 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-hhatto-gorst=mipsel=0.0%7Egit20181029.ca9f730-2%2Bb6=1681037294=0


You look at the wrong log, it's golang-github-hhatto-gorst, not
golang-github-go-enry-go-license-detector.
It FTBFS on buildd currently.



Thanks for pointing out the mistake. I was looking at both failures and 
got confused.

--
Shengjing Zhu

Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Adam D. Barratt]

On Thu, 2023-07-13 at 17:51 +0100, Simon McVittie wrote:
> On Thu, 13 Jul 2023 at 16:58:54 +0100, Adam D. Barratt wrote:
> > On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> > > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > > > [ Reason ]
> > > > https://bugs.debian.org/1040790
> > 
> > Please go ahead, bearing in mind that the window for 12.1 closes
> > over
> > the coming weekend.
> 
> I uploaded it already, it's in
> ;. The
> corresponding unstable update should reach testing tomorrow.
> 

Heh, that'll teach me to catch up on e-mail before reviewing the queue.

> I'm sorry for the timing. I fixed it as fast as I was able, as soon
> as I was aware of the issue (I know both should have happened
> quicker).
> 

FTAOD, it absolutely wasn't a complaint, rather just making sure you
were aware of the date.

Regards,

Adam

Bug#1040956: systemd: Internal USB devices disconnected when `udevadm settle` run in early boot

[Michael Biebl]

Am 13.07.23 um 06:14 schrieb Undef:

Package: systemd
Version: 253.5-1
Severity: important
X-Debbugs-Cc: debian@undef.tools

Dear Maintainer,

On upgrade to systemd 253.5-1 the USB modem on my Librem5 stopped
working. This also occurs on 252.11-1 (testing) but not on 252.6-1
(stable) or 253-3 (previously available in unstable.

This only seems to happen in a very specific configuration:
   * Librem5
   * Booting from eMMC
   * Using full disk encryption
   * Using an on-screen keyboard such as osk-sdl to unlock the device.

Digging into the issue, it seems I can trigger it by adding an initramfs
script which will run `udevadm settle` in the initramfs. This itself
doesn't remove the USB device, but later in the boot the device will
disappear.


Since this is hardware specific, my recommendation would be, that you 
run a git bisect (between 252.6 and 252.11) to find the commit which is 
causing this issue for you.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Thu, 13 Jul 2023 21:24:53 +0530 Nilesh Patra  
wrote:

> Control: tags -1 patch
>
> On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote:
> > On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  
wrote:
> > > The Ubuntu diff contains a patch that looks like a workaround 
(untested).

> >
> > This patch says data directory is reserved for golang autopkgtest 
in Ubuntu.
> > Is this the same on debian too? If yes, that looks like a bad idea 
to me.

>
> AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the
> standard across debian. I got the same impression on skimming through
> dh-golang code.
>
> As far as fix for your package is concerned, it is as simple as 
avoiding
> to remove entire data directory (which is just 28K in size). I'm 
able to get

> autopkgtests passing locally. Patch pasted
> inline.

Thanks. I guess I was over enthusiastic to suppress

I: golang-github-hhatto-gorst-dev: 
package-contains-documentation-outside-usr-share-doc 
[usr/share/gocode/src/github.com/hhatto/gorst/data/autopep8.readme.rst]


and did not notice the autopkgtest failure then.

I'm uploading the fix you suggested.

Bug#1040986: ipcalc: New upstream release (0.51, 2021 Nov 3)

[Florian Ernst]

Source: ipcalc
Version: 0.42-2
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
 (as linked to from
), apparently consolidating many patches
(including some from you) and applying some further changes.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040943: systemd-logind: 'HandlePowerKey=ignore' works in logind.conf, not in logind.conf.d/custom.conf

[Michael Biebl]

Am 12.07.23 um 20:39 schrieb Diederik de Haas:

Package: systemd
Version: 253.5-1
Severity: normal

I'm working on a Debian system/image for Pine64's PineTab2 (tablet) and
by default when I (short) press the power button, the device powers off.
Right now I'm not using any DE, so it's a CLI only system.

When I created /etc/systemd/logind.conf.d/custom.conf with
HandlePowerKey=ignore


If this is the whole content of /etc/systemd/logind.conf.d/custom.conf, 
you are missing a [Login] section at the top of the file


Rule of thumb: Please always attach such configuration data verbatim to 
the bug report.

Makes it much easier for us.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032708: please drop transitional package libtinfo-dev from src:ncurses

[Sven Joachim]

Control: tags -1 - moreinfo

On 2023-03-12 14:44 +, Holger Levsen wrote:

> On Sun, Mar 12, 2023 at 03:36:33PM +0100, Sven Joachim wrote:
>> After taking a closer look, this seems to be all red herring.  Sbuild
>> uses apt for resolving the build dependencies, and while apt prefers
>> virtual packages over real ones, it has no problem to use the virtual
>> one (libncurses-dev in this case) in case the real one is uninstallable
>> or insufficient.
>>
>> I guess I'll drop the transitional packages in an upload to experimental
>> and see what happens with the pseudo-excuses[1].
>
> cool!

Everything went well, and the transitional packages are no longer in
testing. :-)

>> Filing bugs against reverse (build-)dependencies would be doable for
>> libtinfo-dev, but for libncursesw5-dev (#1032740) and libncurses5-dev
>> (for which you did not file a bug, for whatever reason) this is a
>
> I did: #1032741

Err, of course.  Somehow I managed to overlook that bug.

>> non-starter due to the large number of them.
>
> bug filing can be scripted ;)

Surely, but filing 300+ bugs to get rid of three empty packages is still
a very bad ratio and causes a lot of busy work which is not really
necessary.  Rather, I filed _one_ bug against ftp.debian.org[1] to remove
the cruft packages from unstable where they currently remain.

FWIW, what I did looks like a good strategy for other transitional
packages with lots of reverse (build-)dependencies, maybe you would like
to inform their maintainers of it.

Cheers,
   Sven


1. https://bugs.debian.org/1040983

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Torrance, Douglas]

Control: severity -1 important

On Thu 13 Jul 2023 12:21:48 PM -04, Doug Torrance  
wrote:

[[PGP Signed Part:Undecided]]
Control: forwarded -1 https://github.com/algebraic-solving/msolve/issues/66

On Mon 10 Jul 2023 03:33:43 PM +03, Adrian Bunk  wrote:

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity


[[End of PGP Signed Part]]


The latest upload (0.5.0-2) of msolve skips the tests on 32-bit architectures
so that it will still build.  The issue has been reported upstream and hopefully
will be fixed in a future release.

Since the program still works for some inputs on these architectures, I'm
dropping the severity of the bug to "important".


signature.asc
Description: PGP signature

Bug#1040985: metis: New upstream release (v5.2.1, 2022 Dec 5)

[Florian Ernst]

Source: metis
Version: 5.1.0.dfsg-7
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
 provided by one of the
original authors, cf. .

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1039695: libtracker-sparql-3.0-0: keeps segfaulting and restarting endlessly

[Bernhard Übelacker]

Hell Mulas,
I tried to get to the source line of you dmesg output:



[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 
24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 
c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



I think this relates to this source line:

https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);


But a full backtrace is probably still needed by the maintainer.
You could probably collect one by installing systemd-coredump.
Then journalctl should contain a more detailed information on
which functions are involved.

Kind regards,
Bernhard



https://wiki.debian.org/HowToGetABacktrace
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4 == 0b100
 *   bit 0 ==0: no page found   
 *   bit 1 ==0: read access 
 *   bit 2 ==1: user-mode access
.




[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 
8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 
08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



echo -n "find /b ..., ..., 0x" && \
echo "18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 
8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d 
de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'
#





apt install gdb tracker-miner-fs tracker-miner-fs-dbgsym 
libtracker-sparql-3.0-0-dbgsym



gdb -q --args /usr/libexec/tracker-miner-fs-3

set width 0
set pagination off
tb main
run

pipe info share | grep libtracker-sparql-3.0

find /b 0x77b4e120,  0x77bb49f2, 0x18, 0x64, 0x48, 0x2b, 0x04, 
0x25, 0x28, 0x00, 0x00, 0x00, 0x75, 0x35, 0x48, 0x83, 0xc4, 0x20, 0x5b, 0xc3, 
0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x8d, 0x15, 0x84, 0xdd, 0x04, 0x00, 0xbe, 
0x08, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0xfd, 0x77, 0x04, 0x00, 0x48, 0x8b, 
0x48, 0x08, 0x31, 0xc0, 0xe8, 0x5d, 0xde, 0xfd, 0xff, 0x48, 0x8b, 0x7c, 0x24, 
0x10, 0xe8, 0x03, 0xda, 0xfd, 0xff, 0xeb

b * (0x77b6dbee + 42)

(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77b6dc18 in setup_interface_cb at 
../src/libtracker-sparql/core/tracker-data-manager.c:4050
(gdb) disassemble /r 0x77b6dbee, 0x77b6dbee + 62
Dump of assembler code from 0x77b6dbee to 0x77b6dc2c:
   0x77b6dbee :  18 64 48 2b sbb
%ah,0x2b(%rax,%rcx,2)
   0x77b6dbf2 :  04 25   add
$0x25,%al
   0x77b6dbf4 :  28 00   sub
%al,(%rax)
   0x77b6dbf6 :  00 00   add
%al,(%rax)
   0x77b6dbf8 :  75 35   jne
0x77b6dc2f 
   0x77b6dbfa :  48 83 c4 20 add
$0x20,%rsp
   0x77b6dbfe :  5b  pop
%rbx
   0x77b6dbff :  c3  ret
   0x77b6dc00 :  48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x77b6dc05 : 48 8d 15 84 dd 04 00lea
0x4dd84(%rip),%rdx# 0x77bbb990
   0x77b6dc0c : be 08 00 00 00  mov
$0x8,%esi
   0x77b6dc11 : 48 8d 3d fd 77 04 00lea
0x477fd(%rip),%rdi# 0x77bb5415
>>>0x77b6dc18 : 48 8b 48 08 mov
>>>0x8(%rax),%rcx
   0x77b6dc1c : 31 c0   xor
%eax,%eax
   0x77b6dc1e : e8 5d de fd ff  call   
0x77b4ba80 
   0x77b6dc23 : 48 8b 7c 24 10  mov
0x10(%rsp),%rdi
   0x77b6dc28 : e8 03 da fd ff  call   
0x77b4b630 
End of assembler dump.


https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);