Bug#1010700: lintian: Strange report of superfluous-file-pattern

[Helge Kreutzmann]

Hello Jakub,
On Sat, May 07, 2022 at 09:23:02PM +0200, Jakub Wilk wrote:
> * Helge Kreutzmann , 2022-05-07, 18:32:
> > Lintian claims:
> > W: goobox source: superfluous-file-pattern po/uk.po [debian/copyright:461]
> > 
> > However:
> > file po/uk.po
> > po/uk.po: GNU gettext message catalogue, Unicode text, UTF-8 text
> > 
> > grep uk.po debian/copyright
> > Files: po/uk.po
> > 
> > If lots of other po files which are accepted, why is po/uk.po any
> > different?
> 
> I think Lintian is confused because this file was added by a patch. It
> doesn't exist in .orig.tar.

Thanks. This could explain it, currently it is the only file added via
a patch.

Maybe you can add a sentence stating that this message can have some
false positives? (I saw this in other lintian warnings).

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1010715: linux-image-5.10.0-14-amd64: Kernel panic : not syncing: VFS: Unable to mount root fs on unknown block(0,0)

[Jeremy Davis]

Package: src:linux
Version: 5.10.113-1
Severity: important
X-Debbugs-Cc: jer...@turnkeylinux.org

Dear Maintainer,

Running Debian Bullseye (amd64) based system within VirtualBox 6.1 (Debian 
Bullseye host OS).

Reboot after installing latest kernel (linux-image-5.10.0-14-amd64=5.10.113-1) 
- results in kernel panic.
The kernel panic ends with the message:

Kernel panic : not syncing: VFS: Unable to mount root fs on unknown 
block(0,0)

Reboot into previous kernel (linux-image-5.10.0-13-amd64=5.10.106-1) results in 
normal boot.

If you need more info, please ask.



-- Assuming it may be storage related, here is more info about how it's set up:

root@lamp ~# fdisk -l

Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4dd8d2ff

Device Boot Start  End  Sectors Size Id Type
/dev/sda1  * 2048 16775167 16773120   8G 8e Linux LVM


Disk /dev/mapper/turnkey-root: 6.2 GiB, 6652166144 bytes, 12992512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/turnkey-swap_1: 1020 MiB, 1069547520 bytes, 2088960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

-- Boot is within the LVM:

root@lamp ~# df -h /boot
FilesystemSize  Used Avail Use% Mounted on
/dev/mapper/turnkey-root  6.1G  1.8G  4.0G  31% /


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

** Model information
sys_vendor: innotek GmbH
product_name: VirtualBox
product_version: 1.2
chassis_vendor: Oracle Corporation
chassis_version: 
bios_vendor: innotek GmbH
bios_version: VirtualBox
board_vendor: Oracle Corporation
board_name: VirtualBox
board_version: 1.2

** Network interface configuration:
*** /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
 hostname lamp

allow-hotplug eth1
iface eth1 inet dhcp
 hostname lamp

** PCI devices:
not available

** USB devices:
not available


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.10.0-14-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-14-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-14-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.04-20
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-14-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1010714: sane-pixma: sane can't find scanner

[Alexandre Lymberopoulos]

Package: libsane1
Version: 1.1.1-5
Severity: normal
File: sane-pixma

Dear Maintainer,

Any software here usanig sane can't detect my PIXMA MG3510 over
wireless network. For testing purposes I installed the proprietary
software from Canon and eveything woked ok.

I may provide any futher information upon request.

Best, Alexandre

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

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

Versions of packages libsane1:amd64 depends on:
ii  acl2.3.1-1
ii  adduser3.121
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.33-7
ii  libcairo2  1.16.0-5
ii  libcurl3-gnutls7.83.0-1
ii  libgcc-s1  12-20220428-1
ii  libglib2.0-0   2.72.1-1
ii  libgphoto2-6   2.5.27-1
ii  libgphoto2-port12  2.5.27-1
ii  libieee1284-3  0.2.11-14
ii  libjpeg62-turbo1:2.1.2-1
ii  libpng16-161.6.37-5
ii  libpoppler-glib8   22.02.0-3
ii  libsane-common 1.1.1-5
ii  libsnmp40  5.9.1+dfsg-1+b1
ii  libstdc++6 12-20220428-1
ii  libtiff5   4.3.0-7
ii  libusb-1.0-0   2:1.0.26-1
ii  libxml22.9.13+dfsg-1+b1
ii  udev   250.4-1

Versions of packages libsane1:amd64 recommends:
pn  ipp-usb   
pn  sane-airscan  
ii  sane-utils1.1.1-5

Versions of packages libsane1:amd64 suggests:
ii  avahi-daemon  0.8-5
ii  hplip 3.22.2+dfsg0-1

-- no debconf information

Bug#1010713: simple-scan: Scanner not detected

[Alexandre Lymberopoulos]

Package: simple-scan
Version: 42.0-1
Severity: normal

Dear Maintainer,

Not sure to who I should write, so I chose the toplevel software that
allowed me to notice the problem.

When I open simple-scan it can't detct my PIXMA MG-3510 scanner
anymore (it used to work). For testing purposes I installed the
proprietary software from Canon and it recognizes the device and scans
correctly.

I may provide any further information uopn request.

Best, Alexandre

-- Package-specific info:

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

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

Versions of packages simple-scan depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcolord21.4.6-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.1-1
ii  libgtk-3-03.24.33-1
ii  libgusb2  0.3.10-1
ii  libhandy-1-0  1.6.2-1
ii  libpackagekit-glib2-181.2.5-3
ii  libsane1  1.1.1-5
ii  libwebp7  1.2.2-2+b1
ii  libwebpmux3   1.2.2-2+b1
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.11.dfsg-4

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information
[+0.02s] DEBUG: simple-scan.vala:2015: Starting simple-scan 42.0, PID=6460
[+0.02s] DEBUG: unsetenv() is not thread-safe and should not be used after 
threads are created
[+0.13s] DEBUG: _g_io_module_get_default: Found default implementation gvfs 
(GDaemonVfs) for ‘gio-vfs’
[+0.21s] DEBUG: Trying to initialize portal
[+0.60s] DEBUG: _g_io_module_get_default: Found default implementation dconf 
(DConfSettingsBackend) for ‘gsettings-backend’
[+0.79s] DEBUG: app-window.vala:1975: Loading state from 
/home/lymber/.config/simple-scan/state
[+0.81s] DEBUG: app-window.vala:1954: Restoring window to 600x428 pixels
[+1.04s] DEBUG: scanner.vala:1620: sane_init () -> SANE_STATUS_GOOD
[+1.04s] DEBUG: scanner.vala:1626: SANE version 1.1.1
[+1.04s] DEBUG: scanner.vala:1687: Requesting redetection of scan devices
[+1.04s] DEBUG: scanner.vala:863: Processing request
[+1.20s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+10.73s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
[+10.74s] DEBUG: scanner.vala:1687: Requesting redetection of scan devices
[+10.74s] DEBUG: scanner.vala:863: Processing request
[+10.98s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+20.59s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
[+20.70s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+22.00s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+542.20s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+542.84s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+542.95s] DEBUG: scanner.vala:1687: Requesting redetection of scan devices
[+542.95s] DEBUG: scanner.vala:863: Processing request
[+543.06s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+549.60s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+552.58s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
[+552.90s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1432.55s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1433.46s] DEBUG: scanner.vala:1687: Requesting redetection of scan devices
[+1433.46s] DEBUG: scanner.vala:863: Processing request
[+1433.46s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1433.62s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1435.71s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1443.58s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
[+1443.90s] DEBUG: app-window.vala:2051: Saving state to 
/home/lymber/.config/simple-scan/state
[+1716.44s] DEBUG: app-window.vala:2051: Saving 

Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

[Thorsten Glaser]

Paul Gevers dixit:

> On 07-05-2022 10:53, Michael Tokarev wrote:

Huh, didn't get that message.

>> In this bugreport, I see it is/was broken with -machine pc-1.1.
>> There's no indication if it is broken with other machine types.  As
>> of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and
>> in 7.0 (current bookworm) they're removed.

This is rather bad, this will break existing VMs on upgrade
with almost certainly zero clues why.

> Do you agree with this assessment of the bug you reported? If so,
> let's tag this bug with buster and bullseye as indeed I conclude it's
> not a bug in bookworm then.

I'd rather consider this a second RC bug in bookworm, if so.

I'm currently in a really bad situation to look at anything in
detail (waiting for my brain to remember the luks password of
my work laptop), please excuse brevity.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Thorsten Glaser]

On Sat, 7 May 2022, Adam Borowski wrote:

> I've proposed this myself several years ago but it was then rejected.  IIRC
> one of the concerns raised was that eg. Postgresql tools do "unset LANG
> LC_ALL LC_CTYPE" to get the "C" locale.

File a bug against those then; POSIX explicitly states that if all
variables are empty the implementation-defined default locale is used,
and MirBSD, musl and, from what I heard, now also OpenBSD also default
to UTF-8-capable locales.

I don't recall where I read about this re. glibc; best to ask the
Debian packaging team whether there is talk.

I wouldn't hold my breath for it for now though and do it in sysvinit
for internal Debian consistency though.

bye,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

Bug#1010712: RFP: golang-github-xo-dburl -- URL style mechanism for parsing and opening SQL database connection strings

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Go Packaging Team , 
Shengjing Zhu 
Control: block 1010710 by -1

* Package name: golang-github-xo-dburl
  Version : 0.9.1
  Upstream Author : Kenneth Shaw
* URL : https://github.com/pierrec/cmdflag
* License : Expat
  Programming Lang: Go
  Description : URL style mechanism for parsing and opening SQL database 
connection strings

 Dburl provides a standard, URL style mechanism for parsing and opening SQL
 database connection strings for Go. It supports most SQL databases that have
 a publicly available Go driver.

This package is a dependency of golang-github-pierrec-cmdflag.

Bug#1010710: RFP: golang-github-pierrec-cmdflag -- augment the flag package with commands

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Go Packaging Team , 
Shengjing Zhu 

* Package name: golang-github-pierrec-cmdflag
  Version : 0.0.2
  Upstream Author : Pierre Curto
* URL : https://github.com/pierrec/cmdflag
* License : BSD-3-clause
  Programming Lang: Go
  Description : augment the flag package with commands

 Building on top of the excellent flag package from the standard library,
 cmdflag adds a simple way of specifying nested commands. It maintains
 compatibility with flag's idioms as it facilitates the augmentation of
 "flag" with commands.

This package is a dependency of golang-github-pierrec-lz4.v4

Bug#1010709: RM: ROM rust packages that are now virtual.

[Peter Michael Green]

Package: ftp.debian.org

There are a number of rust packages currently showing up in the cruft 
report that
are not being automatically removed because dak incorrectly belives that 
removing

them will cause broken dependencies and/or build-dependencies.

The dependencies are still satisfiable because they are satisfied by 
"Provides:"

entries in other packages.

Can you clean up these cruft packages?



* source package rust-gio version 0.14.8-1 no longer builds
binary package(s): librust-gio+dox-dev librust-gio+embed-lgpl-docs-dev 
librust-gio+subclassing-dev librust-gio+v2-44-dev 
librust-gio+v2-46-dev librust-gio+v2-48-dev librust-gio+v2-50-dev 
librust-gio+v2-52-dev librust-gio+v2-54-dev librust-gio+v2-56-dev 
librust-gio+v2-58-dev

on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by rust-gio)" -s 
unstable -a amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x 
-p -R -b librust-gio+dox-dev librust-gio+embed-lgpl-docs-dev 
librust-gio+subclassing-dev librust-gio+v2-44-dev 
librust-gio+v2-46-dev librust-gio+v2-48-dev librust-gio+v2-50-dev 
librust-gio+v2-52-dev librust-gio+v2-54-dev librust-gio+v2-56-dev 
librust-gio+v2-58-dev

- broken Build-Depends:
squeekboard: librust-gio+v2-58-dev

* source package rust-glib version 0.14.8-1 no longer builds
binary package(s): librust-glib+dox-dev librust-glib+v2-44-dev 
librust-glib+v2-46-dev librust-glib+v2-48-dev librust-glib+v2-50-dev 
librust-glib+v2-52-dev librust-glib+v2-54-dev librust-glib+v2-56-dev 
librust-glib+v2-58-dev

on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by rust-glib)" -s 
unstable -a amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x 
-p -R -b librust-glib+dox-dev librust-glib+v2-44-dev 
librust-glib+v2-46-dev librust-glib+v2-48-dev librust-glib+v2-50-dev 
librust-glib+v2-52-dev librust-glib+v2-54-dev librust-glib+v2-56-dev 
librust-glib+v2-58-dev

- broken Build-Depends:
squeekboard: librust-glib+v2-58-dev

* source package rust-gtk version 0.14.3-1 no longer builds
binary package(s): librust-gtk+dox-dev librust-gtk+embed-lgpl-docs-dev 
librust-gtk+fragile-dev librust-gtk+gtk-rs-lgpl-docs-dev 
librust-gtk+purge-lgpl-docs-dev librust-gtk+subclassing-dev 
librust-gtk+v3-16-dev librust-gtk+v3-18-dev librust-gtk+v3-20-dev 
librust-gtk+v3-22-20-dev librust-gtk+v3-22-26-dev 
librust-gtk+v3-22-27-dev librust-gtk+v3-22-29-dev 
librust-gtk+v3-22-30-dev librust-gtk+v3-22-dev librust-gtk+v3-24-dev

on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by rust-gtk)" -s 
unstable -a amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x 
-p -R -b librust-gtk+dox-dev librust-gtk+embed-lgpl-docs-dev 
librust-gtk+fragile-dev librust-gtk+gtk-rs-lgpl-docs-dev 
librust-gtk+purge-lgpl-docs-dev librust-gtk+subclassing-dev 
librust-gtk+v3-16-dev librust-gtk+v3-18-dev librust-gtk+v3-20-dev 
librust-gtk+v3-22-20-dev librust-gtk+v3-22-26-dev 
librust-gtk+v3-22-27-dev librust-gtk+v3-22-29-dev 
librust-gtk+v3-22-30-dev librust-gtk+v3-22-dev librust-gtk+v3-24-dev

- broken Build-Depends:
squeekboard: librust-gtk+v3-22-dev (>= 0.5)

* source package rust-lexical-core version 0.4.8-5 no longer builds
binary package(s): librust-lexical-core+correct-dev 
librust-lexical-core+stackvector-dev

on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by rust-lexical-core)" 
-s unstable -a 
amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x -p -R -b 
librust-lexical-core+correct-dev librust-lexical-core+stackvector-dev

- broken Depends:
rust-lexical-core: librust-lexical-core+default-dev

* source package rust-regex version 1.5.5-1 no longer builds
binary package(s): librust-regex+perf-cache-dev
on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by rust-regex)" -s 
unstable -a amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x 
-p -R -b librust-regex+perf-cache-dev

- broken Depends:
rust-regex: librust-regex+perf-dev

* source package rust-sequoia-openpgp version 1.8.0-1 no longer builds
binary package(s): librust-sequoia-openpgp+crypto-nettle-dev
on amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by 
rust-sequoia-openpgp)" -s unstable -a 
amd64,arm64,armel,armhf,i386,mips64el,mipsel,ppc64el,s390x -p -R -b 
librust-sequoia-openpgp+crypto-nettle-dev

- broken Depends:
rust-sequoia-openpgp: librust-sequoia-openpgp+default-dev

Bug#1010708: cryptsetup: init script doesn't appear to do anything with force-start due to masked systemd services

[Andres Salomon]

Package: cryptsetup
Version: 2:2.3.7-1+deb11u1


This is on a newly installed Debian 11 system, and an external USB
drive that had previously been used on a Debian 9 or 10 (I forget
which) system.


dilinger@hm90:~$ /sbin/blkid /dev/sda 
/dev/sda: UUID="2d95e6f9-bdfd-4045-8683-42cdef679b6a" TYPE="crypto_LUKS"

dilinger@hm90:~$ grep 2d95e6f9-bdfd-4045-8683-42cdef679b6a /etc/crypttab
8tb UUID=2d95e6f9-bdfd-4045-8683-42cdef679b6a none  luks,noauto
dilinger@hm90:~$ sudo /etc/init.d/cryptdisks force-start; echo $?
0


Calling the init script with 'force-start' was how I used to start the
volume and get prompted for a password, but on a newer system with
systemd, that doesn't _appear_ to work any more:


dilinger@hm90:~$ sudo bash -x /etc/init.d/cryptdisks force-start
+ set -e
+ '[' -r /lib/cryptsetup/cryptdisks-functions ']'
+ . /lib/cryptsetup/cryptdisks-functions
++ PATH=/usr/sbin:/usr/bin:/sbin:/bin
++ CRYPTDISKS_ENABLE=Yes
++ '[' -x /sbin/cryptsetup ']'
++ . /lib/lsb/init-functions
 run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+++ for hook in $(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 
2>/dev/null)
+++ '[' -r /lib/lsb/init-functions.d/00-verbose ']'
+++ . /lib/lsb/init-functions.d/00-verbose
+++ for hook in $(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 
2>/dev/null)
+++ '[' -r /lib/lsb/init-functions.d/40-systemd ']'
+++ . /lib/lsb/init-functions.d/40-systemd
 _use_systemctl=0
 '[' -d /run/systemd/system ']'
 '[' -n '' ']'
 '[' cryptdisks = init-d-script ']'
 '[' cryptdisks = force-start ']'
 executable=/etc/init.d/cryptdisks
 argument=force-start
 prog=cryptdisks
 service=cryptdisks.service
+ systemctl -p LoadState --value show cryptdisks.service
 state=masked
 '[' masked = masked ']'
 exit 0


It turns out that the systemd (247.3-7) package provides the
following:

dilinger@hm90:~/systemd_247.3-7$ ls -l /lib/systemd /system/cryptdisks*
lrwxrwxrwx 1 root root 9 Mar 20 15:55 
/lib/systemd/system/cryptdisks-early.service -> /dev/null
lrwxrwxrwx 1 root root 9 Mar 20 15:55 /lib/systemd/system/cryptdisks.service -> 
/dev/null


The init script doesn't say why it's refusing to run, and
running 'systemctl unmask cryptdisks.service' doesn't actually
delete the symlinks. Once those symlinks are manually deleted,
'/etc/init.d/cryptsetup force-start' works once again.

It would be good if /etc/init.d/cryptsetup either warned about the
masked systemd service, and/or the cryptsetup postinst scripts
deleted or prompted the user about the symlinks.

Unless /etc/init.d/cryptsetup force-start is deprecated, of course!
But README.Debian still describes using the init script.




dilinger@hm90:~$ dpkg -l cryptsetup*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture Description
+++--=-->
ii  cryptsetup   2:2.3.7-1+deb11u1 amd64disk encryption support 
- startup sc>
ii  cryptsetup-bin   2:2.3.7-1+deb11u1 amd64disk encryption support 
- command li>
un  cryptsetup-initramfs(no description 
available)
un  cryptsetup-run  (no description 
available)

Bug#1009797: apt: support "nodoc" build profile

[David Kalnischkies]

> Just to add a rather unrelated argument for the nodoc support in apt. apt is

For the record: I wrote nodoc and pkg.apt.nodoxygen support earlier last
month and have it finally proposed earlier today in a MR request…
https://salsa.debian.org/apt-team/apt/-/merge_requests/238

Another argument is actually that it helps our own CI tests: We do not
build the packages so far, but we build i386 and amd64 to run tests in
different setups (as root and as non-root) and building the docs twice
is kinda pointless, so now we don't do this anymore while also using
apts support for build-profiles to make cuts on setup costs as well.

So…

> Thanks, if it intrigues and inspires you, go for it, though I'd hate to
> send you too deep down that rabbit hole otherwise...

don't worry, I got a bit sidetracked and there could be done a lot more
(as always) but sometimes I enjoy digging myself into a hole even if
nobody really needs it… with three-ish (potential) "wouldn't it be nice"
users this feature set might even be in the upper bracket of usefulness
for things I did in these rabbit hole endeavours… ;P


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1010688: apparmor profile prevents -C -W

[Romain Francoise]

Duh, thanks for the report. Not sure how this was never found despite
the profile being included since 2017 and Debian having AppArmor
enabled by default since Debian 10 (for new installs). I'll fix this
in unstable but it may not qualify for a stable upload. I'll ask.

Bug#1010707: nheko crashes with “failed to retrieve joined groups: 400 Unrecognized request”

[Francesco Ariis]

Package: nheko
Version: 0.8.0+really0.7.2-4
Severity: important
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

nheko crashes with

[2022-05-07 22:16:29.558] [net] [critical] failed to retrieve joined 
groups: 400 Unrecognized request

a few minutes after connection. I attach `nheko-backtrace.dump`. Let me know
if you need further informations
—F



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

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

Versions of packages nheko depends on:
ii  libboost-iostreams1.74.0   1.74.0-9
ii  libboost-thread1.74.0  1.74.0-9
ii  libc6  2.31-13+deb11u3
ii  libcmark0.29.0 0.29.0-4
ii  libfmt77.1.3+ds1-5
ii  libgcc-s1  10.2.1-6
ii  liblmdb0   0.9.24-1
ii  libolm33.2.1~dfsg-7
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickwidgets55.15.2+dfsg-6
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libsodium231.0.18-1
ii  libspdlog1 [libspdlog1-fmt7]   1:1.8.1+ds-2.1
ii  libssl1.1  1.1.1n-0+deb11u1
ii  libstdc++6 10.2.1-6
ii  qml-module-qt-labs-settings5.15.2+dfsg-6
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtmultimedia5.15.2-3
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nheko recommends:
ii  ca-certificates 20210119
ii  fonts-noto-color-emoji  0~20200916-1

nheko suggests no packages.

-- no debconf information


nheko-backtrace.dump
Description: Binary data

Bug#1010706: E1187: Failed to source defaults.vim

[Frank Engler]

Package: vim-tiny
Version: 2:8.2.4793-1
Severity: normal
X-Debbugs-Cc: bts.to.frankeng...@spamgourmet.com

Dear Maintainer,

calling /usr/bin/editor, /usr/bin/vim.tiny or
/usr/bin/vi --clean I get the message

E1187: Failed to source defaults.vim
Press ENTER or type command to continue

If I start vim-tiny just with /usr/bin/vi, no error
is shown. /etc/vim/vimrc and /etc/vim/vimrc.tiny are
unchanged, the user does not have a .vimrc, no
defaults.vim could be found anywhere.

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.tiny
/usr/bin/editor is /usr/bin/vim.tiny

Versions of packages vim-tiny depends on:
ii  libacl1  2.3.1-1
ii  libc62.33-7
ii  libselinux1  3.3-1+b2
ii  libtinfo66.3+20220423-1
ii  vim-common   2:8.2.4793-1

vim-tiny recommends no packages.

Versions of packages vim-tiny suggests:
pn  indent  

Bug#1010698: stunnel4: debci testsuite fails after openssl version update.

[Sebastian Andrzej Siewior]

On 2022-05-07 20:52:41 [+0200], Paul Gevers wrote:
> Hi Sebastian,
Hi Paul,

> On 07-05-2022 18:22, Sebastian Andrzej Siewior wrote:
> > Usertags: flaky
> 
> Why do you conclude that? Normally we call something flaky if it has a
> reasonable amount of failures in pure testing environments (so no migration
> runs). I'm not seeing that for tunnel4 on amd64, nor arm64.

Maybe I missunderstood. According to the tracking page, it failed
everywhere:

| autopkgtest for stunnel4/3:5.63-1:
| amd64: Regression ♻ (reference ♻),
| arm64: Regression ♻ (reference ♻),
| armhf: Regression ♻ (reference ♻),
| i386: Regression ♻ (reference ♻),
| ppc64el: Regression ♻ (reference ♻),
| s390x: Regression ♻ (reference ♻) 

Does this mean flaky or is this something in case it fails _always_ and
not just randomly  swi-prolog/8.4.2+dfsg-2 on i386 while it passed on
other arches.

> > that the error is that it was compiled against one version (1.1.1n)
> > and then tested against another version (1.1.1o)?
> > stunnel4 -version reports:
> > | Compiled with OpenSSL 1.1.1n  15 Mar 2022
> > | Running  with OpenSSL 1.1.1o  3 May 2022
> > 
> > and it is fine, the ABI is stable.
> 
> If your claim is true (and I trust it is), I do agree that it seems that the
> test (and I guess this comes from a runtime check) is too strict. Retitling
> accordingly.

Oki, thanks.

> Paul

Sebastian

Bug#1010700: lintian: Strange report of superfluous-file-pattern

[Jakub Wilk]

* Helge Kreutzmann , 2022-05-07, 18:32:

Lintian claims:
W: goobox source: superfluous-file-pattern po/uk.po [debian/copyright:461]

However:
file po/uk.po
po/uk.po: GNU gettext message catalogue, Unicode text, UTF-8 text

grep uk.po debian/copyright
Files: po/uk.po

If lots of other po files which are accepted, why is po/uk.po any 
different?


I think Lintian is confused because this file was added by a patch. 
It doesn't exist in .orig.tar.


--
Jakub Wilk

Bug#1010609: chromium: Missing suggested package chromium-l10n on 101.0.4951.54-1 upgrade

[Ernesto Domato]

Hi Andres,

Yes indeed, I also tried to merge #1010676 with this report as duplicate
and close both but couldn't, sorry.

Thanks.
Ernesto


On Sat, May 7, 2022 at 3:41 PM Andres Salomon  wrote:

> Hi,
>
> It should all be installable now. Is it?
>
> Thanks,
>
> Andres
>
>
> On 5/5/22 08:13, Ernesto Domato wrote:
> > Package: chromium
> > Version: 101.0.4951.41-2
> > Severity: normal
> > X-Debbugs-Cc: edo...@gmail.com
> >
> > Hi,
> >
> > The package chromium-l10n is missing when trying to upgrade to
> 101.0.4951.54-1
> >
> > Greets,
> > Ernesto
> >
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >APT prefers unstable
> >APT policy: (500, 'unstable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_WARN
> > Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8),
> LANGUAGE=es_AR:es
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages chromium depends on:
> > ii  chromium-common  101.0.4951.41-2
> > ii  libasound2   1.2.6.1-2+b1
> > ii  libatk-bridge2.0-0   2.38.0-4
> > ii  libatk1.0-0  2.38.0-1
> > ii  libatomic1   12-20220428-1
> > ii  libatspi2.0-02.44.1-1
> > ii  libc62.33-7
> > ii  libcairo21.16.0-5
> > ii  libcups2 2.4.1op1-2
> > ii  libdbus-1-3  1.14.0-1
> > ii  libdrm2  2.4.110-1
> > ii  libevent-2.1-7   2.1.12-stable-5
> > ii  libexpat12.4.8-1
> > ii  libflac8 1.3.4-1
> > ii  libfontconfig1   2.13.1-4.4
> > ii  libfreetype6 2.11.1+dfsg-2
> > ii  libgbm1  22.0.2-1
> > ii  libgcc-s112-20220428-1
> > ii  libglib2.0-0 2.72.1-1
> > ii  libgtk-3-0   3.24.33-1
> > ii  libjpeg62-turbo  1:2.1.2-1
> > ii  libjsoncpp25 1.9.5-4
> > ii  liblcms2-2   2.12~rc1-2
> > ii  libminizip1  1.1-8+b1
> > ii  libnspr4 2:4.33-1
> > ii  libnss3  2:3.77-1
> > ii  libopenjp2-7 2.4.0-6
> > ii  libopus0 1.3.1-0.1
> > ii  libpango-1.0-0   1.50.7+ds-1
> > ii  libpng16-16  1.6.37-5
> > ii  libpulse015.0+dfsg1-4
> > ii  libre2-9 20220401+dfsg-1
> > ii  libsnappy1v5 1.1.8-1
> > ii  libstdc++6   12-20220428-1
> > ii  libwayland-client0   1.20.0-1
> > ii  libwebp7 1.2.2-2+b1
> > ii  libwebpdemux21.2.2-2+b1
> > ii  libwebpmux3  1.2.2-2+b1
> > ii  libx11-6 2:1.7.5-1
> > ii  libxcb1  1.14-3
> > ii  libxcomposite1   1:0.4.5-1
> > ii  libxdamage1  1:1.1.5-2
> > ii  libxext6 2:1.3.4-1
> > ii  libxfixes3   1:6.0.0-1
> > ii  libxkbcommon01.4.0-1
> > ii  libxml2  2.9.13+dfsg-1+b1
> > ii  libxrandr2   2:1.5.2-2+b1
> > ii  libxslt1.1   1.1.34-4
> > ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.0-1
> > ii  zlib1g   1:1.2.11.dfsg-4
> >
> > Versions of packages chromium recommends:
> > ii  chromium-sandbox  101.0.4951.41-2
> >
> > Versions of packages chromium suggests:
> > pn  chromium-driver  
> > ii  chromium-l10n101.0.4951.41-2
> > pn  chromium-shell   
> >
> > Versions of packages chromium-common depends on:
> 

Bug#1010689: Crashes with "malloc(): invalid next size (unsorted)"

[Jonathan McDowell]

On Sat, May 07, 2022 at 11:54:07AM +0100, Jonathan McDowell wrote:
> Package: libtpm2-pkcs11-1
> Version: 1.7.0-1
> Severity: important
> X-Debbugs-Cc: nood...@earth.li
> 
> I've upgraded my system from bullseye to bookworm today and as a result 
> libtpm2-pkcs11-1 has gone from 1.5.0-4 to 1.7.0-1. I'm now unable to use
> the library with SSH:
> 
> | noodles@sevai:~$ ssh the.earth.li 
> | malloc(): invalid next size (unsorted)
> | Aborted

Downgrading to 1.5.0-4 (no other package changes) makes things work
again, fwiw.

J.

-- 
   Suburbia: where they tear out   |  .''`.  Debian GNU/Linux Developer
   the trees & then name streets   | : :' :  Happy to accept PGP signed
after them.| `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Bug#1010705: RM: cutter -- RoQA; no more works with current kernels, rc-buggy for years, orphaned, low popcon, looks dead upstream

[Axel Beckert]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: a...@debian.org

Hi,

please remove cutter from Debian Unstable:

* the last time cutter has been in a stable release was with Debian 9
  Stretch (aka oldoldstable at the time of writing).

* It is orphaned since 2017. (https://bugs.debian.org/885922)

* It has an open RC bugs since 2017 (https://bugs.debian.org/446343,
  reports is older, but got bumped to RC in 2017) and nobody
  cared.

  Even worse: Actually the RC bug was against 1.03 and said to be
  fixed in 1.04 upstream, but nobody closed it when 1.04 got uploaded
  a few months later. And nobody seems to have noticed that until now.

* Additionally, even cutter 1.04 seems not to work properly with the
  current nf_conntrack kernel module, see comments #23 and #24 on
  https://bugs.launchpad.net/ubuntu/+source/cutter/+bug/240147

* Installation number is more or less constantly declining since 2015
  (below 100 now) and "vote" is single digit for about a year now:
  https://qa.debian.org/popcon-graph.php?packages=cutter

* There is no newer version than 1.04 from 2015 on
  http://www.digitage.co.uk/digitage/files/cutter/ (i.e. looks dead
  upstream)

Thanks in advance!

Bug#1010698: stunnel4: debci testsuite fails after openssl version update.

[Paul Gevers]

Control: stunnel4: runtime check on openssl too tight

Hi Sebastian,

On 07-05-2022 18:22, Sebastian Andrzej Siewior wrote:

Usertags: flaky


Why do you conclude that? Normally we call something flaky if it has a 
reasonable amount of failures in pure testing environments (so no 
migration runs). I'm not seeing that for tunnel4 on amd64, nor arm64.



The debci testsuite failed for all architectures after the recent
openssl upload

https://ci.debian.net/data/autopkgtest/testing/amd64/s/stunnel4/21436404/log.gz

Am I right to assume as per
| logs/results.log:DEBUG: 2022-05-07 04:07:41,445: [get_version] Trying to 
obtain the version of 
/tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel
| logs/results.log:DEBUG: 2022-05-07 04:07:41,446: [get_version] Started 
`/tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel 
-version` as process 1544
| logs/results.log:CRITICAL: 2022-05-07 04:07:41,449: [main] Something went 
wrong: Stunnel was compiled and run with various OpenSSL versions
…
| autopkgtest [04:07:41]: test upstream: ---]
| upstream FAIL non-zero exit status 1
| autopkgtest [04:07:41]: test upstream:  - - - - - - - - - - results - - - - - 
- - - - -
| autopkgtest [04:07:41]:  summary
| debian-pythonPASS
| upstream FAIL non-zero exit status 1

that the error is that it was compiled against one version (1.1.1n)
and then tested against another version (1.1.1o)?
stunnel4 -version reports:
| Compiled with OpenSSL 1.1.1n  15 Mar 2022
| Running  with OpenSSL 1.1.1o  3 May 2022

and it is fine, the ABI is stable.


If your claim is true (and I trust it is), I do agree that it seems that 
the test (and I guess this comes from a runtime check) is too strict. 
Retitling accordingly.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010609: chromium: Missing suggested package chromium-l10n on 101.0.4951.54-1 upgrade

[Andres Salomon]

Hi,

It should all be installable now. Is it?

Thanks,

Andres


On 5/5/22 08:13, Ernesto Domato wrote:

Package: chromium
Version: 101.0.4951.41-2
Severity: normal
X-Debbugs-Cc: edo...@gmail.com

Hi,

The package chromium-l10n is missing when trying to upgrade to 101.0.4951.54-1

Greets,
Ernesto


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

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

Versions of packages chromium depends on:
ii  chromium-common  101.0.4951.41-2
ii  libasound2   1.2.6.1-2+b1
ii  libatk-bridge2.0-0   2.38.0-4
ii  libatk1.0-0  2.38.0-1
ii  libatomic1   12-20220428-1
ii  libatspi2.0-02.44.1-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcups2 2.4.1op1-2
ii  libdbus-1-3  1.14.0-1
ii  libdrm2  2.4.110-1
ii  libevent-2.1-7   2.1.12-stable-5
ii  libexpat12.4.8-1
ii  libflac8 1.3.4-1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-2
ii  libgbm1  22.0.2-1
ii  libgcc-s112-20220428-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-1
ii  libjpeg62-turbo  1:2.1.2-1
ii  libjsoncpp25 1.9.5-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.33-1
ii  libnss3  2:3.77-1
ii  libopenjp2-7 2.4.0-6
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpng16-16  1.6.37-5
ii  libpulse015.0+dfsg1-4
ii  libre2-9 20220401+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   12-20220428-1
ii  libwayland-client0   1.20.0-1
ii  libwebp7 1.2.2-2+b1
ii  libwebpdemux21.2.2-2+b1
ii  libwebpmux3  1.2.2-2+b1
ii  libx11-6 2:1.7.5-1
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxkbcommon01.4.0-1
ii  libxml2  2.9.13+dfsg-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxslt1.1   1.1.34-4
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.0-1
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages chromium recommends:
ii  chromium-sandbox  101.0.4951.41-2

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n101.0.4951.41-2
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.33-7
ii  libstdc++6  12-20220428-1
ii  libx11-62:1.7.5-1
ii  libxext62:1.3.4-1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-4

Versions of packages chromium-common recommends:
ii  chromium-sandbox101.0.4951.41-2
ii  dunst [notification-daemon] 1.5.0-1+b1
ii  fonts-liberation1:1.07.4-11
ii  libgl1-mesa-dri 22.0.2-1
ii  libu2f-udev 1.1.10-3
ii  

Bug#1010676: chromium-l10n: -l10n version behind chromium version in Sid

[Andres Salomon]

It should all be installable now. Is it?

On 5/6/22 16:31, Andres Salomon wrote:
I think the buildd got stuck: 
https://buildd.debian.org/status/package.php?p=chromium


It finally built the arch:all package(s) 5 hours ago, so they should 
enter the archive soon. I noticed earlier that it had been building 
for 2+ days, despite normally taking about 15 mins to build. :)


On 5/5/22 05:34, Sebastien KALT wrote:

Package: chromium-l10n
Severity: normal

Dear Maintainer,

Chromium is in version 01.0.4951.54-1 in Sid.

But chromium-l10n is older :

$ apt-cache policy chromium-l10n
chromium-l10n:
   Installed: (none)
   Candidate: 101.0.4951.41-2
   Version table:
  101.0.4951.41-2 970
 970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
  99.0.4844.74-1~deb11u1 960
 960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

$  apt-cache policy chromium
chromium:
   Installed: 101.0.4951.54-1
   Candidate: 101.0.4951.54-1
   Version table:
  *** 101.0.4951.54-1 980
 980 http://ftp.fr.debian.org/debian sid/main amd64 Packages
 100 /var/lib/dpkg/status
  101.0.4951.41-2 970
 970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
  99.0.4844.74-1~deb11u1 960
 960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

Thus chromium-l10n is not installable :

# apt install chromium-l10n
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  chromium-l10n : Depends: chromium (< 101.0.4951.41-2.1~) but 
101.0.4951.54-1

is to be installed
E: Unable to correct problems, you have held broken packages.

Regards,

Sébastien KALT


-- System Information:
Debian Release: bookworm/sid
   APT prefers unstable
   APT policy: (980, 'unstable'), (970, 'testing'), (960, 'stable'), 
(500, 'testing-debug'), (1, 'experimental-debug')

Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

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

Versions of packages chromium-l10n depends on:
ii  chromium  101.0.4951.54-1

chromium-l10n recommends no packages.

chromium-l10n suggests no packages.

Bug#1010704: chromium: please provide courgette-tool as a package

[Philippe Cerfon]

Source: chromium
Version: 101.0.4951.54-1
Severity: wishlist


Dear maintainer.

The Google Chromium source tree contains the tool courgette, which makes
binary deltas (allegedly much better than bsdiff, upon which it is based).

Chrome uses it for updates, but it seems that there's also a little CLI tool
included.


Would it be possible to have that built and put into a package?


Some links of possible interest:
https://www.chromium.org/developers/design-documents/software-updates-courgette/
https://lwn.net/Articles/359939/

I guess you wouldn't need the following, because you fully build
Chromium anyway:
https://stackoverflow.com/questions/12542591/how-to-compile-the-google-courgette-tool
https://github.com/rgov/courgette-build


Thanks for your consideration,
Philippe

Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

[Daniel Schepler]

Source: haskell-hashable
Version: 1.3.0.0-2
Severity: serious

>From my build log (in an i386 container, and haskell-devscripts
version was 0.16.14):

...
debian/rules binary-arch
test -x debian/rules
dh_testroot
dh_prep
dh_installdirs -A
mkdir -p "."
CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
Adding cdbs dependencies to debian/libghc-hashable-dev.substvars
dh_installdirs -plibghc-hashable-dev \

perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
   -E 'make_setup_recipe'
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
   -E 'configure_recipe; build_recipe; haddock_recipe; check_recipe'
Running find . ! -newer /tmp/V8FdEAcJVW -exec touch -d "1998-01-01 UTC" {} ;
Running dh_listpackages
libghc-hashable-dev
libghc-hashable-prof
libghc-hashable-doc
Running dh_listpackages
libghc-hashable-dev
libghc-hashable-prof
libghc-hashable-doc
Running dpkg-buildflags --get LDFLAGS
-Wl,-z,relro
Running debian/hlibrary.setup configure --ghc -v2
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib
--builddir=dist-ghc --ghc-option=-optl-Wl,-z,relro --haddockdir=/u
sr/lib/ghc-doc/haddock/hashable-1.3.0.0/ --datasubdir=hashable
--htmldir=/usr/share/doc/libghc-hashable-doc/html/
--enable-library-profiling --hsc2hs-options=-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 --gcc-options=-D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 --ghc-options=-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -optc -D_LARGEFILE_SOURCE -optc
-D_FILE_OFFSET_BITS=64
Non-zero exit code 1.
unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

unrecognized 'configure' option `-optc'

unrecognized 'configure' option `-D_LARGEFILE_SOURCE'

unrecognized 'configure' option `-optc'

unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'
at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 106.
   
Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
"configure", "--ghc", "-v2",
"--package-db=/var/lib/ghc/package.conf.d", "--prefix=/usr",
"--libdir=/usr/lib/haskell-packages/ghc/lib", "--libe
xecdir=/usr/lib", ...) called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line
130
   
Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup",
"configure", "--ghc", "-v2",
"--package-db=/var/lib/ghc/package.conf.d", "--prefix=/usr",
"--libdir=/usr/lib/haskell-packages/ghc/lib", "--libexecdir
=/usr/lib", ...) called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line
629
   Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe()
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2
-- 
Daniel Schepler

Bug#1009387: fbset: FTBFS: modes.tab.c:132:3: error: expected identifier at end of input

[Sudip Mukherjee]

Hi Lucas,

On Tue, Apr 12, 2022 at 07:45:35PM +0200, Lucas Nussbaum wrote:
> Source: fbset
> Version: 2.1-32
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220412 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Can you please recheck this one. I was looking at this one today and
did not see any build failure with sbuild.
>From my build:

+--+
| Summary  |
+--+

Autopkgtest: no tests
Build Architecture: amd64
Build Type: full
Build-Space: 2692
Build-Time: 3
Distribution: unstable
Host Architecture: amd64
Install-Time: 21
Job: /home/sudip/debian/fbset/fbset_2.1-33.dsc
Lintian: warn
Machine Architecture: amd64
Package: fbset
Package-Time: 28
Source-Version: 2.1-33
Space: 2692
Status: successful
Version: 2.1-33

Finished at 2022-05-07T17:09:11Z
Build needed 00:00:28, 2692k disk space

--
Regards
Sudip

Bug#1010702: ITP: pyaps3 -- Python based Atmospheric Phase Screen Estimation

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: pyaps3
  Version : 0.3.1
  Upstream Author : Romain Jolivet, Angelique Benoit, Zhang Yunjun
* URL : https://github.com/insarlab/PyAPS
* License : GPL+
  Programming Lang: Python
  Description : Python based Atmospheric Phase Screen Estimation

Binary package names: python3-pyaps3

 This python 3 module estimates differential phase delay maps due to
 the stratified atmosphere for correcting radar interferograms.
 It is rewritten in Python 3 language from PYAPS source code and
 adapted for ECMWF's ERA-5 corrections.


--
Antonio Valentino

Bug#1010642: RFS: streamlink/4.0.1-1 -- CLI for extracting video streams from various websites to a video player

[Jeroen Ploemen]

Control: tags -1 moreinfo

On Thu, 5 May 2022 23:34:43 +0200
Alexis Murzeau  wrote:

> I am looking for a sponsor for my package streamlink for a new

hi Alexis,

the package as published on mentors ftbfs for me, looks like it's
trying to connect to the internet for something to do with intersphinx
(docs/conf.py:110 ?). See log excerpt [1] below.

Other than that, a few observations:
* control: ancient version requirements for python, requests, and
  pycountry are always met (even in oldstable);
* vcs: consider enabling the CI on Salsa, and pushing changes to
  git before asking for sponsorship - it's a useful quality control
  tool and a nice timesaver for reviewers too.


Please remove the moreinfo tag (and CC me directly) once you have an
updated package ready.


[1] Tail of buildlog:
tests/utils/test_module.py ..[ 96%]
tests/utils/test_named_pipe.py ..[ 96%]
tests/utils/test_parse.py    [ 96%]
tests/utils/test_times.py .. [ 96%]
tests/utils/test_url.py ...

== 4592 passed, 31 skipped in 28.52s ===
   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--buildsystem=pybuild
   dh_prep -O--buildsystem=pybuild
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/streamlink-4.0.1'
LC_ALL=C.UTF-8 LANGUAGE=C.UTF-8 PYTHONPATH=/build/streamlink-4.0.1/src make 
--directory=docs html man
make[2]: Entering directory '/build/streamlink-4.0.1/docs'
sphinx-build -b html -d _build/doctrees  -W . _build/html
Running Sphinx v4.5.0
making output directory... done
loading intersphinx inventory from 
https://docs.python-requests.org/en/stable/objects.inv...

Warning, treated as error:
failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://docs.python-requests.org/en/stable/objects.inv' 
not fetchable due to : 
HTTPSConnectionPool(host='docs.python-requests.org', port=443): Max retries 
exceeded with>
make[2]: *** [Makefile:45: html] Error 2
make[2]: Leaving directory '/build/streamlink-4.0.1/docs'
make[1]: *** [debian/rules:14: override_dh_auto_install] Error 2
make[1]: Leaving directory '/build/streamlink-4.0.1'
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//33402 and its subdirectories


pgpVW7NoEO3qY.pgp
Description: OpenPGP digital signature

Bug#1010701: Installation of bookworm successfully at AMD Desktop PC

[Bernhard]

Package: installation-reports

Boot method: Network PXE Boot
Image version: PXE Boot with daily:

> https://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/initrd.gz

> https://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/linux

Date: 2022-05-07

Machine: Self-made Desktop PC
Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics
Memory: 4GB
Partitions: 

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   1896780   0   18967800% /dev
> tmpfs  tmpfs   383788 9323828561% /run
> /dev/sda1  ext4 113809604 9965780  98016448   10% /
> tmpfs  tmpfs  19189288424   19105041% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs   383784 1163836681% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Root Complex [1022:1410]
>   Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor 
> Root Complex [1043:8526]
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
>   Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526]
>   Kernel driver in use: radeon
>   Kernel modules: radeon, amdgpu
> 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
> HDMI Audio Controller [1002:9902]
>   Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller 
> [1043:8526]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA 
> Controller [AHCI mode] [1022:7801] (rev 40)
>   Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] 
> [1043:8527]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:780b] (rev 14)
>   Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527]
>   Kernel driver in use: piix4_smbus
>   Kernel modules: i2c_piix4, sp5100_tco
> 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia 
> Controller [1022:780d] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:780e] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527]
> 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge 
> [1022:780f] (rev 40)
> 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 0) [1022:43a0]
>   Kernel driver in use: pcieport
> 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 1) [1022:43a1]
>   Kernel driver in use: pcieport
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 0 [1022:1400]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 1 [1022:1401]
> 00:18.2 Host bridge [0600]: Advanced Micro 

Bug#1010700: lintian: Strange report of superfluous-file-pattern

[Helge Kreutzmann]

Package: lintian
Version: 2.114.0
Severity: normal

Lintian claims:
W: goobox source: superfluous-file-pattern po/uk.po [debian/copyright:461]

However:
file po/uk.po
po/uk.po: GNU gettext message catalogue, Unicode text, UTF-8 text

grep uk.po debian/copyright
Files: po/uk.po

If lots of other po files which are accepted, why is po/uk.po any
different?

I went over this multiple times, but I cannot find the reason.

This is in an uptodate sid chroot.

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1010699: linux: Please touch /run/reboot-required in postinst

[Frank Engler]

Source: linux
Version: 5.17.3-1
Severity: wishlist
X-Debbugs-Cc: bts.to.frankeng...@spamgourmet.com

Dear Maintainer,

in #919507 Debian Policy Manual was amended with a signal facility that a
reboot is required. For kernel images this signal had been in
unattended-upgrades and was kept there. This decision isn't suitable for
environments without the unattended-upgrades package. As this signal is
the result of each image install, the postinst scripts of image packages
seem the right place to implement this functionality:

diff --git a/debian/templates/image.postinst.in 
b/debian/templates/image.postinst.in
index 25e7dd6..1c606ee 100755
--- a/debian/templates/image.postinst.in
+++ b/debian/templates/image.postinst.in
@@ -22,4 +22,11 @@ if [ -d /etc/kernel/postinst.d ]; then
  --arg=$image_path /etc/kernel/postinst.d
 fi
 
+if [ -d /run ]; then
+touch /run/reboot-required
+if ! grep -q "^$DPKG_MAINTSCRIPT_PACKAGE$" /run/reboot-required.pkgs 2> 
/dev/null ; then
+echo "$DPKG_MAINTSCRIPT_PACKAGE" >> /run/reboot-required.pkgs
+fi
+fi
+
 exit 0


Thanks

Bug#1010698: stunnel4: debci testsuite fails after openssl version update.

[Sebastian Andrzej Siewior]

Package: stunnel4
Version: 3:5.63-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

The debci testsuite failed for all architectures after the recent
openssl upload
   
https://ci.debian.net/data/autopkgtest/testing/amd64/s/stunnel4/21436404/log.gz

Am I right to assume as per
| logs/results.log:DEBUG: 2022-05-07 04:07:41,445: [get_version] Trying to 
obtain the version of 
/tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel
| logs/results.log:DEBUG: 2022-05-07 04:07:41,446: [get_version] Started 
`/tmp/autopkgtest-lxc.algiqp59/downtmp/build.oOV/src/tests/../src/stunnel 
-version` as process 1544
| logs/results.log:CRITICAL: 2022-05-07 04:07:41,449: [main] Something went 
wrong: Stunnel was compiled and run with various OpenSSL versions
…
| autopkgtest [04:07:41]: test upstream: ---]
| upstream FAIL non-zero exit status 1
| autopkgtest [04:07:41]: test upstream:  - - - - - - - - - - results - - - - - 
- - - - -
| autopkgtest [04:07:41]:  summary
| debian-pythonPASS
| upstream FAIL non-zero exit status 1

that the error is that it was compiled against one version (1.1.1n)
and then tested against another version (1.1.1o)?
stunnel4 -version reports:
| Compiled with OpenSSL 1.1.1n  15 Mar 2022
| Running  with OpenSSL 1.1.1o  3 May 2022

and it is fine, the ABI is stable.

Sebastian

Bug#1010697: hydrapaper: Fails to launch (no module named 'PIL')

[Clay Kimber]

Package: hydrapaper
Version: 2.0.2-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: clay.kim...@gmail.com

Dear Maintainer,

hydrapaper fails to launch.  It fails silently when launched from GNOME but
gives the following error message when launched from the terminal:

Traceback (most recent call last):
  File "/usr/bin/hydrapaper", line 69, in 
from hydrapaper import __main__
  File "/usr/lib/python3/dist-packages/hydrapaper/__main__.py", line 6, in

from .app_window import HydraPaperAppWindow
  File "/usr/lib/python3/dist-packages/hydrapaper/app_window.py", line 3, in

from .main_stack import HydraPapaerMainStack
  File "/usr/lib/python3/dist-packages/hydrapaper/main_stack.py", line 3, in

from .wallpapers_flowbox import HydraPaperWallpapersFlowbox
  File "/usr/lib/python3/dist-packages/hydrapaper/wallpapers_flowbox.py", line
4, in 
from .wallpaper_flowbox_item import WallpaperBox
  File "/usr/lib/python3/dist-packages/hydrapaper/wallpaper_flowbox_item.py",
line 5, in 
from PIL import Image
ModuleNotFoundError: No module named 'PIL'

Installing python3-pil solves the issue.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages hydrapaper depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-handy-1   1.6.2-1
ii  libhandy-1-0 1.6.2-1
ii  python3  3.10.4-1+b1
ii  python3-gi   3.42.1-1

hydrapaper recommends no packages.

hydrapaper suggests no packages.

-- no debconf information

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Georges Khaznadar]

Hello Paul,

I think that I found the clue: Python3.10 interprets the following lines
-8<--- file src/einsteinpy.egg-info/requires.txt 
[:implementation_name == "cpython"]
numba!=0.49.0,>=0.46
-8<--

no exactly as Python3.9 did, and the result of ${python3:Depends} includes
python3-numba as a consequence.

So I shall test another modification: wiring the Python3 dependencies,
and declaring python3-numba as a recommendation.

Best regards,   Georges.

Paul Gevers a écrit :
> Hi,
> 
> [Why not in the bug report? Feel free to quote me.]
> 
> On 07-05-2022 15:44, Georges Khaznadar wrote:
> > Paul Gevers a écrit :
> > > Where are you seeing this? I only see failures:
> > > https://ci.debian.net/packages/e/einsteinpy/
> > 
> > The tests are still failing for Salsa/CI; however the bug 1010215 was
> > different: it was genuinely due to the wrong usage of the symbol np
> > (defined after "import numpy as np"), instead of the string "numpy".
> > This parameter finishes by reaching sympy.lamdify, and the current
> > version of sympy does no longer tolerate this wrong usage.
> > 
> > Please take a look at the begin of Bug#1010215's report for more 
> > information.
> > 
> > I took the freedom to patch einsteinpy's test syntax because sympy was
> > marked for AUTORM if nothing was done for a few weeks.
> > 
> > Besides, you are true: now, the failed tests report a broken dependency
> > on python-numba3, which is not yet compiled with/for Python3.10.
> 
> Your NMU einsteinpy grew a *new* dependency on python3-numba, which has RC
> bug 1000336 for a while already, so don't expect it to migrate. Hence, your
> fix can't migrate to testing as-is.
> 
> Paul




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1010696: libarchive: CVE-2022-28066

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.6.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1672
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libarchive.

CVE-2022-28066[0]:
| Libarchive v3.6.0 was discovered to contain a read memory access
| vulnerability via the function lzma_decode.


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-28066
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28066
[1] https://github.com/libarchive/libarchive/issues/1672
[2] 
https://github.com/libarchive/libarchive/commit/cfaa28168a07ea4a53276b63068f94fce37d6aff

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1010695: poppler: CVE-2022-27337: Logic error in function Hints::Hints

[Salvatore Bonaccorso]

Source: poppler
Version: 22.02.0-3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1230
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for poppler.

CVE-2022-27337[0]:
| A logic error in the Hints::Hints function of Poppler v22.03.0 allows
| attackers to cause a Denial of Service (DoS) via a crafted PDF file.


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-27337
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27337
[1] https://gitlab.freedesktop.org/poppler/poppler/-/issues/1230
[2] 
https://gitlab.freedesktop.org/poppler/poppler/-/commit/81044c64b9ed9a10ae82a28bac753060bdfdac74

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1010694: libvirt: New upstream version 8.3.0 available

[Salvatore Bonaccorso]

Source: libvirt
Version: 8.2.0-1
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi

Upstream version 8.3.0 has been released for libvirt. Not massively
urgent, but I wanted to ask if you can package it for unstable so I
can update libsys-virt-perl?

Regards,
Salvatore

Bug#1010693: netty: CVE-2022-24823

[Salvatore Bonaccorso]

Source: netty
Version: 1:4.1.48-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for netty.

CVE-2022-24823[0]:
| Netty is an open-source, asynchronous event-driven network application
| framework. The package `io.netty:netty-codec-http` prior to version
| 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When
| Netty's multipart decoders are used local information disclosure can
| occur via the local system temporary directory if temporary storing
| uploads on the disk is enabled. This only impacts applications running
| on Java version 6 and lower. Additionally, this vulnerability impacts
| code running on Unix-like systems, and very old versions of Mac OSX
| and Windows as they all share the system temporary directory between
| all users. Version 4.1.77.Final contains a patch for this
| vulnerability. As a workaround, specify one's own `java.io.tmpdir`
| when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to
| set the directory to something that is only readable by the current
| user.

Note as far I understand the insufficient fix impacts only netty in
combination with Java versions 6 and lower, so not of practical impact
for the supported suites. That said, there is likely not action to be
taken directly for the versions in Debian, and just can be closed once
the commit [2] lands in the version.


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-24823
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24823
[1] https://github.com/netty/netty/security/advisories/GHSA-269q-hmxg-m83q
[2] 
https://github.com/netty/netty/commit/185f8b2756a36aaa4f973f1a2a025e7d981823f1

Regards,
Salvatore

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Georges Khaznadar]

Hello Paul,
Paul Gevers a écrit :
> Hi,
> 
> [Why not in the bug report? Feel free to quote me.]

Fixed: This e-mail is Cc-ed to 1010...@bugs.debian.org; I did not pay
attention to the Reply-To: field in the previous e-mail which was missing
1010...@bugs.debian.org

> 
> On 07-05-2022 15:44, Georges Khaznadar wrote:
> > Paul Gevers a écrit :
> > > Where are you seeing this? I only see failures:
> > > https://ci.debian.net/packages/e/einsteinpy/
> > 
> > The tests are still failing for Salsa/CI; however the bug 1010215 was
> > different: it was genuinely due to the wrong usage of the symbol np
> > (defined after "import numpy as np"), instead of the string "numpy".
> > This parameter finishes by reaching sympy.lamdify, and the current
> > version of sympy does no longer tolerate this wrong usage.
> > 
> > Please take a look at the begin of Bug#1010215's report for more 
> > information.
> > 
> > I took the freedom to patch einsteinpy's test syntax because sympy was
> > marked for AUTORM if nothing was done for a few weeks.
> > 
> > Besides, you are true: now, the failed tests report a broken dependency
> > on python-numba3, which is not yet compiled with/for Python3.10.
> 
> Your NMU einsteinpy grew a *new* dependency on python3-numba, which has RC
> bug 1000336 for a while already, so don't expect it to migrate. Hence, your
> fix can't migrate to testing as-is.

Please accept my apologies: I accidentally modified the file 
src/einsteinpy.egg-info/requires.txt, and did not check thouroughly the
patch's content.

Now I reversed the modification, and I shall wait for the feedback of
salsa/CI to decide whether my changes can be accepted.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2

[Nicolas Mora]

Hello,

I've updated glewlwyd/2.5.2-2+deb11u2 with the 
glewlwyd_2.5.2-2+deb11u2...2.5.2-2+deb11u3.debdiff file.


Now both CVEs (CVE-2022-27240 and CVE-2022-29967) are fixed in the update.

The fix for CVE-2022-27240 only addresses the buffer overflow, 
o_base64url_decode isn't changed to o_base64_decode anymore.


The CVE-2022-29967 requires more changes though.
The bug fix uses 'realpath' to avoid traversal access.

Although if an accessed file is a soft link, realpath returns the 
realpath of the file which isn't in /usr/share/glewlwyd/webapp, so an 
error 404 is raised. The solution is to copy jquery, popper.js, 
bootstrap and fonts-fork-awesome files from their respective 
installation into /usr/share/glewlwyd/webapp.diff -Nru glewlwyd-2.5.2/debian/changelog glewlwyd-2.5.2/debian/changelog
--- glewlwyd-2.5.2/debian/changelog 2021-12-17 07:51:46.0 -0500
+++ glewlwyd-2.5.2/debian/changelog 2022-03-17 21:13:09.0 -0400
@@ -1,3 +1,15 @@
+glewlwyd (2.5.2-2+deb11u3) bullseye; urgency=medium
+
+  * d/patches: Fix CVE-2022-27240
+  possible buffer overflow during webauthn signature assertion
+  * d/patches: Fix CVE-2022-29967
+  static_compressed_inmemory_website_callback.c in Glewlwyd
+  through 2.6.2 allows directory traversal
+  * d/glewlwyd-common.install: copy bootstrap, jquery, fork-awesome
+instead of linking it
+
+ -- Nicolas Mora   Thu, 17 Mar 2022 21:13:09 -0400
+
 glewlwyd (2.5.2-2+deb11u2) bullseye; urgency=medium
 
   * d/patches: Fix possible privilege escalation (Closes: #1001849)
diff -Nru glewlwyd-2.5.2/debian/control glewlwyd-2.5.2/debian/control
--- glewlwyd-2.5.2/debian/control   2021-12-17 07:51:46.0 -0500
+++ glewlwyd-2.5.2/debian/control   2022-03-17 21:13:09.0 -0400
@@ -35,6 +35,10 @@
  , node-i18next-http-backend
  , node-qrcode-generator
  , webpack
+ , fonts-fork-awesome
+ , libjs-jquery
+ , libjs-bootstrap4
+ , libjs-popper.js
 Standards-Version: 4.5.1
 Homepage: https://github.com/babelouest/glewlwyd
 Vcs-Browser: https://salsa.debian.org/debian-iot-team/oauth2/glewlwyd.git
diff -Nru glewlwyd-2.5.2/debian/glewlwyd-common.install 
glewlwyd-2.5.2/debian/glewlwyd-common.install
--- glewlwyd-2.5.2/debian/glewlwyd-common.install   2021-12-17 
07:51:46.0 -0500
+++ glewlwyd-2.5.2/debian/glewlwyd-common.install   2022-03-17 
21:13:09.0 -0400
@@ -1,5 +1,6 @@
-webapp-src/css/glewlwyd*.css usr/share/glewlwyd/webapp/css/
-webapp-src/css/*-custom.css usr/share/glewlwyd/webapp/css/
+webapp-src/css/* usr/share/glewlwyd/webapp/css/
+webapp-src/js/* usr/share/glewlwyd/webapp/js/
+webapp-src/fonts/* usr/share/glewlwyd/webapp/fonts/
 webapp-src/locales/ usr/share/glewlwyd/webapp/
 webapp-src/img/ usr/share/glewlwyd/webapp/
 webapp-src/output/*.js usr/share/glewlwyd/webapp/
@@ -7,3 +8,4 @@
 webapp-src/favicon.ico usr/share/glewlwyd/webapp/
 
 debian/config.json usr/share/glewlwyd/templates/
+debian/config.json usr/share/glewlwyd/webapp/
diff -Nru glewlwyd-2.5.2/debian/glewlwyd-common.links 
glewlwyd-2.5.2/debian/glewlwyd-common.links
--- glewlwyd-2.5.2/debian/glewlwyd-common.links 2021-12-17 07:51:46.0 
-0500
+++ glewlwyd-2.5.2/debian/glewlwyd-common.links 1969-12-31 19:00:00.0 
-0500
@@ -1,19 +0,0 @@
-usr/share/javascript/jquery/jquery.min.js 
usr/share/glewlwyd/webapp/js/jquery.min.js
-usr/share/javascript/jquery/jquery.min.js 
usr/share/glewlwyd/webapp/js/jquery.min.js
-usr/share/javascript/popper.js/umd/popper.min.js 
usr/share/glewlwyd/webapp/js/popper.min.js
-usr/share/javascript/popper.js/umd/popper-utils.min.js 
usr/share/glewlwyd/webapp/js/popper-utils.min.js
-
-usr/share/nodejs/bootstrap/dist/js/bootstrap.min.js 
usr/share/glewlwyd/webapp/js/bootstrap.min.js
-usr/share/nodejs/bootstrap/dist/js/bootstrap.min.js.map 
usr/share/glewlwyd/webapp/js/bootstrap.min.js.map
-usr/share/nodejs/bootstrap/dist/css/bootstrap.min.css 
usr/share/glewlwyd/webapp/css/bootstrap.min.css
-usr/share/nodejs/bootstrap/dist/css/bootstrap.min.css.map 
usr/share/glewlwyd/webapp/css/bootstrap.min.css.map
-
-usr/share/fonts-fork-awesome/css/fork-awesome.css 
usr/share/glewlwyd/webapp/css/fork-awesome.min.css
-usr/share/fonts-fork-awesome/css/v5-compat.css 
usr/share/glewlwyd/webapp/css/v5-compat.min.css
-usr/share/fonts/eot/fork-awesome/forkawesome-webfont.eot 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.eot
-usr/share/fonts/svg/fork-awesome/forkawesome-webfont.svg 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.svg
-usr/share/fonts/truetype/fork-awesome/forkawesome-webfont.ttf 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.ttf
-usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff
-usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff2 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff2
-
-etc/glewlwyd/config.json 

Bug#1006753: dkms modules not rebuilt on kernel upgrades with unattended upgrades

[Felix Dörre]

I think your issue could be related but the symptoms seem to be slightly 
different:


When the problem occurred to me, the zfs module was not even built, so 
that's even one step before the initramdisk should be built. 
Consequently not a simple "update-initkamfs" was enough.


Regarding which package is at fault, my best guess still lies with dkms, 
as I understand it, a dkms build requires both, linux image and linux 
headers installed and you can install both of them individually, so on 
upgrade starting with -image, I see:


- linux image installed
- dkms build fails
- linux headers installed
- dkms gets notified through /etc/kernel/header_postinst.d/dkms
- the dkms autoinstall script *somehow* (still don't get how though) 
misses the failed install and does nothing in my case


additionally, that an update-initramfs should be triggered is another 
problem. So I guess the desired resolution would be to understand the 
problem with autoinstall and maybe somehow trigger the update-initramfs 
from there.


changing the behavior of unattended upgrades seem an easier, but hacky 
way to resolve this and additionally the problem with update-initramfs 
in one go.


--
Kind regards,
Felix Dörre

Bug#1009797: apt: support "nodoc" build profile

[Paul Gevers]

Hi,

On Tue, 19 Apr 2022 07:48:55 +0200 Johannes Schauer Marin Rodrigues 
 wrote:


This means
that build dependencies like xsltproc, docbook-xml and docbook-xsl can come
from an existing architecture because both packages are Multi-Arch:foreign.
This is why those build dependencies do not present a problem for
bootstrapping. Other big dependencies like doxygen, graphviz and w3m are in
Build-Depends-Indep so they are also not interesting for bootstrapping as they
are only used to create Architecture:all packages.


Just to add a rather unrelated argument for the nodoc support in apt. 
apt is (understandably) a key package. The Release Team (of which I'm a 
member) is currently exploring improvements to our tools to get a view 
RC buggy key packages. One of the facets we using is the nodoc (and 
nocheck) build annotations. So, we are really in favor of adding these 
nodoc annotations and the support of them in the build process.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)

[John Paul Adrian Glaubitz]

Hi Otto!

On 5/4/22 18:16, Otto Kekäläinen wrote:
> Thanks John for researching this!
> 
> Since you are close to solving it, would you like to finalize it by
> submitting a MR at
> https://salsa.debian.org/mariadb-team/mariadb-server?

I think the change is trivial enough that you can make it yourself. It
will probably take me longer to read through the howto and prepare a proper
pull request than it takes you just to fix the issue.

So, please go ahead.

Thanks,
Adrian

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

Bug#1010691: src:golang-github-sylabs-sif: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: golang-github-sylabs-sif
Version: 1.0.9-2.1
Severity: serious
Control: close -1 2.3.1-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:golang-github-sylabs-sif has been trying 
to migrate for 61 days [2]. Hence, I am filing this bug. Your package 
has an autopkgtest, but it started to fail with one of the recent uploads.


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=golang-github-sylabs-sif



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010619: rsyslog: CVE-2022-24903: Potential heap buffer overflow in TCP syslog server (receiver) components

[Salvatore Bonaccorso]

Hi Michael,

[looping in the sec-team for completeness]

On Thu, May 05, 2022 at 10:19:38PM +0200, Michael Biebl wrote:
> Am 05.05.22 um 17:10 schrieb Salvatore Bonaccorso:
> > Source: rsyslog
> > Version: 8.2204.0-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for rsyslog. Filling for now
> > as grave, but we might downgrade. Probably affected configurations are
> > not that common if I understood correctly, the advisory has some
> > comments about it as well[1].
> 
> Yeah, I think this feature is obscure enough (and not enabled by default)
> that non-RC severity is fine.

Thinking a bit more on it I see two aspects:

* Usually following recommendations one should not expose recievers to
  public, which makes the risk considerably lower.
* Though still reciervers enable octed-framing by default.

So I think to leave the severity actually as it is, and consider it RC
and at earliest point possible for you either do a cherry-picked
upload on top of 8.2204.0-1 or just upload 8.2204.1 to unstable, I
htink I would prefer the later.

Secondly, about releasing a DSA, still slight borderline, but I think
we would be safer to release one. I can help rpepare updates for
bullseye and buster here if needed and wanted. I the git repository I
see 8.2102.0-2+deb11u1 as released for bullseye but this change
actually never landed to bullseye and was not acked by SRM?

Regards,
Salvatore

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Paul Gevers]

Dear Georges,

On 06-05-2022 18:03, Debian Bug Tracking System wrote:

From: Georges Khaznadar 
Date: 06-05-2022 17:59
To: 1010215-d...@bugs.debian.org

and sucessfully passes the tests.


Where are you seeing this? I only see failures:
https://ci.debian.net/packages/e/einsteinpy/

I'm guessing you mean that we need einsteinpy and sympy together from 
unstable in testing. It seems that the test of einsteinpy broke in 
testing when testing with unstable because of a broken python-numba (but 
that's for another bug).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010690: cmake-curses-gui: crashes if all entries are deleted

[Adam Borowski]

Package: cmake-curses-gui
Version: 3.23.1-2
Severity: normal

Hi!
Looking for a way to quickly restore the settings to default without "git
clean", I tried deleting them all in ccmake.  This causes a segfault.

To reproduce: run ccmake, hold "d", boom!


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

Kernel: Linux 5.18.0-rc4-00023-g5b8831768ad6 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cmake-curses-gui depends on:
ii  cmake 3.23.1-2
ii  libarchive13  3.6.0-1
ii  libc6 2.34-0experimental4
ii  libcurl4  7.83.0-1
ii  libgcc-s1 12-20220428-1
ii  libjsoncpp25  1.9.5-4
ii  libncurses6   6.3+20220423-2
ii  librhash0 1.4.2-1
ii  libstdc++612-20220428-1
ii  libtinfo6 6.3+20220423-2
ii  libuv11.44.1-2
ii  zlib1g1:1.2.11.dfsg-4

cmake-curses-gui recommends no packages.

cmake-curses-gui suggests no packages.

-- no debconf information

Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

[Paul Gevers]

Dear Thorsten,

On 07-05-2022 10:53, Michael Tokarev wrote:

06.05.2022 19:49, Mike Gabriel wrote:
..
at least the bugtitle is far to unprecise. Here, I test Debian Edu 
bullseye really heavily and integrate FAI in Debian Edu.


The FAI installer and also the diskless machines I very often boot via 
iPXE/QEMU. In Debian 11 (and probably beyond), PXE booting in QEMU 
works, for BIOS legacy VMs as well as for UEFI based VMs.


In this bugreport, I see it is/was broken with -machine pc-1.1. There's 
no indication
if it is broken with other machine types.  As of qemu 5.2 (bullseye) 
machine types

below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed.


Do you agree with this assessment of the bug you reported? If so, let's 
tag this bug with buster and bullseye as indeed I conclude it's not a 
bug in bookworm then.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008673: gnumeric: libspreadsheet-1.12.50.so segfault

[olaf]

Package: gnumeric
Followup-For: Bug #1008673

Dear Maintainer,

five days ago I installed Gnumeric version 1.12.52-1 with its dependencies. 
None of the errors described to me above have occurred since then, although I 
have tried to reproduce them intentionally alongside daily use. Gnumeric in 
this current version works for me as stable as I knew it from the versions up 
to 1.12.48. Thanks for the repeated rapid update!

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

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

Versions of packages gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  gnumeric-common1.12.52-1
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.5
ii  libatk1.0-02.38.0-1
ii  libc6  2.33-7
ii  libcairo2  1.16.0-5
ii  libgdk-pixbuf-2.0-02.42.8+dfsg-1
ii  libglib2.0-0   2.72.1-1
ii  libgoffice-0.10-10 0.10.51-1
ii  libgsf-1-114   1.14.49-1
ii  libgtk-3-0 3.24.33-1
ii  libpango-1.0-0 1.50.7+ds-1
ii  libpangocairo-1.0-01.50.7+ds-1
ii  libxml22.9.13+dfsg-1+b1
ii  procps 2:3.3.17-7+b1
ii  pxlib1 0.6.8-1+b1
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages gnumeric recommends:
ii  evince42.2-1
ii  gnumeric-doc  1.12.52-1
ii  lp-solve  5.5.2.5-2

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-11
pn  gnumeric-plugins-extra  
ii  libgsf-1-dev1.14.49-1

-- debconf information:
  gnumeric/existing-process-title:
  gnumeric/existing-process: false

Bug#1010516: sqlite3: consider linking dynamically

[GCS]

Control: tags -1 +pending

Hi,

On Tue, May 3, 2022 at 1:15 PM Helmut Grohne  wrote:
> I was investigating why sqlite3 was so "big" and noticed that it links
> libsqlite3 statically. The most common reason for doing so is usage of
> unexported symbols. Evidently that's not the case here. So why would it
> not link dynamically?
 I think upstream has several reasons for linking static. The library
has some features that can be turned in and the sqlite3 binary expects
those features then. New versions add bug fixes and maybe behaviour
changes. Then the library might be installed by third party software
under /opt or /usr/local and the sqlite3 binary might find those
instead of the one in /usr/lib. Of course, Debian packaging prevents
these with strict binary dependency on the library.

> Given that libsqlite3-0 is pulled by very many packages, and that
> /usr/share/doc can be removed in size-constrained settings, the
> reduction achieved by dynamic linking seems reasonable to me. Do you
> agree?
 Well, it's the sqlite3 binary that gets smaller in size, but that's
also pulled in by a number of packages. Going to apply your patch
soon.

Thanks,
Laszlo/GCS

Bug#1010689: Crashes with "malloc(): invalid next size (unsorted)"

[Jonathan McDowell]

Package: libtpm2-pkcs11-1
Version: 1.7.0-1
Severity: important
X-Debbugs-Cc: nood...@earth.li

I've upgraded my system from bullseye to bookworm today and as a result 
libtpm2-pkcs11-1 has gone from 1.5.0-4 to 1.7.0-1. I'm now unable to use
the library with SSH:

| noodles@sevai:~$ ssh the.earth.li 
| malloc(): invalid next size (unsorted)
| Aborted

Commenting out the:

PKCS11Provider /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1

line in my .ssh/config makes things work fine. I ran ssh under GDB and
got the following backtrace:

debug1: Connection established.
malloc(): invalid next size (unsorted)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77a3f546 in __GI_abort () at abort.c:79
#2  0x77a96eb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77bb4a78 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3  0x77a9e91a in malloc_printerr (
str=str@entry=0x77bb7418 "malloc(): invalid next size (unsorted)") at 
malloc.c:5628
#4  0x77aa1d2c in _int_malloc (av=av@entry=0x77bebba0 , 
bytes=bytes@entry=1536)
at malloc.c:3964
#5  0x77aa3364 in __GI___libc_malloc (bytes=1536) at malloc.c:3229
#6  0x772735ab in yaml_document_initialize () from 
/lib/x86_64-linux-gnu/libyaml-0.so.2
#7  0x775049ab in emit_attributes_to_string () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#8  0x7750213f in _db_update_tobject_attrs () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#9  0x775027c1 in ?? () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#10 0x77503a37 in db_new () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#11 0x774fdb70 in backend_init () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#12 0x775065e6 in general_init () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#13 0x774f7438 in C_Initialize () from 
/usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1
#14 0x555e0bc5 in ?? ()
#15 0x5556309f in ?? ()
#16 0x77a407fd in __libc_start_main (main=0xf960, argc=3, 
argv=0x7fffe1f8, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffe1e8)
at ../csu/libc-start.c:332
#17 0x5556487a in ?? ()
(gdb) 


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
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 libtpm2-pkcs11-1 depends on:
ii  libc6 2.33-7
ii  libsqlite3-0  3.38.3-1
ii  libssl1.1 1.1.1n-1
ii  libtss2-esys-3.0.2-0  3.2.0-1
ii  libtss2-mu0   3.2.0-1
ii  libtss2-rc0   3.2.0-1
ii  libtss2-tctildr0  3.2.0-1
ii  libyaml-0-2   0.2.2-1

libtpm2-pkcs11-1 recommends no packages.

libtpm2-pkcs11-1 suggests no packages.

-- no debconf information

Bug#1010418: Proposed bugfix

[Sergio Costas]

I created a MR that should fix this. It is at 
https://gitlab.com/rastersoft/terminus/-/merge_requests/6 Can you test it?


--
Nos leemos
 RASTER(Linux user #228804)
rasters...@gmail.comhttps://www.rastersoft.com

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Adam Borowski]

On Sat, May 07, 2022 at 07:20:07AM +0100, Mark Hindley wrote:
> On Sat, May 07, 2022 at 05:19:05AM +0200, Thorsten Glaser wrote:
> > On Sat, 7 May 2022, Adam Borowski wrote:
> > 
> > > But, as glibc still considers unset locale to mean "C" rather than
> > > "C.UTF-8", _something_ must set these variables.  Debian-installer does
> > 
> > There's talk to chage that in glibc-in-Debian at least.

Oh, interesting.  Could you please provide a link, as I seem to fail to find
such a talk?

I've proposed this myself several years ago but it was then rejected.  IIRC
one of the concerns raised was that eg. Postgresql tools do "unset LANG
LC_ALL LC_CTYPE" to get the "C" locale.


> > > As systemd does define LANG=C.UTF-8, I'm not hopeful the default will
> 
> Since we seem to agree glibc would be the best place to make this change and 
> if
> there is already talk about changing it there let's add our voice to that
> discussion first?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄

Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

[Michael Tokarev]

06.05.2022 19:49, Mike Gabriel wrote:
..

at least the bugtitle is far to unprecise. Here, I test Debian Edu bullseye 
really heavily and integrate FAI in Debian Edu.

The FAI installer and also the diskless machines I very often boot via iPXE/QEMU. In Debian 11 (and probably beyond), PXE booting in QEMU works, for 
BIOS legacy VMs as well as for UEFI based VMs.


In this bugreport, I see it is/was broken with -machine pc-1.1. There's no 
indication
if it is broken with other machine types.  As of qemu 5.2 (bullseye) machine 
types
below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed.

/mjt

Bug#1010688: apparmor profile prvents -C -W

[Harald Welte]

putting the following in /etc/apparmor.d/local/usr.bin.tcpdump
works around the problem:

  /**.[pP][cC][aA][pP][0-9]* rw,

please adjust the packaged apparmor profile for stable and unstable to allow
people to use the -C -W option.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1010688: apparmor profile prevents -C -W

[Harald Welte]

Package: tcpdump
Version: 4.99.1-3
Severity: normal

I have this problem both with Debian 11 and debian unstable:

When trying to use something like "-w /some/file/name.pcap -C 1 -W 10" tcpdump
gets -EACCESS when trying to open the file:

openat(AT_FDCWD, "/var/pcap/lapd.pcap0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 
EACCES (Permission denied)

manually changing UID to tcpdump and trying to create the file works.

audit log shows:

[ 1975.392192] audit: type=1400 audit(1651910055.299:16): apparmor="DENIED" 
operation="mknod" profile="tcpdump" name="/var/pcap/lapd.pcap0" pid=2003 
comm="tcpdump" requested_mask="c" denied_mask="c" fsuid=106 ouid=106

The problem seems to be that the apparmor profile assumes that pcap files end 
in pcap.  However, when using
the -W option, there is a numerical suffix after the pcap, breaking that 
assumption.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.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)
LSM: AppArmor: enabled

Versions of packages tcpdump depends on:
ii  adduser 3.121
ii  libc6   2.33-7
ii  libpcap0.8  1.10.1-4
ii  libssl1.1   1.1.1n-1

tcpdump recommends no packages.

Versions of packages tcpdump suggests:
ii  apparmor  3.0.4-2

-- no debconf information

Bug#1010687: live-tools: error building initramfs on kernel-update from live-system to remounted (rw) boot-device

[Vitus]

Package: live-tools
Version: 1:20190831
Severity: normal

Hello Debian Live Team,

i've got an error from "live-update-initramfs" when installing a new 
kernel-upgrade by "dist-upgrade" under a booted bullseye-live USB-Stick.

Error: "I: update-initramfs is disabled (live system is running without media 
mounted on /run/live/medium)." during build initramfs on remounted boot-device, 
when new kernel is updated by "apt-get dist-upgrade".

Details: "live-update-initramfs" uses at 
https://salsa.debian.org/live-team/live-tools/-/blob/master/bin/live-update-initramfs#L26
 and multiple locations a wrong (rw) remounted path on bootable live-image 
under Debian 11 Bullseye, when updating the kernel from a booted live-image.

As a workaround, the old "live-update-initramfs"-script from "Debian Strech":
https://salsa.debian.org/live-team/live-tools/-/blob/debian/1%2520151214/bin/live-update-initramfs#L25
... fixes this error by using the "correct path" for RW-remounts:

--- cut here ---
... "\/lib\/live\/mount\/medium" 
--- cut here ---

Best regards,
  Veit Berwig

Bug#1010576: akonadi-server: Akonadi/Kontact hangs after resuming from standby

[gis-w]

Exactly, but be careful with kill -9. I once broke my database with it such 
that mariadb would not even start anymore. I had to delete the entire directory 
and let akonadi recreate it from scratch.

Bug#1009188: closing

[alain]

like the solution is found , you can close this thread .


waiting for the time of the development and the publication in the 
distribution.



friendly ,

alain .

Bug#1009188: solution :

[alain]

here is  what alex pevzner found :


1) compile the git  version of ipp-usb :

https://github.com/OpenPrinting/ipp-usb


2) install the latest version of ipp-usb of the repositories

sudo apt install --reinstall ipp-usb


3) copy and add this quirk in  /usr/share/ipp-usb/quirks/HP.conf

[HP ENVY 5530 series]
  disable-fax = true


4) replace /usr/sbin/ipp-usb with the one you compiled .


5) tests .

all must be ok .

Bug#1008997: solution

[alain]

here is  what alex pevzner found :


1) compile the git  version of ipp-usb :

https://github.com/OpenPrinting/ipp-usb


2) install the latest version of ipp-usb of the repositories

sudo apt install --reinstall ipp-usb


3) copy and add this quirk in  /usr/share/ipp-usb/quirks/HP.conf

[HP ENVY 5530 series]
  disable-fax = true


4) replace /usr/sbin/ipp-usb with the one you compiled .


5) tests .

all must be ok .


you can close this thread .

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Mark Hindley]

Hi,

On Sat, May 07, 2022 at 05:19:05AM +0200, Thorsten Glaser wrote:
> On Sat, 7 May 2022, Adam Borowski wrote:
> 
> > But, as glibc still considers unset locale to mean "C" rather than
> > "C.UTF-8", _something_ must set these variables.  Debian-installer does
> 
> There's talk to chage that in glibc-in-Debian at least.

[snip..]

> > As systemd does define LANG=C.UTF-8, I'm not hopeful the default will

Since we seem to agree glibc would be the best place to make this change and if
there is already talk about changing it there let's add our voice to that
discussion first?

Mark