Bug#1056062: coq: FTBFS in sid (dune update?)

[Gianfranco Costamagna]

Source: coq
Version: 8.17.0+dfsg-1
Severity: serious

Hello,

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

As said here, there is a build failure due to probably new dune or something 
similar.

I can reproduce locally, but not always, looks some concurrency issue but also 
running dune with -j1 doesn't fix the issue.

$ (cd _build/default && /usr/bin/bash -e -u -o pipefail -c 
'doc/stdlib/make-library-index doc/stdlib/index-list.html doc/stdlib/hidden-files')
Building file index-list.prehtml... Error: none of doc/stdlib/index-list.html 
and doc/stdlib/hidden-files mention theories/Arith/Between.v
grep: tmp: No such file or directory
grep: tmp: No such file or directory

This is probably the culprit of the issue, but I don't really understand why 
this is not found

and also why running it manually works
bash -e -u -o pipefail -c 'doc/stdlib/make-library-index 
doc/stdlib/index-list.html doc/stdlib/hidden-files'
Building file index-list.prehtml...
Done


Sorry for not providing a patch, but I really don't have much knowledge about 
this build system, and despite my efforts I'm still failing

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056061: gnome-console: Left-click selecting text down does not work. Only up.

[szcl]

Package: gnome-console
Version: 43.0-2
Severity: important
X-Debbugs-Cc: sazamor...@gmail.com


Dear Maintainer,


   * What led up to the situation?
Selecting text down.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Selecting text down does not advance towards the remaining text.
It works only up.

   * What was the outcome of this action?
Not able to select all text in one action as usual.

   * What outcome did you expect instead?
Left click select and scroll down to select all remaining text.


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

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

Versions of packages gnome-console depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas43.0-1
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u3
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libgtop-2.0-11   2.40.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libvte-2.91-gtk4-0   0.70.6-2~deb12u1

gnome-console recommends no packages.

gnome-console suggests no packages.

-- no debconf information

Bug#1056060: gnome-text-editor: left-click selecting text down does not work. Only up.

[szcl]

Package: gnome-text-editor
Version: 43.2-1
Severity: important
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Selecting text down.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Selecting text down does not advance towards the remaining text.
It works only up.

   * What was the outcome of this action?
Not able to select all text in one action as usual.

   * What outcome did you expect instead?
Left click select and scroll down to select all remaining text.



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

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

Versions of packages gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libeditorconfig0 0.12.6-0.1
ii  libenchant-2-2   2.3.3-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libgtksourceview-5-0 5.6.2-1
ii  libicu72 72.1-3
ii  libpango-1.0-0   1.50.12+ds-1

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information

Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor

[Matteo Settenvini]

Package: dracut
Version: 059-4
Severity: important

Dear Maintainer,

dracut will fail to produce a booting initrd since systemd 255 in Debian trixie.

The reason is that /usr/lib/systemd/systemd-executor is missing from the initrd 
image.
The corresponding patch is: https://github.com/dracutdevs/dracut/pull/2535/files

This can also be worked around by creating 
/etc/dracut.conf.d/99-systemd-dracut-bug.conf:

install_items+=" /usr/lib/systemd/systemd-executor "

... and then running dpkg-reconfigure dracut again.

$ apt show systemd
Package: systemd
Version: 255~rc2-1

Thanks!
Matteo Settenvini

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

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

Versions of packages dracut depends on:
ii  dracut-core  059-4

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1056058: libavcodec-extra60: Segmentation fault in vlc 3.0.20-1+b1 attempting to play DVB-T stream

[Arthur Marsh]

Package: libavcodec-extra60
Version: 7:6.1-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Upgrading ffmpeg related packages
ffmpeg (7:6.1-2) over (7:6.0-9+b1)

>From gdb:

Thread 25 "vlc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa4dff6c0 (LWP 16147)]
0x7fff9dcad5a3 in ?? () from /usr/lib/x86_64-linux-gnu/libavcodec.so.60
(gdb) bt
#0  0x7fff9dcad5a3 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#1  0x7fff9e02784e in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#2  0x7fff9e02ae3f in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#3  0x7fff9dfec504 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#4  0x7fff9dfecb35 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#5  0x7fff9dcaad65 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#6  0x7fff9dcab364 in avcodec_send_packet ()
at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#7  0x7fffa4c3b2c2 in  ()
at /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libavcodec_plugin.so
#8  0x77b3b377 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#9  0x77b3af42 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#10 0x77b3b7a4 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#11 0x77c8932c in start_thread (arg=)
at ./nptl/pthread_create.c:444
#12 0x77d0a428 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) bt full
#0  0x7fff9dcad5a3 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#1  0x7fff9e02784e in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#2  0x7fff9e02ae3f in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#3  0x7fff9dfec504 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#4  0x7fff9dfecb35 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#5  0x7fff9dcaad65 in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#6  0x7fff9dcab364 in avcodec_send_packet ()
at /usr/lib/x86_64-linux-gnu/libavcodec.so.60
#7  0x7fffa4c3b2c2 in  ()
at /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libavcodec_plugin.so
#8  0x77b3b377 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#9  0x77b3af42 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#10 0x77b3b7a4 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#11 0x77c8932c in start_thread (arg=)
at ./nptl/pthread_create.c:444
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737350504560, 
-7686621085864270227, -120, 0, 140736566969536, 140735958478848, 
7686777490886911597, 7686603636391044717}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#12 0x77d0a428 in clone3 ()
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78


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

Tried different video outputs with no change, downgrading packages resulted
in successful DVB-T stream playback

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: trixie/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.0-rc1+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libavcodec-extra60 depends on:
ii  libaom3 3.7.0-1
ii  libaribb24-01.0.3-2
ii  libavutil58 7:6.1-2
ii  libc6   2.38-3
ii  libcairo2   1.18.0-1
ii  libcodec2-1.2   1.2.0-2
ii  libdav1d7   1.3.0-2
ii  libglib2.0-02.78.1-4
ii  libgsm1 1.0.22-1
ii  libjxl0.7   0.7.0-10.2
ii  liblzma55.4.4-0.1
ii  libmp3lame0 3.100-6
ii  libopencore-amrnb0  0.1.6-1
ii  libopencore-amrwb0  0.1.6-1
ii  libopenjp2-72.5.0-2
ii  libopus01.4-1
ii  librav1e0   0.6.6-3
ii  librsvg2-2  2.54.7+dfsg-2
ii  libshine3   3.1.1-2
ii  libsnappy1v51.1.10-1
ii  libspeex1   1.2.1-2
ii  libsvtav1enc1d1 1.7.0+dfsg-2
ii  libswresample4  7:6.1-2
ii  libtheora0  1.1.1+dfsg.1-16.1+b1
ii  libtwolame0 0.4.0-2
ii  libva2  2.20.0-2
ii  libvo-amrwbenc0 0.1.3-2
ii  libvorbis0a 1.3.7-1
ii  libvorbisenc2   1.3.7-1
ii  libvpl2 2023.3.0-1
ii  libvpx8 1.13.1-2
ii  libwebp71.3.2-0.3
ii  libwebpmux3 1.3.2-0.3
ii  libx264-164 2:0.164.3095+gitbaee400-3+b1
ii  libx265-199 3.5-2+b1
ii  libxvidcore42:1.3.7-1
ii  libzvbi00.2.42-1
ii  zlib1g  1:1.2.13.dfsg-3

Bug#1055526: efibootmgr: output broken and shows hex dump after update (can be fixed with -u, which is documented as unrelated)

[наб]

On Tue, Nov 07, 2023 at 09:12:39PM +0100, наб wrote:
> Package: efibootmgr
> Version: 18-1
> Severity: normal
> 
> -- >8 --
> $ efibootmgr
> Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
> HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64)69006e0069007400720064003d005c006b006c00610070006b0069005c00370033003100620036003900660030006400610063003100340037006500660061006400660065006400390032006600310032003700310032003700330036005c0036002e0031002e0030002d0039002d0061006d006400360034005c0069006e0069007400720064002e0069006d0067002d0036002e0031002e0030002d0039002d0061006d00640036003400200072006f006f0074003d007a00660073003a004100550054004f0020006600620063006f006e003d0072006f0074006100740065003a003300200069006e00740065006c005f0069006f006d006d0075003d006f006e0020007a00660073002e007a00660073005f006100720063005f006d00610078003d003100320038003800340039003000310038003800380020007100750069006500740020006d006f00640075006c0065002e007300690067005f0065006e0066006f007200630065003d003100
> -- >8 --
> 
> Previous versions did something like this:
> -- >8 --
> Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
> HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64).i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.9.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.9.-.a.m.d.6.4.
>  .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
> .i.n.t.e.l._.i.o.m.m.u.=.o.n. 
> .z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
> .m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
> -- >8 --
> which was suboptimal but still okay (as-in "readable").

And efibootdump still does!
-- >8 --
$ efibootdump Boot0005
Boot0005: * Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64 
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64)i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.9.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.9.-.a.m.d.6.4.
 .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
.i.n.t.e.l._.i.o.m.m.u.=.o.n. 
.z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
.m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
-- >8 --
so what's the deal with this?

I tried to build upstream to bisect this
but it just fundamentally refuses to build, so.

Best,
наб


signature.asc
Description: PGP signature

Bug#1056057: bumps-private-libs: please add arm64 to the list of supported architectures

[Emanuele Rocca]

Package: bumps-private-libs
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: arm64

Hi!

bumps-private-libs builds fine on arm64. Please add arm64 to the
Architecture field in debian/control.

Thanks,
  Emanuele

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Chris Lamb]

Stuart Prescott wrote:

> I think there's a subtle bug about altering `dirs` while
> inside a loop from `os.walk`:

I'm quite impressed that you managed to hunt this down — that's very
nice work. :)

> Which item is not processed in the next iteration by dh_python3 now 
> depends on the order in which `os.walk` lists the directories. That is 
> presumably dependent on all manner of things (filesystem? collation? 
> luck?).

It will be dependent entirely on the filesystem being used because
`os.walk` merely passes on the underlying filesystem ordering. (The
same is true for GNU find as you later query.)

Entirely anecdotally, ext4 will be "more orderful", whilst btrfs,
possibly due to the way it rebalances its tree data structures, tends
to be less so. I raise it only because it can help explain why
different folks will get different results locally despite using the
same building tools. Building under tmpfs will have different
properties as well.

Anyway, thank you again. Once this is addressed in dh-python (even as
a proposed patch), I'll go through the last few months of bugs that
I've filed and see whether they can be closed.


Best wishes,

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

Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640)

[Ben Mesman | Spark Narrowcasting]

Control: merge 1056055 1056056


Van: Debian Bug Tracking System 
Verzonden: donderdag 16 november 2023 14:21
Aan: Ben Mesman | Spark Narrowcasting 
Onderwerp: Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 
'warm' reboot the disk is missing (not detected by the bios) on a HP t640)

[U ontvangt vaak geen e-mail van ow...@bugs.debian.org. Informatie over waarom 
dit belangrijk is op https://aka.ms/LearnAboutSenderIdentification]

LET OP: Deze e-mail is afkomstig van buiten de organisatie. Klik niet op links 
en open geen bijlagen tenzij je de afzender kent en weet dat de inhoud veilig 
is. Bij twijfel neem, altijd contact op met de Servicedesk.

CAUTION: This email was sent from an external source. Do not click on links or 
open attachments unless you know the sender and the content is safe. When in 
doubt, please contact the Servicedesk.


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1056056: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056.

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.

As you requested using X-Debbugs-CC, your message was also forwarded to
  b...@sparknarrowcasting.nl
(after having been given a Bug report number, if it did not have one).

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

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

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

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

Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640

[Ben Mesman]

Package: src:linux
Version: 6.1.55-1
Severity: important
X-Debbugs-Cc: b...@sparknarrowcasting.nl

If the HP t640 (I tried 2 different systems) runs this kernel, a 
'reboot' will result in the BIOS reporting that the disk is missing. 
After a cold reboot (turning the device off and on again) the disk wil 
be detected and the system will boot as expected. The next reboot will 
again trigger this bug.


Other HP thin-clients from similar series (t620, t630, t655) do not have 
the same problem.


Debian bullseye (kernel 5.10) does not have this problem, but upgrading 
to 6.1.0 (through bulleye-backports) will trigger this bug. Upgrading 
bookworm to a 6.5 kernel (through bookworm-backports) does not solve the 
bug.


Because the installer uses the same kernel, after the installation is 
complete and does the reboot, the bug will be triggered.



-- Package-specific info:
** Version:
Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 
root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet


** Not tainted

** Kernel log:
[    0.00] Linux version 6.1.0-13-amd64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU 
ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 
6.1.55-1 (2023-09-29)
[    0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 
root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet

[    0.00] BIOS-provided physical RAM map:
[    0.00] BIOS-e820: [mem 0x-0x0009] usable
[    0.00] BIOS-e820: [mem 0x000a-0x000f] 
reserved

[    0.00] BIOS-e820: [mem 0x0010-0x09df] usable
[    0.00] BIOS-e820: [mem 0x09e0-0x09ffdfff] 
reserved

[    0.00] BIOS-e820: [mem 0x09ffe000-0x0a1f] usable
[    0.00] BIOS-e820: [mem 0x0a20-0x0a20afff] 
ACPI NVS

[    0.00] BIOS-e820: [mem 0x0a20b000-0x7a88dfff] usable
[    0.00] BIOS-e820: [mem 0x7a88e000-0x7a980fff] 
reserved
[    0.00] BIOS-e820: [mem 0x7a981000-0x7a9b5fff] 
ACPI data
[    0.00] BIOS-e820: [mem 0x7a9b6000-0x7af20fff] 
ACPI NVS
[    0.00] BIOS-e820: [mem 0x7af21000-0x7c96bfff] 
reserved
[    0.00] BIOS-e820: [mem 0x7c96c000-0x7ca04fff] 
type 20

[    0.00] BIOS-e820: [mem 0x7ca05000-0x7dff] usable
[    0.00] BIOS-e820: [mem 0x7e00-0x7fff] 
reserved
[    0.00] BIOS-e820: [mem 0xf800-0xfbff] 
reserved
[    0.00] BIOS-e820: [mem 0xfd00-0xfdff] 
reserved
[    0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfed8-0xfed8] 
reserved
[    0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] 
reserved
[    0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] 
reserved
[    0.00] BIOS-e820: [mem 0xfee0-0xfeef] 
reserved
[    0.00] BIOS-e820: [mem 0xff00-0x] 
reserved

[    0.00] BIOS-e820: [mem 0x0001-0x00015eff] usable
[    0.00] BIOS-e820: [mem 0x00015f00-0x00017eff] 
reserved

[    0.00] BIOS-e820: [mem 0x00017f00-0x00017f33] usable
[    0.00] BIOS-e820: [mem 0x00017f34-0x00017fff] 
reserved

[    0.00] NX (Execute Disable) protection: active
[    0.00] efi: EFI v2.70 by American Megatrends
[    0.00] efi: TPMFinalLog=0x7aed8000 ACPI 2.0=0x7a998000 
ACPI=0x7a998000 SMBIOS=0x7c82 SMBIOS 3.0=0x7c81f000 
MEMATTR=0x790b6298 ESRT=0x790c0698

[    0.00] secureboot: Secure boot disabled
[    0.00] SMBIOS 3.2.1 present.
[    0.00] DMI: HP HP t640 Thin Client/8523, BIOS M43 v01.04 10/29/2019
[    0.00] tsc: Fast TSC calibration using PIT
[    0.00] tsc: Detected 2395.458 MHz processor
[    0.000628] e820: update [mem 0x-0x0fff] usable ==> reserved
[    0.000631] e820: remove [mem 0x000a-0x000f] usable
[    0.000644] last_pfn = 0x17f340 max_arch_pfn = 0x4
[    0.001139] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP UC- WT
[    0.001351] e820: update [mem 0x8000-0x] usable ==> reserved
[    0.001361] last_pfn = 0x7e000 max_arch_pfn = 0x4
[    0.006355] esrt: Reserving ESRT space from 0x790c0698 to 
0x790c06d0.

[    0.006369] e820: update [mem 

Bug#1055989: emacs-gtk: emacs rejects font preference, falls back to "Purisa" font

[David Bremner]

Control: tag -1 confirmed

Christoph Reichenbach  writes:

> * What exactly did you do (or not do) that was effective (or ineffective)?
>
> Executing the following steps:
>
> - (customize-face 'default)
>   - Font Family: setting "Terminus (TTF)"
>   - Font Foundry: setting "PfEd"
>   - Optionally (does not affect outcome):
> - Weight: setting "medium"
> - Disabling any font attributes (inlcuding Weight)
>   - [Apply]
[snip]
> * What was the outcome of this action?
>
> Emacs used the "Purisa" font as default font.  This font has the same Font
> Foundry as "Terminus (TTF)" but is a "Comic Sans"-like special-purpose font
> and unsuitable for normal operations.
>

For me, it is Fantasque Sans Mono, but I agree it is not selecting the correct
font. The selected font seems non-deterministic, possibly state
dependent. After some various choices of Mono font, I ended up with 

Can you duplicate the problem for other fonts?  I tried 4 or 5 other
monospaced fonts and they all seemed to work, at least in a fresh "emacs
-Q".

I observed that choosing some non-existing font name (e.g. FooBar) had
more or less the same effect. So maybe the issue is just that emacs
cannot find "Terminus (TTF)". A wild guess would be the parens in the
name causing the problem.

Apologies if this is covered already in your extensive report.

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi again Balint,

On 16/11/2023 11:35, Bálint Réczey wrote:

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58


You mentioned:

"The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch."

I'm not quite sure what is incorrect here, this file is patched already 
via debian/patches/0001-fix-libtypec-libdir.patch


For an i386 build, the .pc file in usr/share/pkgconfig contains:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/i386-linux-gnu
includedir=${prefix}/include/i386-linux-gnu
..

For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include/x86_64-linux-gnu
..

For an arm64 build, the .pc file in usr/share/pkgconfig contains:
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib/aarch64-linux-gnu
includedir=${prefix}/include/aarch64-linux-gnu
..

..so I'm a bit confused. Do you mind clarifying for me.

Colin

Bug#1056054: openmpi-doc: /usr/share/man/man1/pterm.1.gz is already shipped by pterm

[Andreas Beckmann]

Package: openmpi-doc
Version: 5.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Unpacking openmpi-doc (5.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/openmpi-doc_5.0.0-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/pterm.1.gz', which is also in 
package pterm 0.79-1
  Errors were encountered while processing:
   /var/cache/apt/archives/openmpi-doc_5.0.0-1_all.deb

cheers,

Andreas


pterm=0.79-1_openmpi-doc=5.0.0-1.log.gz
Description: application/gzip

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[James Addison]

On Thu, 16 Nov 2023 at 09:57, Ray Kinsella  wrote:
>
> On Wed, 15 Nov 2023 at 22:30, James Addison  wrote:
>>
>> On Wed, 15 Nov 2023 at 21:57, Ray Kinsella  wrote:
> [...]
> I spent a not insignificant amount of time devising this solution, to get 
> "Debian Support"
> After a few false starts and missteps, eventually I came up with LibX1000 
> which was a pretty effective fix IMHO.
>
> When I started sharing it around with the Debian & Kernel folks - the 
> response was pretty clear.
> "This is a mess, Intel should just fix the bug ... " - which honestly in 
> retrospect was the right thing to do.

Yep; frustrating though it can be, pushing back to figure out the
origins of bugs and resolve them there is likely the way to free up
enough developer and maintainer time, and to improve hardware and
software quality enough, to reach Reliable Technology Utopia.. should
be any day now :)

>> > It's been a long time since Intel manufactured the X1000 / Quark, I am not 
>> > sure how many are left in the wild.
>> > Do you think this is something that Debian might want to package and ship?
>>
>> I should admit that I'm not a Debian maintainer or developer, just a
>> passerby who attempts to make progress on bugs that interest to me
>> (possibly to the annoyance of actual DMs/DDs), so my opinion is
>> somewhat external (i.e.: take with a grain of salt).
>
>
> Thrilled that you reached out about it.

I've been thinking more about how to improve the chances that the
package could be accepted into Debian -- my suggestion would be to
rebuild it and upload it to the mentors[1] portal, where it can
(hopefully) receive review.  I've considered uploading it myself, but
I don't have hardware to test the results on, so I'd be navigating
without a way to test the results.  From personal experience
attempting packaging: the mentoring guidelines and making sure to run
lintian checks are both worthwhile.

Even so there'd be no guarantee of review or upload acceptance -- and
unfortunately the same test-hardware limitation probably applies to
most reviewers -- so I don't know whether it'd be worth your time, but
in my mind it's possible that someone attempts to install Debian on an
X1000 platform in future, learns of this bug, and then in a
hypothetical future _might_ find libx1000 in the archive, and then be
grateful for the availalble fix.

(after re-reading your blog-post, I think that there could technically
still be rare cases where the bug appears despite the package being
installed -- the mention of 98% of cases handled -- but even so, a
mostly-usable system compared to a completely useless one seems like a
big improvement)

[1] - https://mentors.debian.net/

Bug#1056049: consolekit2: Not buildable on hurd-i386

[Mark Hindley]

Control: tags -1 pending

Svante,

Many thanks for this. Queued for upload.

Best wishes

Mark

Bug#1056053: debci-worker: QEMU backend arguments cannot contain quoted arguments

[Christian Kastner]

Package: debci-worker
Version: 3.7
Severity: normal

3.7 added this nice feature where arguments can be passed to backends. However,
the --qemu-options parameter of the QEMU backend cannot be used with the
current implementation because its argument usually contains spaces, and these
get misinterpreted during expansion of "$@".

For example, given the following setting,

debci_autopkgtest_args_qemu"--ram-size 32768 --cpus 4 --qemu-options='--cpu 
host'"

running a test will tmpfail with

autopkgtest-virt-qemu: error: unrecognized arguments: host'

because |--qemu-options='--cpu| and |host'| get interpreted as two words,
rather than one.


A POSIXly solution doesn't immediately jump to my mind, but I'd thought I'd
report it for now, just to track the issue.

I don't think the other backends are affected, they don't have similar
parameters.

Best,
Christian

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting Paul Gevers (2023-11-16 11:22:45)
> On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard  wrote:
> > Quoting Scott Talbert (2023-10-12 02:33:45)
> > > It looks like pandoc can be updated to v3.0.1 and be compatible with the 
> > > dependencies that are in unstable currently (LTS 21).  Can you please let 
> > > us know if there are any dependencies still missing?
> 
> > I will look at it soon - probably this upcoming weekend.
> 
> Is there any progress with fixing this bug? It seems that this issue is 
> one of the last blocking issues in the haskell transition. src:pandoc is 
> a key package, we can't easily remove it from testing to "fix" the blockage.

Thanks for pinging/nudging, Paul.

Upstream project has restructured to now be organized as multiple
projects to be built as dependencies of each other.

I had hoped to be able to orchestrate such chain-of-builds internally in
the single source package, but the Haskell build helper tools seem to be
in too bad shape for that: Apparently all Haskell packages use CDBS
which is quite cumbersome to use for "looping" subtasks, and both of the
two available non-CDBS debhelper tools existing in Debian are broken.

I therefore give up on that approach, and see no other way forward than
to introduce the libraries of Pandoc as a new source package, and then
have the existing src:pandoc package depend on that to build the binary.

I will now file an RFP for that new dependent package, in the hope that
the Haskell team can adopt maintenance of that.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1054302: add support for loongarch

[liuxiang]

patch attached

Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 python-greenlet (2.0.2-1.loong64) UNRELEASED; urgency=medium
 .
   * Add support for loongarch.
Author: Xiang Liu 

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

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

--- python-greenlet-2.0.2.orig/setup.py
+++ python-greenlet-2.0.2/setup.py
@@ -58,6 +58,7 @@ if (
 #
 # Adding the -Os flag fixes the problem.
 or (is_linux and plat_machine == "riscv64")
+or (is_linux and plat_machine == "loongarch64")
 ):
 global_compile_args.append("-Os")
 
--- /dev/null
+++ python-greenlet-2.0.2/src/greenlet/platform/switch_loongarch64_linux.h
@@ -0,0 +1,31 @@
+#define STACK_REFPLUS 1
+
+#ifdef SLP_EVAL
+#define STACK_MAGIC 0
+
+#define REGS_TO_SAVE "s0", "s1", "s2", "s3", "s4", "s5", \
+ "s6", "s7", "s8", "fp", \
+		 "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"
+
+static int
+slp_switch(void)
+{
+  register int ret;
+  register long *stackref, stsizediff;
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  __asm__ volatile ("move %0, $sp" : "=r" (stackref) : );
+  {
+  SLP_SAVE_STATE(stackref, stsizediff);
+  __asm__ volatile (
+ "add.d $sp, $sp, %0\n\t"
+ : /* no outputs */
+ : "r" (stsizediff)
+ );
+  SLP_RESTORE_STATE();
+  }
+  __asm__ volatile ("" : : : REGS_TO_SAVE);
+  __asm__ volatile ("move %0, $zero" : "=r" (ret) : );
+  return ret;
+}
+
+#endif
--- python-greenlet-2.0.2.orig/src/greenlet/slp_platformselect.h
+++ python-greenlet-2.0.2/src/greenlet/slp_platformselect.h
@@ -38,6 +38,8 @@ extern "C" {
 #include "platform/switch_s390_unix.h"	/* Linux/S390 */
 #elif defined(__GNUC__) && defined(__s390x__) && defined(__linux__)
 #include "platform/switch_s390_unix.h"	/* Linux/S390 zSeries (64-bit) */
+#elif defined(__GNUC__) && defined(__loongarch64) && defined(__linux__)
+#include "platform/switch_loongarch64_linux.h"	/* Linux/LoongArch64 */
 #elif defined(__GNUC__) && defined(__arm__)
 #ifdef __APPLE__
 #include 

Bug#1056052: Subject: ITP: wasix-libc -- wasix libc implementation for WebAssembly

[daichi1.fukui]

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

* Package name: wasix-libc
  Version : 0.0~git20230922.d0362cb
  Upstream Author : Johnathan Sharratt 
* URL : https://github.com/wasix-org/wasix-libc
* License : Apache-2.0 and Apache-2.0-with-LLVM-Exceptions and Expat
  Programming Lang: C
  Description : wasix libc implementation for WebAssembly

Reason for ITP:
wasix-libc is the libc implementation for WebAssembly (WASM) with POSIX 
conformance.
WASIX is a superset on top of WASI, so wasix-libc incorporates POSIX-compliant 
extentions
such as support for sockets, which are not available in wasi-libc.
With this package, we will be able to build a C source code with POSIX 
interfaces into a WASM module.

A git repository will be created on salsa:
https://salsa.debian.org/dfukui/wasix-libc

Maintenance plan:
Because I have less experience in debian packaging, I would like to
ask Debian developers to review my upload. I need a sponsor too.
Report will be sent to Debian Bug Tracking System 

Bug#819341: [unison] Please build unison-fsmonitor

[Damian Lukowski]

Please consider 
https://salsa.debian.org/ocaml-team/unison/-/merge_requests/2

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Sat, Nov 04, 2023 at 10:38:32AM -0300, Antonio Terceiro wrote:
> On Fri, Nov 03, 2023 at 09:07:49PM -0300, Antonio Terceiro wrote:
> > On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> > > Package: python3-textual
> > > Severity: normal
> > > X-Debbugs-Cc: 
> > > 
> > > Dear maintainer,
> > > 
> > > The current version of python3-textual in Debian is quite out of date,
> > > and it's not possible to run newer textual apps with it anymore.,
> > > Please upgrade to the latest upstream version (currenly (0.40.0) so
> > > that this package can be useful again.
> > 
> > I have a textual locally updated to the latest upstream version:
> > https://salsa.debian.org/terceiro/textual
> > 
> > I had to disable a few tests due to either missing dependencies, of
> > mismatching expectations between the versions in Debian and the ones
> > assumed by upstream (poetry.lock). There is still some work to do, e.g.
> > converting the autopkgtest to use autopkgtest-pkg-pybuild.
> 
> This is now done.
> 
> BTW there is a new build dependency, python3-time-machine, which is in
> NEW right now:
> 
> https://salsa.debian.org/python-team/packages/python-time-machine

FWIW this package has passed NEW and is even already in testing.


signature.asc
Description: PGP signature

Bug#1024079: uvloop FTBFS on IPV6-only buildds

[Dale Richards]

As promised, please find attached the updated patch. This patch allows the 
package to build and test successfully on hosts that are IPv4-only, IPv6-only 
or dual-stack.

Best regards,
Dale Richards

ipv6-fix-tests.patch
Description: Binary data

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
Permanently

On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
> So this URL gives a 301 Moved Permanently with
> https://ftp-master.debian.org/new.822 as the new URL,
> and reportbug does not attempt to use this new URL.

Sorry, it actually seems to be used (the information is now encrypted
in the strace output, hence the confusion).

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

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Thanks for the quick response.
Please check my other observations, too, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58

Cheers,
Balint

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 11:22):
>
> On 15/11/2023 13:47, Bálint Réczey wrote:
> > Hi Colin,
> >
> > There are a few upstream source files licensed under GPL.
> > Please update debian/copyright to cover all the used licenses.
>
> Updated and uploaded -3 to mentors
>
> Thanks for the prompt review feedback. Much appreciated.
>
> Colin
>
> >
> > You can run 'cme update dpkg-copyright' in the source directory or any
> > other tool from https://wiki.debian.org/CopyrightReviewTools
> >  to help with the manual
> > labor.
> >
> > Cheers,
> > Balint
> >
> > On 2023. Nov 15., Wed at 10:27, Bálint Réczey  > > wrote:
> >
> > Hi Colin,
> >
> > Colin King (gmail)  > > ezt írta (időpont: 2023.
> > nov. 14., K, 17:58):
> >  >
> >  > Hi Balint,
> >  >
> >  > I've uploaded 0.4.0-2 with the suggested fixes.
> >  >
> >  > reply inlined below:
> >  >
> >  > On 09/11/2023 16:23, Bálint Réczey wrote:
> >  > > Hi Colin,
> >  > >
> >  > > Colin King (gmail)  > > ezt írta (időpont: 2023.
> >  > > nov. 7., K, 15:18):
> >  > >>
> >  > >> Hi Balint,
> >  > >>
> >  > >> Thanks for responding with the review. I was waiting for the
> > upstream
> >  > >> project to release a 0.4 with some minor fixes before
> > re-uploading to
> >  > >> mentors.
> >  > >>
> >  > >> I've addressed the issues you found as below:
> >  > >
> >  > > Please see my observations below.
> >  > >
> >  > >> On 22/10/2023 22:38, Bálint Réczey wrote:
> >  > >>> Hi Colin,
> >  > >>>
> >  > >>> I've checked the second upload at [1].
> >  > >>> As you can see in the Lintian warnings there is a .git
> > directory which
> >  > >>> is not ideal for a source package.
> >  > >>> I suggest using the most widely used git-buildpackage based
> > workflow
> >  > >>> where the gbp command takes care of exporting the source package
> >  > >>> without the .git dir from the packaging repository.
> >  > >>> I'd be happy to set up a packaging repo for you at
> >  > >>> https://salsa.debian.org/debian/libtypec
> >  and add you as a maintainer
> >  > >>> as described in [2]
> >  > >
> >  > > I still hold up my offer about setting up a git repo for
> > packaging on
> >  > > Salsa. That comes with the benefit of automated fixes from Debian
> >  > > Janitor and I could also comment on changes right where they
> > happened.
> >  >
> >  > Thank you for your kind offer; I definitely think this is a good
> > idea,
> >  > please can you set this up for me. Much appreciated!
> >
> > I've created the repo at https://salsa.debian.org/debian/libtypec
> >  and
> > added you as a maintainer.
> > I've also set up CI, thus when you push your branches the pipelines
> > will start.
> >
> > You may already be familiar with
> > https://dep-team.pages.debian.net/deps/dep14/
> >  , but if not, please
> > check it before pushing your packaging repository.
> >
> > ...
> >
> >  > > I think my comment here was misleading, sorry for that.
> >  > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
> > dir as a
> >  > > result of specifying .../libtypec.pc as the target dir in the
> > .install
> >  > > file was not desired. It was even patched to have the right
> > content.
> >  > > Please ship the .pc file in the -dev package.
> >  >
> >  > Fixed.
> >
> > The .pc file is now at the right location, but contains multiarch
> > strings which will differ across architectures.
> > I suggest hardcoding the paths in the patch.
> >
> > ...
> >
> >  > > * As you switched back to use upstream's 0.4.0 SO version the
> > .symbols
> >  > > file became wrong  not matching the shipped SO version. Please fix
> >  > > that and also switch to the libtypec0 package name since it
> > needs to
> >  > > match upstream's major SO version
> >  >
> >  > Fixed.
> >
> > The .symbols file's first line should be:
> >   libtypec.so.0 libtypec0 #MINVER#
> >
> > See deb-symbols(5) for more details.
> >
> >  > .
> >  > >
> >  > > * I'd recommend asking upstream to switch to semantic SO versioning
> >  > > instead of using the project's version and switching to major
> > version
> >  > > 1 when the API stabilized.
> >  >
> >  > Good idea. Will do when API changes and stabilizes.
> >
> > 

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

Package: reportbug
Version: 12.0.0
Severity: normal

In it search for newer versions of the package, reportbug outputs

  Checking for newer versions at madison and 
https://ftp-master.debian.org/new.html

However, /usr/lib/python3/dist-packages/reportbug/checkversions.py
has

NEWQUEUE_URL = 'http://ftp-master.debian.org/new.822'

In the strace output, I can see

193537 connect(45, {sa_family=AF_INET, sin_port=htons(80), 
sin_addr=inet_addr("192.91.235.231")}, 16) = -1 EINPROGRESS (Operation now in 
progress)
193537 poll([{fd=45, events=POLLOUT|POLLERR}], 1, 6) = 1 ([{fd=45, 
revents=POLLOUT}])
193537 getsockopt(45, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
193537 poll([{fd=45, events=POLLOUT}], 1, 6) = 1 ([{fd=45, 
revents=POLLOUT}])
193537 sendto(45, "GET /new.822 HTTP/1.1\r\nHost: 
ftp-master.debian.org\r\nUser-Agent: reportbug/12.0.0 
(Debian)\r\nAccept-Encoding: gzip;q=1.0, deflate;q=0.9, 
identity;q=0.5\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n", 190, 0, NULL, 
0) = 190
193537 ioctl(45, FIONBIO, [1])  = 0
193537 poll([{fd=45, events=POLLIN}], 1, 6) = 1 ([{fd=45, revents=POLLIN}])
193537 recvfrom(45, "HTTP/1.1 301 Moved Permanently\r\nDate: Tue, 14 Nov 2023 
14:11:18 GMT\r\nServer: Apache\r\nX-Content-Type-Options: 
nosniff\r\nX-Frame-Options: sameorigin\r\nReferrer-Policy: 
no-referrer\r\nX-Xss-Protection: 1\r\nPermissions-Policy: 
interest-cohort=()\r\nLocation: 
https://ftp-master.debian.org/new.822\r\nContent-Length: 316\r\nKeep-Alive: 
timeout=5, max=100\r\nConnection: Keep-Alive\r\nContent-Type: text/html; 
charset=iso-8859-1\r\n\r\n\n\n301 Moved 
Permanently\n\nMoved Permanently\nThe document 
has moved https://ftp-master.debian.org/new.822\;>here.\n\nApache
 Server at ftp-master.debian.org Port 80\n\n", 8192, 0, 
NULL, NULL) = 727

So this URL gives a 301 Moved Permanently with
https://ftp-master.debian.org/new.822 as the new URL,
and reportbug does not attempt to use this new URL.

So there are several issues:

1. The NEWQUEUE_URL URL is obsolete (this seems to have been fixed
in Git, but even unstable is still affected).

2. In the output, https://ftp-master.debian.org/new.html does not match
what is actually used (or is this on purpose in case this has the same
contents?).

3. The "301 Moved Permanently" is ignored. If this is on purpose,
I think that a warning should be output in order to be aware of the
issue, in case of a future move.

-- Package-specific info:
** Environment settings:
EDITOR="/home/vinc17/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vinc17/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vinc17/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc
timeout 20

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable-security'), (900, 
'stable-debug'), (900, 'proposed-updates-debug'), (900, 'stable'), (500, 
'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages reportbug depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.82
ii  debsums 3.0.2.1
ii  dlocate 1.12
ii  emacs-bin-common1:28.2+1-15
ii  file1:5.44-3
ii  gnupg   2.2.40-1.1
ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

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

Bug#1056050: mate-power-manager: Non-installable on hurd-i386

[Svante Signell]

Source: mate-power-manager
Version: 1.26.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

mate-power-manager is not installable on hurd-i386 due to dependencies on
polkitd, pkexec, and systemd or elogind which are only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-15 12:36:26.0 +0100
+++ b/debian/control	2023-11-15 12:26:19.0 +0100
@@ -26,7 +26,7 @@
libxrandr-dev,
mate-common (>= 1.24.0-1~),
pkg-config,
-   polkitd,
+   polkitd [linux-any],
xmlto,
yelp-tools,
 Standards-Version: 4.6.2
@@ -40,8 +40,8 @@
 Depends: default-dbus-session-bus | dbus-session-bus,
  mate-notification-daemon | notification-daemon,
  mate-power-manager-common (= ${source:Version}),
- polkitd, pkexec,
- systemd | elogind | consolekit,
+ polkitd [linux-any] , pkexec [linux-any],
+ systemd [linux-any] | elogind [linux-any] | consolekit,
  upower,
  ${misc:Depends},
  ${shlibs:Depends},

Bug#1056049: consolekit2: Not buildable on hurd-i386

[Svante Signell]

Source: consolekit2
Version: 1.2.6-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

consolekit is not buildable on hurd-i386 due to a dependency on libevdev-dev
which is only available for GNU/Linux.

A patch enabling a successful build on GNU/Hurd is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-07 18:27:10.0 +0100
+++ b/debian/control	2023-11-15 12:39:55.0 +0100
@@ -14,7 +14,7 @@
libselinux1-dev [linux-any],
libudev-dev [linux-any],
libacl1-dev [linux-any],
-   libevdev-dev,
+   libevdev-dev [linux-any],
libpam0g-dev,
xsltproc,
xmlto,

Bug#1052277: Bumping severity to important, 2 weeks till RC

[Luca Boccassi]

Control: severity -1 important

Hi,

As requested by Helmut, bumping severity of these bugs to important.
systemd.pc will be changed to point to /usr in 2 weeks (November 30th),
at which point the severity will be bumped again to RC for all these
bugs.

-- 
Kind regards,
Luca Boccassi


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

Bug#1056048: Memory leak in dcm2json

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.8~git20231027.1549d8c-2

Looks like there is a memory leak using the new citrus/oficonv lib:

curl -O https://dclunie.com/images/charset/charsettests.20070405.tar.bz2
tar xf charsettests.20070405.tar.bz2
valgrind  --leak-check=full --show-leak-kinds=all dcm2json
charsettests/SCSARAB  output.json

I cannot reproduce the symptoms using default glibc/iconv (dcmtk 3.6.7-9).

Reports:

==1688197== Memcheck, a memory error detector
==1688197== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1688197== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1688197== Command: dcm2json charsettests/SCSARAB output.json
==1688197==
==1688197==
==1688197== HEAP SUMMARY:
==1688197== in use at exit: 1,562 bytes in 18 blocks
==1688197==   total heap usage: 80,067 allocs, 80,049 frees, 2,124,652
bytes allocated
==1688197==
==1688197== 8 bytes in 1 blocks are still reachable in loss record 1 of 18
==1688197==at 0x48455EF: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F594EA: _citrus_UTF8_stdenc_init
(citrus_stdenc_template.h:84)
==1688197==by 0x4F4E301: _citrus_stdenc_open (citrus_stdenc.c:118)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==by 0x498A83C: DcmItem::convertToUTF8() (dcitem.cc:4465)
==1688197==
==1688197== 15 bytes in 1 blocks are still reachable in loss record 2 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4E037F9: strdup (strdup.c:42)
==1688197==by 0x4F56F9F: _citrus_mapper_open (citrus_mapper.c:370)
==1688197==by 0x4F5C6F1: _citrus_csmapper_open.constprop.0
(citrus_csmapper.c:411)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:186)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:225)
==1688197==by 0x4F55B54: UnknownInlinedFun (citrus_iconv_std.c:283)
==1688197==by 0x4F55B54: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:382)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197==by 0x4F59117: _iconv_open (oficonv_iconv.c:107)
==1688197==by 0x4AE71E2: UnknownInlinedFun (ofchrenc.cc:337)
==1688197==by 0x4AE71E2:
OFCharacterEncoding::selectEncoding(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (ofchrenc.cc:785)
==1688197==by 0x49B5F63:
DcmSpecificCharacterSet::selectCharacterSetWithoutCodeExtensions()
(dcspchrs.cc:338)
==1688197==by 0x49B6797:
DcmSpecificCharacterSet::selectCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&) (dcspchrs.cc:189)
==1688197==by 0x498F5A6:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, unsigned long, bool) (dcitem.cc:4403)
==1688197==by 0x498CB96:
DcmItem::convertCharacterSet(std::__cxx11::basic_string, std::allocator > const&, unsigned long,
bool) (dcitem.cc:4442)
==1688197==
==1688197== 24 bytes in 1 blocks are still reachable in loss record 3 of 18
==1688197==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1688197==by 0x4F4E2EA: _citrus_stdenc_open (citrus_stdenc.c:112)
==1688197==by 0x4F55A69: _citrus_iconv_std_iconv_init_shared
(citrus_iconv_std.c:374)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:201)
==1688197==by 0x4F56B83: UnknownInlinedFun (citrus_iconv.c:265)
==1688197==by 0x4F56B83: _citrus_iconv_open (citrus_iconv.c:349)
==1688197== 

Bug#1055567: Error: gscan2pdf fails to compile

[Soumyanath Chatterjee]

Please find the responses in red.


On 16/11/23 02:22, jeff wrote:

On 15/11/2023 12:19, Soumyanath Chatterjee wrote:

I find line 8 is commented out


I take it, therefore, that you didn't comment out the line yourself 
sometime in the past?


How did you install gscan2pdf?



I am not very sure. I think I installed it from ubuntu repository or 
might have taken it from sourceforge






ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1
lrwxrwxrwx 1 root root 17 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1-> libsane.so.1.0.29


What about

ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1.0.29 



-rw-r--r-- 1 root root 92232 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1.0.29

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

On 15/11/2023 13:47, Bálint Réczey wrote:

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.


Updated and uploaded -3 to mentors

Thanks for the prompt review feedback. Much appreciated.

Colin



You can run 'cme update dpkg-copyright' in the source directory or any 
other tool from https://wiki.debian.org/CopyrightReviewTools 
 to help with the manual 
labor.


Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey > wrote:


Hi Colin,

Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
nov. 14., K, 17:58):
 >
 > Hi Balint,
 >
 > I've uploaded 0.4.0-2 with the suggested fixes.
 >
 > reply inlined below:
 >
 > On 09/11/2023 16:23, Bálint Réczey wrote:
 > > Hi Colin,
 > >
 > > Colin King (gmail) mailto:colin.i.k...@gmail.com>> ezt írta (időpont: 2023.
 > > nov. 7., K, 15:18):
 > >>
 > >> Hi Balint,
 > >>
 > >> Thanks for responding with the review. I was waiting for the
upstream
 > >> project to release a 0.4 with some minor fixes before
re-uploading to
 > >> mentors.
 > >>
 > >> I've addressed the issues you found as below:
 > >
 > > Please see my observations below.
 > >
 > >> On 22/10/2023 22:38, Bálint Réczey wrote:
 > >>> Hi Colin,
 > >>>
 > >>> I've checked the second upload at [1].
 > >>> As you can see in the Lintian warnings there is a .git
directory which
 > >>> is not ideal for a source package.
 > >>> I suggest using the most widely used git-buildpackage based
workflow
 > >>> where the gbp command takes care of exporting the source package
 > >>> without the .git dir from the packaging repository.
 > >>> I'd be happy to set up a packaging repo for you at
 > >>> https://salsa.debian.org/debian/libtypec
 and add you as a maintainer
 > >>> as described in [2]
 > >
 > > I still hold up my offer about setting up a git repo for
packaging on
 > > Salsa. That comes with the benefit of automated fixes from Debian
 > > Janitor and I could also comment on changes right where they
happened.
 >
 > Thank you for your kind offer; I definitely think this is a good
idea,
 > please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec
 and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines
will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/
 , but if not, please
check it before pushing your packaging repository.

...

 > > I think my comment here was misleading, sorry for that.
 > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/
dir as a
 > > result of specifying .../libtypec.pc as the target dir in the
.install
 > > file was not desired. It was even patched to have the right
content.
 > > Please ship the .pc file in the -dev package.
 >
 > Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

 > > * As you switched back to use upstream's 0.4.0 SO version the
.symbols
 > > file became wrong  not matching the shipped SO version. Please fix
 > > that and also switch to the libtypec0 package name since it
needs to
 > > match upstream's major SO version
 >
 > Fixed.

The .symbols file's first line should be:
  libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

 > .
 > >
 > > * I'd recommend asking upstream to switch to semantic SO versioning
 > > instead of using the project's version and switching to major
version
 > > 1 when the API stabilized.
 >
 > Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

 > Colin
 >
 > >
 > > Cheers,
 > > Balint
 > >
 > >> Kind regards,
 > >>
 > >> Colin
 > >>
 > >>
 > >>> Cheers,
 > >>> Balint
 > >>>
 > >>> [1] https://mentors.debian.net/package/libtypec/

 > >>> [2]
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 

 > >>>
 > >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 > >>> mailto:colin.i.k...@gmail.com>> wrote:
 >  Hi,
 > 
 >  I've uploaded a fixed package that addresses these 

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Paul Gevers]

Hi,

On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard  wrote:

Quoting Scott Talbert (2023-10-12 02:33:45)
> It looks like pandoc can be updated to v3.0.1 and be compatible with the 
> dependencies that are in unstable currently (LTS 21).  Can you please let 
> us know if there are any dependencies still missing?



I will look at it soon - probably this upcoming weekend.


Is there any progress with fixing this bug? It seems that this issue is 
one of the last blocking issues in the haskell transition. src:pandoc is 
a key package, we can't easily remove it from testing to "fix" the blockage.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056034: systemd: some services don't start after systemd update)

[Antonio]

You are not using a Debian kernel, so we cannot offer you support.
Someone with the same broken kernel reported a similar issue upstream,
and was redirected to the kernel supplier:

https://github.com/damentz/liquorix-package/issues/147


I checked and in fact there are no problems with the latest version of 
the Debian kernel.


Thanks for the information,
I have reported it to the Liquorix maintainers.

https://techpatterns.com/forums/about3055.html 



Antonio

Bug#1056047: python-skbio ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:python-skbio
Version: 0.5.8-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-skbio ftbfs with Python 3.12 (and cython 3.0.5):

[...]
dh_auto_configure
I: pybuild base:310: python3.12 setup.py config
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:381: 
FutureWarning: Cython directive 'language_level' not set, using '3str' 
for now (Py3). This has changed from earlier releases! File: 
/<>/skbio/alignment/_ssw_wrapper.pyx

  tree = Parsing.p_module(s, pxd, full_module_name)

Error compiling Cython file:

...
else:
matrix = self._convert_dict2d_to_matrix(substitution_matrix)
# Set up our mask_length
# Mask is recommended to be max(query_sequence/2, 15)
if mask_auto:
self.mask_length = len(query_sequence) / 2
   ^


skbio/alignment/_ssw_wrapper.pyx:584:51: Cannot assign type 'double' to 
'int32_t'

[1/6] Cythonizing skbio/alignment/_ssw_wrapper.pyx
Traceback (most recent call last):
  File "/<>/setup.py", line 129, in 
extensions = cythonize(extensions, force=True)
 ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1154, in cythonize

cythonize_one(*args)
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: skbio/alignment/_ssw_wrapper.pyx
E: pybuild pybuild:395: configure: plugin distutils failed with: exit 
code=1: python3.12 setup.py config

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[Ray Kinsella]

On Wed, 15 Nov 2023 at 22:30, James Addison  wrote:

> On Wed, 15 Nov 2023 at 21:57, Ray Kinsella 
> wrote:
> >
> > Thanks for this - you are kind to look at this issue.
>
> You're welcome - I enjoyed learning a bit about the Quark hardware,
> and the esoteric lock bug.  A shame I didn't learn about it five years
> ago I suppose, but there we are.
>
>
I spent a not insignificant amount of time devising this solution, to get
"Debian Support"
After a few false starts and missteps, eventually I came up with LibX1000
which was a pretty effective fix IMHO.

When I started sharing it around with the Debian & Kernel folks - the
response was pretty clear.
"This is a mess, Intel should just fix the bug ... " - which honestly in
retrospect was the right thing to do.


> > It's been a long time since Intel manufactured the X1000 / Quark, I am
> not sure how many are left in the wild.
> > Do you think this is something that Debian might want to package and
> ship?
>
> I should admit that I'm not a Debian maintainer or developer, just a
> passerby who attempts to make progress on bugs that interest to me
> (possibly to the annoyance of actual DMs/DDs), so my opinion is
> somewhat external (i.e.: take with a grain of salt).


Thrilled that you reached out about it.


> It's entirely
> possible that the maintenance for an additional package wouldn't be
> worthwhile -- and in general, 32-bit x86 support in Debian does tend
> to be dwindling.  Basically: someone has to be motivated about it
> enough to be responsible for the package.
>

[SNIP]


> Do you know whether Intel shipped many Quark units?  I see that
> manufacturing stopped in Y2019, which isn't too long ago, but I don't
> know much about how widely-adopted they were.


There were a few micro[processors,controllers] shipped under Quark.
My memory is that the X1000 didn't last long beyond 2017.
I remember seeing stacks of them (Galileo Boards) sitting gathering dust in
Frys and Maplin.
So I couldn't say how many are in the wild being used.

It was the
> energy-efficiency focus of them that gathered my interest in the first
> place, FWIW.
>
>
Boards like the Up-board (https://up-board.org/) and its successors really
filled this gap more effectively


> > On Wed, 15 Nov 2023 at 12:27, James Addison  wrote:
> >>
> >> Followup-For: Bug #738575
> >> X-Debbugs-Cc: raykinsell...@gmail.com
> >>
> >> If I understand correctly, then Ray's libx1000 library[1] provides a
> way to
> >> work around this in software.  It uses some LD_PRELOAD magic, and from
> what I
> >> remember, it's worth being careful when using that approach.
> >>
> >> I opened an RFP[2] for libx1000 earlier this year, and took another
> look at the
> >> Debian packaging metadata in the codebase today, resulting in a few
> suggested
> >> edits as a pull request on GitHub - cc'ing you to notify you about
> that, Ray.
> >> I'm unsure whether some of the proposed postinst steps are required,
> and will
> >> ask you about those upstream too.
> >>
> >> [1] -
> http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html
> >>
> >> [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037070
>

Bug#1053955: rust-toml: please update to v0.7.8

[Peter Green]

Please update to (at least) newer upstream release v0.7.8.


toml itself is not semver-breaking, but it's closely coupled dependency
toml_edit is.

Relavent parts of the upstream changelog.


0.21.0 - 2023-11-06
Breaking Change

Split default-features=false APIs into parse and display features



0.20.0 - 2023-09-13
Compatibility

Serialization and deserialization of tuple variants has changed from being 
an array to being a table with the key being the variant name and the value 
being the array


0.20->0.21 looks low risk to me, but 0.19->0.20 looks potentially riskier.

With that in mind lets look at the reverse dependencies.

btm - still on 0.19 upstream.
python-maturin - uses 0.21 upstream, did not make any code changes when bumping 
from 0.19 to 0.21, already broken and not in testing.
rust-cargo - uses 0.20 upstream, did not make any code changes when bumping 
from 0.19 to 0.20
rust-rstest-test - uses 0.19 upstream, not in testing, no rdeps
rust-trycmd - uses 0.20 upstream

My overall conclusion is that btm is the main blocker. Jonas, btm is one
of your packages, can you work with upstream to prepare and test an update?

Updated versions of toml_edit and toml are availble in experimental for
you to test with.

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

On 16.11.23 10:44, Ole Streicher wrote:

Hi Matthias,

There is a new version of yt, which should resolve this. However, it 
can't be uploaded due to the missing cython-3 in Debian. If you have 
packaged cython-3.0.5, maybe you can make it available?


yes, we will make it available in experimental soon, and also document 
an upgrade path.

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Ole Streicher]

Hi Matthias,

There is a new version of yt, which should resolve this. However, it 
can't be uploaded due to the missing cython-3 in Debian. If you have 
packaged cython-3.0.5, maybe you can make it available?


Best

Ole

Bug#1055516: Ongoing work

[Thomas Goirand]

Hi,

FYI, to package latest version, I need python-jsonschema-specifications 
that I started packaging, but now this one needs the latest version of 
python3-referencing. As per here:


https://github.com/python-jsonschema/referencing/commit/fdc8ab0116c82622a1ed0cd642e51237788ad1eb

version 0.31.0 of referencing add 
"referencing.jsonschema.EMPTY_REGISTRY" that jsonschema-specifications 
uses (at least during tests, maybe more...).


Roland, can you upgrade referencing to 0.31.0 then?

Cheers,

Thomas Goirand (zigo)

Bug#1056046: pyregion ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:pyregion
Version: 2.2.0-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

pyregion ftbfs with Python 3.12 (and cython 3.0.5):

[...]
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:381: 
FutureWarning: Cython directive 'language_level' not set, using '3str' 
for now (Py3). This has changed from earlier releases! File: 
/<>/pyregion/_region_filter.pyx

  tree = Parsing.p_module(s, pxd, full_module_name)

Error compiling Cython file:

...

cdef extern from "stdlib.h":
pass


cimport  c_numpy
 ^


pyregion/_region_filter.pyx:9:9: 'c_numpy.pxd' not found

Error compiling Cython file:

...
cdef extern from "stdlib.h":
pass


cimport  c_numpy
from c_numpy cimport npy_bool
^


pyregion/_region_filter.pyx:10:0: 'c_numpy/npy_bool.pxd' not found

Error compiling Cython file:

...
pass


cimport  c_numpy
from c_numpy cimport npy_bool
cimport c_python
^


pyregion/_region_filter.pyx:11:8: 'c_python.pxd' not found

Error compiling Cython file:

...
return RegionAnd(self, o)

def __or__(self, RegionBase o):
return RegionOr(self, o)

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:103:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

 ^


pyregion/_region_filter.pyx:134:9: 'ndarray' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

 ^


pyregion/_region_filter.pyx:134:37: 'npy_intp' is not a type identifier

Error compiling Cython file:

...
ny = c_python.PySequence_GetItem(shape, 0)
nx = c_python.PySequence_GetItem(shape, 1)

return self._mask(nx, ny)

cdef c_numpy.ndarray _mask(self, c_numpy.npy_intp nx, 
c_numpy.npy_intp ny):

  ^


pyregion/_region_filter.pyx:134:58: 'npy_intp' is not a type identifier

Error compiling Cython file:

...
cdef RegionBase child_region

def __init__(self, RegionBase child_region):
self.child_region = child_region

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:246:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...

cdef class RegionOrList(RegionList):
"""
>>> r = RegionOrList(r1, r2, r3, r4, ...)
"""
cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:286:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
cdef class RegionAndList(RegionList):
"""
>>> r = RegionAndList(r1, r2, r3, r4, ...)
"""

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:305:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...

cdef int _transform(self, double x, double y, double *xp, double *yp):
xp[0] = x
yp[0] = y

cdef npy_bool _inside(self, double x, double y):
 ^


pyregion/_region_filter.pyx:365:9: 'npy_bool' is not a type identifier

Error compiling Cython file:

...
def __init__(self, double xc, double yc, double radius,

Bug#1054508: Connman: breaks connections, uses 1 CPU core, and trashes disk space

[Vignesh Raman]

Hi,

On 16/11/23 11:26, программист некто wrote:

Hello. I will try to test it, but it may be difficult. Because, I got the issue 
with Wi-Fi that located in another city.
I never got this issue with home Wi-Fi.


Thank you. I will reduce the severity of this bug from critical to 
important since it is only observed with a particular Wi-Fi network.


Regards,
Vignesh

Bug#1056045: healpy ftbfs with Python 3.12

[Matthias Klose]

Package: src:healpy
Version: 1.16.1-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

healpy ftbfs with Python 3.12, although it also fails the same way with 
3.11.  Probably you need to wait until we have built all the depending 
modules when adding 3.12.



[...]
= test session starts 
==
platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0 -- 
/usr/bin/python3.11

cachedir: .pytest_cache
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase(PosixPath('/<>/.pybuild/cpython3_3.11_healpy/build/.hypothesis/examples'))

rootdir: /<>
configfile: setup.cfg
plugins: cov-4.1.0, doctestplus-1.0.0, arraydiff-0.5.0, 
hypothesis-6.88.1, cython-0.1.1, mock-3.11.1, astropy-header-0.2.2, 
filter-subpackage-0.1.2, remotedata-0.4.1, astropy-0.11.0

collecting ... collected 0 items / 1 error

 ERRORS 

 ERROR collecting test session 
_
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:641: in 
_importconftest

mod = import_path(conftestpath, mode=importmode, root=rootpath)
/usr/lib/python3/dist-packages/_pytest/pathlib.py:567: in import_path
importlib.import_module(module_name)
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1126: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1126: in _find_and_load_unlocked
???
:241: in _call_with_frames_removed
???
:1204: in _gcd_import
???
:1176: in _find_and_load
???
:1147: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
:940: in exec_module
???
:241: in _call_with_frames_removed
???
healpy/__init__.py:90: in 
from ._query_disc import query_disc, query_strip, query_polygon, 
boundaries

healpy/src/_query_disc.pyx:10: in init healpy._query_disc
???
E   ModuleNotFoundError: No module named '_pixelfunc'
=== short test summary info 


ERROR ../../.. - ModuleNotFoundError: No module named '_pixelfunc'
 Interrupted: 1 error during collection 

=== 1 error in 0.28s 
===
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=2: 
cd /<>/.pybuild/cpython3_3.11_healpy/build; python3.11 -m 
pytest --doctest-modules

Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry

[Thomas Goirand]

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

* Package name: python-jsonschema-specifications
  Version : 2023.11.1
  Upstream Contact: Julian Berman 
* URL : 
https://github.com/python-jsonschema/jsonschema-specifications
* License : Expat
  Programming Lang: Python
  Description : JSON Schema meta-schemas and vocabularies, exposed as a 
Registry

 This package contains JSON support files from the JSON Schema Specifications
 (metaschemas, vocabularies, etc.), packaged for runtime access from Python as
 a referencing-based Schema Registry.

Note: This package is needed to update python-jsonschema to the latest
upsteram release.

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:yt
Version: 4.2.2-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

yt ftbfs with Python 3.12 (and cython 3.0.5):

[...]
Error compiling Cython file:

...
# Compute number of fields to skip. This should be 31 in 3 dimensions
skip_len = (1  # father index
+ 2*ndim   # neighbor index
+ 2**ndim  # son index
+ 2**ndim  # cpu map
+ 2**ndim  # refinement map
^


yt/frontends/ramses/io_utils.pyx:48:16: Cannot assign type 'double' to 
'INT64_t'


Error compiling Cython file:

...
nlevelmax = headers['nlevelmax']
n_levels = nlevelmax - min_level
ncpu = headers['ncpu']

ncpu_and_bound = nboundary + ncpu
twotondim = 2**ndim
 ^


yt/frontends/ramses/io_utils.pyx:103:17: Cannot assign type 'double' to 
'INT64_t'


Error compiling Cython file:

...
cdef str field
cdef INT64_t twotondim
cdef int ilevel, icpu, ifield, nfields, nlevels, nc, ncpu_selected
cdef np.ndarray[np.uint8_t, ndim=1] mask

twotondim = 2**ndim
 ^


yt/frontends/ramses/io_utils.pyx:157:17: Cannot assign type 'double' to 
'INT64_t'

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1345, in cythonize_one_helper

return cythonize_one(*m)
   ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: yt/frontends/ramses/io_utils.pyx

Error compiling Cython file:

...
@cython.cdivision(True)
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t bitrange(np.int64_t x, np.int64_t width,
 np.int64_t start, np.int64_t end):
return x >> (width-end) & ((2**(end-start))-1)
^


yt/utilities/lib/geometry_utils.pyx:92:28: Invalid operand types for '&' 
(int64_t; double)


Error compiling Cython file:

...
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t rrot(np.int64_t x, np.int64_t i, np.int64_t width):
i = i%width
x = (x>>i) | (xwidth-i)
return x&(2**width-1)
^


yt/utilities/lib/geometry_utils.pyx:108:12: Invalid operand types for 
'&' (int64_t; double)


Error compiling Cython file:

...
@cython.cdivision(True)
@cython.boundscheck(False)
@cython.wraparound(False)
cdef np.int64_t setbit(np.int64_t x, np.int64_t w, np.int64_t i, 
np.int64_t b):

if b == 1:
return x | 2**(w-i-1)
 ^


yt/utilities/lib/geometry_utils.pyx:129:17: Invalid operand types for 
'|' (int64_t; double)


Error compiling Cython file:

...
@cython.wraparound(False)
cdef np.int64_t setbit(np.int64_t x, np.int64_t w, np.int64_t i, 
np.int64_t b):

if b == 1:
return x | 2**(w-i-1)
elif b == 0:
return x & ~2**(w-i-1)
   ^


yt/utilities/lib/geometry_utils.pyx:131:19: Invalid operand type for '~' 
(double)

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1345, in cythonize_one_helper

return cythonize_one(*m)
   ^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: yt/utilities/lib/geometry_utils.pyx
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib/python3.11/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
^^^
  File "/usr/lib/python3.11/multiprocessing/pool.py", line 48, in mapstar
return 

Bug#1056042: xrayutilities ftbfs with Python 3.12

[Matthias Klose]

Package: src:xrayutilities
Version: 1.7.4-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

some tests fail with:

[...]
/usr/lib/python3.12/subprocess.py:571: CalledProcessError
- Captured stderr call 
-

Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12_xrayutilities/build/examples/simpack_xrr_SiO2_Ru_CoFe_IrMn_Al2O3.py", 
line 20, in 

import lmfit
  File "/usr/lib/python3/dist-packages/lmfit/__init__.py", line 38, in 


from .confidence import conf_interval, conf_interval2d
  File "/usr/lib/python3/dist-packages/lmfit/confidence.py", line 10, 
in 

from .minimizer import MinimizerException
  File "/usr/lib/python3/dist-packages/lmfit/minimizer.py", line 41, in 


from .parameter import Parameter, Parameters
  File "/usr/lib/python3/dist-packages/lmfit/parameter.py", line 10, in 


from uncertainties import correlated_values, ufloat
  File "/usr/lib/python3/dist-packages/uncertainties/__init__.py", line 
225, in 

from .core import *
  File "/usr/lib/python3/dist-packages/uncertainties/core.py", line 22, 
in 

from past.builtins import basestring
  File "/usr/lib/python3/dist-packages/past/builtins/__init__.py", line 
54, in 

from past.builtins.misc import (apply, chr, cmp, execfile, intern, oct,
  File "/usr/lib/python3/dist-packages/past/builtins/misc.py", line 45, 
in 

from imp import reload
ModuleNotFoundError: No module named 'imp'

complete build log at
https://launchpadlibrarian.net/697894338/buildlog_ubuntu-noble-amd64.xrayutilities_1.7.4-1build2_BUILDING.txt.gz

Bug#1056041: tombo ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:tombo
Version: 1.5.1-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

tombo ftbfs with Python 3.12 (and cython 3.0.5):

[...]
[1/1] Cythonizing tombo/_c_dynamic_programming.pyx
Traceback (most recent call last):
  File "/<>/setup.py", line 55, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
107, in setup

return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 185, in setup

return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 201, in run_commands

dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 969, in run_commands

self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 131, in run

self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", 
line 318, in run_command

self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File 
"/usr/lib/python3/dist-packages/setuptools/command/build_ext.py", line 
88, in run

_build_ext.run(self)
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 345, in run

self.build_extensions()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 467, in build_extensions

self._build_extensions_serial()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 493, in _build_extensions_serial

self.build_extension(ext)
  File 
"/usr/lib/python3/dist-packages/setuptools/command/build_ext.py", line 
249, in build_extension

_build_ext.build_extension(self, ext)
  File "/usr/lib/python3/dist-packages/Cython/Distutils/build_ext.py", 
line 130, in build_extension

new_ext = cythonize(
  ^^
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1154, in cythonize

cythonize_one(*args)
  File "/usr/lib/python3/dist-packages/Cython/Build/Dependencies.py", 
line 1321, in cythonize_one

raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: tombo/_c_dynamic_programming.pyx
E: pybuild pybuild:395: build: plugin distutils failed with: exit 
code=1: /usr/bin/python3.12 setup.py build

I: pybuild base:310: /usr/bin/python3 setup.py build

Bug#1056040: ros-image-common ftbfs with Python 3.12

[Matthias Klose]

Package: src:ros-image-common
Version: 1.12.0-12
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

ros-image-common ftbfs with Python 3.12:

[...]
[Testcase: testunit_test] ... ERROR!
ERROR: 'RosTest' object has no attribute 'assert_'
  File "/usr/lib/python3.12/unittest/case.py", line 58, in testPartExecutor
yield
  File "/usr/lib/python3.12/unittest/case.py", line 636, in run
self._callTestMethod(testMethod)
  File "/usr/lib/python3.12/unittest/case.py", line 589, in _callTestMethod
if method() is not None:
   
  File "/usr/lib/python3/dist-packages/rostest/runner.py", line 113, in fn
self.assert_(self.test_parent is not None, "ROSTestParent 
initialization failed")




[ROSTEST]---


SUMMARY
 * RESULT: FAIL
 * TESTS: 0
 * ERRORS: 1
 * FAILURES: 0

Bug#1056039: ros-geometry2 ftbfs with Python 3.12 (amd64 only)

[Matthias Klose]

Package: src:ros-geometry2
Version: 0.7.7-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

ros-geometry2 ftbfs with Python 3.12 (amd64 only), on other 
architectures the tests pass. Tests also pass with 3.11.


[...]
I: pybuild base:310: dh_auto_test --buildsystem=cmake 
--builddirectory=/<>/.pybuild/cpython3_3.12/build --
I: pybuild pybuild:340: catkin_test_results 
/<>/.pybuild/cpython3_3.12/build
test_results/tf2_geometry_msgs/rostest-test_test.xml: 1 tests, 1 errors, 
0 failures, 0 skipped
test_results/tf2_kdl/rostest-test_test.xml: 1 tests, 1 errors, 0 
failures, 0 skipped
test_results/tf2_ros/rostest-test_message_filter_test.xml: 1 tests, 1 
errors, 0 failures, 0 skipped
test_results/tf2_ros/rostest-test_transform_listener_time_reset_test.xml: 
1 tests, 1 errors, 0 failures, 0 skipped
test_results/tf2_ros/rostest-test_transform_listener_unittest.xml: 1 
tests, 1 errors, 0 failures, 0 skipped

Summary: 95 tests, 5 errors, 0 failures, 0 skipped
E: pybuild pybuild:395: test: plugin cmake failed with: exit code=1: 
catkin_test_results /<>/.pybuild/cpython3_3.12/build

Bug#1041519: transmission: contains prebuilt javascript without source

[Alexandre Rossi]

> The source package contains:
> 
> web/public_html/index.html
> web/public_html/transmission-app.js
> 
> These files are copied into the binary package as:
> 
> /usr/share/transmission/public_html/index.html
> /usr/share/transmission/public_html/transmission-app.js
> 
> Those files should be built from source with no network connection.

Hi,

I gave it a try and published my current status. Advice will
be appreciated.

https://salsa.debian.org/debian/transmission/-/merge_requests/16

Thanks,

Alex

Bug#1056038: python-thinc ftbfs with Python 3.12 (and cython 3.0.5)

[Matthias Klose]

Package: src:python-thinc
Version: 8.1.7-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-thinc ftbfs with Python 3.12 (and cython 3.0.5):

[...]
Error compiling Cython file:

...
dims = table.shape[1]

cdef np.ndarray output
if reals2d_ft is float2d_t:
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:448:32: Cannot assign type 'saxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, float, const float *, int, float *, int) except * nogil'.


Error compiling Cython file:

...
dims = table.shape[1]

cdef np.ndarray output
if reals2d_ft is float2d_t:
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:448:32: Cannot assign type 'saxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, float, const float *, int, float *, int) except * nogil'.


Error compiling Cython file:

...
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

table.shape[0], dims, rows, indices.shape[1])
else:
output = self.xp.zeros((rows, dims), dtype="float64")
cpu_gather_add(daxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:452:32: Cannot assign type 'daxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, double, const double *, int, double *, int) except * 
nogil'.


Error compiling Cython file:

...
output = self.xp.zeros((rows, dims), dtype="float32")
cpu_gather_add(saxpy(cblas), output.data, 
[0, 0], [0, 0],

table.shape[0], dims, rows, indices.shape[1])
else:
output = self.xp.zeros((rows, dims), dtype="float64")
cpu_gather_add(daxpy(cblas), output.data, 
[0, 0], [0, 0],

^


thinc/backends/numpy_ops.pyx:452:32: Cannot assign type 'daxpy_ptr' to 
'ptr'. Exception values are incompatible. Suggest adding 'noexcept' to 
type 'void (int, double, const double *, int, double *, int) except * 
nogil'.




complete build log at
https://launchpadlibrarian.net/697893737/buildlog_ubuntu-noble-amd64.python-thinc_8.1.7-1build1_BUILDING.txt.gz

Bug#1056037: python-sqt ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-sqt
Version: 0.8.0-6
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-sqt ftbfs with Python 3.12:

[...]
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
pybuild --clean -i python{version} -p "3.12 3.11"
I: pybuild base:310: python3.12 setup.py clean
/<>/versioneer.py:485: SyntaxWarning: invalid escape 
sequence '\s'

  LONG_VERSION_PY['git'] = '''
Traceback (most recent call last):
  File "/<>/setup.py", line 95, in 
version = versioneer.get_version(),
  
  File "/<>/versioneer.py", line 1473, in get_version
return get_versions()["version"]
   ^^
  File "/<>/versioneer.py", line 1406, in get_versions
cfg = get_config_from_root(root)
  ^^
  File "/<>/versioneer.py", line 412, in get_config_from_root
parser = configparser.SafeConfigParser()
 ^
AttributeError: module 'configparser' has no attribute 
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
E: pybuild pybuild:395: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" 
returned exit code 13

Bug#1056036: python-aiohttp ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-aiohttp
Version: 3.8.6-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-aiohttp ftbfs with Python 3.12:

[...]
building 'aiohttp._websocket' extension
creating build
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/aiohttp
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 
-Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/python-aiohttp-3.8.6-1build1 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.12 -c 
aiohttp/_websocket.c -o 
build/temp.linux-x86_64-cpython-312/aiohttp/_websocket.o
aiohttp/_websocket.c: In function 
‘__pyx_pf_7aiohttp_10_websocket__websocket_mask_cython’:
aiohttp/_websocket.c:1475:3: warning: ‘Py_OptimizeFlag’ is deprecated 
[-Wdeprecated-declarations]

 1475 |   if (unlikely(!Py_OptimizeFlag)) {
  |   ^~
In file included from /usr/include/python3.12/Python.h:48,
 from aiohttp/_websocket.c:6:
/usr/include/python3.12/cpython/pydebug.h:13:37: note: declared here
   13 | Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_OptimizeFlag;
  | ^~~
aiohttp/_websocket.c: In function ‘__Pyx_get_tp_dict_version’:
aiohttp/_websocket.c:2680:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2680 | return likely(dict) ? __PYX_GET_DICT_VERSION(dict) : 0;
  | ^~
In file included from /usr/include/python3.12/dictobject.h:90,
 from /usr/include/python3.12/Python.h:61:
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_get_object_dict_version’:
aiohttp/_websocket.c:2692:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]
 2692 | return (dictptr && *dictptr) ? 
__PYX_GET_DICT_VERSION(*dictptr) : 0;

  | ^~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_object_dict_version_matches’:
aiohttp/_websocket.c:2696:5: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]
 2696 | if (unlikely(!dict) || unlikely(tp_dict_version != 
__PYX_GET_DICT_VERSION(dict)))

  | ^~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_CLineForTraceback’:
aiohttp/_websocket.c:2741:9: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2741 | __PYX_PY_DICT_LOOKUP_IF_MODIFIED(
  | ^~~~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c:2741:9: warning: ‘ma_version_tag’ is deprecated 
[-Wdeprecated-declarations]

 2741 | __PYX_PY_DICT_LOOKUP_IF_MODIFIED(
  | ^~~~
/usr/include/python3.12/cpython/dictobject.h:22:34: note: declared here
   22 | Py_DEPRECATED(3.12) uint64_t ma_version_tag;
  |  ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyInt_As_long’:
aiohttp/_websocket.c:3042:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3042 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c:3097:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3097 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyInt_As_int’:
aiohttp/_websocket.c:3238:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3238 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c:3293:53: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

 3293 | const digit* digits = ((PyLongObject*)x)->ob_digit;
  | ^~
aiohttp/_websocket.c: In function ‘__Pyx_PyIndex_AsSsize_t’:
aiohttp/_websocket.c:3744:45: error: ‘PyLongObject’ {aka ‘struct 

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Emanuele Rocca]

Hi Rafael,

On 2023-11-16 08:42, Rafael Laboissière wrote:
> Control: forwarded -1 https://sourceforge.net/p/plplot/bugs/206/
> 
> * Rafael Laboissière  [2023-11-16 07:51]:
> 
> > My guess is that the bug is in PLplot and not in gfortran, but this is
> > just a guess. I will eventually inform the PLplot upstream authors about
> > the issue.
> 
> Done !

Thank you!

To be honest I think it's safe to close 1055750 (gfortran) and mark
1055228 (plplot) as forwarded upstream though, I don't think we have any
reasons to believe the compiler is at fault really.

  Emanuele

Bug#1056035: mirror submission for mirror.matnetwrk.net

[Mathieu Mafille]

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

Submission-Type: new
Site: mirror.matnetwrk.net
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mathieu Mafille 
Country: CH Switzerland
Location: Saint-Imier / Switzerland
Sponsor: MATNETWRK https://matnetwrk.net




Trace Url: http://mirror.matnetwrk.net/debian/project/trace/
Trace Url: 
http://mirror.matnetwrk.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.matnetwrk.net/debian/project/trace/mirror.matnetwrk.net

Bug#1056034: systemd: some services don't start after systemd update

[antonio]

Package: systemd
Version: 255~rc2-1
Severity: normal
X-Debbugs-Cc: antde...@gmail.com

Dear Maintainer,
after updating "systemd" to version "255~rc2-1" some services do not start:

- systemd-resolved.service:

nov 16 08:57:37 SAT (resolved)[1183]: systemd-resolved.service: Failed to set
up special execution directory in /run: Invalid argument

- systemd-timesyncd.service:

nov 16 08:57:37 SAT systemd[1]: Failed to start systemd-timesyncd.service -
Network Time Synchronization.
nov 16 08:57:37 SAT (imesyncd)[1249]: systemd-timesyncd.service: Failed to set
up special execution directory in /run: Invalid argument

- wpa_supplicant.service:

nov 16 08:57:38 SAT (pplicant)[1943]: wpa_supplicant.service: Failed to set up
special execution directory in /run: Invalid argument
nov 16 08:57:38 SAT systemd[1]: Failed to start wpa_supplicant.service
nov 16 08:58:46 SAT NetworkManager[1453]:  [1700121526.2236] device
(wlan0): Couldn't initialize supplicant interface: Failed to D-Bus activate
wpa_supplicant service

- systemd-tmpfiles

nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/snd/seq failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/snd/timer failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/loop-control
failed: Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/net/tun failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/fuse failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vfio/vfio failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vhost-net failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[661]: fchmod() of /dev/vhost-vsock failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/snd/seq failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/snd/timer failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/loop-control
failed: Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/net/tun failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/fuse failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vfio/vfio failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vhost-net failed:
Invalid argument
nov 16 08:57:36 SAT systemd-tmpfiles[670]: fchmod() of /dev/vhost-vsock failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/dbus/containers
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/php failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/rpcbind failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/screen failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/systemd/netif
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/run/systemd/netif/links failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/run/systemd/netif/leases failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/systemd/netif/lldp
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/utmp failed:
Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/tpm2-tss/eventlog
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of /run/log/journal
failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/sys/kernel/security/tpm0/binary_bios_measurements failed: Invalid argument
nov 16 08:57:37 SAT systemd-tmpfiles[1096]: fchmod() of
/sys/kernel/security/ima/binary_runtime_measurements failed: Invalid argument

---

also note the truncated keywords "(pplicant)", "(imesyncd)"

what has changed?

Thanks,
Antonio


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1

Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.7-1
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

As discussed in private, here is a patch which fixes the arch detection for
sparc64 in cabal. Previously, cabal treated "sparc64" as an alias for 32-bit
sparc which results in the GHC build process not being able to find the built
binaries as these are stored in a $ARCH-$OS subfolder.

The patch has already been pushed upstream, approved and should be merged within
the next hours after some more waiting [1].

The attached patch is a backported version of the patch which applies to GHC 
9.4.7.

Thanks,
Adrian

> [1] https://github.com/haskell/cabal/pull/9445

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- ghc-9.4.6.orig/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs
+++ ghc-9.4.6/libraries/Cabal/Cabal-syntax/src/Distribution/System.hs
@@ -158,19 +158,17 @@ buildOS = classifyOS Permissive System.I
 -- 
 
 -- | These are the known Arches: I386, X86_64, PPC, PPC64, Sparc,
--- Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa, Rs6000,
--- M68k, Vax, JavaScript and Wasm32.
---
+-- Sparc64, Arm, AArch64, Mips, SH, IA64, S390, S390X, Alpha, Hppa,
+-- Rs6000, M68k, Vax, JavaScript and Wasm32.
 -- The following aliases can also be used:
 --* PPC alias: powerpc
 --* PPC64 alias : powerpc64, powerpc64le
---* Sparc aliases: sparc64, sun4
 --* Mips aliases: mipsel, mipseb
 --* Arm aliases: armeb, armel
 --* AArch64 aliases: arm64
 --
 data Arch = I386  | X86_64  | PPC  | PPC64 | Sparc
-  | Arm   | AArch64 | Mips | SH
+  | Sparc64 | Arm   | AArch64 | Mips | SH
   | IA64  | S390| S390X
   | Alpha | Hppa| Rs6000
   | M68k  | Vax
@@ -185,7 +183,7 @@ instance NFData Arch where rnf = generic
 
 knownArches :: [Arch]
 knownArches = [I386, X86_64, PPC, PPC64, Sparc
-  ,Arm, AArch64, Mips, SH
+  ,Sparc64 ,Arm, AArch64, Mips, SH
   ,IA64, S390, S390X
   ,Alpha, Hppa, Rs6000
   ,M68k, Vax
@@ -197,7 +195,6 @@ archAliases Strict _   = []
 archAliases Compat _   = []
 archAliases _  PPC = ["powerpc"]
 archAliases _  PPC64   = ["powerpc64", "powerpc64le"]
-archAliases _  Sparc   = ["sparc64", "sun4"]
 archAliases _  Mips= ["mipsel", "mipseb"]
 archAliases _  Arm = ["armeb", "armel"]
 archAliases _  AArch64 = ["arm64"]
--- ghc-9.4.6.orig/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs
+++ ghc-9.4.6/libraries/Cabal/Cabal/src/Distribution/Simple/PreProcess.hs
@@ -717,6 +717,7 @@ platformDefines lbi =
   PPC -> ["powerpc"]
   PPC64   -> ["powerpc64"]
   Sparc   -> ["sparc"]
+  Sparc64 -> ["sparc64"]
   Arm -> ["arm"]
   AArch64 -> ["aarch64"]
   Mips-> ["mips"]

Bug#1036165: ITP: atuin -- Rich shell history using a SQLite database with optional encrypted sync

[Arturo Borrero Gonzalez]

On Tue, 16 May 2023 18:01:52 +0800 Blair Noctis  wrote:

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: atuin
  Version : 14.0.1
  Upstream Contact: Ellie Huxtable 
* URL : https://atuin.sh/
* License : MIT
  Programming Lang: Rust
  Description : Rich shell history replacement using SQLite with optional
encrypted sync server



Hi there,

thanks for working on this.

Do you have a repository where you are developing this?

regards.

Bug#1056032: Dependency missing - "ModuleNotFoundError: No module named 'PyQt5.QtMultimedia'"

[Philipp Marek]

To: Debian Bug Tracking System <>
Package: qtqr
Version: 2.1~bzr47-1
Severity: important
X-Debbugs-Cc: phil...@marek.priv.at


qtqr seems to be missing a dependency:

$ qtqr
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 17, in 
from PyQt5.QtMultimedia import QCameraInfo
ModuleNotFoundError: No module named 'PyQt5.QtMultimedia'
$

After installing python3-pyqt5.qtmultimedia it works as expected.

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

Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de

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

Versions of packages qtqr depends on:
ii  python3  3.11.4-5+b1
ii  python3-pyqt55.15.10+dfsg-1
ii  python3-qrtools  2.1~bzr47-1

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: can't check qtqr file /usr/share/doc/qtqr/changelog.Debian.gz 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/bookmark.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/email-address.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/email-message.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/geo.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/mms.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/phonebook.png (Wide character in subroutine 
entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/sms.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/telephone.png (Wide character in subroutine 
entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/text-non-ascii.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file 
/usr/share/doc/qtqr/examples/text-plain.png (Wide character in 
subroutine entry)
debsums: can't check qtqr file /usr/share/doc/qtqr/examples/url.png 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/man/man1/qtqr.1.gz (Wide 
character in subroutine entry)
debsums: can't check qtqr file /usr/share/pixmaps/qtqr.png (Wide 
character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_de_DE.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_en_GB.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_es.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_es_AR.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_fr.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_is_IS.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_it_IT.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_ja.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_ru.qm 
(Wide character in subroutine entry)
debsums: can't check qtqr file /usr/share/qt5/translations/qtqr_zh_CN.qm 
(Wide character in subroutine entry)