Bug#1024828: might cause one test of r-cran-lexrankr on i386 architecture fail

[Andreas Tille]

Control: retitle -1 might cause one test of r-cran-lexrankr on i386 
architecture fail
Control: severity -1 normal

In a patch[1] the test of r-cran-lexrankr prevents that the sorting
error which occures on i386 only after the r-cran-igraph upgrade causes
the test suite to fail.  As long as the issue is not clarified this
bug should not be closed but the severity is reduced to normal.

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/r-pkg-team/r-cran-lexrankr/-/blob/master/debian/tests/run-unit-test#L14-18

-- 
http://fam-tille.de

Bug#1027050: growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found

[Martin Pitt]

Package: cloud-initramfs-growroot
Version: 0.18.debian11
Severity: important

In our CI we recently tried to refresh our Debian testing image [1], which
exposed a regression: Trying to resize the image with

qemu-resize  20G

leads to a boot failure:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.38.1
[/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1
/dev/vda1: clean, 118601/647168 files, 1027851/2588667 blocks
done.
[1.064055] EXT4-fs (vda1): mounted filesystem with ordered data mode. 
Quota mode: none.
done.
Begin: Running /scripts/local-bottom ... [1.086933] EXT4-fs (vda1): 
unmounting filesystem.
GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
/sbin/growpart: line 714: flock: not found
FAILED: Error while obtaining exclusive lock on /dev/vda
[1.114862] GPT:Primary header thinks Alt. header is not at the end of 
the disk.
[1.115544] GPT:20971519 != 41943039
[1.115927] GPT:Alternate GPT header not at the end of the disk.
[1.116488] GPT:20971519 != 41943039
[1.116806] GPT: Use GNU Parted to correct GPT errors.
[1.117273]  vda: vda1 vda14 vda15
/scripts/local-bottom/growroot: line 97: wait-for-root: not found
done.
Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev 
failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
done.
mount: mounting /run on /root/run failed: No such file or directory
BusyBox v1.35.0 (Debian 1:1.35.0-4) multi-call binary.

Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT NEW_INIT 
[ARGS]
[...]

and it lands in the (initramfs) interactive prompt. Pressing Enter then just
quickly fails to boot:

(initramfs)
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
/init: line 331: can't open /root/dev/console: no such file
[   10.166875] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0100

The "flock: not found" is #1014662, but that is already present in our current
image with cloud-initramfs-tools 0.18.debian8, and does not seem fatal. So far
the "wait-for-root: not found" seems to be the culprit?

The image build log [2] has a list of all package changes at the bottom. This
includes the kernel (6.0.10-2 -> 6.0.12-1) and two handful of other packages,
but the single one that stands out is

  cloud-initramfs-tools (0.18.debian8 -> 0.18.debian11)

Thanks,

Martin

[1] https://github.com/cockpit-project/bots/pull/4189
[2] 
https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-logs/debian-testing-20221220-225656.log

Bug#1027048: missing zxing patch

[Johannes Schauer Marin Rodrigues]

Hi,

turns out that when resuming a bug with reportbug, all its attachments 
get lost even though they do get stored in the resume file.


Here is the patch for real now. :)diff -Nru libreoffice-7.4.3/debian/changelog libreoffice-7.4.3/debian/changelog
--- libreoffice-7.4.3/debian/changelog	2022-11-28 18:32:19.0 +0100
+++ libreoffice-7.4.3/debian/changelog	2022-12-26 04:25:07.0 +0100
@@ -1,3 +1,11 @@
+libreoffice (1:7.4.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * add 0004-Remove-dependency-on-BitArray.h-from-zxing-1.2.0.patch from
+clearlinux-pkgs, see https://github.com/zxing-cpp/zxing-cpp/issues/361
+
+ -- Johannes Schauer Marin Rodrigues   Mon, 26 Dec 2022 04:25:07 +0100
+
 libreoffice (1:7.4.3-2) unstable; urgency=medium
 
   * debian/rules: disable checks on s390x for now (cause OOM on the buildds),
diff -Nru libreoffice-7.4.3/debian/patches/0004-Remove-dependency-on-BitArray.h-from-zxing-1.2.0.patch libreoffice-7.4.3/debian/patches/0004-Remove-dependency-on-BitArray.h-from-zxing-1.2.0.patch
--- libreoffice-7.4.3/debian/patches/0004-Remove-dependency-on-BitArray.h-from-zxing-1.2.0.patch	1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.4.3/debian/patches/0004-Remove-dependency-on-BitArray.h-from-zxing-1.2.0.patch	2022-12-26 04:23:31.0 +0100
@@ -0,0 +1,50 @@
+From a06c0eabc164cd2233cad4e159cff005951a5d06 Mon Sep 17 00:00:00 2001
+From: "Brett T. Warden" 
+Date: Fri, 2 Dec 2022 12:06:35 -0800
+Subject: [PATCH] Remove dependency on BitArray.h from zxing-1.2.0
+
+In zxing-1.4.0, numerous headers are no longer public. Rework the
+ConvertToSVGFormat method so it uses bitmatrix.get instead of
+bitmatrix.getRow, similar to the ToSVG method in zxing itself.
+
+See https://github.com/zxing-cpp/zxing-cpp/issues/361
+
+---
+ cui/source/dialogs/QrCodeGenDialog.cxx | 5 +
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/cui/source/dialogs/QrCodeGenDialog.cxx b/cui/source/dialogs/QrCodeGenDialog.cxx
+index 3e7b48e7af86..c334785d2bea 100644
+--- a/cui/source/dialogs/QrCodeGenDialog.cxx
 b/cui/source/dialogs/QrCodeGenDialog.cxx
+@@ -27,7 +27,6 @@
+ #endif
+ 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
+@@ -79,7 +78,6 @@ OString ConvertToSVGFormat(const ZXing::BitMatrix& bitmatrix)
+ OStringBuffer sb;
+ const int width = bitmatrix.width();
+ const int height = bitmatrix.height();
+-ZXing::BitArray row(width);
+ sb.append("\n"
+   "http://www.w3.org/2000/svg\; version=\"1.1\" viewBox=\"0 0 "
+   + OString::number(width) + " " + OString::number(height)
+@@ -87,10 +85,9 @@ OString ConvertToSVGFormat(const ZXing::BitMatrix& bitmatrix)
+ "

Bug#1027049: python-matplotlib-data: missing copyright file

[Jakub Wilk]

Package: python-matplotlib-data
Version: 3.6.2-3
Severity: serious
Justification: Policy §12.5

$ lintian -F python-matplotlib-data_3.6.2-3_all.deb
E: python-matplotlib-data: no-copyright-file

--
Jakub Wilk

Bug#1027048: FTBFS with zxing-cpp 1.4 from experimental

[Johannes Schauer Marin Rodrigues]

Source: libreoffice
Version: 1:7.4.3-2
Severity: important
Tags: patch

Hi,

libreoffice FTBFS with zxing-cpp 1.4 from experimental:

[build CXX] cui/source/dialogs/QrCodeGenDialog.cxx
S=/<> && I=$S/instdir && W=$S/workdir &&  mkdir -p 
$W/CxxObject/cui/source/dialogs/ $W/Dep/CxxObject/cui/source/dialogs/ && cd 
/<> &&  aarch64-linux-gnu-g++ -DAARCH64 
-DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 
-DLINUX -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -D_FORTIFY_SOURCE=2 
-D_PTHREADS -D_REENTRANT -Wdate-time -Wdate-time -D_FORTIFY_SOURCE=2 
-DCUI_DLLIMPLEMENTATION  -DSYSTEM_LIBXML  -flto=4 -fuse-linker-plugin -O2 
-fvisibility=hidden-Wall -Wno-missing-braces -Wnon-virtual-dtor 
-Wendif-labels -Wextra -Wundef -Wunreachable-code -Wshadow -Wunused-macros  
-finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe  
-Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 
-Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden 
-fPIC -Wshadow -Woverloaded-virtual -std=c++17 -pthread  -g1 -g1 -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security   -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs
-DLIBO_INTERNAL_ONLY  -c $S/cui/source/dialogs/QrCodeGenDialog.cxx -o 
$W/CxxObject/cui/source/dialogs/QrCodeGenDialog.o -MMD -MT 
$W/CxxObject/cui/source/dialogs/QrCodeGenDialog.o -MP -MF 
$W/Dep/CxxObject/cui/source/dialogs/QrCodeGenDialog.d_ -DSYSTEM_ZXING 
-I$S/external/clew/source/include -I$S/include 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-I$S/config_host  -I$S/cui/inc -I$S/cui/source/inc  
-I$W/CustomTarget/officecfg/registry -I$W/UnoApiHeadersTarget/udkapi/normal 
-I$W/UnoApiHeadersTarget/offapi/normal -I/usr/include  -isystem 
/usr/include/libxml2  -isystem /usr/include/liborcus-0.17  -isystem 
/usr/include/ZXing   && mv 
$W/Dep/CxxObject/cui/source/dialogs/QrCodeGenDialog.d_ 
$W/Dep/CxxObject/cui/source/dialogs/QrCodeGenDialog.d 
[build CXX] cui/source/dialogs/GraphicTestsDialog.cxx
/<>/cui/source/dialogs/QrCodeGenDialog.cxx:30:10: fatal error: 
BitArray.h: No such file or directory
   30 | #include 
  |  ^~~~
compilation terminated.
make[3]: *** [/<>/solenv/gbuild/LinkTarget.mk:337: 
/<>/workdir/CxxObject/cui/source/dialogs/QrCodeGenDialog.o] Error 1

The attached patch fixes the problem and makes libreoffice compile with
both zxing 1.2 from unstable as well as 1.4 from experimental.

Please consider applying the attached patch for a smooth transition.

Thanks!

cheers, josch

Bug#1027047: ruby-google-api-client: FTBFS with ruby-googleauth 1.3.0

[Vivek K J]

Package: ruby-google-api-client
Version: 0.50.0-2
Severity: important
Tags: ftbfs
X-Debbugs-Cc: vive...@disroot.org

Hi,
On building this package against latest version of ruby-googleauth
(1.3.0) in experimental, your package failed to build

(Relevant log, hopefully)

┌──┐
│ Checking Rubygems dependency resolution on ruby3.1   │
└──┘

GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
 ruby3.1 -e gem\ \"google-api-client\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in 
activate_dependencies': Could not find 'googleauth' (~> 0.9) among 114 total 
gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
 at: 
/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all/specifications/google-api-client-0.50.0.gemspec,
 execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
find 'googleauth' (~> 0.9) - did find: [googleauth-1.3.0] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
 , execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'

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

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

Versions of packages ruby-google-api-client depends on:
ii  libruby3.0 [ruby-rexml]  3.0.4-8
ii  libruby3.1 [ruby-rexml]  3.1.2-3
ii  ruby 1:3.1
ii  ruby-addressable 2.8.0-3
ii  ruby-googleauth  1.3.0-1
ii  ruby-httpclient  2.8.3+git20211122.4658227-1
ii  ruby-mini-mime   1.1.1-2
ii  ruby-representable   3.0.4-1.1
ii  ruby-retriable   3.1.2-1
ii  ruby-signet  0.17.0-1

ruby-google-api-client recommends no packages.

ruby-google-api-client suggests no packages.

-- no debconf information

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Package: linux-image-5.19.0-13797-ge091ba5cf827
Version: 5.19.0-13797-ge091ba5cf827-17
Followup-For: Bug #1025537

Nope... I just re-triggered the Oops on the preceding commit, e091ba5cf827.

I'll restart the bisection from there...

[ 2976.696730] Oops:  [#1] PREEMPT SMP NOPTI
[ 2976.700471] CPU: 0 PID: 1969 Comm: nfsd Not tainted 
5.19.0-13797-ge091ba5cf827 #17
[ 2976.704341] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013
[ 2976.708272] RIP: 0010:kernel_sendpage+0x1d/0x120
[ 2976.712213] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 
48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 
08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80
[ 2976.720602] RSP: 0018:a7f641733dc0 EFLAGS: 00010282
[ 2976.724805] RAX: b1933e60 RBX: 9897918e7400 RCX: 1000
[ 2976.729097] RDX:  RSI:  RDI: 9897918e7400
[ 2976.733433] RBP: 9896dab74280 R08:  R09: b12492e0
[ 2976.737779] R10: 0003 R11:  R12: 9897918e7400
[ 2976.742168] R13: 1000 R14: 9897aa997010 R15: b8fd
[ 2976.746524] FS:  () GS:9897d7c0() 
knlGS:
[ 2976.750910] CS:  0010 DS:  ES:  CR0: 80050033
[ 2976.755323] CR2: 0008 CR3: 0001ff94a000 CR4: 06f0
[ 2976.759755] Call Trace:
[ 2976.764102]  
[ 2976.768390]  ? sock_sendmsg+0x58/0x70
[ 2976.772648]  svc_tcp_sendmsg+0x121/0x180 [sunrpc]
[ 2976.776967]  ? nfsd_shutdown_threads+0x90/0x90 [nfsd]
[ 2976.781283]  svc_tcp_sendto+0x90/0x190 [sunrpc]
[ 2976.785577]  svc_send+0x4d/0x160 [sunrpc]
[ 2976.789807]  nfsd+0xd5/0x190 [nfsd]
[ 2976.794006]  kthread+0xe9/0x110
[ 2976.798048]  ? kthread_complete_and_exit+0x20/0x20
[ 2976.802159]  ret_from_fork+0x22/0x30
[ 2976.806223]  
[ 2976.810202] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo 
br_netfilter bridge stp llc overlay tls cmac algif_hash ecb algif_skcipher 
af_alg bnep ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE 
nf_nat xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink 
binfmt_misc amdgpu gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce 
ir_kbd_i2c cx23885 btusb tveeprom btrtl altera_ci btbcm cx2341x btintel btmtk 
tda18271 snd_pcm bluetooth snd_timer isofs rfkill amd64_edac snd 
jitterentropy_rng cdrom soundcore sha512_ssse3 edac_mce_amd sha512_generic 
altera_stapl kvm_amd radeon videobuf2_dvb ctr drbg videobuf2_dma_sg 
videobuf2_memops cp210x ansi_cprng m88ds3103 ccp i2c_mux usbserial i2c_algo_bit 
dvb_core videobuf2_v4l2 drm_ttm_helper rng_core evdev videobuf2_common joydev 
ttm kvm ecdh_generic drm_display_helper irqbypass ecc videodev xfs 
drm_kms_helper mc cec pcspkr k10temp rc_core
[ 2976.810298]  sp5100_tco button watchdog sg acpi_cpufreq w83795 jc42 tun loop 
msr nfsd parport_pc ppdev auth_rpcgss lp nfs_acl parport lockd grace drm 
efi_pstore sunrpc fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache 
jbd2 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor uas usb_storage raid6_pq libcrc32c 
crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic usbhid 
hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif 
crct10dif_generic crc64 crct10dif_common ahci libahci libata ohci_pci scsi_mod 
ohci_hcd ehci_pci ehci_hcd scsi_common tg3 i2c_piix4 usbcore ptp pps_core 
libphy usb_common
[ 2976.876303] CR2: 0008
[ 2976.881421] ---[ end trace  ]---
[ 2976.886579] RIP: 0010:kernel_sendpage+0x1d/0x120
[ 2976.891691] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 
48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 
08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80
[ 2976.902360] RSP: 0018:a7f641733dc0 EFLAGS: 00010282
[ 2976.907711] RAX: b1933e60 RBX: 9897918e7400 RCX: 1000
[ 2976.913121] RDX:  RSI:  RDI: 9897918e7400
[ 2976.918506] RBP: 9896dab74280 R08:  R09: b12492e0
[ 2976.923843] R10: 0003 R11:  R12: 9897918e7400
[ 2976.929141] R13: 1000 R14: 9897aa997010 R15: b8fd
[ 2976.934339] FS:  () GS:9897d7c0() 
knlGS:
[ 2976.939481] CS:  0010 DS:  ES:  CR0: 80050033
[ 2976.944570] CR2: 0008 CR3: 0001ff94a000 CR4: 06f0

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

Kernel: Linux 5.19.0-13797-ge091ba5cf827 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8) 

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Package: linux-image-5.19.0-13930-g7ebfc85e2cd7
Version: 5.19.0-13930-g7ebfc85e2cd7-23
Followup-For: Bug #1025537

Ah, here we go! It just Oopsed again, on what is presumably the first 
commit introducing the issue.

I'm gonna try to buidthe previous commit and see if it's happy for a 
while.

[ 2047.224083] Oops:  [#1] PREEMPT SMP NOPTI
[ 2047.228190] CPU: 1 PID: 1987 Comm: nfsd Not tainted 
5.19.0-13930-g7ebfc85e2cd7 #23
[ 2047.232427] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013
[ 2047.236740] RIP: 0010:kernel_sendpage+0x1d/0x120
[ 2047.241021] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 
48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 
08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80
[ 2047.250067] RSP: 0018:b12541e2fdc0 EFLAGS: 00010282
[ 2047.254722] RAX: 86733e60 RBX: 88f681d5b740 RCX: 1000
[ 2047.259428] RDX:  RSI:  RDI: 88f681d5b740
[ 2047.264219] RBP: 88f7aede4280 R08:  R09: 860491b0
[ 2047.268977] R10:  R11: 88f785ed0900 R12: 88f681d5b740
[ 2047.273716] R13: 1000 R14: 88f8645ed010 R15: 181e
[ 2047.278481] FS:  () GS:88f897c8() 
knlGS:
[ 2047.283269] CS:  0010 DS:  ES:  CR0: 80050033
[ 2047.288017] CR2: 0008 CR3: 000160e42000 CR4: 06e0
[ 2047.292772] Call Trace:
[ 2047.297454]  
[ 2047.302061]  ? sock_sendmsg+0x58/0x70
[ 2047.306715]  svc_tcp_sendmsg+0x121/0x180 [sunrpc]
[ 2047.311515]  ? nfsd_shutdown_threads+0x90/0x90 [nfsd]
[ 2047.316291]  svc_tcp_sendto+0x90/0x190 [sunrpc]
[ 2047.321083]  svc_send+0x4d/0x160 [sunrpc]
[ 2047.325811]  nfsd+0xd5/0x190 [nfsd]
[ 2047.330486]  kthread+0xe9/0x110
[ 2047.334999]  ? kthread_complete_and_exit+0x20/0x20
[ 2047.339497]  ret_from_fork+0x22/0x30
[ 2047.343930]  
[ 2047.348280] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo 
br_netfilter bridge stp llc overlay cmac algif_hash ecb algif_skcipher af_alg 
bnep tls ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE nf_nat 
xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu 
gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 
tveeprom altera_ci cx2341x btusb tda18271 btrtl snd_pcm btbcm snd_timer btintel 
snd btmtk soundcore bluetooth altera_stapl rfkill videobuf2_dvb 
jitterentropy_rng sha512_ssse3 isofs videobuf2_dma_sg radeon cdrom 
sha512_generic videobuf2_memops ctr m88ds3103 amd64_edac edac_mce_amd drbg 
i2c_algo_bit i2c_mux cp210x ansi_cprng drm_ttm_helper dvb_core joydev kvm_amd 
videobuf2_v4l2 ttm videobuf2_common drm_display_helper usbserial ccp evdev 
rng_core drm_kms_helper videodev ecdh_generic cec mc kvm ecc rc_core irqbypass 
xfs pcspkr sp5100_tco
[ 2047.348518]  k10temp sg watchdog button acpi_cpufreq w83795 jc42 tun loop 
msr nfsd parport_pc ppdev auth_rpcgss lp nfs_acl lockd parport grace sunrpc 
efi_pstore drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
btrfs blake2b_generic zstd_compress uas usb_storage raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic 
usbhid hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif 
crct10dif_generic crc64 crct10dif_common ahci libahci ohci_pci libata tg3 
ohci_hcd ptp ehci_pci ehci_hcd i2c_piix4 usbcore scsi_mod pps_core libphy 
scsi_common usb_common
[ 2047.421645] CR2: 0008
[ 2047.427434] ---[ end trace  ]---
[ 2047.433257] RIP: 0010:kernel_sendpage+0x1d/0x120
[ 2047.439046] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 
48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 
08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80
[ 2047.451057] RSP: 0018:b12541e2fdc0 EFLAGS: 00010282
[ 2047.457127] RAX: 86733e60 RBX: 88f681d5b740 RCX: 1000
[ 2047.463252] RDX:  RSI:  RDI: 88f681d5b740
[ 2047.469361] RBP: 88f7aede4280 R08:  R09: 860491b0
[ 2047.475419] R10:  R11: 88f785ed0900 R12: 88f681d5b740
[ 2047.481451] R13: 1000 R14: 88f8645ed010 R15: 181e
[ 2047.487369] FS:  () GS:88f897c8() 
knlGS:
[ 2047.493199] CS:  0010 DS:  ES:  CR0: 80050033
[ 2047.498970] CR2: 0008 CR3: 000160e42000 CR4: 06e0

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Package: linux-image-5.19.0-13930-g7ebfc85e2cd7
Version: 5.19.0-13930-g7ebfc85e2cd7-23
Followup-For: Bug #1025537

Ok, so the bisect got me down to commit 
7ebfc85e2cd7b08f518b526173e9a33b56b3913b 
(v6.0-rc1~28). This is unfortunate, as it is quite a large one [0].

A caveat to this report is that I'm not 100% sure my way of triggering 
the issue always worked. This commit OOPSed the first time round, but 
when it was found to be the first faulty commit at the end of the bisect 
pass (logs below), I could no longer trigger the bug on a newly rebuilt 
kernel off the same commit. I now realise that I didn't clean between 
builds, but I assume `make bindeb-pkg` would start from a fresh clean 
state.

This commit doesn't seem to directly touch NFS code, but does touch 
the networking state, so it is still a plausible suspect.

As per my previous message, the latest kernel also exhibit the issue. 
Worse so, it seems to even hang the kernel, which didn't seem to happen 
on earlier versions.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ebfc85e2cd7b08f518b526173e9a33b56b3913b

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

Kernel: Linux 5.19.0-13930-g7ebfc85e2cd7 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to 
en_AU.UTF8), LANGUAGE=en_AU:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- Bisect log:

git bisect start
# good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19
git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd
# good: [fcf22aefe87101424563a8dd8adec8a75b8c7576] Linux 5.19.11
git bisect good fcf22aefe87101424563a8dd8adec8a75b8c7576
# bad: [e60276b8c11ab4a8be23807bc67b048cfb937dfa] Linux 6.0.8
git bisect bad e60276b8c11ab4a8be23807bc67b048cfb937dfa
# good: [7c5c3a6177fa9646884114fc7f2e970b0bc50dc9] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 7c5c3a6177fa9646884114fc7f2e970b0bc50dc9
# bad: [5e2e7383b57fa03ec2b00c82bb7f49a4a707c1f7] Merge tag 'pinctrl-v6.0-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
git bisect bad 5e2e7383b57fa03ec2b00c82bb7f49a4a707c1f7
# bad: [83e4b196838d90799a8879e5054a3beecf9ed256] selftests: forwarding: add 
shebang for sch_red.sh
git bisect bad 83e4b196838d90799a8879e5054a3beecf9ed256
# bad: [d974730c8884cd784810b4f2fe903ac882a5fec9] Merge branch 
'net-lantiq_xrx200-fix-errors-under-memory-pressure'
git bisect bad d974730c8884cd784810b4f2fe903ac882a5fec9
# skip: [7a53e17accce9d310d2e522dfc701d8da7ccfa65] Merge tag 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
git bisect skip 7a53e17accce9d310d2e522dfc701d8da7ccfa65
# bad: [96f86ff08332d88defd35c330fc6dae219b9e264] Merge tag 
'perf-tools-fixes-for-v6.0-2022-08-13' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
git bisect bad 96f86ff08332d88defd35c330fc6dae219b9e264
# bad: [e140f731f9807035e967c401198171f316744696] Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect bad e140f731f9807035e967c401198171f316744696
# bad: [6c833c0581f1c15db2e0344da19360cba75a3351] Merge tag 
'devicetree-fixes-for-6.0-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect bad 6c833c0581f1c15db2e0344da19360cba75a3351
# skip: [8b30b09317ec6fda5f36a428e9e331253b5c4739] dt-bindings: rtc: nuvoton: 
add NCT3018Y Real Time Clock
git bisect skip 8b30b09317ec6fda5f36a428e9e331253b5c4739
# good: [668c3c237f5ddc2889879b08f26d2374231f3287] Merge tag 'sound-6.0-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 668c3c237f5ddc2889879b08f26d2374231f3287
# good: [a9e9c93966afdaae74a6a7533552391646b93f2c] Documentation/mm: add 
details about kmap_local_page() and preemption
git bisect good a9e9c93966afdaae74a6a7533552391646b93f2c
# good: [c235698355fa94df7073b51befda7d4be00a0e23] Merge tag 'cxl-for-6.0' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
git bisect good c235698355fa94df7073b51befda7d4be00a0e23
# bad: [7ebfc85e2cd7b08f518b526173e9a33b56b3913b] Merge tag 'net-6.0-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect bad 7ebfc85e2cd7b08f518b526173e9a33b56b3913b
# good: [786da5da5671c2d4cf812fe1ccc980bdde30c69e] Merge tag 
'ceph-for-5.20-rc1' of https://github.com/ceph/ceph-client
git bisect good 786da5da5671c2d4cf812fe1ccc980bdde30c69e
# good: [996237d9ba4d092469fbfca18995656c32834ac7] Merge branch 
'do-not-use-rt_tos-for-ipv6-flowlabel'
git bisect good 996237d9ba4d092469fbfca18995656c32834ac7
# good: [fbe8870f72e8e71bb57b883d29c600aaaca6cd20] Merge 
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
git bisect good fbe8870f72e8e71bb57b883d29c600aaaca6cd20
# good: [e091ba5cf82714c8691d978781696cd1fc2dec70] Merge tag 

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Package: src:linux
Followup-For: Bug #1025537

Confirming this still happens on the latest version of the kernel.

-- Package-specific info:
** Version:
Linux version 6.0.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9.1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64 
root=UUID=0c917590-acc7-464c-8961-64f79e1d1c69 ro init=/lib/systemd/systemd 
init=/lib/systemd/systemd

** Tainted: D (128)
 * kernel died recently, i.e. there was an OOPS or BUG

** Kernel log:

** Model information
[ 2046.604163]  __pagevec_release+0x1b/0x30
[ 2046.610505]  svc_xprt_release+0x1a3/0x1e0 [sunrpc]
[ 2046.617070]  svc_send+0x59/0x160 [sunrpc]
[ 2046.623473]  nfsd+0xd5/0x190 [nfsd]
[ 2046.629656]  kthread+0xe9/0x110
[ 2046.635602]  ? kthread_complete_and_exit+0x20/0x20
[ 2046.641456]  ret_from_fork+0x22/0x30
[ 2046.647159]  
[ 2046.652696] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo 
br_netfilter bridge stp llc overlay tls cmac algif_hash ecb algif_skcipher 
af_alg bnep ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE 
nf_nat xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink 
binfmt_misc amdgpu gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce 
ir_kbd_i2c cx23885 altera_ci tda18271 btusb altera_stapl btrtl btbcm m88ds3103 
btintel i2c_mux btmtk cx2341x bluetooth tveeprom videobuf2_dvb dvb_core 
jitterentropy_rng isofs videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 
sha512_ssse3 videobuf2_common sha512_generic amd64_edac videodev cdrom 
edac_mce_amd radeon ctr kvm_amd mc drbg snd_pcm ccp snd_timer ansi_cprng snd 
drm_display_helper rng_core cec ecdh_generic cp210x soundcore rc_core usbserial 
kvm drm_ttm_helper joydev evdev rfkill xfs ttm irqbypass ecc drm_kms_helper 
i2c_algo_bit pcspkr k10temp
[ 2046.652939]  sp5100_tco watchdog sg button acpi_cpufreq w83795 jc42 tun loop 
msr nfsd parport_pc ppdev lp auth_rpcgss nfs_acl parport lockd grace sunrpc drm 
efi_pstore fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
btrfs blake2b_generic zstd_compress uas usb_storage raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic 
usbhid hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif 
crct10dif_generic crc64 crct10dif_common ohci_pci ahci libahci tg3 libata 
ohci_hcd ehci_pci ehci_hcd usbcore i2c_piix4 libphy scsi_mod usb_common ptp 
pps_core scsi_common
[ 2046.733846] ---[ end trace  ]---
[ 2046.739371] RIP: 0010:release_pages+0xcd/0x500
[ 2046.744879] Code: 84 c0 74 1a 48 8b 04 24 48 8d 54 24 30 49 89 46 08 48 89 
44 24 30 4c 89 75 08 48 89 55 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 
08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e
[ 2046.756004] RSP: 0018:af7a811cfe30 EFLAGS: 00010206
[ 2046.761509] RAX: 0007 RBX: 8faf16948b78 RCX: eaa8c45c8608
[ 2046.767032] RDX: af7a811cfe60 RSI: af7a811cfe60 RDI: eaa8c45c8608
[ 2046.772518] RBP: 0017c000 R08: eaa8c4ba4988 R09: 00018bf0
[ 2046.777973] R10: 0003 R11:  R12: 
[ 2046.783387] R13:  R14: eaa8c4ba4988 R15: 8faf16948b28
[ 2046.788737] FS:  () GS:8fb017c8() 
knlGS:
[ 2046.794102] CS:  0010 DS:  ES:  CR0: 80050033
[ 2046.799361] CR2: 7f505ca0db28 CR3: 000108692000 CR4: 06e0
[ 2047.009929] stack segment:  [#7] PREEMPT SMP NOPTI
[ 2047.015823] CPU: 1 PID: 2244 Comm: nfsd Tainted: G  D
6.0.0-6-amd64 #1  Debian 6.0.12-1
[ 2047.021769] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013
[ 2047.027727] RIP: 0010:release_pages+0xcd/0x500
[ 2047.033679] Code: 84 c0 74 1a 48 8b 04 24 48 8d 54 24 30 49 89 46 08 48 89 
44 24 30 4c 89 75 08 48 89 55 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 
08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e
[ 2047.046097] RSP: 0018:af7a81133e30 EFLAGS: 00010206
[ 2047.052343] RAX: 0007 RBX: 8faf1685cb78 RCX: eaa8c45a3e08
[ 2047.058605] RDX: af7a81133e60 RSI: af7a81133e60 RDI: eaa8c45a3e08
[ 2047.064809] RBP: 0017c000 R08: eaa8c45cba48 R09: 0077
[ 2047.071008] R10: 2d40 R11:  R12: 
[ 2047.077241] R13:  R14: eaa8c45cba48 R15: 8faf1685cb28
[ 2047.083490] FS:  () GS:8fb017c8() 
knlGS:
[ 2047.089783] CS:  0010 DS:  ES:  CR0: 80050033
[ 2047.096089] CR2: 7f505ca0db28 CR3: 00016dafa000 CR4: 06e0
[ 2047.102466] Call Trace:
[ 2047.108808]  
[ 2047.115136]  ? nfsd_shutdown_threads+0x90/0x90 

Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)

[Chow Loong Jin]

On Wed, Dec 21, 2022 at 06:34:40PM +1300, Olly Betts wrote:
> On Wed, Dec 21, 2022 at 11:21:03AM +0800, Chow Loong Jin wrote:
> > I've fixed the segfault by applying the patch from [1], but there's one
> > issue remaining -- PrusaSlicer fails to initialize GLEW due to [2],
> > resulting in the plater screen not showing up, same as this SuperSlicer
> > issue[3].
> > 
> > I've also attempted to roll PrusaSlicer back to wxwidgets3.0
> 
> Please don't do that.  We're really close to eliminating wxwidgets3.0
> now, and we're not planning to include it in the bookworm release.
> 
> We're going to switch to --disable-glcanvasegl in wxwidgets3.2 which
> should solve the incompatibilities with GLEW which seem to be the
> problem here.  However that's an ABI breaking change affecting any
> packages using wxwidgets3.2's OpenGL APIs so it needs coordinating
> with the release team - Scott is currently working on that.

Alright, I'll leave the slic3r-prusa as-is then. I'm guessing that a
binNMU will take care of things when we get there.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1027046: webext-bulk-media-downloader: Does not download video

[avarner]

Package: webext-bulk-media-downloader
Version: 0.2.1-3.1
Severity: normal
X-Debbugs-Cc: debianreport...@avarner.org

Dear Maintainer,

This package advertises being able to download video, however it does not seem 
to download video, nor recognize when there is a video element on the page, nor 
show a list of m3u8 files loaded from a page.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

webext-bulk-media-downloader depends on no packages.

Versions of packages webext-bulk-media-downloader recommends:
ii  chromium 106.0.5249.119-1
ii  firefox-esr  102.3.0esr-1

webext-bulk-media-downloader suggests no packages.

-- no debconf information

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Mon, 26 Dec 2022 at 20:36, Patrick Franz  wrote:
>
> Hi,
>
> I agree that solution a) sounds like the better option, especially since
> we've gone this route with Qt 5.
>
> However, I will revisit this issue once we have transitioned 6.4 into
> unstable.

It's up to you, but the patch is straightforward and will not
introduce any problems with the transition.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Mon, 26 Dec 2022 at 20:07, Helmut Grohne  wrote:
[snip]
> In any case, I've attached a patch for it now. It is based on what we do
> for qt5.

Thanks!

> I caution though that selecting version 5 or 6 is kinda messed up. If
> you run qmake6 or -qmake6, it'll use qt6 as expected. If you
> run plain qmake, it'll go through qtchooser and select the relevant
> version via QT_SELECT. Howeve, -qmake is presently owned by
> qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
> we want "QT_SELECT=6 -qmake" to run the cross qt6 qmake, we'll
> also have to modify qtchooser and qt5-qmake.

We don't want to mix qtchooser and Qt 6. qtchooser is currently
deprecated and will disappear with Qt 5. It's not worth the effort to
remove it right now (I think). so the current behavior makes sense.

Thanks!




-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1025513: ITP: ubelt -- A Python utility library with a stdlib like feel and extra batteries. Paths, Progress, Dicts, Downloads, Caching, Hashing: ubelt makes it easy!

[Bo YU]

Control: block -1 by 1026966

Thanks,

Bug#1023312: Not fixed in 1.8.19-3

[Andreas Kloeckner]

Control: reopen 1023312

As far as I can tell, this is not fixed in 1.8.19-3.

# dpkg -l | grep ipmitool
ii  ipmitool 1.8.19-3   
   amd64utility for IPMI control with kernel driver or LAN 
interface (daemon)
# ipmitool sdr | head -1
IANA PEN registry open failed: No such file or directory

Andreas

-- 

Bug#1027045: shaderc: FTBFS everywhere

[Sebastian Ramacher]

Source: shaderc
Version: 2022.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

https://buildd.debian.org/status/fetch.php?pkg=shaderc=amd64=2022.2-1%2Bb2=1672017841=0

[ 28%] Building CXX object 
libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o
cd /<>/obj-x86_64-linux-gnu/libshaderc_util && /usr/bin/c++ 
-DENABLE_HLSL -I/<>/libshaderc_util/include -I/usr/include/glslang 
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wimplicit-fallthrough 
-Wextra-semi -Wall -Werror -fvisibility=hidden -fPIC -std=c++11 -std=gnu++11 
-MD -MT libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o -MF 
CMakeFiles/shaderc_util.dir/src/resources.cc.o.d -o 
CMakeFiles/shaderc_util.dir/src/resources.cc.o -c 
/<>/libshaderc_util/src/resources.cc
/<>/libshaderc_util/src/resources.cc:142:6: error: cannot convert 
‘’ to ‘int’ in initialization
  142 | }};
  |  ^
make[4]: *** [libshaderc_util/CMakeFiles/shaderc_util.dir/build.make:149: 
libshaderc_util/CMakeFiles/shaderc_util.dir/src/resources.cc.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[3]: *** [CMakeFiles/Makefile2:301: 
libshaderc_util/CMakeFiles/shaderc_util.dir/all] Error 2
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [Makefile:149: all] Error 2

Cheers
-- 
Sebastian Ramacher

Bug#1027044: transition: numpy 1.24.x

[Sandro Tosi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: nu...@packages.debian.org, mo...@debian.org
Control: affects -1 + src:numpy

Resuming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025788#43

In the meantime, since upstream released it, i've uploaded
numpy/1.24.0 to experimental and the autopkgtest results are
https://qa.debian.org/excuses.php?experimental=1=numpy

now, there's a lot of red in there but almost all of the errors come
in the format of

AttributeError: module 'numpy' has no attribute 'X'

with X being [float, int, bool, object, ...].

This is because, numpy upstream in 1.24.0, finally decided to expire
https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases
some deprecations introduced in 1.20.0
https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated
(released almost 2 years ago).

All of those are quite straightforward to fix, since often it's just
necessary to stop importing them from numpy and use the python native
types.

There are handful more errors in the form of:

  * ValueError: setting an array element with a sequence. The
requested array has an inhomogeneous shape after 1 dimensions. The
detected shape was (2,) + inhomogeneous part.
  * Too many indices for array: array is 0-dimensional, but 1 were indexed

which will need to be looked at in more details, likely by individual
projects upstream.

This additional transition seems to be comfortably in the reach for
Bullseye and will place us in a better position to get support from
upstream. I also anticipate that a few more patch releases (fixing
bugs etc) for the 1.24.x series will be published before Bullseye is
released and we would like to update numpy to them in Debian if
reasonable.

Please let me know if i can proceed with a numpy upload to unstable.


With ginggs' reply https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025788#48

Hi Sandro

I should have closed this bug once numpy 1:1.23.5-2 migrated.  Doing
so now.  Please file a new bug for discussing 1.24.0.

On Mon, 26 Dec 2022 at 00:12, Sandro Tosi  wrote:
> In the meantime, since upstream released it, i've uploaded
> numpy/1.24.0 to experimental and the autopkgtest results are
> https://qa.debian.org/excuses.php?experimental=1=numpy
>
> now, there's a lot of red in there but almost all of the errors come
> in the format of
>
> AttributeError: module 'numpy' has no attribute 'X'
>
> with X being [float, int, bool, object, ...].
>
> This is because, numpy upstream in 1.24.0, finally decided to expire
> https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases
> some deprecations introduced in 1.20.0
> https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated
> (released almost 2 years ago).
>
> All of those are quite straightforward to fix, since often it's just
> necessary to stop importing them from numpy and use the python native
> types.

That's a lot of breakage, but good that the fix is straightforward.

> There are handful more errors in the form of:
>
>   * ValueError: setting an array element with a sequence. The
> requested array has an inhomogeneous shape after 1 dimensions. The
> detected shape was (2,) + inhomogeneous part.
>   * Too many indices for array: array is 0-dimensional, but 1 were indexed
>
> which will need to be looked at in more details, likely by individual
> projects upstream.

The sooner these bugs are filed, the better.

> This additional transition seems to be comfortably in the reach for
> Bullseye and will place us in a better position to get support from
> upstream. I also anticipate that a few more patch releases (fixing
> bugs etc) for the 1.24.x series will be published before Bullseye is
> released and we would like to update numpy to them in Debian if
> reasonable.

s/Bullseye/bookworm but agreed.

> Please let me know if i can proceed with a numpy upload to unstable.

Please let's wait for a bit on this one.  There's still a matplotlib
transition in flight (#1026119) that needs bugs filed and autopkgtests
fixed before it can migrate.  Let's aim to do this once the initial
rebuilds for Python 3.11 as default (#1026825) have been done.  In the
meantime, it would help if bugs were filed against the packages that
need updating for numpy 1.24.x.

Bug#1019628: ruby-hashie: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: expected NoMethodError with "The property 'middle_name' is not defined for DashTest.", got #

[Antonio Terceiro]

Control: reassign -1 ruby-rspec-expectations
Control: retitle -1 ruby-rspec-expectations: raise_error() matcher does not 
work  with ruby3.1
Control: forwarded -1 https://github.com/rspec/rspec-expectations/issues/1338
Control: affects -1 src:ruby-hashie

On Sat, Nov 19, 2022 at 03:29:31PM +0200, Adrian Bunk wrote:
> Control: tags -1 fixed-upstream
[...]
> This seems to be fixed in 5.0.0.

It turns out this is a problem rspec-expectations on ruby3.1. The latest
upstream should fix this.


signature.asc
Description: PGP signature

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Patrick Franz]

Hi,

I agree that solution a) sounds like the better option, especially since 
we've gone this route with Qt 5.

However, I will revisit this issue once we have transitioned 6.4 into 
unstable.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1027043: libvncserver1: 0.9.13+dfsg-2+deb11u1 make x11vnc slow. 0.9.13+dfsg-2 works fine.

[Jay]

Package: libvncserver1
Version: 0.9.13+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I run x11vnc over a gigabit direct connection with:

x11vnc -usepw -ncache_cr -display :0 -loop -noxdamage -shared -nomodtweak -noshm

Upgrading to 0.9.13+dfsg-2+deb11u1 and then reconnecting my client caused 
x11vnc 
to run very slowly.  `*** fb_push ublen NOT ZERO: 3290940` appeared in the log 
very frequently.  From my logs, I had only seen this message once before, 10 
months ago.

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

Ineffective: reconnecting, restarting x11vnc, or rebooting

Effective: downgrading to 0.9.13+dfsg-2 and reconnecting

   * What was the outcome of this action?

reconnecting, restarting x11vnc, or rebooting: x11vnc remained sluggish and 
`fb_push ublen NOT ZERO` continued to appear

downgrading to 0.9.13+dfsg-2 and reconnecting: went back to a usable speed

   * What outcome did you expect instead?

I did not expect a minor update to change the speed of x11vnc.

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'stable'), (875, 'oldstable'), 
(800, 'oldoldstable'), (800, 'testing'), (700, 'oldoldstable'), (700, 
'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvncserver1 depends on:
ii  libc62.33-8
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5+deb11u2
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblzo2-22.10-2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

libvncserver1 recommends no packages.

libvncserver1 suggests no packages.

-- no debconf information

Bug#1027026: libllvm15: Packages depending on libllvm15:i386 fail to install because of version mistmatch

[Tobias Frost]

Control: block -1 by 1025530

On Mon, 26 Dec 2022 16:53:27 +0200 Kostadin Shishmanov  
wrote:
> Package: libllvm15
> Version: 1:15.0.6-3
> Severity: normal
> X-Debbugs-Cc: koce...@tutanota.com
> 
> Trying to install steam fails with "The following packages have unmet 
> dependencies:
>  libgl1-mesa-dri:i386 : Depends: libllvm15:i386 but it is not going to be 
>installed
> E: Unable to correct problems, you have held broken packages."
> 
> I think it happens because libllvm15:i386 is at version 15.0.6-3+b1, while 
> libllvm15:amd64 is at version 15.0.6-3
>

This is due to #1025530: on i386, the binNMU built and on all other archs 
(incl. amd64) it didn't…
Once that FTBFS is fixed, it will become coninstallable again.

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Helmut Grohne]

Control: tags -1 + patch

On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.

No, (a) does not require going through NEW. There already is qmake6-bin.
qmake6 and qmake6-bin even have the needed Multi-Arch values already.

> Last time you did the packaging with DMitry, so I'm kind of lost here.

Dmitry also expressed being in favour of (a). Notably missing is a
response from Patrick.

In any case, I've attached a patch for it now. It is based on what we do
for qt5.

I caution though that selecting version 5 or 6 is kinda messed up. If
you run qmake6 or -qmake6, it'll use qt6 as expected. If you
run plain qmake, it'll go through qtchooser and select the relevant
version via QT_SELECT. Howeve, -qmake is presently owned by
qt5-qmake only and will bypass qtchoser without honouring QT_SELECT. If
we want "QT_SELECT=6 -qmake" to run the cross qt6 qmake, we'll
also have to modify qtchooser and qt5-qmake.

Helmut
diff -Nru qt6-base-6.3.1+dfsg/debian/changelog 
qt6-base-6.3.1+dfsg/debian/changelog
--- qt6-base-6.3.1+dfsg/debian/changelog2022-10-01 18:58:47.0 
+0200
+++ qt6-base-6.3.1+dfsg/debian/changelog2022-12-26 22:56:51.0 
+0100
@@ -1,3 +1,10 @@
+qt6-base (6.3.1+dfsg-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install -qmake6 cross wrapper. (Closes: #1025663)
+
+ -- Helmut Grohne   Mon, 26 Dec 2022 22:56:51 +0100
+
 qt6-base (6.3.1+dfsg-10) unstable; urgency=medium
 
   [ Lisandro Damián Nicanor Pérez Meyer ]
diff -Nru qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in 
qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in
--- qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in   1970-01-01 
01:00:00.0 +0100
+++ qt6-base-6.3.1+dfsg/debian/qmake-cross-wrapper.in   2022-12-26 
22:56:51.0 +0100
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if [ "x$1" = x-qt6 ] || [ "x$1" = "x-qt=6" ] || [ "x$1" = "x-qt=qt6" ]; then
+   shift
+fi
+
+QMAKE_MODE=
+
+if [ "x$1" = x-query ]; then
+   exec /usr/lib/qt6/bin/qmake "$@" -qtconf 
/usr/lib/@DEB_HOST_MULTIARCH@/qt6/qt6.conf
+elif [ "x$1" = x-makefile ] || [ "x$1" = x-project ]; then
+   QMAKE_MODE="$1"
+   shift
+fi
+
+exec /usr/lib/qt6/bin/qmake6 \
+   $QMAKE_MODE \
+   -qtconf /usr/lib/@DEB_HOST_MULTIARCH@/qt6/qt6.conf \
+   -early \
+   QMAKE_CC=${CC:-@DEB_HOST_GNU_TYPE@-gcc} \
+   QMAKE_CXX=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
+   QMAKE_LINK=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
+   QMAKE_STRIP=${STRIP:-@DEB_HOST_GNU_TYPE@-strip} \
+   QMAKE_QMAKE=/usr/bin/@DEB_HOST_GNU_TYPE@-qmake6 \
+   PKG_CONFIG=@DEB_HOST_GNU_TYPE@-pkg-config \
+   -before \
+   "$@"
diff -Nru qt6-base-6.3.1+dfsg/debian/qmake6.install 
qt6-base-6.3.1+dfsg/debian/qmake6.install
--- qt6-base-6.3.1+dfsg/debian/qmake6.install   2022-04-22 19:50:08.0 
+0200
+++ qt6-base-6.3.1+dfsg/debian/qmake6.install   2022-12-26 22:56:45.0 
+0100
@@ -1,3 +1,4 @@
+usr/bin/*-qmake6
 usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++-64/qmake.conf
 usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++-64/qplatformdefs.h
 usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/aix-g++/qmake.conf
diff -Nru qt6-base-6.3.1+dfsg/debian/rules qt6-base-6.3.1+dfsg/debian/rules
--- qt6-base-6.3.1+dfsg/debian/rules2022-09-17 19:21:11.0 +0200
+++ qt6-base-6.3.1+dfsg/debian/rules2022-12-26 22:56:51.0 +0100
@@ -89,6 +89,12 @@
sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/' debian/qt.conf.in \
> debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/qt6/qt6.conf
 
+   mkdir -p debian/tmp/usr/bin
+   sed -e 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
+   -e 's/@DEB_HOST_GNU_TYPE@/$(DEB_HOST_GNU_TYPE)/g' \
+   < debian/qmake-cross-wrapper.in > 
debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-qmake6
+   chmod +x debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-qmake6
+
 override_dh_makeshlibs:
dh_makeshlibs -XlibQt6EglFSDeviceIntegration -XlibQt6EglFsKmsGbmSupport 
-XlibQt6EglFsKmsSupport -XlibQt6XcbQpa
 

Bug#1027042: RM: telepathy-ring -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove telepathy-ring. It's one of the last package still using
Python 2, there hasn't been a maintainer followup on #938644 since
2019 and https://git.merproject.org/mer-core/telepathy-ring is gone.

Bug#1026986: console-setup: "Dead" keys do not work for Greek keyboard layout in tty

[Samuel Thibault]

Hello,

Pavlos Gkesos, le dim. 25 déc. 2022 19:36:15 +0200, a ecrit:
> I remember this annoying issue, in all Debian based distros, at least for the 
> last 7 years.

Apparently it hasn't been reported for that much time, so... ;)

> Type KEY a (in Greek is the CHAR "α"). Two CHARs "'α" appear in tty - WRONG! 
> (This is not 'α but ά)

Oh, indeed, diacritics were completely broken with a newer perl version,
and broken in utf-8 mode. I have fixed it in version 1.213.

Samuel

Bug#1027041: linux-perf: perf version blank in sid, correct in bullseye

[наб]

Package: linux-perf
Version: 6.0.12-1
Severity: normal

Dear Maintainer,

On bullseye:
-- >8 --
$ /bin/perf version
perf version 5.10.158
-- >8 --
on sid:
-- >8 --
# perf version
perf version
-- >8 --

Ruh-roh!

Digging through the latest buildd log at
  
https://buildd.debian.org/status/fetch.php?pkg=linux=amd64=6.0.12-1=1670594526=1
I see:
-- >8 --
asciidoctor -b manpage -d manpage \
-a compat-mode -I. -rasciidoctor-extensions -a mansource="perf" -a 
manmanual="perf Manual" -a revdate=2022-12-09 -aperf_version= -o 
/<>/debian/build/build-tools/tools/perf/perf-annotate.1+ 
perf-annotate.txt && \

/bin/sh util/PERF-VERSION-GEN 
/<>/debian/build/build-tools/tools/perf/
cut: ../../PERF-VERSION-FILE: No such file or directory
  PERF_VERSION =
-- >8 --

Since I was already there for an unrelated #1017810 fix,
it appears that this had been fixed in
-- >8 --
commit 81935f10e694e390c7d23055952ebe0ac2173d1d
Author: Will Chandler 
Date:   Fri Sep 30 11:11:57 2022 -0400

perf tools: Fix empty version number when building outside of a git repo

When perf is built in a full source tree that is not a git repository,
e.g. from a kernel source tarball, `perf version` will print empty tag
and commit strings:

  $ perf version
  perf version

Currently the tag version is only generated from the root Makefile when
building in a git repository. If PERF-VERSION-FILE has not been
generated and the source tree is not in a git repository, then
PERF-VERSION-GEN will return an empty version.

The problem can be reproduced with the following steps:

  $ wget https://git.kernel.org/torvalds/t/linux-6.0-rc7.tar.gz
  $ tar -xf linux-6.0-rc7.tar.gz && cd linux-6.0-rc7
  $ make -C tools/perf
  $ tools/perf/perf -v
  perf version

Builds from tarballs generated with `make perf-tar-src-pkg` are not
impacted by this issue as PERF-VERSION-FILE is included in the archive.

The perf RPM provided by Fedora for 5.18+ is experiencing this problem.
Package build logs[0] show that the build is attempting to fall back on
PERF-VERSION-FILE, but it is not present.

To resolve this, revert back to the previous logic of using the kernel
Makefile version if not in a git repository and PERF-VERSION-FILE does
not exist.
-- >8 --

Which is apparently in v6.1-rc1; that, OTOH, cites commit
7572733b84997d23077ebd852703055034b7a1d2 ("perf tools: Fix version
 kernel tag"), first seen in v5.18-rc1, so the time-line works out.

This probably means this will be fixed, no intervention required,
by the 6.1 kernel. Please verify :)

Best,
наб

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

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

Versions of packages linux-perf depends on:
ii  libbabeltrace1   1.5.8-1+b3
ii  libc62.31-13+deb11u5
ii  libcap2  1:2.44-1
ii  libdw1   0.183-1
ii  libelf1  0.183-1
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libnuma1 2.0.12-1+b1
ii  libperl5.32  5.32.1-4+deb11u2
ii  libpython3.9 3.9.2-1
ii  libslang22.3.2-5
ii  libunwind8   1.3.2-2
ii  linux-perf-5.10  5.10.158-2
ii  perl 5.32.1-4+deb11u2
ii  python3  3.9.2-3
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

linux-perf recommends no packages.

Versions of packages linux-perf suggests:
pn  linux-doc-6.0  


signature.asc
Description: PGP signature

Bug#1024055: Upload MariaDB 1:10.3.37-0+deb10u1 ?

[Otto Kekäläinen]

On Mon, 5 Dec 2022 at 01:18, Utkarsh Gupta  wrote:
>
> Hi Otto,
>
> On Mon, Dec 5, 2022 at 5:33 AM Otto Kekäläinen  wrote:
> > I didn't get a reply to this, so asking again.
>
> I could take care of the upload but if you'd like to do that, please
> feel free to do so and I can take care of the paperwork. One quick
> thing I spotted in the target in d/ch is "buster". Could you please
> change that to "buster-security" instead?
>
> Let me know if you'd like to upload yourself or want me to take care
> of it. Thanks.

Sorry for the late reply, but 10.3.37 does not include any CVE tracked
security fixes (https://mariadb.com/kb/en/security/) so I guess it
does not warrant a buster-*security* upload. I will just leave it at
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster as
the base for importing 10.3.38 in January/February.

Bug#167629: Solution for Home/End Problem

[Colin Watson]

On Wed, Feb 23, 2005 at 12:02:41PM +, Colin Watson wrote:
> Going back to xterm compatibility and surveying the available
> LinuxFunctionKeys modes in pterm, "pterm.LinuxFunctionKeys: 5" (a.k.a.
> FUNKY_SCO) appears to match xterm's current behaviour for Home/End, but
> very little else; Insert/Delete/PageUp/PageDown match xterm in
> LinuxFunctionKeys modes 0 (FUNKY_TILDE), 1 (FUNKY_LINUX), 2
> (FUNKY_XTERM), and 4 (FUNKY_VT100P).
> 
> Here's a patch that makes pterm emit sequences that match current xterm
> in FUNKY_XTERM mode. If you don't want to apply it without making it
> configurable as well, would you mind if I applied this at least in
> Debian, so that we're in sync with the way other Debian terminal
> emulators behave?

I've been belatedly revisiting this bug today.  I've used
TERM=putty-256color as a workaround for this sort of thing for a long
time, but that has some other significant annoyances: I'm forever having
to set TERM=xterm-256color for various applications, and that's what
PuTTY's own documentation recommends, so I'd like to get back to it.
However, having Home and End not work in my editor (compare
https://github.com/neovim/neovim/issues/6014) is indescribably annoying.

This updated version of my patch from 2005 seems to work to align PuTTY
a bit more closely with "modern" xterm behaviour (r6 and onwards); but I
make no claim to having extensively vetted its compliance with the
official terminfo entries, as I'm afraid I find terminfo rather
impenetrable!

diff --git a/terminal/terminal.c b/terminal/terminal.c
index 584bd3e6..26759193 100644
--- a/terminal/terminal.c
+++ b/terminal/terminal.c
@@ -7617,6 +7617,10 @@ int format_small_keypad_key(char *buf, Terminal *term, 
SmallKeypadKey key,
 }
 } else if ((code == 1 || code == 4) && term->rxvt_homeend) {
 p += sprintf(p, code == 1 ? "\x1B[H" : "\x1BOw");
+} else if ((code == 1 || code == 4) &&
+   (term->funky_type == FUNKY_XTERM ||
+term->funky_type == FUNKY_XTERM_216)) {
+p += sprintf(p, code == 1 ? "\x1B[H" : "\x1B[F");
 } else {
 if (term->vt52_mode) {
p += sprintf(p, "\x1B[%d~", code);

Thanks,

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

Bug#1027040: lintian: lacks-unversioned-link-to-shared-library warning despite present linker script

[Sven Joachim]

Package: lintian
Version: 2.115.3
Severity: normal

I get these warnings in ncurses:

,
| W: libncurses6: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libncurses.so [lib/x86_64-linux-gnu/libncurses.so.6.3]
| W: libncursesw6: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libncursesw.so 
[lib/x86_64-linux-gnu/libncursesw.so.6.3]
`

These files usr/lib/x86_64-linux-gnu/libncurses{,w}.so actually exist in
libncurses-dev, but they are linker scripts rather than symlinks.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.161-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.39.50.20221224-1
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.13
ii  dpkg-dev1.21.13
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.13
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.58-3
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.4.0-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Timothy Pearson]

- Original Message -
> From: "Andres Salomon" 
> To: "Soren Stoutner" 
> Cc: 1020...@bugs.debian.org, "Dmitry Shachnev" , "Agustin 
> Martin" , "Debian
> Qt/KDE Maintainers" , "Roland 
> Rosenfeld" , "Rene Engelhard"
> , "Mattia Rizzolo" , "Debian Chromium 
> Team" ,
> "Timothy Pearson" 
> Sent: Monday, December 26, 2022 2:33:52 PM
> Subject: Re: Bug#1020387: dictionaries-common: Consensus regarding the 
> packaging of the Qt WebEngine hunspell binary
> dictionaries

> On Mon, Dec 26 2022 at 10:32:20 AM -0700, Soren Stoutner
>  wrote:
>> Dmitry
>> 
>> 
>> It hasn’t been discussed, but I think it would make sense for
>> Chromium to ship the convert_dict tool as it is the upstream for the
>> project.  I suppose the reason why the discussion was around how it
>> is shipped in the Qt packages was because that is the only place it
>> is currently shipped in Debian:
>> 
>> 
>> 
>> 
>> 
>> Andres, do you have an comments on the feasibility of shipping
>> convert_dict as part of a Chromium package targeted at developers?
>> 
>> 
> 
> 
> It's definitely feasible*. However, there's the question of whether we
> want other important packages depending on chromium.
> https://bugs.debian.org/1004441 shows that it's still an outstanding
> question whether chromium will even ship in bookworm. I now have Tim
> helping with packaging, which is wonderful and a huge help (thanks
> Tim!), but he doesn't have upload privs.

For what it's worth I'm interested in obtaining upload privileges to further 
assist, but I think I need a sponsor etc. for that process?

Thanks!

Bug#1027034: simple-scan: Too slow to find scanners.

[Jörg Frings-Fürst]

severity 1027034 normal
tags 1027034 + moreinfo
thanks



Hello Roger,

thank you for spending your time helping to make Debian better with
this bug report.


With the information provided, further processing of the bug is not
possible.


Please provide the following information:


- Which scanner do we use?

- How is the scanner connected?

- What does too long mean? Compared to which configuration?


Thank you.

CU 
Jörg



-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/


Am Montag, dem 26.12.2022 um 14:12 -0500 schrieb Roger:
> Package: simple-scan
> Version: 3.38.1-1
> Severity: important
> X-Debbugs-Cc: slow_sp...@att.net
> 
> The programmer states that this is an old version and so they cannot
> diagnose
> the problem.
> 
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> 
[...]



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

Bug#1027039: lintian: bogus lacks-unversioned-link-to-shared-library warnings in multilib packages

[Sven Joachim]

Package: lintian
Version: 2.115.3
Severity: normal

I get these warnings in ncurses' lib32* packages:

,
| W: lib32ncurses6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libform.so [usr/lib32/libform.so.6.3]
| W: lib32ncurses6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libmenu.so [usr/lib32/libmenu.so.6.3]
| W: lib32ncurses6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libncurses.so [lib32/libncurses.so.6.3]
| W: lib32ncurses6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libpanel.so [usr/lib32/libpanel.so.6.3]
| W: lib32ncursesw6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libformw.so [usr/lib32/libformw.so.6.3]
| W: lib32ncursesw6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libmenuw.so [usr/lib32/libmenuw.so.6.3]
| W: lib32ncursesw6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libncursesw.so [lib32/libncursesw.so.6.3]
| W: lib32ncursesw6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libpanelw.so [usr/lib32/libpanelw.so.6.3]
| W: lib32tinfo6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libtic.so [usr/lib32/libtic.so.6.3]
| W: lib32tinfo6: lacks-unversioned-link-to-shared-library example: 
usr/lib32/libtinfo.so [lib32/libtinfo.so.6.3]
`

All those symlinks exist in the lib32ncurses-dev package.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.161-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.39.50.20221224-1
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.13
ii  dpkg-dev1.21.13
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.13
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.58-3
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  

Bug#1026972: [L10N,CA] iso-codes: updated Catalan iso-3166-1 translation

[Dr. Tobias Quathamer]

control: tag -1 pending

Am 25.12.22 um 12:42 schrieb Holger Wansing:

attached is an updated translation into Catalan for iso-3166-1, provided by
Catalan d-i translator.

Please include it in your package.


Hi Holger,

done, thanks for submitting.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025423: [L10N,KK] iso-codes: updated Kazakh translation

[Dr. Tobias Quathamer]

control: tag -1 pending

Am 04.12.22 um 14:07 schrieb Holger Wansing:

attached is an updated translation into Kazakh for iso-3166-1, provided by
Baurzhan Muftakhidinov .

Please include it in your package.


Hi Holger,

done, thanks for submitting.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Dmitry Shachnev]

Hi Andres!

On Mon, Dec 26, 2022 at 03:33:52PM -0500, Andres Salomon wrote:
> It's definitely feasible*. However, there's the question of whether we want
> other important packages depending on chromium.
> https://bugs.debian.org/1004441 shows that it's still an outstanding
> question whether chromium will even ship in bookworm. I now have Tim helping
> with packaging, which is wonderful and a huge help (thanks Tim!), but he
> doesn't have upload privs. If I were to get hit by a bus (or more likely,
> hit by Responsibilities), he'd have to find someone else to sponsor his
> upload. Without his help, I'm not sure I'd want commit to the next 3 years
> of security support. So the question of other packages build-depending on
> convert_dict from chromium will involve the release team and what we decide
> to do for bookworm.

OK, it is a valid reason (although it's a bit weird that we can ship without
Chromium for security maintenance reasons, but at the same time ship with
Qt WebEngine which is usually not getting any security updates at all).

So, if the consensus is that we should ship convert-dict from the Qt side,
I propose to name the package and the executable in a generic way, without
the Qt word (e.g. /usr/bin/convert-dict). This way if the situation changes
in future, we will be able to transfer this binary package to the Chromium
team which is a better home for it.

Also, I am passing the ball to Patrick Franz, who is the Qt 6 maintainer
(unlike me, who mostly works on Qt 5). He may have his own objections, of
course.

If you agree with my naming suggestion, the needed thing will be to add a
symlink /usr/bin/convert-dict -> /usr/lib/qt6/libexec/qwebengine_convert_dict,
and then either rename qt6-webengine-dev-tools to convert-dict or make it
provide a virtual package (the latter won't require passing the NEW queue).

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1027038: QR code support

[Joey Hess]

Package: impass
Version: 0.12.2-1
Severity: wishlist

The "pass" password manager has a show QR code option, which makes it
easy to transfer a single password to a phone. On the phone, you just
copy and paste the password into whatever program. This is perfect for
me, since I don't want my phone to have access to all my passwords, but
do occasionally need one there.

Might it make sense to add a similar feature to impass? I'll leave that
to you. I tried to cobble something together from existing parts, and
the script below does a decent job. But a feature would make the idea
discoverable to users; I would not have thought of doing this if I had
not see the feature in "pass".

#!/bin/sh
buf="$(xsel)"
IMPASS_XPASTE=xclip impass gui
xsel -b | qr
echo "$buf" | xsel -i

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1024425: [Debian-med-packaging] Bug#1024425: help needed on pysam ftbfs with python3.11

[Graham Inggs]

Hi Étienne

On Fri, 23 Dec 2022 at 20:03, Étienne Mollier  wrote:
> Hmn, I'm dry on the python-pysam failure to build from source
> with python3.11, and upstream remained silent for now[1].  If I
> were dealing with C code, I would have suspected something like
> an uncaught segmentation fault, or uninitialized memory usage,
> but cython seems to be a slightly different beast, however
> similar it might sound.
>
> [1]: https://github.com/pysam-developers/pysam/issues/1151
>
> As far as I can tell, the purpose of the test is to check the
> behavior of an iterator once it ran out of values, to make sure
> ValueErrors can be sent to callers.  The test code seems to rely
> on the iterator to return NULL once out, or a memory address in
> a normal situation.  But according to the debugger, the address
> obtained is 0x1 (or 2^32), and for some reason, I don't
> even manage to get an ugly workaround checking for that value
> running as expected.
>
> so I formally request help on this one,

What about skipping this test for now?

I tried this, and it allowed at least the three reverse-dependencies I
tried (kinetic stools, python-pybedtools, umis) to build with Python
3.11.

Regards
Graham

Bug#1027037: backdoor-factory: Backdoor-factory isn't working after python3 transition

[Carlos Henrique Lima Melara]

Source: backdoor-factory
Version: 3.4.2+dfsg-5
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: charlesmel...@outlook.com

Dear Maintainers, hi.

I was working to get a new debian release of backdoor-factory (bdf) before the
freeze and noted while testing it that it doesn't work with python3.

I tested the application trying to patch a binary in 4 scenarios:

1. ELF binary - ssh with -fPIE compiler flag set (it
shouldn't work as warned in the man page);
2. ELF binary - devtodo without -fPIE flag set (I've built it locally
and disabled hardening option in d/rules);
3. PE binary - premake4.exe;
4. PE binary - PSTools from microsoft (the one actually show in the README 
example).

In all test scenarios, bdf showed a message saying the binary wasn't
compatible although they were in 3 out of 4 scenarios.

Digging a little deeper in the source code, I've found the problem.
Even though bdf was patched to build with python3, those changes only
fixed syntactic problems (mostly print statements). The actual problem -
and source of the bug - is the change on how files are read in python3.

In python2, everything read from a file was considered a string. But in
python3 it is considered a bitearray if the file was opened as a binary
('rb' option for example). In the source code of bdf, everything is treated
as strings (comparisons, assignments, operations, etc), but now everything
read from the binary file is a bytearray so the program fails to
identify it as a susceptible binary.

Even though it would be easy to patch this to make bdf correctly
identify the file, every step after that would also need to be fixed
(Right now, it basicaly fails to identify the files as susceptible and
exits). That would require a major rewrite of the program, together with
testing and debugging.

Cheers,
Charles

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

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

Bug#1027036: O: libiodbc2 -- iODBC Driver Manager

[Aurélien COUDERC]

Package: wnpp
Severity: normal
X-Debbugs-Cc: libiod...@packages.debian.org, Debian Qt/KDE Maintainers 

Control: affects -1 + src:libiodbc2

I intend to orphan the libiodbc2 package.

The package used to be required by the KDE stack but it’s not the case
anymore since a couple of releases and so the Qt/KDE Team hasn’t been
updating it.

The project is not dead upstream and has seen several new releases since
the last upstream version we packaged in 2014.


The package description is:
 The iODBC (intrinsic Open Database Connectivity) driver manager is compatible
 with the ODBC 2.x and 3.x specification and performs all the jobs of a
 ODBC driver manager (i.e. driver loading, parameters and function sequence
 checking, driver's function invoking, etc). Any ODBC driver working with
 ODBC 2.0 and 3.x driver manager will also work with iODBC driver manager
 and vice versa.
 .
 Applications (using ODBC function calls) linked with iODBC driver manager
 will be able to simultaneously access different types of data sources within
 one process through suitable iODBC drivers.
 .
 This package contains the library files. Look for the iodbc package, too!

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Andres Salomon]

On Mon, Dec 26 2022 at 10:32:20 AM -0700, Soren Stoutner 
 wrote:

Dmitry


It hasn’t been discussed, but I think it would make sense for 
Chromium to ship the convert_dict tool as it is the upstream for the 
project.  I suppose the reason why the discussion was around how it 
is shipped in the Qt packages was because that is the only place it 
is currently shipped in Debian:






Andres, do you have an comments on the feasibility of shipping 
convert_dict as part of a Chromium package targeted at developers?






It's definitely feasible*. However, there's the question of whether we 
want other important packages depending on chromium. 
https://bugs.debian.org/1004441 shows that it's still an outstanding 
question whether chromium will even ship in bookworm. I now have Tim 
helping with packaging, which is wonderful and a huge help (thanks 
Tim!), but he doesn't have upload privs. If I were to get hit by a bus 
(or more likely, hit by Responsibilities), he'd have to find 
someone else to sponsor his upload. Without his help, I'm not sure I'd 
want commit to the next 3 years of security support. So the question of 
other packages build-depending on convert_dict from chromium will 
involve the release team and what we decide to do for bookworm.



* for my own future reference:  ninja -j$(njobs) -C out/Release  
convert_dict;  install ./out/Release/convert_dict

Bug#1019599: w3m: CVE-2022-38223

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

Hi,

On Mon, Sep 12, 2022 at 10:35:41PM +0200, Moritz Mühlenhoff wrote:
> Source: w3m
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for w3m.
> 
> CVE-2022-38223[0]:
> | There is an out-of-bounds write in checkType located in etc.c in w3m
> | 0.5.3. It can be triggered by sending a crafted HTML file to the w3m
> | binary. It allows an attacker to cause Denial of Service or possibly
> | have unspecified other impact.
> 
> https://github.com/tats/w3m/issues/242
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2022-38223
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38223
> 
> Please adjust the affected versions in the BTS as needed.

Upstream has commited a fix as
https://github.com/tats/w3m/commit/419ca82d57c72242817b55e2eaa4cdbf6916e7fa
.

Regards,
Salvatore

Bug#1023483: systemd upgrade to 252-2 breaks suspend, suspend-then-hibernate

[Michael Biebl]

Version: 252.4-1

Am 26.12.22 um 19:56 schrieb Nicolas Peugnet:
If I am not mistaken this has been fixed in 252.4-1 (see 
 
and ).


Indeed. Thanks for catching this.
Marking as fixed for that version.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023530: nut: flaky autopkgtest: varying failures

[Laurent Bigonville]

On Sun, 6 Nov 2022 07:30:38 +0100 Paul Gevers  wrote:

> Dear maintainer(s),

Hello Paul

> I looked at the results of the autopkgtest of your package. I noticed
> that it regularly fails (after the fix for bug #1019221).
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

It's impossible for me to reproduce this locally, can you still see that 
in the CI runs?


For me this looks like a race condition, the test code already waits for 
2 sec after the start of the nut daemon an drivers to be certain that 
everything is properly started. I can increase that sleep, but that's 
probably not the best solution. An other solution is to have a loop 
checking that the (dummy) driver is really connected, but I need to 
investigate how and I've no time ATM.


Last solution could be to ask the release team to tag this bug as 
"bookworm-ignore" so it can be part of the upcoming release and try to 
fix this for the next one.


WDYT?

Kind regards,

Laurent Bigonville

Bug#1027006: Acknowledgement (hexchat: URL handling mechanism is broke under KDE)

[Felicia P]

Found the source of the issue with the gio command when running:

$ desktop-file-install --dir=$HOME/.local/share/applications 
.local/share/applications/firefox.desktop


value "\\$HOME/.local/firefox/firefox %u" for key "Exec" in group 
"Desktop Entry" contains a reserved character '$' outside of a quote


Adding quotes didn't help.  The solution was to hard-code my home 
directory in the Exec= line instead of using $HOME.  Then the gio 
command successfully runs:


$ gio mime x-scheme-handler/http firefox.desktop
Set firefox.desktop as the default for x-scheme-handler/http

$ gio mime x-scheme-handler/https firefox.desktop
Set firefox.desktop as the default for x-scheme-handler/https

$ gio mime x-scheme-handler/https
Default application for “x-scheme-handler/https”: firefox.desktop
Registered applications:
firefox.desktop
chromium.desktop
kfmclient_html.desktop
Recommended applications:
firefox.desktop
chromium.desktop
kfmclient_html.desktop


On 12/25/22 23:06, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

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

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

Your message has been sent to the package maintainer(s):
  Mattia Rizzolo 

If you wish to submit further information on this problem, please
send it to 1027...@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.

Bug#1025820: Bug: grub-pc 2.06-3~deb10u3 upgrade assumes /tmp is exec

[Steve McIntyre]

Control: reassign -1 debconf

Hi!

On Fri, Dec 09, 2022 at 03:54:34PM -0500, imschmeg wrote:
>Package: grub-pc
>Version: 2.06-3~deb10u3
>
>The error message during an "apt upgrade" that includes grub-pc is:
>
>open2: exec of /tmp/grub-pc.config.ajRf2i configure 2.06-3~deb10u2
>failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm
>line 59. 
>
>The problem is that apt upgrade assumes /tmp is mounted exec.  Common
>security practice is to mount /tmp noexec, which I do.
>
>Apt install scripts could instead be executed without being exec by
>passing them as a parameter to the shell command.
>
>Also, after the error, the apt upgrade finished instead of aborting,
>leaving my system in an unknown state.  I had to remount /tmp with exec
>and reinstall the grub packages.

This really isn't a grub bug - AFAICS what you're seeing here would
happen with any package that's doing upgrades and uses debconf for
configuration. I don't think this behaviour is necessarily a bug
personally, but I'm reassigning this to debconf...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Bug#1027035: libcpuset1: cpuset.3 references nonexistent bootcpuset.8, bootcpuset.conf.5

[Nick Black (Public gmail account)]

Package: libcpuset1
Version: 1.0-6+b1
Severity: minor
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

The cpuset.3 man page references bootcpuset.8 and bootcpuset.conf.5. Neither of
these man pages appear to exist in any package.


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

Kernel: Linux 6.1.0nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcpuset1 depends on:
ii  libbitmask1  2.0-5
ii  libc62.36-7

libcpuset1 recommends no packages.

libcpuset1 suggests no packages.

-- no debconf information

Bug#1025994: distributed-net: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[tony mancill]

On Mon, Dec 12, 2022 at 08:12:49PM -0300, Paulo Henrique de Lima Santana wrote:
> Package: distributed-net
> Tags: l10n patch
> Severity: wishlist
> 
> Hello,
> 
> Could you please update this Brazilian Portuguese translation?
> 
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and
> tested with msgfmt and podebconf-display-po.

Hi,

Thank you for the update.  I will prepare an upload for distributed-net
to include this translation.  

Do you know whether I should rename and update the pt.po -> pt_PT.po
currently shipped with the package, or is it sufficient to leave it
as-as?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1026741: python-xsdata: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.11 3.10" returned exit code 13

[s3v]

Control: forwarded -1 https://github.com/tefra/xsdata/commit/775be731
thanks

Dear Maintainer,
this is a bug in Python 3.11.1 that was fixed and backported to 3.11.2
(but not released yet).
Upstream skipped problematic test for the time being.

Kind Regards.

[1] 
https://github.com/python/cpython/commit/d4426c829565e3ef922c091ee9bd48bc556f2550
[2] https://docs.python.org/3/whatsnew/changelog.html#changelog [gh-100098]

Bug#980064: scalpel FTCBFS: combines CFLAGS into CC

[Eriberto Mota]

Hi guys,

Due an NMU sent to Debian without considering previous commits on
Salsa, I 'injected' this NMU in Salsa and I did cherry-picks to put
all unreleased commits in a position after this NMU. Consequently, the
fix for #980064 is now at:

https://salsa.debian.org/pkg-security-team/scalpel/-/commit/a760f0bd202e2c2164be2d4025964c98dd8aa1a5

Regards,

Eriberto

Bug#1027034: simple-scan: Too slow to find scanners.

[Roger]

Package: simple-scan
Version: 3.38.1-1
Severity: important
X-Debbugs-Cc: slow_sp...@att.net

The programmer states that this is an old version and so they cannot diagnose
the problem.


Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:

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

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

Versions of packages simple-scan depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.24-0+deb11u1
ii  dbus-x11 [dbus-session-bus]   1.12.24-0+deb11u1
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  libc6 2.31-13+deb11u5
ii  libcairo2 1.16.0-5
ii  libcolord21.4.5-3
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libgusb2  0.3.5-1
ii  libpackagekit-glib2-181.2.2-2
ii  libsane1  1.0.31-4.1
ii  libwebp6  0.6.1-2.1
ii  libwebpmux3   0.6.1-2.1
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

Bug#1023483: systemd upgrade to 252-2 breaks suspend, suspend-then-hibernate

[Nicolas Peugnet]

If I am not mistaken this has been fixed in 252.4-1 (see 
 
and ).


Although I haven't tested it myself yet.
--
Nicolas P.

Bug#1027033: transition: libsecp256k1

[Bastian Germann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

libsecp256k1 has a SONAME bump in 0.2.0-1 (experimental).
The only reverse dependency that needs a fix for the transition is electrum 
(already uploaded to experimental).
The other reverse dependencies bitcoin and ring FTBFS currently due to other 
issues.

Bug#1026948: schleuder: FTBFS with ruby-sinatra >= 3.0: ERROR: Test "ruby3.1" failed: NoMethodError:

[Antonio Terceiro]

Control: tag -1 + patch
Control: retitle -1 FTBFS with ruby-sinatra >= 3.0: gemspec has strict 
dependency on sinatra ~> 2

On Sat, Dec 24, 2022 at 12:50:51PM -0300, Antonio Terceiro wrote:
> Source: schleuder
> Version: 4.0.3-6
> Severity: important
> Justification: FTBFS
> Tags: sid ftbfs
> User: debian-r...@lists.debian.org
> Usertags: sinatra-3
> 
> Hi,
> 
> While trying rebuilds with src:ruby-sinatra 3.0.5-1, your package failed to
> build on amd64. Please try to support sinatra 3 as soon as possible, as we
> would like to have that version in bookworm.
> 
> Relevant part (hopefully):
> >   NoMethodError:
> > undefined method `first_plaintext_part' for nil:NilClass
> > 
> >   expect(mail.first_plaintext_part.decoded).to 
> > include("Refreshing all keys from the keyring of list #{list.email} 
> > resulted in this")
> >  ^
> >   # ./spec/schleuder/integration/cli_spec.rb:56:in `block (3 levels) in 
> > '
> >   # ./spec/spec_helper.rb:64:in `block (3 levels) in '
> >   # ./spec/spec_helper.rb:63:in `block (2 levels) in '
> > 
> > Finished in 3 minutes 13.9 seconds (files took 0.93149 seconds to load)
> > 543 examples, 18 failures
> > 
> > Failed examples:
> > 
> > rspec ./spec/schleuder/unit/list_spec.rb:512 # Schleuder::List#fetch_keys 
> > fetches one key by fingerprint
> > rspec ./spec/schleuder/unit/list_spec.rb:526 # Schleuder::List#fetch_keys 
> > fetches one key by URL
> > rspec ./spec/schleuder/unit/list_spec.rb:540 # Schleuder::List#fetch_keys 
> > fetches one key by email address
> > rspec ./spec/schleuder/unit/list_spec.rb:554 # Schleuder::List#fetch_keys 
> > does not import non-self-signatures
> > rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:212 # GPGME::Ctx#refresh_keys 
> > does not import non-self-signatures
> > rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:200 # GPGME::Ctx#refresh_keys 
> > reports errors from refreshing keys
> > rspec ./spec/schleuder/unit/gpgme_ctx_spec.rb:186 # GPGME::Ctx#refresh_keys 
> > updates keys from the keyserver
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1444 # user sends 
> > keyword x-fetch-key with fingerprint
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1516 # user sends 
> > keyword x-fetch-key without arguments
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1480 # user sends 
> > keyword x-fetch-key with fingerprint of unchanged key
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1330 # user sends 
> > keyword x-fetch-key with URL
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1408 # user sends 
> > keyword x-fetch-key with unknown fingerprint
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1294 # user sends 
> > keyword x-fetch-key with unknown email-address
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1258 # user sends 
> > keyword x-fetch-key with email address
> > rspec ./spec/schleuder/integration/keywords_spec.rb:1368 # user sends 
> > keyword x-fetch-key with invalid URL
> > rspec ./spec/schleuder/integration/cli_spec.rb:25 # cli #refresh_keys 
> > updates keys from the keyserver for only a specific list
> > rspec ./spec/schleuder/integration/cli_spec.rb:5 # cli #refresh_keys 
> > updates keys from the keyserver
> > rspec ./spec/schleuder/integration/cli_spec.rb:48 # cli #refresh_keys 
> > reports errors from refreshing keys
> > 
> > Randomized with seed 37252
> > 
> > /usr/bin/ruby3.1 
> > -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
> >  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> > --format documentation failed
> > ERROR: Test "ruby3.1" failed: 

Actually, all of those failures are related to an issue on my local
system. I had something else running on , so the test suite could
not start spec/sks-mock.rb.

The only blocker, really, to taking sinatra 3 is the dependency
declaration in the gemspec, which says sinatra ~> 2. If I replace that
~> with a >=, then everything just works (at least all the tests pass).

I'm making an upload with a patch relaxing this dependency.
From: Antonio Terceiro 
Date: Mon, 26 Dec 2022 15:20:34 -0300
Subject: gemspec: accept sinatra 3

All the tests pass, so it should be fine.
---
 schleuder.gemspec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/schleuder.gemspec b/schleuder.gemspec
index 277b5d2..c28e28f 100644
--- a/schleuder.gemspec
+++ b/schleuder.gemspec
@@ -32,8 +32,8 @@ Gem::Specification.new do |s|
   s.add_runtime_dependency 'mail', '~> 2.7.1'
   s.add_runtime_dependency 'mail-gpg', '~> 0.3'
   s.add_runtime_dependency 'rake', '>= 10.5.0'
-  s.add_runtime_dependency 'sinatra', '~> 2'
-  s.add_runtime_dependency 'sinatra-contrib', '~> 2'
+  s.add_runtime_dependency 'sinatra', '>= 2'
+  s.add_runtime_dependency 'sinatra-contrib', '>= 2'
   s.add_runtime_dependency 'sqlite3', '~> 1.4.2'
   s.add_runtime_dependency 

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El vie, 23 dic 2022 a las 17:21, Roland Rosenfeld
() escribió:
>
> Hi Agustin!
>
> > By the way, I have been playing with an old helper
> > (installdeb-myspell) shipped with dictionaries-common-dev to help with
> > these bdic files. First cut committed to salsa. Currently
> > installdeb-myspell will fail if no conversion tool is found.
>
> Just one question about this: Why did you add this code to
> installdeb-myspell and not to installdeb-hunspell?
> It's quite confusing that the .bdic file (used by hunspell) is
> generated by installdeb-myspell and not by installdeb-hunspell,
> especially since the former uses debian/info-myspell and the latter
> uses debian/info-hunspell (so I now need to have both of them...).

Hi, Roland,

I agree that this may sound strange and there is indeed no big reason
behind. Just did it because it was simpler and more straighforward to
reuse installdeb-myspell code and debian/info-myspell file format when
playing with this. Also, debian/info-hunspell is harder to handle from
e.g., lo-dicts while it should be easier to generate a temporary file
in debian/info-myspell file format from minimal info.

Regards

-- 
Agustin

Bug#1027032: hello: New upstream release 2.12.1

[Santiago Vila]

Package: src:hello
Version: 2.10-2
Severity: wishlist

This is to let everyone know that I'm aware that there
is a new hello (2.12.1) available here:

https://ftp.gnu.org/gnu/hello/

Bug#1027010: [Pkg-clamav-devel] Bug#1027010: libclamav9 0.103.7+dfsg-1+b2 leads to ERROR: Can't verify database integrity

[Joerg Dorchain]

On Mon, Dec 26, 2022 at 04:50:16PM +0100, Sebastian Andrzej Siewior wrote:
> On 2022-12-26 10:50:44 [+0100], Joerg Dorchain wrote:
> > the latest update to version 0.103.7+dfsg-1+b2 gives for me
> > ERROR: Can't verify database integrity
> > for clamav-daemon and clamav-freshclam
> > 
> > Downgrading to libclamav9 0.103.7+dfsg-1+b1 as a workaround
> > helps.
> 
> Just to be clear: You also updated the libtfm1 lib to 0.13.1-1? Because
> having both upgraded should work.

No:
dpkg-query -W|grep libtfm
libtfm1:amd64   0.13-4.1

I am following testing, https://tracker.debian.org/pkg/tomsfastmath says it 
will enter testing in three
days earliest.

I will install it from unstable manually. Thanks for the hint!

Feedback will take a bit, as feshclam retried the "failed" download after 5 
seconds, so within a minutes I was
banned from clamav updates for 2 days.

I would strongly recommend a libtfm1 >= 0.13.1 dependy in the new libclamav9 
package to prevent other people
from this experience.

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#1021204: ITP: whey -- A simple Python wheel builder for simple projects

[Nilson Silva]

Hello Bastian!
Clear. Thanks for the guidance.

As for this particular package, I was thinking of bundling it, but when I saw 
the amount of dependencies it needs, I gave up.
That's when Bo YU opened ITP. From there, I plucked up the courage, and I'm 
packaging its dependencies to see if Whey makes it into Debian.

I have several programs that I want to put in Debian, but it depends on it.



Nilson F. Silva



De: Bastian Germann 
Enviado: segunda-feira, 26 de dezembro de 2022 12:29
Para: 1021...@bugs.debian.org <1021...@bugs.debian.org>; Nilson Silva 

Assunto: Re: ITP: whey -- A simple Python wheel builder for simple projects

Control: block -1 by 1026975
Control: block -1 by 1026963
Control: block 1026963 by 1026835

Hi Nilson,

On Sun, 25 Dec 2022 16:11:21 + Nilson Silva  
wrote:
> dom-toml => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026975
>
> consolekit => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026963
>
> deprecation-alias=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026835

When you know of missing dependencies, please add them as block relationships 
between the ITPs or RFPs.
See this email's Control stanzas. That way a sponsor can easily get to the 
leafs of the dependency tree and sponsor them
first.

Bug#1026335: RFS: carl9170fw/1.9.9-427-gecb68a7-1 [ITP] -- firmware for AR9170 USB wireless adapters

[Bastian Germann]

The reason why I requested you to reopen the old RFS instead of filing a new 
one is
that you have not yet addressed all of pabs's comments:

On Wed, 05 Jan 2022 09:49:13 +0800 Paul Wise  wrote:
> Several files have missing/incorrect information in debian/copyright,
> please do a full audit of the code looking for copyright/license info.
>
>  * tools/include/list.h is LGPL
>  * tools/include/frame.h is partly from Linux, unknown copyright
>  * include/shared/eeprom.h also contains ISC code

Bug#1026975: ITP: python-toml -- library for parsing and creating TOML

[Nilson Silva]

Hi Alexandre!

I packaged this program, not knowing it was already in Debian.

But as it was a dependency of this package here:
https://github.com/domdfcoding/dom_toml<

I took advantage of the same itp, making the necessary corrections.

You can see that I already changed the title of the BUG python-dom-toml

Is there a specific situation you want to deal with?



Nilson F. Silva



De: Alexandre Rossi 
Enviado: segunda-feira, 26 de dezembro de 2022 14:36
Para: Josenilson Ferreira da Silva ; 
1026...@bugs.debian.org <1026...@bugs.debian.org>
Assunto: Re: Bug#1026975: ITP: python-toml -- library for parsing and creating 
TOML 
 


Le dim. 25 déc. 2022 à 09:11:29 -03:00:00, Josenilson Ferreira da 
Silva  a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Josenilson Ferreira da Silva 
> X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com
> 
> * Package name    : python-toml
>   Version : 0.10.2
>   Upstream Author : William Pearson 
> * URL : https://github.com/uiri/toml
> * License : MIT/expat
>   Programming Lang: Python
>   Description : library for parsing and creating TOML
> 
>   this package is a dependency for "dom-toml"
>   Where "dom-toml" is a required dependency for the "whey" package:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204


Already done?
https://packages.debian.org/sid/python3-toml

Alex

Bug#1027031: Upcoming test suite regression due to changes in file/libmagic

[Christoph Biedl]

Source: yara
Version: 4.2.3-1
Severity: important

Hello,

The last upload of file/libmagic (1:5.43-3), currently in experimental)
breaks the yara test suite:

==
==
   yara 4.2.3: ./test-suite.log
==

# TOTAL: 18
# PASS:  17
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-magic


tests/test-magic.c:24: rule does not match (but should)
FAIL test-magic (exit status: 1)
==

While I did not fully understand how that test works, I reckon it's
about how tests/data/ChipTune.efi is detected:

- MS-DOS executable PE32+ executable (EFI application) x86-64 (stripped to 
external PDB), for MS Windows
+ PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS 
Windows, 4 sections

This will break your package once I upload to unstable, something I want
to do in a week from now. In case you think file should see an
improvement here, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#993769: dgit: dpkg-source "duplicate files" error could be made more helpful

[Ian Jackson]

It is a shame that dpkg-source prints an unhelpful message, but so
many things with source packages are unhelpful...

I have added a new check for this in dgit, which I hope will detect
and report this situation, and do so before dgit has made the
situation worse by proliferating any erroneous origs.

The message looks like this:

  dgit: multiple representations of similar orig example_1.0.orig.tar:
example_1.0.orig.tar.xz: in .. 
(/home/ian/things/Dgit/dgit/tests/tmp/import-linkorigs/dupes)
example_1.0.orig.tar.gz: in build-products-dir 
(/home/ian/things/Dgit/dgit/tests/tmp/import-linkorigs/dupes/example/../bpd)

  dgit: error: Duplicate/inconsistent orig tarballs.  Delete the spurious ones.

This is currently in a local branch here.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1026975: ITP: python-toml -- library for parsing and creating TOML

[Alexandre Rossi]

Le dim. 25 déc. 2022 à 09:11:29 -03:00:00, Josenilson Ferreira da 
Silva  a écrit :

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-toml
  Version : 0.10.2
  Upstream Author : William Pearson 
* URL : https://github.com/uiri/toml
* License : MIT/expat
  Programming Lang: Python
  Description : library for parsing and creating TOML

  this package is a dependency for "dom-toml"
  Where "dom-toml" is a required dependency for the "whey" package:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204



Already done?
https://packages.debian.org/sid/python3-toml

Alex

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

Dmitry

It hasn’t been discussed, but I think it would make sense for Chromium to ship 
the 
convert_dict tool as it is the upstream for the project.  I suppose the reason 
why the 
discussion was around how it is shipped in the Qt packages was because that is 
the only 
place it is currently shipped in Debian:

https://packages.debian.org/search?
searchon=contents=convert_dict=path=testing=any[1]

Andres, do you have an comments on the feasibility of shipping convert_dict as 
part of a 
Chromium package targeted at developers?

Dmitry, can you also comment about adding a symlink from /usr/share/qt5/
qtwebengine_dictionaries to /usr/share/hunspell-dict as part of one of the 
libqt5webengine 
packages and from /usr/share/qt6/qtwebengine_dictionaries as part of one of the 
libqt6webengine packages?

There is some information about where Qt WebEngines search for these 
dictionaries at 
https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker[2]

On Monday, December 26, 2022 9:08:38 AM MST Dmitry Shachnev wrote:
> On Tue, Dec 13, 2022 at 10:43:06AM -0700, Soren Stoutner wrote:
> > Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of
> > either creating a meta package that depends on the most recent package
> > that includes qwebengine_convert_dict or creating an unversioned package
> > that installs qwebengine_convert_dict?  Also, either having
> > qwebengine_convert_dict being installed in an unversioned location or
> > having a symlink that is unversioned?  That would make it easier for
> > Hunspell language packages to build-depend on qwebengine_convert_dict and
> > wouldn’t require reworking all of those packages’ build scripts every time
> > the version of Qt in Debian changes.
> 
> I think we can do this, but why do you think such tool should be provided by
> Qt WebEngine, not by Chromium itself?
> 
> Chromium is the main upstream for convert_dict tool, while Qt WebEngine is
> one of several wrappers around it (e.g. another one is Electron). Also
> having it in Chromium will help to avoid the problem with versions, as
> there is always only one version of Chromium.
> 
> Source code for convert_dict is present in the Chromium tarball [1], so it
> shouldn't be hard to provide a new binary package for it.
> 
> (Maybe this was already discussed in the thread, but I did not read every
> message, please give me a link if it's the case.)
> 
> [1]:
> https://sources.debian.org/src/chromium/108.0.5359.124-1/chrome/tools/conve
> rt_dict/
> 
> --
> Dmitry Shachnev


-- 
Soren Stoutner
so...@stoutner.com



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

Bug#1027020: davmail-server: fails to install: insserv: script davmail-server: service davmail already provided!

[Alexandre Rossi]

Hi,

Thanks for your report.

> When trying to update davmail / install davmail-server I get:
>
>
> Setting up davmail-server (6.0.1.3390-3) ...
> insserv: script davmail-server: service davmail already provided!
> update-rc.d: error: no runlevel symlinks to modify, aborting!
> dpkg: error processing package davmail-server (--configure):
>  installed davmail-server package post-installation script subprocess 
> returned error exit status 1
[...]
> The reason seems to be that /etc/init.d/davmail is still around (and
> has "Provides. davmail")

Thanks for the pointer.

I'm tempted to do the following. Do you have an easy way to confirm it
works for you?
As the fix requires sysvinit, testing it will take me a bit more time.

Thanks,

Alex

--- a/debian/control
+++ b/debian/control
@@ -34,7 +34,7 @@ Package: davmail
 Architecture: all
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
- davmail-server,
+ davmail-server (= ${binary:Version}),
  default-jre,
  libswt-cairo-gtk-4-jni,
  libopenjfx-java,
diff --git a/debian/davmail-server.init b/debian/davmail-server.init
index eaa866c6..252141f2 100755
--- a/debian/davmail-server.init
+++ b/debian/davmail-server.init
@@ -1,6 +1,6 @@
 #! /bin/sh
 ### BEGIN INIT INFO
-# Provides:  davmail
+# Provides:  davmail-server
 # Required-Start:$local_fs $remote_fs
 # Required-Stop: $local_fs $remote_fs
 # Default-Start: 2 3 4 5

Bug#1020595: Tests FTBFS on arm64

[Bastian Germann]

Control: tags -1 pending

I have just uploaded this to NEW.

Bug#980555: Info received (update)

[Bartosz Fenski]

After reading this bugreport I'm not longer sure if this is the best idea ;)

https://bugzilla.redhat.com/show_bug.cgi?id=1943318

Sorry for the noise.

regards
Bartosz Fenski

Bug#1019665: ruby-safe-yaml: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: ArgumentError:

[Lucas Nussbaum]

On 17/12/22 at 14:51 +0100, Diederik de Haas wrote:
> On 13 Sep 2022 09:00:07 -0300 Antonio Terceiro  wrote:
> > Source: ruby-safe-yaml
> > Version: 1.0.5-2
> > Justification: FTBFS
> > Usertags: ruby3.1
> > 
> > We are about to start the ruby3.1 transition in unstable. While trying to
> > rebuild ruby-safe-yaml with ruby3.1 enabled, the build failed.
> > 
> > Relevant part of the build log (hopefully):
> > >   ArgumentError:
> > > wrong number of arguments (given 2, expected 1)
> > >   # ./lib/safe_yaml/load.rb:149:in `load'
> > >   # ./lib/safe_yaml.rb:29:in `safe_load'
> > >   # ./spec/safe_yaml_spec.rb:7:in `safe_load_round_trip'
> > >   # ./spec/safe_yaml_spec.rb:745:in `block (4 levels) in  > >   (required)>'
> > > 
> > > Finished in 0.08109 seconds (files took 0.12613 seconds to load)
> > > 134 examples, 20 failures
> > > 
> > > Failed examples:
> > > 
> > > rspec ./spec/safe_yaml_spec.rb:29 # Psych unsafe_load allows exploits 
> > > through objects defined in YAML w/ !ruby/hash via custom :[]= methods
> 
> There is an upstream PR: https://github.com/dtao/safe_yaml/pull/101
> which tried to address this, but someone who tried it still got errors.
> 
> Last upstream commit was from 2019-02-22 and there are several PRs open and 
> it 
> looks like the maintainer hasn't responded to any of them for > 5 YEARS

Since ruby-crack no longer depends on ruby-safe-yaml, ruby-safe-yaml
should probably just be removed from testing (and Debian)...

Lucas


signature.asc
Description: PGP signature

Bug#893083: hello: Packaging should be hosted on salsa.debian.org

[Santiago Vila]

El 26/12/22 a las 17:30, Raphael Hertzog escribió:

Hello,

On Fri, 23 Dec 2022, Santiago Vila wrote:

For example, this one:

I have just imported version 2.10-2. Now dpkg-buildpackage
does not work because it expects some timestamps to be the ones in the
orig.tar.gz where upstream maintainer already ran autoconf and friends.

I know that autoreconf may help here, but I would prefer not to be forced
to use it. What are my options?

Is there some git-buildpackage specific solution for this?


Yes, I think so. Use --git-export-dir=../build-area/ (many persons
have it in their ~/.gbp.conf).

$ cat ~/.gbp.conf
[DEFAULT]
pristine-tar = True
cleaner = /bin/true

[buildpackage]
sign-tags = True
export-dir = ../build-area/
ignore-branch = True
ignore-new = True

[import-orig]
filter-pristine-tar = True

[pq]
patch-numbers = False

[dch]
multimaint-merge = True
ignore-branch = True


Ok. For "hello" I will follow the trend and add whatever build-dependencies are 
required for
it to work in all cases, but I'm still interested in these kind of tricks just 
in case I need
them for other packages.

So, suppose that someone has a package requiring the above for "gbp 
buildpackage" to work.
Does the package have a disclaimer somewhere saying "plain dpkg-buildpackage is 
not supported
here" or something alike?

Thanks a lot.

Bug#1000618: summary + reducing severity

[Lucas Nussbaum]

Control: retitle -1 ruby-gtk2: crash if 'include Gtk' is done before require 
openssl
Control: severity -1 normal

Hi,

Summarizing the investigations (thanks!)

The root cause is this code in origami-pdf:

require 'gtk2'
include Gtk
require 'openssl'

this crashes with: superclass mismatch for class Socket (TypeError)

That's because the Gtk module has its own Socket class, which conficts
with the Socket from the standard library.

includ'ing Gtk is probably a bad idea. It would be better if origami-pdf
did not do it. However, a workaround exists, with:

require 'gtk2'
require 'openssl'
include Gtk

I don't think that this bug warrants severity:serious.

Lucas

Bug#1027030: RFS: runit/2.1.2-52 -- system-wide service supervision

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : runit
   Version  : 2.1.2-52
   Upstream contact : Gerrit Pape 
 * URL  : http://smarden.org/runit/
 * License  : CC0-1.0, BSD-3-clause, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/runit
   Section  : admin

The source builds the following binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  runit-systemd - transitional package for runit-systemd users
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-52.dsc

git repo:

  https://salsa.debian.org/debian/runit/-/tree/next

Changes since the last upload:

 runit (2.1.2-52) unstable; urgency=medium
 .
   * upload to unstable
   * run_sysv_scripts: remove test for name-daemon case
   * stage1: special case for alsa-utils initscript
   * bump Standards-Version, no changes required
   * shellcheck on cpsv, trigger_sv
   * cpsv:
- fix wrong (old) metafiles path for make_svlinks
- update also log/run with -f
- stop using a tmp dir
- exclude conf pattern with diff
- small optimizations
- update manpage

Regards,
Lorenzo Puliti

Bug#980555: update

[Bartosz Fenski]

Hello everyone,

Any chance to have ec_sys enabled in a near future?

I'm working on packaging https://github.com/nbfc-linux/nbfc-linux tool 
and while it supports various ways of accessing EC the ec_sys is 
preferred method.


regards
Bartosz Fenski

Bug#1027029: llvm-toolchain-13: FTBFS with grpc 1.51

[Sylvestre Ledru]

Le 26/12/2022 à 17:23, Sebastian Ramacher a écrit :

Source: llvm-toolchain-13
Version: 1:13.0.1-10
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-13=amd64=1%3A13.0.1-10%2Bb1=1671890995=0


yeah, I have a fix for this

I will do the upload in the next few days.

Cheers

S

Bug#1026392: transition: gnat-12

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/gnat-12.html

Hi Nicolas

On 2022-12-23 14:19:36 +0100, Nicolas Boulenguez wrote:
> > libgnatcoll-db succesfully built on mipsel in the meantime.
> 
> Yes, I have uploaded a fixed version.
> 
> > > - are removed from testing because of #1020018,
> > > - are updated in experimental, but now
> > >   fail to build on a supported architecture.
> > > I intend to
> > > - fill RC bugs against them in order to prevent their migration from
> > >   unstable to to testing.
> > Against libgmpada and libnatcoll-db or are there also others?
> 
> This only applies to libgmpada and bug #1026828.

Okay, then please go ahead with the transition.

> > > - reupload them from experimental to unstable with the other packages
> > >   as part of the transition
> > >   (so that the versions depending on gnat-11 disappear from unstable)
> > >   (and so that RC-buggy but mostly usable versions are available)
> > > - try to fix the issues after the transition is completed
> 
> > Given the upcoming freeze, I'd suggest fixing those as soon as possible.
> 
> I fear I don’t know what to do for libgmpada.  The build fails
> reproductibly on buildds but succeeds on the i386 porterbox.

Architecture-specific removal could be an option. In any case, if
libgmpada should be part of bookworm, it needs to migrate to testing
before the start of the soft freeze in February.

Cheers
-- 
Sebastian Ramacher

Bug#1021391: Possible solved with kernel 6.0.12

[Bernhard]

Hello all

It seems, with Kernel 6.0.12 this problem is solved.
This problem was never shown with kernel 6.0.12.

I'll have a further look for the next days.
After that, i'll close this bug.

Best regards and thank you for the great work.
Bernhard



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

Bug#893083: hello: Packaging should be hosted on salsa.debian.org

[Raphael Hertzog]

Hello,

On Fri, 23 Dec 2022, Santiago Vila wrote:
> For example, this one:
> 
> I have just imported version 2.10-2. Now dpkg-buildpackage
> does not work because it expects some timestamps to be the ones in the
> orig.tar.gz where upstream maintainer already ran autoconf and friends.
> 
> I know that autoreconf may help here, but I would prefer not to be forced
> to use it. What are my options?
>
> Is there some git-buildpackage specific solution for this?

Yes, I think so. Use --git-export-dir=../build-area/ (many persons
have it in their ~/.gbp.conf).

$ cat ~/.gbp.conf
[DEFAULT]
pristine-tar = True
cleaner = /bin/true

[buildpackage]
sign-tags = True
export-dir = ../build-area/
ignore-branch = True
ignore-new = True

[import-orig]
filter-pristine-tar = True

[pq]
patch-numbers = False

[dch]
multimaint-merge = True
ignore-branch = True


That way git-build-package will run the build in a fresh tree where
all the files will have the same timestamp.

> Related to the above: Is it acceptable/desirable to put a package in git when 
> it may not
> be compiled from git yet? Or maybe I should start the git history in a point 
> where such build
> from git is actually possible? Should I add a warning somewhere that only the 
> latest
> version is expected to work, or maybe that's already implicit?

It's certainly OK if the initial import does not work and if only the
latest version is really working. It would be surprising that the checkout
of the released tag does not work but it would not be a big deal either.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1027029: llvm-toolchain-13: FTBFS with grpc 1.51

[Sebastian Ramacher]

Source: llvm-toolchain-13
Version: 1:13.0.1-10
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-13=amd64=1%3A13.0.1-10%2Bb1=1671890995=0

[5383/7347] : && /<>/build-llvm/./bin/clang++ 
-fstack-protector-strong -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
-fdata-sections 
-ffile-prefix-map=/<>/build-llvm/tools/clang/stage2-bins=build-llvm/tools/clang/stage2-bins
 -ffile-prefix-map=/<>/= -no-canonical-prefixes -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG -g1 -Wl,-z,relro 
-Wl,--build-id -fuse-ld=gold-Wl,-O3 -Wl,--gc-sections 
tools/clang/tools/extra/clangd/index/remote/monitor/CMakeFiles/clangd-index-server-monitor.dir/Monitor.cpp.o
 -o bin/clangd-index-server-monitor  -Wl,-rpath,"\$ORIGIN/../lib"  
lib/libclangBasic.a  lib/libclangdSupport.a  lib/libMonitoringServiceProto.a  
lib/libRemoteIndexServiceProto.a  lib/libMonitoringServiceProto.a  
lib/libRemoteIndexProto.a  lib/libLLVM-13.so.1  
/usr/lib/x86_64-linux-gnu/libgrpc++.so  
/usr/lib/x86_64-linux-gnu/libprotobuf.so && :
FAILED: bin/clangd-index-server-monitor 
: && /<>/build-llvm/./bin/clang++ -fstack-protector-strong 
-Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
-fdata-sections 
-ffile-prefix-map=/<>/build-llvm/tools/clang/stage2-bins=build-llvm/tools/clang/stage2-bins
 -ffile-prefix-map=/<>/= -no-canonical-prefixes -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG -g1 -Wl,-z,relro 
-Wl,--build-id -fuse-ld=gold-Wl,-O3 -Wl,--gc-sections 
tools/clang/tools/extra/clangd/index/remote/monitor/CMakeFiles/clangd-index-server-monitor.dir/Monitor.cpp.o
 -o bin/clangd-index-server-monitor  -Wl,-rpath,"\$ORIGIN/../lib"  
lib/libclangBasic.a  lib/libclangdSupport.a  lib/libMonitoringServiceProto.a  
lib/libRemoteIndexServiceProto.a  lib/libMonitoringServiceProto.a  
lib/libRemoteIndexProto.a  lib/libLLVM-13.so.1  
/usr/lib/x86_64-linux-gnu/libgrpc++.so  
/usr/lib/x86_64-linux-gnu/libprotobuf.so && :
/usr/include/grpcpp/completion_queue.h:119: error: undefined reference to 
'absl::debian3::Mutex::~Mutex()'
/usr/include/grpcpp/completion_queue.h:119: error: undefined reference to 
'absl::debian3::Mutex::~Mutex()'
/usr/include/grpcpp/completion_queue.h:119: error: undefined reference to 
'absl::debian3::Mutex::~Mutex()'
/usr/include/grpcpp/impl/call_op_set.h:978: error: undefined reference to 
'gpr_log'
/usr/include/grpcpp/impl/call_op_set.h:978: error: undefined reference to 
'gpr_log'
/usr/include/grpcpp/impl/call_op_set.h:978: error: undefined reference to 
'gpr_log'
/usr/include/grpcpp/impl/call_op_set.h:978: error: undefined reference to 
'gpr_log'
clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)
[5384/7347] : && /usr/bin/cmake -E rm -f lib/libclangSema.a && 
/<>/build-llvm/bin/llvm-ar Dqc lib/libclangSema.a  
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/AnalysisBasedWarnings.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/CodeCompleteConsumer.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/DeclSpec.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/DelayedDiagnostic.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/IdentifierResolver.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/JumpDiagnostics.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/MultiplexExternalSemaSource.cpp.o
 tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/ParsedAttr.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Scope.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/ScopeInfo.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Sema.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaAccess.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaAttr.cpp.o 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaAvailability.cpp.o 

Bug#1027010: [Pkg-clamav-devel] Bug#1027010: libclamav9 0.103.7+dfsg-1+b2 leads to ERROR: Can't verify database integrity

[Sebastian Andrzej Siewior]

On 2022-12-26 10:50:44 [+0100], Joerg Dorchain wrote:
> the latest update to version 0.103.7+dfsg-1+b2 gives for me
> ERROR: Can't verify database integrity
> for clamav-daemon and clamav-freshclam
> 
> Downgrading to libclamav9 0.103.7+dfsg-1+b1 as a workaround
> helps.

Just to be clear: You also updated the libtfm1 lib to 0.13.1-1? Because
having both upgraded should work.

> Bye,
> 
> Joerg

Sebastian

Bug#1020435: ruby-prof: FTBFS on ppc64el

[Sebastian Ramacher]

Control: severity -1 serious

On 2022-09-25 14:06:09 -0300, Antonio Terceiro wrote:
> Control: tag -1 + unreproducible
> Control: severity -1 important
> 
> Hi,
> 
> On Wed, Sep 21, 2022 at 07:20:31PM +0200, Sebastian Ramacher wrote:
> > Source: ruby-prof
> > Version: 1.4.3-1
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > X-Debbugs-Cc: sramac...@debian.org
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=ruby-prof=ppc64el=1.4.3-1%2Bb1=1663720013=0
> > 
> >   1) Failure:
> > PrinterGraphTest#test_graph_results_sorting 
> > [/<>/test/printer_graph_test.rb:37]:
> > Array [0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 
> > 0.0, 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0] is not sorted.
> > --- expected
> > +++ actual
> > @@ -1 +1 @@
> > -[0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 0.0, 
> > 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0]
> > +[0.171, 0.171, 0.17, 0.17, 0.169, 0.169, 0.167, 0.167, 0.166, 0.164, 
> > 0.004, 0.004, 0.002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
> > 
> > 
> > 51 runs, 687 assertions, 1 failures, 0 errors, 0 skips
> > rake aborted!
> > Command failed with status (1): [ruby -w -I"test" 
> > /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
> >  "test/abstract_printer_test.rb" "test/alias_test.rb" "test/basic_test.rb" 
> > "test/call_tree_visitor_test.rb" "test/call_trees_test.rb" 
> > "test/duplicate_names_test.rb" "test/enumerable_test.rb" 
> > "test/exceptions_test.rb" "test/exclude_methods_test.rb" 
> > "test/exclude_threads_test.rb" "test/fiber_test.rb" "test/gc_test.rb" 
> > "test/line_number_test.rb" "test/marshal_test.rb" 
> > "test/multi_printer_test.rb" "test/no_method_class_test.rb" 
> > "test/printer_call_stack_test.rb" "test/printer_call_tree_test.rb" 
> > "test/printer_flat_test.rb" "test/printer_graph_html_test.rb" 
> > "test/printer_graph_test.rb" "test/printing_recursive_graph_test.rb" 
> > "test/profile_test.rb" "test/rack_test.rb" "test/singleton_test.rb" -v]
> > /usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in ` > (required)>'
> > Tasks: TOP => default
> > (See full trace by running task with --trace)
> > ERROR: Test "ruby3.0" failed. Exiting.
> 
> Unfortunately I could not reproduce this on the ppc64el porterbox, even
> trying the same random seed as the original build failure. I was
> suspecting an random test failure, but I didn't see this after trying 50
> builds in a row. In fact, just giving back the build on the buildd made
> it succeed. I'm not saying there is no issue, so I am keeping this open
> and maybe we will be able to figure it out at some point.
> 
> I hope you don't mind me downgrading this to important.

It's happening again. Reraising the severity to serious.

https://buildd.debian.org/status/fetch.php?pkg=ruby-prof=ppc64el=1.4.3-2%2Bb1=1671856091=0

Cheers
-- 
Sebastian Ramacher

Bug#1025779: onetbb: Please add patch to add support for ia64

[M. Zhou]

Control: tag -1 +moreinfo

I have tried exactly the same patch half a year ago,
which resulted a massive number of segmentation faults.
Build log can be found in our buildd.

See https://github.com/oneapi-src/oneTBB/issues/777

I'm not sure whether the latest assembly code in
https://github.com/oneapi-src/oneTBB/pull/983
would avoid those segfaults, so tagging this bug
with moreinfo.

Bug#1024614: Eric fails to start, crashes/shuts down after launch

[Gudjon I. Gudjonsson]

Hi

There has been some progress.

Qscintilla 2.13.3 is entering unstable.

Trove-classifiers is in the queue for entering Debian:
https://salsa.debian.org/python-team/packages/trove-classifiers

Eric7 is packaged on Salsa. Works but not ready for upload but will be as soon 
as Trove-classifiers enters Debian
https://salsa.debian.org/python-team/packages/eric

Please download, build and test.

Regards
Gudjon

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Dmitry Shachnev]

Hi all!

(And sorry for the late response. debian-qt-...@lists.debian.org is a
list for bots, so I didn't get it in my inbox. It's better to use
pkg-kde-t...@alioth-lists.debian.net or @packages.debian.org.)

On Tue, Dec 13, 2022 at 10:43:06AM -0700, Soren Stoutner wrote:
> Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of
> either creating a meta package that depends on the most recent package
> that includes qwebengine_convert_dict or creating an unversioned package
> that installs qwebengine_convert_dict?  Also, either having
> qwebengine_convert_dict being installed in an unversioned location or
> having a symlink that is unversioned?  That would make it easier for
> Hunspell language packages to build-depend on qwebengine_convert_dict and
> wouldn’t require reworking all of those packages’ build scripts every time
> the version of Qt in Debian changes.

I think we can do this, but why do you think such tool should be provided by
Qt WebEngine, not by Chromium itself?

Chromium is the main upstream for convert_dict tool, while Qt WebEngine is one
of several wrappers around it (e.g. another one is Electron). Also having it
in Chromium will help to avoid the problem with versions, as there is always
only one version of Chromium.

Source code for convert_dict is present in the Chromium tarball [1], so it
shouldn't be hard to provide a new binary package for it.

(Maybe this was already discussed in the thread, but I did not read every
message, please give me a link if it's the case.)

[1]: 
https://sources.debian.org/src/chromium/108.0.5359.124-1/chrome/tools/convert_dict/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1023830: widelands: FTBFS on s390x

[Tobias Frost]

Control: block -1 by 1027028

FWIIW, I've requested removal of widelands on s390x. Once this is done, this 
bug can be downgraded in severity.

-- 
tobi

Bug#1027028: RM: widelands [s390x] -- ROM; does not build on s390x

[Tobias Frost]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: widela...@packages.debian.org
Control: affects -1 + src:widelands

Widelands FTBFS on s390x due to an test failure. It built before, but the
new version is appearantly not working anymore…

It is unlikely that someone will play this game on a mainframe, so I request
to remove widelands from s390x, until someone(tm) sends a patch.

-- 
Cheers,
tobi

Bug#958989: dgit-user(7): building instructions don't work

[Ian Jackson]

Control: tags -1 moreinfo

Hi.  I was looking at this again, perhaps with a clearer head than
before.

You wrote:
> But this eventually fails with:
> 
> 
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -rfakeroot
> dpkg-buildpackage: info: source package valgrind
> dpkg-buildpackage: info: source version 1:3.15.0-2~1.gbpd4e99a
> dpkg-buildpackage: info: source distribution UNRELEASED
> dpkg-buildpackage: info: source changed by Nikolaus Rath 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  fakeroot debian/rules clean
> dh clean --with=autoreconf
>dh_clean
>  dpkg-source -b .
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
> tarball found at ../valgrind_3.15.0.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25

I don't think we should be trying to rebuild the source package at
this point.  Empirically, when invoked in a directory, sbuild runs
dpkg-source directly to build the source package, even before it
prints its banner line.  The source package ought not then to be
*re*built via dpkg-buildpackage.

The rune in dgit-user(7) is intended to cause the source package built
by sbuild's invocation of dpkg-source to be built as 1.0, to bypass
all of the things that can go wrong with `3.0 (quilt)`.  But the
example rune doesn't also have sbuild pass those options through
dpkg-buildpackage to the 2nd invocation of dpkg-source, becauwe it's
not expecting there to *be* a 2nd invocation.

In my test suite, where I test the rune out of the manpage, I see this
in the corresponding part of the sbuild logfile:

| dpkg-buildpackage
| -
| 
| Command: dpkg-buildpackage -us -uc -b -rfakeroot
| dpkg-buildpackage: info: source package example
| dpkg-buildpackage: info: source version 1.1-1
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Ian Jackson 

|  dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
|  fakeroot debian/rules clean
| EXAMPLE RULES TARGET clean
| ./clean-target-hook
| + test build-27ad867f-e55f-47bf-a551-48e756059a46
| dh_clean
| dh_clean: warning: Compatibility levels before 10 are deprecated (level 8 in 
use)
|  debian/rules build

Note the ddifference in dpkg-buildpacakge invocations:
> Command: dpkg-buildpackage -us -uc -rfakeroot
| Command: dpkg-buildpackage -us -uc -b -rfakeroot

I don't seem to be able to find in this bug a complete sbuild logfile
from a repro of the original report, but:

RTFMing sbuild suggests that the "--source" option may be implicated -
especially, via the BUILD_SOURCE sbuild config variable.

Do you have this setting in your personal configuration ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1025955: librxtx-java: new upstream version 2.2.0

[tony mancill]

On Mon, Dec 12, 2022 at 08:23:00PM -0800, tony mancill wrote:
> On Mon, Dec 12, 2022 at 03:15:58PM +0100, Thomas Uhle wrote:
> > Package: librxtx-java
> > Version: 2.2pre2+dfsg1-2
> > Severity: normal
> > 
> > Dear maintainers,
> > 
> > according to Github [1] and Maven [2], there is finally a new release
> > upstream after so many years.  Could you please update librxtx-java to the
> > current version before the bookworm freeze.
> 
> Hi Thomas,
> 
> Thanks for the pointer.  I have the package building and can upload once
> all of the r-deps build successfully.

I have built jtharness -> jtreg6 -> openjdk-17 against rxtx 2.2.0+dfsg-2
and don't see any (obvious) regressions.  The test results for
openjdk-17 look the same or better than the build without the update,
and are very similar to the results from the autobuilders.

I will upload later soon.


signature.asc
Description: PGP signature

Bug#1025691: atril: Segfault when opening a copy of a PDF document with annotations

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this issue by these steps:


- installed a minimal test VM with `apt install systemd-coredump mc xdm 
xserver-xorg jwm xterm atril latexmk texlive-latex-extra gdb 
libatrilview3-dbgsym libgtk-3-0-dbgsym libglib2.0-0-dbgsym atril-dbgsym`
- created the PDF by `latexmk -pdf test.latex`
- open atril
- open PDF
- switch the sidebar from "Thumbnail" to "Annotations"
- create a annotation
- save the PDF
- closed atril
- opened atril
- opened the saved PDF
- then "Open a Copy" crashed it


This crashed here:

https://sources.debian.org/src/atril/1.26.0-2/libview/ev-view.c/#L2694

2691child = ev_view_get_window_child (view, window);
2692gdk_window_get_origin (gtk_widget_get_window (GTK_WIDGET (view)),
2693   _x, _y);
2694if (root_x != child->parent_x || root_y != child->parent_y) {
2695gint dest_x, dest_y;

(gdb) bt full 4
#0  ev_view_window_child_move_with_parent (view=0x5637f6058560, 
window=0x5637f61ac330) at ./libview/ev-view.c:2694
child = 0x0
root_x = 613
root_y = 107
#1  0x7f5e6bdfbd9b in show_annotation_windows (page=0, view=0x5637f6058560) 
at ./libview/ev-view.c:2920
...
(rr) print view->window_children
$2 = 0x0


The variable child still contains a null here, looks like because
view->window_children is also a null.

Unfortunately found no matching upstream entry in [1].

Kind regards,
Bernhard



[1] https://github.com/mate-desktop/atril/issues

(gdb) bt
#0  ev_view_window_child_move_with_parent (view=0x5637f6058560, 
window=0x5637f61ac330) at ./libview/ev-view.c:2694
#1  0x7f5e6bdfbd9b in show_annotation_windows (page=0, view=0x5637f6058560) 
at ./libview/ev-view.c:2920
#2  ev_view_draw (widget=0x5637f6058560, cr=0x5637f6066c00) at 
./libview/ev-view.c:4078
#3  0x7f5e6b56efdc in gtk_widget_draw_internal 
(widget=widget@entry=0x5637f6058560, cr=cr@entry=0x5637f6066c00, 
clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084
#4  0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f6058560, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854
#5  0x7f5e6b3212fd in gtk_container_draw (widget=, 
cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674
#6  0x7f5e6b497c5a in gtk_scrolled_window_render (gadget=, cr=0x5637f6066c00, 
x=, y=, width=, height=, 
data=0x0) at ../../../gtk/gtkscrolledwindow.c:2119
#7  0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f6309600, 
cr=0x5637f6066c00, x=1, y=1, width=598, height=519) at 
../../../gtk/gtkcsscustomgadget.c:159
#8  0x7f5e6b32c627 in gtk_css_gadget_draw (gadget=0x5637f6309600, 
cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcssgadget.c:885
#9  0x7f5e6b49a60c in gtk_scrolled_window_draw (widget=0x5637f62bb460, 
cr=0x5637f6066c00) at ../../../gtk/gtkscrolledwindow.c:3050
#10 0x7f5e6b56efdc in gtk_widget_draw_internal 
(widget=widget@entry=0x5637f62bb460, cr=cr@entry=0x5637f6066c00, 
clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084
#11 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f62bb460, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854
#12 0x7f5e6b3212fd in gtk_container_draw (widget=, 
cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674
#13 0x7f5e6b56efdc in gtk_widget_draw_internal 
(widget=widget@entry=0x5637f63072a0, cr=cr@entry=0x5637f6066c00, 
clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084
#14 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f63072a0, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854
#15 0x7f5e6b3212fd in gtk_container_draw (widget=, 
cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674
#16 0x7f5e6b2cae96 in gtk_box_draw_contents (gadget=0x5637f6309400, cr=0x5637f6066c00, 
x=, y=, width=, height=, unused=0x0) at ../../../gtk/gtkbox.c:453
#17 0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f6309400, 
cr=0x5637f6066c00, x=0, y=0, width=600, height=521) at 
../../../gtk/gtkcsscustomgadget.c:159
#18 0x7f5e6b32c627 in gtk_css_gadget_draw (gadget=0x5637f6309400, 
cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcssgadget.c:885
#19 0x7f5e6b2cdb5c in gtk_box_draw (widget=0x5637f629fe30, 
cr=0x5637f6066c00) at ../../../gtk/gtkbox.c:462
#20 0x7f5e6b56efdc in gtk_widget_draw_internal 
(widget=widget@entry=0x5637f629fe30, cr=cr@entry=0x5637f6066c00, 
clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084
#21 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f629fe30, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854
#22 0x7f5e6b442ae1 in gtk_paned_render (gadget=, cr=0x5637f6066c00, x=, y=, width=, height=, data=0x0) at 
../../../gtk/gtkpaned.c:1832
#23 0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f62a4190, 
cr=0x5637f6066c00, x=0, y=0, width=600, height=521) at 
../../../gtk/gtkcsscustomgadget.c:159
#24 0x7f5e6b32c627 in 

Bug#1021204: ITP: whey -- A simple Python wheel builder for simple projects

[Bastian Germann]

Control: block -1 by 1026975
Control: block -1 by 1026963
Control: block 1026963 by 1026835

Hi Nilson,

On Sun, 25 Dec 2022 16:11:21 + Nilson Silva  
wrote:

dom-toml => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026975

consolekit => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026963

deprecation-alias=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026835


When you know of missing dependencies, please add them as block relationships 
between the ITPs or RFPs.
See this email's Control stanzas. That way a sponsor can easily get to the leafs of the dependency tree and sponsor them 
first.

Bug#1027022: RM: puppet-beaker/4.30.0-2

[Lucas Nussbaum]

On 26/12/22 at 15:30 +0100, Paul Gevers wrote:
> Hi Lucas,
> 
> On 26-12-2022 14:55, Lucas Nussbaum wrote:
> > Please remove puppet-beaker from testing.
> 
> Normally that's handled by requesting removal from unstable as removal there
> is synced to testing.
> 
> > It is orphaned, broken, outdated compared to upstream, and blocks the
> > migration of ruby-net-scp (that's how I ran into it)
> 
> Have you considered requesting removal from unstable? If not, why not?

I am mainly interested in restoring a clean state for ruby-net-scp
(which cannot migrate without an update of puppet-beaker in testing, or
a removal of puppet-beaker from testing).

Someone with more interest in puppet-beaker than I have might be able to
fix it, and then it could migrate again. So I'd rather keep it in
unstable for now.

> autoremoval will remove it on 10 January (under normal circumstances). Can
> we wait until then?

Yes, it can wait until Jan 10th (but then I need to remember to check
that ruby-net-scp migrates after Jan 10th).

Lucas

Bug#1027027: src:android-platform-build-kati: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: android-platform-build-kati
Version: 10.0.0+r32-6
Severity: serious
Control: close -1 10.0.0+r32+git20220314.09dfa26c4e59-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1023766

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:android-platform-build-kati has been 
trying to migrate for 61 days [2]. Hence, I am filing this bug. Your 
package is blocked by an autopkgtest regression that I reported in bug 
1023766.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=android-platform-build-kati



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027026: libllvm15: Packages depending on libllvm15:i386 fail to install because of version mistmatch

[Kostadin Shishmanov]

Package: libllvm15
Version: 1:15.0.6-3
Severity: normal
X-Debbugs-Cc: koce...@tutanota.com

Trying to install steam fails with "The following packages have unmet 
dependencies:
 libgl1-mesa-dri:i386 : Depends: libllvm15:i386 but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages."

I think it happens because libllvm15:i386 is at version 15.0.6-3+b1, while 
libllvm15:amd64 is at version 15.0.6-3

Output of `apt policy libllvm15:amd64 libllvm15:i386`

libllvm15:
  Installed: 1:15.0.6-3
  Candidate: 1:15.0.6-3
  Version table:
 *** 1:15.0.6-3 500
500 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
libllvm15:i386:
  Installed: (none)
  Candidate: 1:15.0.6-3+b1
  Version table:
 1:15.0.6-3+b1 500
500 https://deb.debian.org/debian testing/main i386 Packages


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

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

Versions of packages libllvm15 depends on:
ii  libc6   2.36-6
ii  libedit23.1-20221030-2
ii  libffi8 3.4.4-1
ii  libgcc-s1   12.2.0-10
ii  libstdc++6  12.2.0-10
ii  libtinfo6   6.3+20220423-2
ii  libxml2 2.9.14+dfsg-1.1+b2
ii  libz3-4 4.8.12-3
ii  zlib1g  1:1.2.13.dfsg-1

libllvm15 recommends no packages.

libllvm15 suggests no packages.

-- no debconf information

Bug#1027025: psi4: FTBFS with Python 3.11 as default version

[Graham Inggs]

Source: psi4
Version: 1:1.3.2+dfsg-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

Psi4 fails its build-time tests with Python 3.11 as the default
version, although the build doesn't fail outright, probably because of
the following in debian/rules:

override_dh_auto_test:
mkdir -p $(CURDIR)/builddir/tmp-scratch
-(cd builddir/tests; CTEST_OUTPUT_ON_FAILURE=TRUE ctest -L quicktests)

I've copied what I hope is the relevant part of the log below.

Regards
Graham


Traceback (most recent call last):
  File "/<>/builddir/stage/bin/psi4", line 177, in 
import psi4
  File "/<>/builddir/stage/lib/x86_64-linux-gnu/psi4/__init__.py",
line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized
module 'psi4' (most likely due to a circular import)
(/<>/builddir/stage/lib/x86_64-linux-gnu/psi4/__init__.py)
Exit Status: infile ( 1 ); autotest ( None ); sowreap ( None ); overall ( 1 )


0% tests passed, 143 tests failed out of 143

Bug#1027024: src:widelands: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: widelands
Version: 2:1.0-4
Severity: serious
Control: close -1 2:1.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1023830

Dear maintainer(s),

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


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=widelands



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027023: src:rdma-core: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: rdma-core
Version: 42.0-1
Severity: serious
Control: close -1 43.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1026088

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:rdma-core has been trying to migrate for 
63 days [2]. Hence, I am filing this bug. Your package is blocked by the 
ftbfs bug 1026088.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rdma-core



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027022: RM: puppet-beaker/4.30.0-2

[Paul Gevers]

Hi Lucas,

On 26-12-2022 14:55, Lucas Nussbaum wrote:

Please remove puppet-beaker from testing.


Normally that's handled by requesting removal from unstable as removal 
there is synced to testing.



It is orphaned, broken, outdated compared to upstream, and blocks the
migration of ruby-net-scp (that's how I ran into it)


Have you considered requesting removal from unstable? If not, why not? 
autoremoval will remove it on 10 January (under normal circumstances). 
Can we wait until then?


In other words, should this bug be reassigned to ftp.debian.org?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016737: Loop in POST when using --removable option in grub-install

[Pascal Hambourg]

I wrote:


I observe the same behaviour on my laptop.


And on another x86 desktop PC too. When loaded from the removable media 
path (/EFI/BOOT/BOOTX64.EFI), shim loads fbx64.efi which reboots the 
system if it did not find any BOOTX64.CSV file in /EFI/BOOT, as expected 
on removable media.


Here is the console output after setting FALLBACK_VERBOSE with

 mokutil --set-fallback-verbosity true

efi_main: System BootOrder not found.  Initializing defaults.
efi_main: tpm not present, starting the first image
Verbose enabled, sleeping for 50 mseconds... Press the Pause key now 
to hold for longer.

Reset System
Verbose enabled, sleeping for 50 mseconds... Press the Pause key now 
to hold for longer.



My workaround is to remove EFI/BOOT/fbx64.efi from the EFI partition.
IMO --removable should not install this file.


This is confirmed in the shim source package.

- In README.fallback:
When you boot removable media, it'll be in \EFI\BOOT , but fallback.efi
won't be there, so it goes ahead and boots the normal bootloader
(grubx64.efi).

- In shim.c:
/* Do not print the error here - this is an acceptable case
 * for removable media, where we genuinely don't want
 * fallback.efi to exist.

Also fbx64.efi is not present in the EFI partition of Debian 
installation images.

Bug#1019989: python-reportlab: diff for NMU version 3.6.11-1.1

[Jochen Sprickerhof]

Control: tags 1019989 + patch
Control: tags 1019989 + pending


Dear maintainer,

I've prepared an NMU for python-reportlab (versioned as 3.6.11-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-reportlab-3.6.11/debian/changelog python-reportlab-3.6.11/debian/changelog
--- python-reportlab-3.6.11/debian/changelog	2022-07-17 14:14:52.0 +0200
+++ python-reportlab-3.6.11/debian/changelog	2022-12-26 15:13:28.0 +0100
@@ -1,3 +1,10 @@
+python-reportlab (3.6.11-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix PYTHONPATH in d/rules to fix FTBFS (Closes: #1019989)
+
+ -- Jochen Sprickerhof   Mon, 26 Dec 2022 15:13:28 +0100
+
 python-reportlab (3.6.11-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-reportlab-3.6.11/debian/rules python-reportlab-3.6.11/debian/rules
--- python-reportlab-3.6.11/debian/rules	2022-03-10 19:14:33.0 +0100
+++ python-reportlab-3.6.11/debian/rules	2022-12-26 15:13:23.0 +0100
@@ -5,7 +5,7 @@
 
 # all versions
 PY3VERS	:= $(shell py3versions -vs)
-VER3	:= $(shell py3versions -vd)
+VER3	:= $(shell py3versions -vd | tr -d .)
 
 include /usr/share/python3/python.mk
 


signature.asc
Description: PGP signature

Bug#1027022: RM: puppet-beaker/4.30.0-2

[Lucas Nussbaum]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Please remove puppet-beaker from testing.

It is orphaned, broken, outdated compared to upstream, and blocks the
migration of ruby-net-scp (that's how I ran into it)

I tried updating it to the latest upstream version but failed.

Lucas

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Dmitry Shachnev]

Hi all,

as I was mentioned in this discussion...

On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
>
> Last time you did the packaging with DMitry, so I'm kind of lost here.

...I would also prefer if Qt 6 used a similar setup to Qt 5. This way the
transition from Qt 5 to Qt 6 would be more transparent for the reverse
dependencies. E.g. they will only need to replace ${DEB_HOST_GNU_TYPE}-qmake
with ${DEB_HOST_GNU_TYPE}-qmake6.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

As usual I'm a little bit behind this with emails, so I just saw this.

On Thu, 8 Dec 2022 at 08:48, Helmut Grohne  wrote:
[snip]
> I'd like to get some reply from Patrick before moving forward with this
> though. And it would be super awesome if this could be included in
> bookworm, so time isn't infinite here.

I would very much prefer (a). Now, as you said, timing is important
here. Do we need a pass through NEW? If that's the case then that will
need to happen after the next transition, if time allows it. If it can
be easily added to the existing packaging without the need of NEW then
we might add it right now.

Last time you did the packaging with DMitry, so I'm kind of lost here.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1027021: libp11: please add these DEP8 tests

[Andreas Hasenack]

Package: libp11
Version: 0.4.12-0.1
Severity: normal

Dear Maintainer,

please consider adding these DEP8 tests to the libp11 package.

https://salsa.debian.org/opensc-team/libp11/-/merge_requests/4

Thanks