Bug#1068496: [manpage] notify-send(1): inaccurate "-A" option description

[Frank Mascal]

Package: libnotify-bin
Version: 0.8.1-1
Severity: minor
Tags: patch

Hi,

(Note that it impacts unstable despite being reported against bookworm)

There is an error in the documentation of notify-send(1), i quote:

> -A, --action=[NAME=]Text...
> Specifies the actions to display to the user. Implies --wait to wait
> for user input. May be set multiple times. The NAME of the action is
> output to stdout. If NAME is not specified, the numerical index of
> the option is used (starting with 1).

It's not starting with 1, but 0. Run this in a terminal and click "See log":

notify-send -i /usr/share/icons/vendor/64x64/emblems/emblem-vendor.png \
-A "See log" -t 2000 \
"Unattended-upgrade" "Some upgrades were applied\!"

To check it out.

Cheers,

Frank.

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

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

Versions of packages libnotify-bin depends on:
ii  libc6 2.36-9+deb12u4
ii  libglib2.0-0  2.74.6-2
ii  libnotify40.8.1-1

libnotify-bin recommends no packages.

libnotify-bin suggests no packages.

-- no debconf information
--- notify-send.1.orig	2024-04-06 13:26:21.536113318 +0200
+++ notify-send.1	2024-04-06 13:26:56.028113864 +0200
@@ -59,7 +59,7 @@ of the action is output to
 stdout\&. If
 \fINAME\fR
 is not specified, the numerical index of the option is used (starting with
-1)\&.
+0)\&.
 .RE
 .PP
 \fB\-u\fR, \fB\-\-urgency\fR=\fILEVEL\fR

Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).

[Frank B. Brokken]

Dear Peter Green, you wrote:
> > Also, the bootstrapping procedure is only required when icmake isn't
> > available ...

Thanks for your bugreport: I'm about to update icmake so that the circular
dependency between bobcat and icmake is removed. Shortly after icmake's
update bobcat will also be updated.

-- 
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#1068068: Need rebootstrapping on armel and armhf

[Frank B. Brokken]

Dear Andrey Rakhmatullin, you wrote:
> 
> Package: icmake,libbobcat6
> Severity: serious
> Tags: ftbfs
> 
> As src:icmake B-D:libbobcat-dev, src:bobcat B-D:icmake, there seems to be zero
> packaging-level support for bootstrapping, the packages are not 
> cross-buildable
> and the upstream bootstrapping instructions are too tedious, I'm filing this
> for visibility (as there are ~14 packages B-D:libbobcat-dev).

Thanks for your bug report. You write: 

> there seems to be zero packaging-level support for bootstrapping, the
> packages are not cross-buildable and the upstream bootstrapping instructions
> are too tedious,

So far no issues were encountered when the bootstrapping procedure as
described in the README.bobatbootstrap file in icmake's src distribution is
followed. 

If you could be a bit more specific about what you mean by 'bootstrapping
instructions are too tedious' then I'm sure those instructions can be changed
so that they're less tedious. 

Wrt the package not being cross-buildable:

The https://packages.debian.org/sid/libbobcat-dev shows the following lines
for armel and armhf:

armel   6.04.00-1   1,604.2 kB  8,598.0 kB  [list of files]
armhf   6.04.00-1   1,608.4 kB  8,126.0 kB  [list of files] 

although I also see packages for which version 6.04.00-1+b2 or 6.04.00-1+b4 is
listed. So maybe for unstable some issues recently appeared?

Also, the bootstrapping procedure is only required when icmake isn't avaialble
yet. For the construction of the bobcat library icmake 11.01.02-1 is required,
and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since
bullseye (oldstable).

So maybe you can also provide some info about why the bootstrapping procedure
is needed/used?

In any case: the dependence on icmake when constructing the full bobcat
library could be avoided, but I'd rather not do that once icmake *is*
available. So please advise.


-- 
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature

Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"

[Frank Heckenbach]

Package: libc-bin
Version: 2.36-9+deb12u4
Severity: normal
File: /usr/bin/iconv

% printf '\xc3\xa4' | iconv -futf8 -tascii
iconv: illegal input sequence at position 0

- First, according to the FSF's own coding standards
  (https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html),
  it should be "invalid" instead of "illegal" since this byte sequence is not
  "prohibited by law".

- The input sequence is not even invalid. It's correct UTF-8 for U+00E4.
  The actual problem is that this character is not representable in the output
  charset. The message gives no indication about this.

- I tried to report it upstream, but that's also broken. According to
  https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs
  should be reported at https://www.gnu.org/software/libc/bugs.html, but this
  page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html
  which does not mention reporting bugs.

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.36-9+deb12u4

Versions of packages libc-bin recommends:
ii  manpages  6.03-2

libc-bin suggests no packages.

-- debconf-show failed

Bug#1067240: debootstrap: Devuan install scripts in /usr/share/debootstrap/scripts/

[Frank Guthausen]

Package: debootstrap
Version: 1.0.134
Severity: wishlist
X-Debbugs-Cc: frank.guthausen.2...@gmail.com

file
/usr/share/debootstrap/scripts/ceres
contains wrong keyring line

keyring /usr/share/keyrings/debian-archive-keyring.gpg

which should be

keyring /usr/share/keyrings/devuan-archive-keyring.gpg

#

files

/usr/share/debootstrap/scripts/ascii
/usr/share/debootstrap/scripts/beowulf

symlink wrong to sid
but should be symlinks to ceres.

#

symlinks

/usr/share/debootstrap/scripts/chimaera
/usr/share/debootstrap/scripts/daedalus
/usr/share/debootstrap/scripts/excalibur

to ceres are missing.

#

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

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

Versions of packages debootstrap depends on:
ii  wget  1.21.4-1+b1

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2023.4
pn  gnupg   
ii  mount   2.39.3-6

Versions of packages debootstrap suggests:
pn  binutils
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.6.0-0.2
ii  zstd1.5.5+dfsg2-2

-- no debconf information

Bug#1055771: sysvinit script corrections

[Frank Lienhard]

On 17.03.2024 20:24, Jonas Smedegaard wrote:

It would be helful if you could double-check using newest package and
with*only*  the init script change, leaving all other settings at their
defaults and with no prior Radicale-related files created on the system
- and then check if the logging works as intended.

I'm not totally certain what you mean by that.
Here is what I think. Using a fresh install, install radicale and only 
add the logging part to the initscript or the $dir part, too?


Without any changes in /etc/radicale. (tha is the 5-minute install from 
the radicale website).


greets
Frank

Bug#1055771: sysvinit script corrections

[Frank Lienhard]

On 17.03.2024 00:55, Jonas Smedegaard wrote:

Thanks for the proposed patch.
Unfortunately it does not apply to the Debian package.

First: apologies.
I seem to have made a mistake during my dist-upgrade and ended up with 
the old init-script, which makes my provided "patch" logically totally 
wrong.



Please provide a patch against the Debian package (not Devuan).
which makes this request unnecessary, because the devuan package is 
identical to the debian package.


Also, nothing else in the Debian packaging messes with the path
"$dir/collection-root" - that is left for Radicale itself to handle.
Can you please test if adequate to replace the 3 instances of
"$dir/collections" with "$dir" instead?


So the actual needed patch is quite small and more cosmetic, since it 
works out of the box, just w/o logging. And your suggested adjustment 
works, too.


Again, apologies for my f***up.

I had a minor problem changing the storage dir.
All works fine with the defaults storage dir 
(/var/lib/radicale/collections). When changing it to a different 
location in the config file, I only got it working, if I do not generate 
the "storage" part from "filesystem_folder = /path/to/storage" beforehand.


Otherwise I get a write permission problem.--- radicale_orig	2024-03-17 18:39:40.696898778 +0100
+++ radicale	2024-03-17 18:41:25.995228178 +0100
@@ -55,9 +55,9 @@
 			chown $DAEMON_UID:$DAEMON_GID $dir
 			chmod g-w,o-rwx $dir
 			if [ "$CALDIR" = $dir ]; then
-[ -e $dir/collections ] || mkdir -p $dir/collections
-chown $DAEMON_UID:$DAEMON_GID $dir/collections
-chmod g-w,o-rwx $dir/collections
+[ -e $dir ] || mkdir -p $dir
+chown $DAEMON_UID:$DAEMON_GID $dir
+chmod g-w,o-rwx $dir
 			fi
 		fi
 	done
@@ -70,7 +70,7 @@
 	start-stop-daemon --start --quiet --startas $DAEMON \
 		--exec $DAEMON --test > /dev/null \
 		|| return 1
-	start-stop-daemon --start --quiet --startas $DAEMON --background \
+	start-stop-daemon --start --quiet --startas $DAEMON --background --output $LOGDIR/$NAME.log \
 		--exec $DAEMON --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
 		$RADICALE_OPTS \
 		|| return 2

Bug#1055771: sysvinit script corrections

[Frank Lienhard]

Package: radicale
Version: 3.1.8-2
[..]
Filename: pool/DEBIAN/main/r/radicale/radicale_3.1.8-2_all.deb

My System
Devuan Daedalus (radicale package the debian bookworm packge)
6.1.0-18-amd64

So applied changes from #1038930 and #1055771

I'm not a 100% sure that I had the unmodified original, so it would be 
nice if someone could re-check my attached patch--- radicale_orig	2024-03-09 10:46:34.564111521 +0100
+++ radicale	2024-03-12 17:29:29.364390914 +0100
@@ -34,7 +34,7 @@
 . /lib/lsb/init-functions
 
 # Declare default options
-RADICALE_OPTS="--daemon"
+RADICALE_OPTS=""
 
 # Read configuration variable file if it is present
 [ -r /etc/default/$NAME ] && . /etc/default/$NAME
@@ -55,9 +55,9 @@
 			chown $DAEMON_UID:$DAEMON_GID $dir
 			chmod g-w,o-rwx $dir
 			if [ "$CALDIR" = $dir ]; then
-[ -e $dir/collections ] || mkdir -p $dir/collections
-chown $DAEMON_UID:$DAEMON_GID $dir/collections
-chmod g-w,o-rwx $dir/collections
+[ -e $dir/collection-root ] || mkdir -p $dir/collection-root
+chown $DAEMON_UID:$DAEMON_GID $dir/collection-root
+chmod g-w,o-rwx $dir/collection-root
 			fi
 		fi
 	done
@@ -68,10 +68,10 @@
 	fi
 
 	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --test > /dev/null \
+		--exec $DAEMON --test > /dev/null \
 		|| return 1
-	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
+	start-stop-daemon --start --quiet --startas $DAEMON --background --output $LOGDIR/$NAME.log \
+		--exec $DAEMON --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
 		$RADICALE_OPTS \
 		|| return 2
 }
@@ -86,7 +86,7 @@
 	#   1 if daemon was already stopped
 	#   2 if daemon could not be stopped
 	#   other if a failure occurred
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --name $NAME
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DAEMON_UID
 }
 
 case "$1" in

Bug#1064258: Upstream moved to github

[Frank Mascal]

Hi,

Note that further developments moved to: https://github.com/v1cont/yad

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Frank Weißer]

Hi Pascal,

Pascal Hambourg:

On 29/02/2024 at 08:51, Frank Weißer wrote:


Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(


eth* names are no persistent and may change at any boot.
But ethernet interface should get predictable names like enpXsY or enoX.
In /proc/interrupts we can see enp1s0.


Thank you for the epiphany!


randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'


By "randomized" do you mean "plain dm-crypt with random key" ?


yes


The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab


These two remind me of Bug#995108 ("d-i: partman-crypto: plain dm-crypt 
device management issues").

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995108>


seems so


I had submitted a patch but received no feedback so far.
<https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/4>

:-(

Kind regards

readU
Frank

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Frank Weißer]

Package: installation-reports
Severity: wishlist

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
http://get.debian.org/cdimage/release/current/amd64/iso-bd/debian-edu-12.5.0-amd64-BD-1.iso
 2024-02-10 14:48
http://get.debian.org/cdimage/release/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
http://get.debian.org/cdimage/release/current/amd64/iso-cd/debian-edu-12.5.0-amd64-netinst.iso
http://get.debian.org/cdimage/archive/11.0.0/i386/iso-cd/debian-11.0.0-i386-netinst.iso
and others too
Date: <2024-02-24 15:20>

Machine: Fujitsu Esprimo C710 Intel Core i3-2100T CPU @ 2.50GHz 32GB RAM 120GB 
SSD 4TB HDD
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[0]
Configure network:  [E]
Detect media:   [0]
Load installer modules: [0]
Clock/timezone setup:   [0]
User/password setup:[0]
Detect hard drives: [0]
Partition hard drives:  [E]
Install base system:[0]
Install tasks:  [0]
Install boot loader:[0]
Overall install:[0]

Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(

randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'

The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==

==
Installer hardware-summary:
==
uname -a: Linux tjener.intern 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.76-1 (2024-02-01) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0100] (rev 09)
lspci -knn: DeviceName:  PCH Q75
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller [8086:0102] 
(rev 09)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V 
Gigabit Network Connection [8086:1503] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d9]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d8]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244e] (rev a4)

Bug#1061590: sysfsutil invalid parsing of whitespace in value

[Klaus Frank]

Package: sysfsutils
Version: 2.1.1-6
Severity: important

When the value part of an entry in /etc/sysfs.conf contains a whitespace it 
gets incorreclty parsed by the init script and therefore fails.

`/etc/sysfs.conf`:
```
bus/virtio/drivers/virtio_blk/virtio1/block/vda/cache_type = write through
```

error:
```
syntax error in /etc/sysfs.conf: 
'bus/virtio/drivers/virtio_blk/virtio1/block/vda/cache_type' 'write' 'through' 
... failed!
```


# dpkg --status sysfsutils
Package: sysfsutils
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 67
Maintainer: Guillem Jover 
Architecture: amd64
Multi-Arch: foreign
Version: 2.1.1-6
Depends: libc6 (>= 2.34), libsysfs2 (>= 2.1.1), sysvinit-utils (>= 3.05-4~), 
pci.ids
Pre-Depends: init-system-helpers (>= 1.54~)
Conffiles:
 /etc/init.d/sysfsutils 597d2442fa3a55417cf3e49edeea6b6e
 /etc/sysfs.conf c11f380832980cdee233b7412ff4a04c
Description: sysfs query tool and boot-time setup
 The sysfs is a virtual file system found in Linux kernels 2.5+ that provides
 a tree of system devices. This package provides the program 'systool' to
 query it, which can be used to list devices by bus, class, and topology.
 .
 In addition this package ships a configuration file /etc/sysfs.conf which
 allows one to conveniently set sysfs attributes at system bootup (via an
 init script).
Homepage: https://github.com/linux-ras/sysfsutils

# dpkg --list sysfsutils
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  sysfsutils 2.1.1-6  amd64sysfs query tool and boot-time 
setup

# dpkg --search sysfsutils
sysfsutils: /usr/share/doc/sysfsutils/copyright
sysfsutils: /usr/lib/systemd/system/sysfsutils.service
sysfsutils: /etc/init.d/sysfsutils
sysfsutils: /usr/share/doc/sysfsutils/changelog.Debian.gz
sysfsutils: /usr/share/doc/sysfsutils

Bug#1061510: Engrampa fails to handle 7z and zip archives

[Frank de Bruijn]

Package: engrampa
Version: 1.26.1-2
Severity: Normal

Also: https://bugs.launchpad.net/ubuntu/+source/engrampa/+bug/2051014

After p7zip was replaced with 7zip, engrampa will no longer create or 
open 7z and zip archives. This is a known problem which has already been 
fixed upstream in version 1.27.


https://github.com/mate-desktop/engrampa/issues/433
https://github.com/mate-desktop/engrampa/pull/472


Using: Debian Testing 64-bit
Kernel: Linux asus 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 
(2023-11-29) x86_64 GNU/Linux

libc6: 2.37-13

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

[Frank Loeffler]

Hi,

just to add a small bit of information:

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


A game that still uses the library, although not being shipped with 
Debian (while in principle, it could), is "The Secret Chronicles of Dr. 
M." (https://secretchronicles.org/en/).


On that note: the current version in Debian is called 
"0.8.7+git20220615-3". I did assume this is the git version of the 
master branch on date 20220615 of the main repo 
https://github.com/cegui/cegui/. However, that cannot be, as changes 
made in that repo are not present in the Debian package. One example is 
Editbox.cpp: compare that file in


https://github.com/cegui/cegui/tree/master/cegui/src/widgets (2 years 
old)


to the one here:

https://salsa.debian.org/games-team/cegui-mk2/-/tree/master/cegui/src/widgets?ref_type=heads 
(8 years old)


That file is special only insofar as TSC currently faces the problem 
that the version of cegui in Debian is too old to be used with a 
"current" build against cegui, see 
https://github.com/Secretchronicles/TSC/issues/708.


Frank



signature.asc
Description: PGP signature

Bug#777584: wrap long lines

[Frank Heckenbach]

Hello Georges,

> thank you for your response.

I was busy otherwise recently. I suppose, this is still open, isn't it?

> cron is a key command for UNIX systems, and it is supposed to remain
> lightweight and efficient. This is why it does not implement the mailing
> features, and relies on other UNIX commands to do this job (`mail` or
> `sendmail`)
> 
> You can browse the file do_command.c in cron's source package, and read,
> near line 360, how cron does its job to collect data coming from
> children commands, and compose an e-mail.
>
> So far, the output of the child command is just appended to a text
> stream, which begins with From:, To:, Subject:, Date: lines. However you
> are searching to address the case when the output of the command is too
> big to be just appended to such a text file.
>
> In the case of a big output, the solution would be to encode it (QP or
> base64 are possible encodings), but in such a case, they should not be
> appended to the same stream which contains From:, To:, Subject:, Date:
> lines, but included in a separate stream, and handed to `send` or
> `sendmail` command as an attachment.

Not necessarily an attachment. They can be appended to the stream,
provided that the Content-Transfer-Encoding header is set
appropriately, which would have to be done retroactively when we
encounter long lines.

However, when reading the code, I noticed that cron uses 8bit
transfer encoding by default, but already accepts the environment
variable CONTENT_TRANSFER_ENCODING and passes it through to the mail
header, but without doing any encoding itself. So this only works if
the cron command's output is already encoded which seems strange.
I don't know how people use this option (and I guess neither do
you?). Maybe it's just a relic from back when cron used 7bit by
default, so it was needed for any non-ASCII output at all.

Anyway, given that this variable exists, perhaps we can add a
special value, say "auto", which cron would turn into some encoding
(I'd suggest quoted-printable). So if the environment variable is
set to some other value, nothing will change, but if set to "auto",
it will put QP in the header and do QP encoding itself.

This would be backward-compatible. However, it would require
everyone who's affected by this problem to put something like
"CONTENT_TRANSFER_ENCODING=auto" in their crontab, and in a few
years, people will wonder why such a silly thing is required.

We could go one step further and make "auto" the default. I *think*
these days every mail client should support QP, but you never know
(https://xkcd.com/1172/). In any case, those who want the old
behaviour could still get it by setting
"CONTENT_TRANSFER_ENCODING=8bit".

So that would be a transparent bugfix, but not
100% backward-compatible, and may require action by (I hope) just a
few users.

What do you think?

> ---
> 
> Would you please be kind enough to propose a patch for the file
> do_command.c, which implements encoding and attaching big outputs?

I think I can write the code. Fortunately, QP is not too complex and
rather easy to implement on the fly without any dependencies.

> If you can do it, I would be very pleased to read your code and include
> your patch to the series of patches which are part of the debian source
> package, in order to create this new feature.
> 
> By the way, if you modify the way cron sends e-mails, please can you
> propose a simple test to check whether your modification is running as
> expected? This test will be appended to the series used in autopkgtest,
> in order to prevent eventual future regressions.

Unfortunately, I'm not familiar with the test framework. I can
certainly provide some crontabs and expected mails, but I'd have to
leave it to you to integrate them.

Regards,
Frank

Bug#1055418: systemtap: autopkgtest regression: Pass 4: compilation failed. [man error::pass4]

[Frank Ch. Eigler]

Hi -

> Version: 4.9-1
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemtap/39374282/log.gz
> 
> 223s /usr/share/systemtap/runtime/linux/print.c:367:46: error: ‘struct
> module’ has no member named ‘core_text_size’; did you mean
> ‘kprobes_text_size’?
> 223s   367 |(unsigned long)
> (THIS_MODULE->core_text_size)/1024,
> 223s   |  ^~
> 223s /usr/src/linux-headers-6.5.0-3-common/include/linux/printk.h:427:33:
> note: in definition of macro ‘printk_index_wrap’
> [...]
> [/usr/src/linux-headers-6.5.0-3-common/scripts/Makefile.build:248:

> 223s Tip: /usr/share/doc/systemtap/README.Debian should help you get
> started.

These errors are typical of the situation where a kernel is much newer
than the release of systemtap that you're using.  Version 5.0,
released this past weekend, supports all the way up to 6.6.
Unfortunately, the kernel API is a not a stationary target, so regular
updates are necessary.

- FChE

Bug#1054602: mosdepth: Needs "libhts.so" as a dependency, avaialbe in package "libhts-dev"

[Frank Bearoff]

Package: mosdepth
Version: 0.3.3+ds-2
Severity: important
X-Debbugs-Cc: fbear...@gmail.com

Dear Maintainer,

* What led up to the situation?
sudo apt install "mosdepth"

* What exactly did you do (or not do) that was effective (or
 ineffective)?
 sudo apt install "libhts-dev"

* What was the outcome of this action?
mosdepth works

It appears "mosdepth has the undecalred dependency of "libhts-dev"

Thanks!

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/64 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 mosdepth depends on:
ii  libc6  2.36-9+deb12u3

mosdepth recommends no packages.

mosdepth suggests no packages.

-- no debconf information

Bug#1053740: /usr/bin/rsvg-convert (pdf): different x/y scale only respected for stroke, not fill of same text

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.54.7+dfsg-1~deb12u1
Severity: normal
File: /usr/bin/rsvg-convert

% cat test.svg

ABC

% rsvg-convert -f pdf -o test.pdf test.svg

The resulting pdf has the outline (stroke) correctly, but the filled
letters are spaced without respecting the scale, see attached
screenshot from okular. When both x and y are scaled the same, the
result is correct. (Honestly, I find it hard to imagine what would
cause such a strange bug, shouldn't the placement of the letters
always be the same for stroke and fill?)

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages librsvg2-bin depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  librsvg2-2   2.54.7+dfsg-1~deb12u1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#1050378: python3-selenium: still errors

[Frank de Bruijn]

With 4.12.0+dfsg-1, this becomes:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/driver_finder.py", 
line 38, in get_path
path = SeleniumManager().driver_location(options) if path is None 
else path

   ^^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 78, in driver_location

args = [str(self.get_binary()), "--browser", browser]
^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 57, in get_binary

if not path.is_file() and os.environ["CONDA_PREFIX"]:
  ~~
  File "", line 679, in __getitem__
KeyError: 'CONDA_PREFIX'

Bug#777584: wrap long lines

[Frank Heckenbach]

Hello,

> I am the new maintainer for cron package, since a few months. Please can
> one elaborate a little longer about use cases where too long lines are a
> problem?

Thanks for picking up this issue again. I'm not the original
reporter, but also effected, as I wrote in my comment last year.

SMTP standards (RFC 2822) specify a maximum line length of 998
characters.

It can be avoided by encoding the mail. QP (quoted-printable) and
base64 are common encdings. QP can break source lines (by inserting
"=\n" anywhere), and base64 output doesn't care about line breaks at
all.

> Would it be sufficient to truncate such lines to 998 characters, hoping
> that such a length would be sufficient to diagnose a problem?

This would lose information. I don't think I'd like this unless the
original content was stored somewhere and the mail contains a link
where to find it. But that seems more work than the alternatives.

> It would
> be more secure than splitting them and making it possible to overflow
> the file system (for example with too big messages, repeated every
> minute during one day).

Overflowing the file system is a separate issue which can just as
well happen with many short lines. Sure, you might want to handle
this too, but for that you'd might want to set a maximum size (say,
in MB and perferably configurable) independent of line lengths.

Regards,
Frank

Bug#1050378: python3-selenium can't find a driver

[Frank de Bruijn]

Package: python3-selenium
Version: 4.11.2+dfsg-1
Severity: normal

After upgrading to version 4.11.2+dfsg-1, python3-selenium fails with:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/driver_finder.py", 
line 38, in get_path
path = SeleniumManager().driver_location(options) if path is None 
else path

   ^^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 73, in driver_location

args = [str(self.get_binary()), "--browser", browser]
^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 57, in get_binary
raise WebDriverException(f"Unable to obtain working Selenium 
Manager binary; {path}")
selenium.common.exceptions.WebDriverException: Message: Unable to obtain 
working Selenium Manager binary; 
/usr/lib/python3/dist-packages/selenium/webdriver/common/linux/selenium-manager


Reverting to 4.10.0+dfsg-1 clears the problem.

Using: Debian Testing 64-bit
Kernel: Linux asus 6.4.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3 
(2023-08-08) x86_64 GNU/Linux

libc6: 2.37-7

Installed versions of packages python3-selenium depends on or recommends:
ii  python3 3.11.4-5+b1
ii  python3-certifi 2022.9.24-1
ii  python3-trio0.22.2-1
ii  python3-trio-websocket  0.10.3-1
ii  python3-urllib3 1.26.16-1
ii  chromium-driver 115.0.5790.170-1


This appears to be the same issue as reported here:
https://bugs.launchpad.net/ubuntu/+source/python-selenium/+bug/2032687

Bug#1049986: ITP: filtermail -- Filtermail filters incoming e-mail as accepted, spam, or ignored

[Frank B. Brokken]

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

* Package name: filtermail
  Version : 1.02.00
  Upstream Contact: Frank B. Brokken 
* URL : https://fbb-git.gitlab.io/filtermail
* License : GPL
  Programming Lang: C++
  Description : Filtermail filters incoming e-mail as accepted, spam, or 
ignored

Filtermail filters incoming e-mail as either accepted, spam, or ignored
e-mail. It uses rule files, which are inspected in sequence until the incoming
e-mail matches a rule. Once that happens the rule's associated action (accept,
spam, or ignore) is executed. If the e-mail is not matched by any rule then
the e-mail is accepted.

Accepted e-mail normally is appended to the mail file which is used by the
incoming mail server when receiving mail for the current user. E.g., if the
user's username is frank then incoming mail is appended to the file
/var/mail/frank. Users may also define directories to contain saved e-mails
(e.g., ~/Mail), and filtermail can be configured to append e-mail considered as
spam to, e.g., ~/Mail/spam. Likewise, e-mail matching the 'ignore'
criteria could be appended to ~/Mail/ignore. 

Instead of appending the complete e-mail to its destination file the received
e-mail's From: and Subject: headers can be appended to its destination
file. Alternatively, such e-mail can also be ignored, losing it completely.

Filtermail uses three types of files:
* The configuration file contains values of options with are generally
used (covered in the man-page's sections CONFIGURATION and OPTIONS);
* Mail filtering rules are hierarchically ordered in the rules
file: incoming mail is sequentially matched against the patterns
defined in files specified in the rules file until a match is
found. Once a match has been found the rule's action (accept, ignore
or spam) is executed, ending the filtering process;
* Each file specified in the rules file defines matching patterns, which
are tested sequentially. Testing those patterns ends once the incoming
mail matches a pattern.

In addition to the filtermail program itself a small support program 'inspect'
is part of filtermail: inspect expects a received e-mail file at its standard
input. Mail handling programs (e.g., mutt(1)) allow its users to pipe an
e-mail file to a program, inspecting the received e-mail.  Depending on the
content of the Received: headers inspect's output shows the domain name of the
sender, its IP address, its country of origin and the cidr-range containing
the received IP address. If the received e-mail is considered conspicuous
(e.g., spam or mail to ignore) then the mail's details, e.g. its cidr
range. could be added to the file recognizing spam-rated e-mail.

 - why is this package useful/relevant? 
The main reason for developing filtermail was the fact that I frequently
receive mail which is either spam or which is completely irrelevant and
annoying. Previously I used a bash-script to filter such mail, but that
script eventually was hard to maintain. A compilable program offers, IMHO,
better facilities for maintenance and modifications so I wrote
filtermail. Over the past three months it performed its job as
expected. E.g., of the about 300 e-mails I received in the category
'igored' were all correctly categorized.

  - it a dependency for another package? 
 No, it's a stand-alone program

  - do you use it? 
 Yes, I do

  - if there are other packages providing similar functionality, how does it
compare?  
 There exists a program 'mailfilter' focusing on handling pop-accounts and
 also offering ways to recognize e-mail as spam. Filtermail, on the other
 hand, uses the 'ignore' category in addition to the 'spam' category and
 primarily aims at categorizing (in various forms) incoming e-mail.

 - how do you plan to maintain it? 
 I have a long history of building and maintaining programs, many of them
 are also registered as Debian packages. I handle the maintenance of the
 programs myself, and almost all my direct contact with Debian is via Tony
 Mancill (tmanc...@debian.org) who is a Debian developer. When there's a
 new version of one of my Debian provided programs I prepare the required
 update, upload it to salsa, and send Tony an e-mail asking him to verify
 the latest update.

 Filtermail's website is at https://fbb-git.gitlab.io/filtermail/ where
 you also find links to the man-pages, to its repository, and to a list of
 programs I developed, most of them are available as Debian packages.

   - do you need a sponsor?
  If I'm correct then the 'sponsor' is a Debian maintainer who's willing to
  adopt a program for Debian. If so, then yes, I do.
  
I hope you like filtermail!

Bug#1047029: systemtap: Fails to build source after successful build

[Frank Ch. Eigler]

Hi -

> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).

This "make clean" imperfection is improved with upstream commit 88aa8253.

- FChE

Bug#1042862: Xspice crashes on start

[Frank Heckenbach]

Package: xserver-xspice
Version: 0.1.6-1
Severity: grave
Justification: renders package unusable

See #1038648.

As I wrote there, 0.1.6-1 doesn't fix the problem, but this was
ignored, so I'm sending a new bug report.

The buggy patch is now upstream, but that doesn't make it correct.
I've already explained how to fix it correctly.

Bug#1042764: dvbcut: A warning or possibly an error is issued when exporting.

[Frank Zündorff]

Package: dvbcut
Version: 0.7.4-1+b1
Severity: normal
X-Debbugs-Cc: frank.zuendo...@gmail.com

Dear Maintainer,

when I cut and export a DVB recording with this version of dvbcut, there is a 
message in the output window:

  Neukodierung von 1 Bild
  avcodec_open(mpeg2video_encoder): Rückgabewert -22

which means in english:

  Re-encoding of 1 picture
  Return value -22

The following message is displayed on the console in parallel:

  [mpeg2video @ 0x55ffbaad14c0] The encoder timebase is not set.

The export does not abort, the stream is playable afterwards, but may not be 
complete.

I can reproduce the message with different recordings. (current and
older ones eg. >4 years). I saw this behavior never before in older
versions of dvbcut.

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

Kernel: Linux 6.4.7-1-siduction-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dvbcut depends on:
ii  liba52-0.7.40.7.4-20
ii  libao4  1.2.2+20180113-1.1
ii  libavcodec607:6.0-4
ii  libavformat60   7:6.0-4
ii  libavutil58 7:6.0-4
ii  libc6   2.37-6
ii  libgcc-s1   13.1.0-9
ii  libmad0 0.15.1b-10.1+b1
ii  libqt5core5a5.15.10+dfsg-3
ii  libqt5gui5  5.15.10+dfsg-3
ii  libqt5widgets5  5.15.10+dfsg-3
ii  libqt5xml5  5.15.10+dfsg-3
ii  libstdc++6  13.1.0-9
ii  libswscale7 7:6.0-4

Versions of packages dvbcut recommends:
ii  mplayer  2:1.5+svn38423-2+b1

dvbcut suggests no packages.

-- no debconf information

Bug#1040467: file: /sys/firmware/acpi/bgrt/image strange behaviour

[frank]

Package: file
Followup-For: Bug #1040467

Indeed if I only read 4096 bytes, I get:
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 5.5761e-05 s, 73.5 MB/s
/dev/stdin: data

If I read the entire file size, except for the last byte, I still get:
$ dd if=/tmp/image bs=$(( $(stat --format=%s /tmp/image) - 1)) count=1 | file -
1+0 records in
1+0 records out
565109 bytes (565 kB, 552 KiB) copied, 0.00157071 s, 360 MB/s
/dev/stdin: data

Only when I read the whole file, then I get:
$ dd if=/tmp/image bs=$(stat --format=%s /tmp/image) count=1 | file -
1+0 records in
1+0 records out
565110 bytes (565 kB, 552 KiB) copied, 0.00156589 s, 361 MB/s
/dev/stdin: PC bitmap, Windows 3.x format, 434 x 432 x 24, image size 565056, 
cbSize 565110, bits offset 54

So it appears the very last byte is still important for correct detection of 
the image file through `file` and 4096 bytes will never be enough in this case.

For unknown reasons, this workaround does not work, because nbytes=4096 is 
still being used:
$ 

Bug#1041740: Error: Regex version mismatch, expected: 10.42 2022-12-11 actual: 10.36 2020-12-04

[Frank lin Piat]

Package: selinux-policy-default
Version: 2:2.20210203-7
Severity: minor

After upgading from bullseye to bookworm...
I had the following error many time (tens or hundreds times) when I use 
apt/dpkg programs:

> dpkg: warning: selinux: Regex version mismatch, expected: 10.42 2022-12-11 
> actual: 10.36 2020-12-04

I installed SELinux at some point on my system and partially removed it.
Some packages were in configured (uninstalled) state.

After purging those packages configuraiton, the error don't occur anymore :

Purging configuration files for selinux-basics (0.5.8) ...
Purging configuration files for selinux-policy-dev (2:2.20210203-7) ...
Purging configuration files for at (3.1.23-1) ...
Purging configuration files for selinux-policy-default (2:2.20210203-7) ...
Purging configuration files for setools-gui (4.3.0-2) ...
Purging configuration files for discover (2.1.2-8) ...


My assumption is that this error wouldn't occur anymore if the packages were
installed state during the upgrade.

Thanks

Franklin Piat

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.4-1+b6
ii  libsemanage2 3.4-1+b5
ii  libsepol23.4-2.1
pn  policycoreutils  
pn  selinux-utils

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#1041739: Error: Regex version mismatch, expected: 10.42 2022-12-11 actual: 10.36 2020-12-04

[Frank Lin PIAT]

Package: selinux-policy-default
Version: 2:2.20210203-7
Severity: minor

After upgading from bullseye to bookworm...
I had the following error many time (tens or hundreds times) when I use 
apt/dpkg programs:

> dpkg: warning: selinux: Regex version mismatch, expected: 10.42 2022-12-11 
> actual: 10.36 2020-12-04

I installed SELinux at some point on my system and partially removed it.
Some packages were in configured (uninstalled) state.

After purging those packages configuraiton, the error don't occur
anymore :

Purging configuration files for selinux-basics (0.5.8) ...
Purging configuration files for selinux-policy-dev (2:2.20210203-7) ...
Purging configuration files for at (3.1.23-1) ...
Purging configuration files for selinux-policy-default (2:2.20210203-7) ...
Purging configuration files for setools-gui (4.3.0-2) ...
Purging configuration files for discover (2.1.2-8) ...


My assumption is that this error wouldn't occur anymore if the packages were
installed state during the upgrade.

Thanks

Franklin Piat

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.4-1+b6
ii  libsemanage2 3.4-1+b5
ii  libsepol23.4-2.1
pn  policycoreutils  
pn  selinux-utils

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Patrick Frank]

Package: dosbox
X-Debbugs-Cc: foss.conn...@kaffeeschluerfer.com
Version: 0.74-3-4+b1
Severity: normal

Hello,

it is true that the config option "usescancodes=false" affects the problem
of keys not functioning as expected, but only by ~50% in combination with
"keyboardlayout=de". You can get only one of both halfs of the special
keys. Very curious for me - either you get the ":" char or the arrow keys
and the "-" char. So it locks me out of several use cases. At least when
you install / configure they keyboard layout "German" and the system
language "English".


-- System Information:

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

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

Versions of packages dosbox depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9
ii  libgcc-s112.2.0-14
ii  libgl1   1.6.0-1
ii  libpng16-16  1.6.39-2
ii  libsdl-net1.21.2.8-6+b1
ii  libsdl-sound1.2  1.0.3-9+b2
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   12.2.0-14
ii  libx11-6 2:1.8.4-2+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Bug#1040467: file: /sys/firmware/acpi/bgrt/image strange behaviour

[frank]

Package: file
Version: 1:5.44-3
Severity: normal

Dear Maintainer,

UEFI systems make the boot logo accessible for reading at the path 
/sys/firmware/acpi/bgrt/image

The file can be displayed directly using for example:
$ feh /sys/firmware/acpi/bgrt/image

Strange things happen when you copy this file elsewhere:
$ cp /sys/firmware/acpi/bgrt/image /tmp/image

and then run `file` on it:
$ file /sys/firmware/acpi/bgrt/image /tmp/image
/sys/firmware/acpi/bgrt/image: data
/tmp/image:PC bitmap, Windows 3.x format, 434 x 432 x 24, 
image size 565056, cbSize 565110, bits offset 54

If you diff those files, they are the same:
$ diff -s /sys/firmware/acpi/bgrt/image /tmp/image
Files /sys/firmware/acpi/bgrt/image and /tmp/image are identical

If you use the -d flag for `file`, it will produce internal debugging 
information:
$ file -d /sys/firmware/acpi/bgrt/image >/tmp/sys-firmware-acpi-bgrt-image.log 
2>&1
$ file -d /tmp/image >/tmp/tmp-image.log 2>&1

If you then diff those logfiles, you can notice that that 
/tmp/sys-firmware-acpi-bgrt-image.log only uses nbytes=4096, whereas 
/tmp/tmp-image.log uses nbytes=565110. /tmp/sys-firmware-acpi-bgrt-image.log 
also fails to match the bitmap for unknown reason.

Please forward this bug upstream if it's not only on debian, thank you.

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

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

Versions of packages file depends on:
ii  libc6  2.36-9
ii  libmagic1  1:5.44-3

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#1038648: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1038648: fixed in xserver-xorg-video-qxl 0.1.6-1)

[Frank Heckenbach]

Doesn't fix the problem.

Bug#1038648: Xspice crashes on start

[Frank Heckenbach]

Control: tags patch

I think I found the problem. It seems to be
Fix-a-build-error-with-Xorg-master.patch

To be honest, I don't really understand the patch. According to the
comment, instead of just changing one renamed parameter, it changes
the calling conventions at the cost of an unnecessary "slight
performance drop" in not one but three functions "for consistency"
and goes on to explain why it should work which sounds questionable
to me and apparently doesn't work after all.

So instead doing the simple thing seems to work. I suggest replacing
the patch with this one:

Index: xserver-xorg-video-qxl-0.1.5+git20200331/src/qxl_option_helpers.c
===
--- xserver-xorg-video-qxl-0.1.5+git20200331.orig/src/qxl_option_helpers.c
+++ xserver-xorg-video-qxl-0.1.5+git20200331/src/qxl_option_helpers.c
@@ -34,7 +34,7 @@ int get_bool_option(OptionInfoPtr option
 const char* value = getenv(env_name);
 
 if (!value) {
-return options[option_index].value.bool;
+return options[option_index].value.boolean;
 }
 if (strcmp(value, "0") == 0 ||
 strcasecmp(value, "off") == 0 ||

Bug#1038648: Xspice crashes on start

[Frank Heckenbach]

Package: xserver-xspice
Version: 0.1.5+git20200331-3
Severity: grave
Justification: renders package unusable

Since upgrading to bookworm, Xspice always crashes when I try to
start it:

Xspice --config xspice.1.conf :25

(EE) Caught signal 6 (Aborted). Server aborting

Full log: xspice.1.log

https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/issues/14
describes a similar problem and suggest to add some options in the
config file. When I do this, I get a segfault instead:

Xspice --config xspice.2.conf :25

(EE) Caught signal 11 (Segmentation fault). Server aborting

Full log: xspice.2.log

The page above mentions this too and refers to
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/+bug/1967719

That report was closed since they were "confident it was fixed in
https://launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/0.1.5+git20200331-3;.
However, the same version seems to be in bookworm (unless Debian
made its own changes to it), and the problem does occur.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xspice depends on:
ii  libc6  2.36-9
ii  libspice-server1   0.15.1-1
ii  libxfont2  1:2.0.6-1
ii  python33.11.2-1+b1
ii  xserver-xorg   1:7.7+23
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.7-3

xserver-xspice recommends no packages.

xserver-xspice suggests no packages.

-- no debconf information


xspice.1.conf
Description: Binary data


xspice.1.log
Description: Binary data


xspice.2.conf
Description: Binary data


xspice.2.log
Description: Binary data

Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)

[Frank Heckenbach]

> > You added a "Requires.private" in the .pc, but that doesn't help.
> > "Requires" is required (sic!) because a program that links to ortp
> > apparently must also link to bctoolbox.
> 
> Dude, did you not see that the string "bctbx_set_log_level_mask" does
> not occur anywhere in your program?  And that as a consequence the
> error message does not really make any sense?  Because if you did see
> it then you could have said something.

Sorry, I did suggest to add it as "Requires:" (not private) and
added a simple demo program to check it.

> It was not immediately obvious to me that ortp_set_log_level_mask() in
> the distant past was provided by libortp.so, but then replaced with
> bctbx_set_log_level_mask() from libbctoolbox.so and the name change
> papered over with a macro (instead of a wrapper function which would
> have preserved the old linkage relationship).

I didn't know these details and history either (my code using the
library was a few years old then, so I didn't remember all of it at
the time), just saw the error message and found that adding
-lbctoolbox fixed it.

> Anyway, I'll fix it when preparing 1:5.2.x which I'll try to get to in
> the coming weeks.

Thanks.

Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)

[Frank Heckenbach]

Package: libortp-dev
Version: 1:5.1.64-2
Severity: normal


> This is an automatic notification regarding your Bug report
> which was filed against the libortp-dev package:
>
> #994437: libortp: missing -lbctoolbox
>
> It has been closed by Debian FTP Masters 
> (reply to Bernhard Schmidt ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters  pmas...@ftp-master.debian.org> (reply to Bernhard Schmidt  >) by
> replying to this email.

It's actually not fixed!

You added a "Requires.private" in the .pc, but that doesn't help.
"Requires" is required (sic!) because a program that links to ortp
apparently must also link to bctoolbox.

My original test program still applies:

% cat a.c
#include 

int main ()
{
  ortp_init ();
  ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c  `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol 
'bctbx_set_log_level_mask'
/usr/bin/ld: /lib/x86_64-linux-gnu/libbctoolbox.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
% gcc a.c  `pkg-config --cflags --libs ortp` -lbctoolbox
% ./a.out

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[Frank Scheiner]

Hi all,

On 17.05.23 11:27, John Paul Adrian Glaubitz wrote:

Hi Michael!

On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:

On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:

After a long discussion on IRC and the mailing list, we have agreed to raise the
baseline for the alpha architecture to EV56 to improve the generated code and 
fix
a number of issues. The change is already being implemented in the glibc 
packages
which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 
[2].

Could you raise the baseline for gcc on alpha to EV56?

I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".


Yes, please!

I suggest the following in debian/rules2:

ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
   CONFARGS += --with-cpu=ev56 --with-tune=ev6
endif

(the --with-tune only affects instruction scheduling and better tunes
code for ev6 and more recent machines, but allows execution down to
ev56.)  I have tested this in the past with a rebuild of most packages
that are in the base essential chroot in the past and it works well.


Doesn't that come with a speed penalty for EV56 machines? I'm asking because 
EV56 is
currently the baseline for QEMU when emulating Alpha.


How high will it be? I have some numbers from my PWS 500au for 7z 16.02
and openssl 3.0.7, so we could compare that later on.

With everything below EV56 dropped, I'd say let's get everything out of
the later (real) machines and use "ev67" here. Even my DS20E already
uses EV67s.

UPDATE: Reading through [1] and [2], it looks like there's no difference
between EV6 and EV67 for instruction scheduling. So fine as proposed.

[1]: https://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html
[2]:
https://uprrp2.uprrp.edu/help?key=SQLPRE72~SQLPRE_Command_Line~Arguments~ARCHITECTURE=VMS%20Help=

Cheers,
Frank

Bug#1035044: autorandr: recommend libinput-tools missing

[Frank Scherrer]

Hi

On Fri, Apr 28, 2023 at 04:33:50PM -0700, Don Armstrong wrote:
> We currently aren't distributing (or installing) autorandr-lid-listener
> in the Debian package.

My bad. You are right, I was not talking about the package included in
debian. Did not realize/remember that I had the package built myself
from some instructions on github.

Thanks for looking into it!


signature.asc
Description: PGP signature

Bug#1035044: autorandr: recommend libinput-tools missing

[Frank Scherrer]

Package: autorandr
Version: 1.12.1-27-g4653ea6
Severity: minor

Dear Maintainer,

first: Thanks for your work, I was missing a tool like autorandr dearly and was
so glad I found it. That was years ago.

   * What led up to the situation?

I detected and stored two differend setups of Monitors, both connected to
docking-station and external monitor.
One with lid closed, one with lid open.

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

Opening or closing the lid.

   * What was the outcome of this action?

No change of Displays Configuration

   * What outcome did you expect instead?

Change of Displays Configuration

   * Additional Info apart from default questions

Systemd-Service autorandr-lid-listener failed with error:
In the journal of autorandr-lid-listener I found

  autorandr[51936]: stdbuf: failed to run command ‘libinput’: No such file or
directory

So I installed libinput-tools. Afterwards I could get the service started and
the Configuration changed after opening/closing the lid.

I suggest to put libinput-tools into the list of recommended packages.

Does this sound reasonable?

cheers
Frank


signature.asc
Description: PGP signature

Bug#1034708: lintian: false positive "build-depends-on-versioned-berkeley-db Build-Depends:libdb5.3-sql-dev"

[Frank Heckenbach]

Package: lintian
Version: 2.116.3
Severity: normal

I get the warning "build-depends-on-versioned-berkeley-db 
Build-Depends:libdb5.3-sql-dev"

My package used to depend on libdb-sql-dev, but this package doesn't
exist anymore in bookworm, so I think I have to depend on
libdb5.3-sql-dev now, don't I?

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

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

lintian recommends no packages.

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

-- no debconf information

Bug#1031899: radiotray

[Frank]

Would it make sense to contact Ed Bruck, who provides radiotray-ng 
(https://github.com/ebruck/radiotray-ng), about possible co-operation? 
It seems unproductive to have two incarnations of radiotray.


Regards,
Frank

Bug#1031380: install: options --compare (-C) and --preserve-timestamps are mutually exclusive

[Frank Heckenbach]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

===

% install -C -p x y
install: options --compare (-C) and --preserve-timestamps are mutually exclusive
Try 'install --help' for more information.
% install --help
Usage: install [OPTION]... [-T] SOURCE DEST
  or:  install [OPTION]... SOURCE... DIRECTORY
  or:  install [OPTION]... -t DIRECTORY SOURCE...
  or:  install [OPTION]... -d DIRECTORY...

This install program copies files (often just compiled) into destination
locations you choose.  If you want to download and install a ready-to-use
package on a GNU/Linux system, you should instead be using a package manager
like yum(1) or apt-get(1).

In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to
the existing DIRECTORY, while setting permission modes and owner/group.
In the 4th form, create all components of the given DIRECTORY(ies).

Mandatory arguments to long options are mandatory for short options too.
  --backup[=CONTROL]  make a backup of each existing destination file
  -b  like --backup but does not accept an argument
  -c  (ignored)
  -C, --compare   compare each pair of source and destination files, and
in some cases, do not modify the destination at all
  -d, --directory treat all arguments as directory names; create all
components of the specified directories
  -D  create all leading components of DEST except the last,
or all components of --target-directory,
then copy SOURCE to DEST
  -g, --group=GROUP   set group ownership, instead of process' current group
  -m, --mode=MODE set permission mode (as in chmod), instead of rwxr-xr-x
  -o, --owner=OWNER   set ownership (super-user only)
  -p, --preserve-timestamps   apply access/modification times of SOURCE files
to corresponding destination files
  -s, --strip strip symbol tables
  --strip-program=PROGRAM  program used to strip binaries
  -S, --suffix=SUFFIX  override the usual backup suffix
  -t, --target-directory=DIRECTORY  copy all SOURCE arguments into DIRECTORY
  -T, --no-target-directory  treat DEST as a normal file
  -v, --verbose   print the name of each directory as it is created
  --preserve-context  preserve SELinux security context
  -Z  set SELinux security context of destination
file and each created directory to default type
  --context[=CTX] like -Z, or if CTX is specified then set the
SELinux or SMACK security context to CTX
  --help display this help and exit
  --version  output version information and exit

The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:

  none, off   never make backups (even if --backup is given)
  numbered, t make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups

GNU coreutils online help: 
Report any translation bugs to 
Full documentation 
or available locally via: info '(coreutils) install invocation'

===

I see no explanation there why these options should be mutually exclusive.
(RTFS did not reveal any insight either.)

If the error message is unnecessary, please remove it.

Otherwise, please provide an explanation why and possible workarounds.

What I want to achieve is to preserve timestamps and to avoid doing extra work.
Both goals seem rather natural, and I see no reason why they should not be 
combined.

(In fact it seems "-p" should make it *easier* to implement "-C" as
timestamps will compare equal when nothing's changed. Then again,
need_copy() doesn't seem to care about times at all, so why should
it be incompatible with "-p"?)

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u5
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1029913: Fwd: Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

[Frank Heckenbach]

Siep Kroonenberg wrote:

> The problem was that the test was specifically for a file rather
> than for any filesystem item.
> 
> In the updated TL package, the test has been removed altogether
> since there was already a later test for successful generation of a
> temp subdirectory.
> 
> The updated package is now available as both a CTAN package and a TL
> package.

I tried it, and it fixes the problem as I reported.

Of course, chdir into /tmp is a bit risky as any file creation
before the next chdir would be susceptible to the same problem, but
I assume you made sure this won't happen.

BTW, when looked at the changes made, I noticed this:

  io.stdout:write('cannot cd into '..d..'\n')

I don't know much about Lua conventions, but normally I'd expect
such messages to be written to stderr, not stdout.

Bug#1030938: os-prober: Does not detect OpenSuse Tumbleweed

[Frank McCormick]

Package: os-prober
Version: 1.81
Severity: wishlist
X-Debbugs-Cc: bea...@videotron.ca


Debian Sid updated Grub today and when os-prober ran via update-grub it did not 
detect
my OpenSuse Tumbleweed partition.
The update had installed the new Grub so I could not boot into
Tumbleweed.

Now I have held all the grub packages so I won't be faced
with this again. The Tumbleweed grub installation and it's version
of os-prober does detect both Debian and Fedora on another partition.
FYI Fedoras os-prober also doesn't detect Tumbleweed but that's a 
problem I'll report to them.





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

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

Versions of packages os-prober depends on:
ii  grub-common  2.06-8
ii  libc62.36-8
ii  mount2.38.1-4

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information

Bug#1029963: Dictionary: Bug#1029963: trans-de-en: Typo "none tumor" should be "bone tumor"

[Frank Richter]

Hallo Roland,

Am 29.01.23 um 18:19 schrieb Roland Rosenfeld

Anbei ein Bugreport gegen das aktuelle devel-Wörterbuch.
Ich fürchte, Axel hat recht, dass "none tumor" ein typo ist und es im
britischen und amerikanischen Englisch "bone tumor" heißen muss.
Auch ich habe "none tumor" nirgends, außer in Deinem Wörterbuch finden
können.



Ganz klar ein Typo. Den habe ich korrigiert – der aktuelle Devel-Stand mit 
etlichen weiteren Korrekturen und Ergänzungen demnächst auf


https://ftp.tu-chemnitz.de/pub/Local/urz/ding/de-en-devel/


Danke und viele Grüße
Frank


- Forwarded message from Axel Beckert  -

From: Axel Beckert 
Subject: Bug#1029963: trans-de-en: Typo "none tumor" should be "bone tumor"
To: Debian Bug Tracking System 
Date: Sun, 29 Jan 2023 17:35:32 +0100
Reply-To: Axel Beckert , 1029...@bugs.debian.org

Package: trans-de-en
Version: 1.9-5
Severity: normal
Tags: upstream

Hi,

$ translate -i "bone tumour"
Geschwulst {f}; Gewächs {n}; Wucherung {f}; Tumor {m}; Neoplasma {n} [med.] | 
Geschwülste {pl}; Gewächse {pl}; Wucherungen {pl}; Tumoren {pl}; Neoplasmen 
{pl} | Blasentumor {m} | Gefäßtumor {m} | gutartiger Tumor; benigner Tumor | 
Knochentumor {m} |  Knochentumoren {pl} | (nur) langsam wachsender Tumor | 
schnell wachsender Tumor | einen Tumor freilegen | durch einen Tumor 
verschlossen :: growth; tumour [Br.]; tumor [Am.]; neoplasm; emphyma | growths; 
tumours; tumors; neoplasms; emphymas | bladder tumour [Br.]; bladder tumor 
[Am.]; vesical tumour [Br.]; vesical tumor [Am.] | vascular tumor | benign 
tumor | bone tumour [Br.]; none tumor [Am.] | bone tumours; none tumors | 
slow-growing tumour; low-grade tumour | fast-growing tumour; high-grade tumour 
| to expose a tumour | obstructed by a tumour

Please note especially these items:

   bone tumour [Br.]; none tumor [Am.] | bone tumours; none tumors
  ^^   ^^^

So twice the American English translation says "none" instead of
"bone". Given that "b" and "n" are directly beside each other on any
standard keyboard and that https://en.wikipedia.org/wiki/Bone_tumor does
not contain the word "none", I assume that's a typo (and the plural then
a copy & paste error).

Seems to be an upstream issues, since the two real hits on
https://duckduckgo.com/?q=%22none+tumor%22=v11=web point to
https://dict.tu-chemnitz.de/english-german/none%20tumor.html and
https://dict.tu-chemnitz.de/english-german/none%20tumors.html and all
others point to something containing "bone tumor" (and probably the word
"none" somewhere close or similar words like "nono" or "neo").

[...]
- End forwarded message -



--
Frank Richter
Facharbeitsgruppe Datenkommunikation
Universitätsrechenzentrum

Technische Universität Chemnitz
Straße der Nationen 62 | R. B302A
09111 Chemnitz
Germany

Tel: +49 371 531 31879
frank.rich...@hrz.tu-chemnitz.de
www.tu-chemnitz.de/urz



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

[Frank Heckenbach]

Package: texlive-pictures
Version: 2020.20210202-3
Severity: grave
File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu

Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.

Harmless demonstration:

% mkfifo /tmp/1
% epspdf /etc/hostname /dev/null  # any non-empty input file will do

hangs indefinitely trying to write to the pipe (as can be seen using
strace).

That's already a bug (and incidentally the one that actually
happened to me), but it seems it can be turned into an exploit using
a symlink. Though on my system this seems to be mitigated due to
this kernel patch:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

But on systems where the patch is not installed or not active, it
would be possible to get any other user, possibly root, that runs
this program to write "test" to a new file of the attacker's choice.
I don't know how to turn this into a more serious privilege
escalation, but that's just my lack of fanatsy and knowledge of e.g.
every possible file and subdirectory under /etc. In any case,
writing such a file is already transgressing privileges.

To avoid this, as usual for this kind of exploit, files written
under publicly writable directories such as /tmp must be opened with
O_CREAT|O_EXCL (whatever the equivalent in texlua is, if any), or a
subdirectory must be created since mkdir will fail if the target
exists already, even as a dangling symlink.

Bug#1029395: Our yad package is severely outdated

[Frank Mascal]

Package: yad
Version: 0.40.0-1+b1

Hi,

Debian Unstable proposes version 0.40.0-1+b1 of yad which is from 2019,
while the real upstream version is 12.3, released on December 2022.

Upstream moved their repository to github at:
https://github.com/v1cont/yad

Can you please provide an update for this package?

Thanks in advance!

Bug#1028955: Our Drawing version is severely outdated

[Frank Mascal]

Package: drawing
Version: 0.8.5-2

Hi,

The version of Drawing Debian ships is severely outdated, it is version 1.0.1 
nowadays.

It looks like upstream made a decent job already in their debian/ directory so 
it may be quite easy.

Can you please update the version provided in Debian?

Thanks in advance.
 
 
 

Bug#1027409: ffuf: Typo in the package description

[Frank Dietrich]

Source: ffuf
Version: 1.1.0-1
Severity: minor
Tags: patch
X-Debbugs-Cc: frank.dietr...@gmx.li

Dear Maintainer,

In the package description is a small typo. Instead of 'fast' it's spelled
'fest'.

The attached patch fix it.

kind regards
Frank


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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
diff -ur ffuf-1.1.0/debian/control ffuf-1.1.0_fix/debian/control
--- ffuf-1.1.0/debian/control   2020-09-10 13:04:29.0 +0200
+++ ffuf-1.1.0_fix/debian/control   2022-12-30 23:50:26.23523 +0100
@@ -19,6 +19,6 @@
  ${shlibs:Depends}
 Built-Using: ${misc:Built-Using}
 Description: Fast web fuzzer written in Go (program)
- ffuf is a fest web fuzzer written in Go that allows typical directory
+ ffuf is a fast web fuzzer written in Go that allows typical directory
  discovery, virtual host discovery (without DNS records) and GET and POST
  parameter fuzzing.
diff -ur ffuf-1.1.0/debian/ffuf.1 ffuf-1.1.0_fix/debian/ffuf.1
--- ffuf-1.1.0/debian/ffuf.12020-09-10 13:04:29.0 +0200
+++ ffuf-1.1.0_fix/debian/ffuf.12022-12-30 23:50:33.018546171 +0100
@@ -13,7 +13,7 @@
 .fam T
 .fi
 .SH DESCRIPTION
-\fBffuf\fP is a fest web fuzzer written in Go that allows typical directory
+\fBffuf\fP is a fast web fuzzer written in Go that allows typical directory
 discovery, virtual host discovery (without DNS records) and GET and POST
 parameter fuzzing.
 .RE

Bug#1025392: Is the dependency on xfonts-utils needed?

[Frank]

Package: fonts-terminus-otb
Severity: wishlist

Hi,

I was wondering whether the dependency on xfonts-utils is needed for this font?
(Isn't this leftover from the original bitmap terminus font?)

Bye,
Frank

Bug#1024983: Add support for HEIC/HEIF images

[Frank]

Package: swayimg
Severity: wishlist

Hi,

it seems that upstream supports linking swayimg with libheif library to add 
support for HEIC/HEIF images (native format of iPhones).

Would you consider to also link with the library to enable the support?
Considering how widespread the format is, it makes sense.

Cheers,
Frank

Bug#1015293: wrong row targeted with "insert ... on duplicate" and "replace", leading to data corruption

[Frank Heckenbach]

Forwarded: https://jira.mariadb.org/browse/MDEV-30046

Bug#1021703: slapd crashes when too many clients connect in a short period of time.

[Frank Menzel]

Package: slapd
Version: 2.4.57+dfsg-3+deb11u1
Severity: important

Dear Maintainer,

When many clients connect to a slapd in a short period of time we
noticed to different versions of a crash:
   * slapd crashes with following error:
 slapd: ../../../../servers/slapd/daemon.c:1957: slap_listener: \
  Assertion `SLAP_SOCK_NOT_ACTIVE( tid, sfd )' failed.
   * sometimes slapd does not crash, but transforms into a zombie state:
 * New connections are not accepted
 * some established connections seem to work, some don't
 * when sending a SIGTERM the process prints:
   slapd shutdown: waiting for 129 operations/tasks to finish
 * ...but it never stops and has to be killed by SIGKILL

We first observed this within our production environment. We created a
python script to stress the slapd and could reproduce the behaviour in
our DEV environment as well.
The script can be found here: https://paste.debian.net/hidden/dbf61b60/
We were able to reliably crash the slapd by running the script from 3 machines 
at
the same time.

   * What led up to the situation?
   We installed slapd in the following environment:
 * We use cn=config approach
 * We are using GSSAPI/kerberos auth with startTLS
 * Problem appears both on a slapd master and on a syncrepl host
 * Appears both with included init script and custom unitfile
 * openfiles limit for slapd has been raised to 16k
 * Loaded Modules: syncprov and back_mdb
 * We only modified/set the following settings:
   * olcSaslHost
   * olcSaslRealm
   * olcSaslSecProps
   * olcTLS*
 * Current slapd commandline (through systemd unitfile):
   * /usr/sbin/slapd -d0 -h ldap:/// ldapi:/// -g openldap \
  -u openldap -F /etc/ldap/slapd.d
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 * Update to bullseye backports version behaves the same

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

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

Versions of packages slapd depends on:
ii  adduser 3.118
ii  coreutils   8.32-4+b1
ii  debconf [debconf-2.0]   1.5.77
ii  libc6   2.31-13+deb11u4
ii  libcrypt1   1:4.4.18-4
ii  libdb5.35.3.28+dfsg1-0.8
ii  libldap-2.4-2   2.4.57+dfsg-3+deb11u1
ii  libltdl72.4.6-15
ii  libodbc12.3.6-0.1+b1
ii  libperl5.32 5.32.1-4+deb11u2
ii  libsasl2-2  2.1.27+dfsg-2.1+deb11u1
ii  libwrap07.6.q-31
ii  lsb-base11.1.0
ii  perl [libmime-base64-perl]  5.32.1-4+deb11u2
ii  psmisc  23.4-2

Versions of packages slapd recommends:
ii  ldap-utils  2.4.57+dfsg-3+deb11u1

Versions of packages slapd suggests:
ii  libsasl2-modules 2.1.27+dfsg-2.1+deb11u1
ii  libsasl2-modules-gssapi-heimdal  2.1.27+dfsg-2.1+deb11u1

-- Configuration Files:
/etc/default/slapd changed [not included]
/etc/ldap/schema/nis.ldif changed [not included]
/etc/ldap/schema/nis.schema changed [not included]

-- debconf information excluded

Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19

[Frank Ch. Eigler]

Hi -

>  WARNING: nginx pid 3525 target 3525
>  ERROR: read fault [man error::fault] at 0x561c9d23e380 near operator
>  '@var' at samples/openresty.stp:18:17
>  WARNING: Number of errors: 1, skipped probes: 0
>  WARNING: /usr/bin/staprun exited with status: 1
>  Pass 5: run completed in 0usr/70sys/569real ms.
>  Pass 5: run failed.  [man error::pass5]
>  Tip: /usr/share/doc/systemtap/README.Debian should help you get
>  started.
> 
>However, not all global var access will fail, if I build luajit from
>source code, and get a global var named globalL, it will success.

Please raise this with the openresty folks instead of debian.  A
robust stap script must be prepared for intermittent access errors of
@var() type expressions, via constructs such as try/catch.

- FChE

Bug#1019188: vim-youcompleteme makes vim show many error messages on start and while using

[Frank Scherrer]

Hi,



On Mon, Sep 05, 2022 at 08:02:20PM +0200, David Kalnischkies wrote:
> Hi,
> 
> On Mon, Sep 05, 2022 at 09:47:33AM +0200, Frank Scherrer wrote:
> > ...
> 
> Mhhh. Which filetype (vim tells you if you type ":set filetype?") has
> this buffer? Can you perhaps attach a file triggering these error for
> you? Perhaps its a problem with a specific filetype/syntax file
> (recently there was e.g. a bug in vims typescript syntax file, but you
>  have a fixed version installed already).
I just open vi, no file specified, and still get the errors. So no
filetype set at all.
> 
> How are you enabling vim-youcompleteme? I recently switched the package
> away from vim-addon-manager, even if it should still be technically
> supported (and that was already done before your "good" -3) but perhaps
> it broke in a later version. I note that the "bad" versions added a few
> experimental features and with it a bit of refactoring and new files.
I use vim-addon-manager
> 
> …
> 
> Now, I wanted to ask you to run 'vim -Nu NONE' (starting vim without any
> configuration) and then run ':packadd youcompleteme' to see if it is
> dependent on your local configuration, but I forgot the 'N' flag and as
> a result got similar errors as you got…
> Could it be that you run vim in vi compatible mode? (:set compatible?)
No, it sais nocompatible.
Starting vim in the way you suggested does not result in error messages,
even when I add youcompleteme next. So it is my configuration, right?
> 
> Ideally this plugin should really work regardless of compatible mode or
> not, but I am not sure upstream agrees and will probably need some time
> to dig into what is going on here.
> Just wanting to confirm now that I am not following a red herring and
> this is indeed the cause of the issue (or if I found another).
> 
> If you are in compatible mode I suppose it is a deliberate choice as
> I think it is not Debians default, but on the off chance that it is not
> feel free to join the nocompatible side as a possible fix/workaround.
> We have cookies. ;)
I am nocompatible already ... regarding vim-configuration :-D..

So as I described above I think this is something with my
vim-configuration and I digged a bit. This is, what I came up with:
I can make the Errors vanish by adding a link:
~/.vim/autoload/youcompleteme -> 
/usr/share/vim-youcompleteme/autoload/youcompleteme

If I understand
https://salsa.debian.org/debian/vim-youcompleteme/-/compare/48b92f5f...master?from_project_id=26053#aa93b379d38d836d0026e27ca5e01c0bba4ac1b9_512_576
correct, then s:AllowedToCompleteInBuffer in autoload/youcompleteme.vim
of the new version calls another function
youcompleteme#filetypes#AllowedForFiletype( filetype ) which is in
autoload/youcompleteme/filetypes

So my question now is: How should I (un)configure vim-youcompleteme
correctly?

Thanks again in advance.

> 
> 
> Best regards
> 
> David Kalnischkies

BR
Frank




signature.asc
Description: PGP signature

Bug#1016288: pulseaudio-dlna: crashes on start

[Frank Loeffler]

Package: pulseaudio-dlna
Version: 0.5.3+git20200329-0.1
Followup-For: Bug #1016288

Dear Maintainer,

A similar situation occurs on stable:

Exception in thread zeroconf-ServiceBrowser__googlecast._tcp.local.:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1557, in run
self._service_state_changed.fire(
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1333, in fire
h(**kwargs)
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1427, in 
on_change
listener.add_service(*args)
  File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 65, in 
add_service
self._add_update_service(zconf, typ, name, self.add_callback)
  File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 123, in 
_add_update_service
callback(uuid, name)
  File "/usr/lib/python3/dist-packages/pychromecast/__init__.py", line 246, in 
internal_callback
callback(
  File "/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/__init__.py", 
line 36, in wrapper
device = f(*args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/chromecast/__init__.py",
 line 47, in _on_device_added
return ChromecastRendererFactory.from_pychromecast(device)
  File 
"/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/chromecast/renderer.py",
 line 183, in from_pychromecast
ip=pychromecast.host,
AttributeError: 'Chromecast' object has no attribute 'host'

Dependencies of pulseaudio-dlna recently changed quite a bit, so
updating to the newest version is likely not going to work well (with
other system-installed dependencies and other software depending on
those). However, I could without problem build release 0.6.3, which
works on Debian stable and also officially should work with the
libraries present in Debian stable.

Versions > 0.5.2 are available from here: 
https://github.com/Cygn/pulseaudio-dlna .

I am reporting this here even though the previous report was for
unstable because quite likely versions of dependencies are the problem
in both cases and similar fixes/updates could be made in both cases.

Without any change, this package is quite unuseable also on Debian
stable, so 'grave' seems to be the correct severity.

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

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

Versions of packages pulseaudio-dlna depends on:
ii  flac  1.3.3-2+deb11u1
ii  lame  1:3.100-dmo2
ii  opus-tools0.1.10-1+b1
ii  python3   3.9.2-3
ii  python3-chardet   4.0.0-1
ii  python3-dbus  1.2.16-5
ii  python3-distutils 3.9.2-1
ii  python3-docopt0.6.2-3
ii  python3-gi3.38.0-2
ii  python3-lxml  4.6.3+dfsg-0.1+deb11u1
ii  python3-netifaces 0.10.9-0.2+b3
ii  python3-notify2   0.3-4
ii  python3-psutil5.8.0-1
ii  python3-pychromecast  7.7.1-2
ii  python3-pyroute2  0.5.14-2
ii  python3-requests  2.25.1+dfsg-2
ii  python3-setproctitle  1.2.1-1+b1
ii  sox   14.4.2+git20190427-2
ii  vorbis-tools  1.4.0-11+b1

Versions of packages pulseaudio-dlna recommends:
ii  ffmpeg   10:4.4-dmo4+deb11u5
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
pn  gir1.2-rsvg-3.0  
pn  libav-tools  
ii  python3-cairo1.16.2-4+b2

pulseaudio-dlna suggests no packages.

-- no debconf information

Bug#1019188: vim-youcompleteme makes vim show many error messages on start and while using

[Frank Scherrer]

Package: vim-youcompleteme
Version: 0+20220824+git7c3a88f+ds-2
Severity: normal

Dear Maintainer,

I think I have discovered an Issue with the latest version of
vim-youcompleteme:

   * What led up to the situation?
   An update from version 0+20220402+git3ededae+ds-3, if
   snapshot.debian.org is right, there was a version in between.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I started vi and tried to move around in a file after pressing return
   to all the error messages.
   * What was the outcome of this action?
   The error messages occurred and reoccurred.
   * What outcome did you expect instead?
   No errors.

Here come the error messages:
Error detected while processing CursorMoved Autocommands for "*"..function 
45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer:
line   12:
E117: Unknown function: youcompleteme#filetypes#AllowedForFiletype
Press ENTER or type command to continue
E117: Unknown function: youcompleteme#filetypes#AllowedForFiletype
Press ENTER or type command to continue
Error detected while processing CursorMoved Autocommands for "*"..function 
45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer[12]..45_PollServerReady[14]..45_OnFileTypeSet[8]..45_AllowedToComplet
eInCurrentBuffer[1]..45_AllowedToCompleteInBuffer:
line   14:
E121: Undefined variable: allowed
Press ENTER or type command to continue
Error detected while processing CursorMoved Autocommands for "*"..function 
45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer[12]..45_PollServerReady[14]..45_OnFileTypeSet[8]..45_AllowedToComplet
eInCurrentBuffer[1]..45_AllowedToCompleteInBuffer:
line   19:
E121: Undefined variable: allowed
Press ENTER or type command to continue
Error detected while processing CursorMoved Autocommands for "*"..function 
45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer:
line   14:
E121: Undefined variable: allowed
Press ENTER or type command to continue
Error detected while processing CursorMoved Autocommands for "*"..function 
45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer:
line   19:
E121: Undefined variable: allowed
Press ENTER or type command to continue

Pressing ENTER afterwards makes vim look normal until you try to move
around or do something else.

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

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

Versions of packages vim-youcompleteme depends on:
ii  python3   3.10.6-1
ii  python3-future0.18.2-6
ii  vim-nox [vim-python3] 2:9.0.0242-1
ii  ycmd [ycmd-core-version]  0+20220824+git2ee4100+ds-1+b1

Versions of packages vim-youcompleteme recommends:
ii  ycmd  0+20220824+git2ee4100+ds-1+b1

vim-youcompleteme suggests no packages.

-- no debconf information
Thank you for using reportbug

I have now downgraded to version 0+20220402+git3ededae+ds-3 from
snapshot.debian.org which resolves my situation for now.

Let me know if I can help resolving this and many thanks in advance.
Bear with me, this is my first bugreport.

cheers
Frank


signature.asc
Description: PGP signature

Bug#1016057: should use --disable-unit-tests for ./configure

[Frank Lichtenheld]

Package: openvpn
Version: 2.6.0~git20220518+dco-3

Currently openvpn implicitely disables the unit tests by not build-depending on
libcmocka-dev. If it is installed, the unit tests will be built. If not running
the unit tests is intentional you should specify the --disable-unit-tests 
configure
flags to get consistent behavior. Or add libcmocka-dev to the build 
dependencies.

However, on Ubuntu the package even fails to build when libcmocka-dev is 
installed
since Ubuntu enables -flto by default which breaks linking of some of the UTs.

Regards,
-- 
  Frank Lichtenheld

Bug#1006500: Missing bnx2x firmware 7.13.21.0 renders NIC unusable with Linux 5.16

[Frank Burkhardt]

Hi,

the problem affects Debian stable as well. Use case is installing
an old HP server using PXE/Netboot(5.10.0-16)/Preseed. I managed
to smuggle the 3 missing files (bnx2x-e1-7.13.21.0.fw,
bnx2x-e1h-7.13.21.0.fw, bnx2x-e2-7.13.21.0.fw) into
/lib/firmware of the installer but without them being included
in the firmware-bnx2x package, I can't install them properly into
the target partition.

Best regards,

Frank

Bug#1015294: spamprobe: a few patches

[Frank Heckenbach]

--- spamprobe-1.4d.orig/src/parser/JpegParser.cc
+++ spamprobe-1.4d/src/parser/JpegParser.cc
@@ -61,6 +61,7 @@ bool JpegParser::parseImage()
 initializeSource();
 digestImage();
 tokenizeImage();
+return true;
   } catch (runtime_error ) {
 return false;
   }
Index: spamprobe-1.4d/src/parser/MbxMailMessageReader.cc
===
--- spamprobe-1.4d.orig/src/parser/MbxMailMessageReader.cc
+++ spamprobe-1.4d/src/parser/MbxMailMessageReader.cc
@@ -85,6 +85,7 @@ bool MbxMailMessageReader::readMBXRecord
   cerr << "MBX: SKIPPED DELETED MESSAGE" << endl;
 }
   }
+  return true;
 }
 
 OWNED MailMessage *MbxMailMessageReader::readMessage()
Index: spamprobe-1.4d/src/parser/PngParser.cc
===
--- spamprobe-1.4d.orig/src/parser/PngParser.cc
+++ spamprobe-1.4d/src/parser/PngParser.cc
@@ -73,6 +73,7 @@ bool PngParser::parseImage()
   try {
 digestImage();
 initializeImage();
+return true;
   } catch (runtime_error ) {
 return false;
   }
Description: Avoid deprecated strstream
Author: Frank Heckenbach 
Index: spamprobe-1.4d/src/database/FrequencyDBImpl_bdb.cc
===
--- spamprobe-1.4d.orig/src/database/FrequencyDBImpl_bdb.cc
+++ spamprobe-1.4d/src/database/FrequencyDBImpl_bdb.cc
@@ -32,7 +32,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include "CleanupManager.h"
 #include "LockFile.h"
 #include "WordData.h"
@@ -67,10 +67,9 @@ inline int throw_on_error(const char *fu
 return rc;
   }
   if (rc != 0) {
-static char buffer[4096];
-ostrstream msg(buffer, sizeof(buffer));
+ostringstream msg;
 msg << function_name << ": " << db_strerror(rc) << " (" << rc << ")" << ends;
-throw runtime_error(buffer);
+throw runtime_error(msg.str());
   }
   return rc;
 }
Index: spamprobe-1.4d/src/database/FrequencyDBImpl_pbl.cc
===
--- spamprobe-1.4d.orig/src/database/FrequencyDBImpl_pbl.cc
+++ spamprobe-1.4d/src/database/FrequencyDBImpl_pbl.cc
@@ -32,7 +32,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "CleanupManager.h"
 #include "LockFile.h"
@@ -55,10 +55,9 @@ inline int throw_on_error(const char *fu
 return PBL_ERROR_NOT_FOUND;
   }
 
-  static char buffer[4096];
-  ostrstream msg(buffer, sizeof(buffer));
+  ostringstream msg;
   msg << function_name << ": " << pbl_errstr << " (" << pbl_errno << ")" << ends;
-  throw runtime_error(buffer);
+  throw runtime_error(msg.str());
 }
 
 inline int warn_on_error(const char *function_name,
Description: use reproducible pseudo-random numbers in AutoTrainMailMessageReader
Author: Frank Heckenbach 
Index: spamprobe-1.4d/src/parser/AutoTrainMailMessageReader.cc
===
--- spamprobe-1.4d.orig/src/parser/AutoTrainMailMessageReader.cc
+++ spamprobe-1.4d/src/parser/AutoTrainMailMessageReader.cc
@@ -29,6 +29,7 @@
 //
 
 #include 
+#include 
 #include "MailMessage.h"
 #include "AutoTrainMailMessageReader.h"
 
@@ -140,5 +141,15 @@ OWNED MailMessage *AutoTrainMailMessageR
 
 bool AutoTrainMailMessageReader::shouldUseSpam()
 {
-  return (m_totalCount >= 0) && ((random() % m_totalCount) < m_spamCount);
+  /* The original code uses "random" here without seeding it.
+ But some DB backends (e.g. BDB) seed the PRNG internally.
+ This gives the worst of both worlds: No real randomness,
+ yet different results with different backends which makes
+ it hard to compare them for performance or correctness.
+ Now, this uses a separate PRNG and leaves it unseeded,
+ to make results comparable, at the cost of no real
+ randomness which does not seem so important here. */
+  static mt19937 PRNG;
+  uniform_int_distribution dist(0, m_totalCount - 1);
+  return (m_totalCount >= 0) && (dist(PRNG) < m_spamCount);
 }

Bug#1015293: wrong row targeted with "insert ... on duplicate" and "replace", leading to data corruption

[Frank Heckenbach]

Package: mariadb-server-core-10.5
Version: 1:10.5.15-0+deb11u1
Severity: important

Using the MySQL interface, these statements:

DROP TABLE IF EXISTS t;
CREATE TABLE t (s BLOB, n INT, UNIQUE (s));
INSERT INTO t VALUES ('Hrecvx_0004ln-00',1), ('Hrecvx_0004mm-00',1);
INSERT INTO t VALUES ('Hrecvx_0004mm-00',2) ON DUPLICATE KEY UPDATE n = VALUES 
(n);
SELECT * FROM t;

produce this output:

s   n
Hrecvx_0004ln-002
Hrecvx_0004mm-001

So the latter "INSERT" updates the wrong row.

This happens whether the first column is "BLOB" or "TEXT", but only
with specific values. (In my actual use case with ~1 million rows,
it happened a few dozen times, which might be consistent e.g. with
collisions of a 32 bit hash or so.)

Likewise, these statements:

DROP TABLE IF EXISTS t;
CREATE TABLE t (s BLOB, n INT, UNIQUE (s));
INSERT INTO t VALUES ('Hrecvx_0004ln-00',1), ('Hrecvx_0004mm-00',1);
REPLACE INTO t VALUES ('Hrecvx_0004mm-00',2);
SELECT * FROM t;

give the error:

ERROR 1062 (23000) at line 4: Duplicate entry 'Hrecvx_0004mm-00' for key 's'

In my understanding, this error should actually be impossible with
"REPLACE INTO".

It might be the same issue, i.e. it tries to delete the wrong row
before inserting the new one, so it's still duplicate.

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

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

Versions of packages mariadb-server-core-10.5 depends on:
ii  libaio1 0.3.112-9
ii  libc6   2.31-13+deb11u3
ii  libcrypt1   1:4.4.18-4
ii  liblz4-11.9.3-2
ii  libpcre2-8-010.36-2
ii  libsnappy1v51.1.8-1
ii  libssl1.1   1.1.1n-0+deb11u3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7
ii  mariadb-common  1:10.5.15-0+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

mariadb-server-core-10.5 recommends no packages.

mariadb-server-core-10.5 suggests no packages.

-- no debconf information

Bug#1014880: sftp_readdir_async: Assertion `offset == 0' failed on OPENDIR when mounted through nfs

[Frank de Lange]

Package: sshfs
Version: 3.7.1+repack-2
Severity: grave
Justification: renders package unusable

Given the following setup:

 - remote directory mounted to /mnt/incoming on server using the
   following options:
   sshfs -d --debug librarian@archive:/mnt/incoming /mnt/incoming -o 
rw,delay_connect,transform_symlinks,idmap=user,allow_other,uid=1011,gid=1011,identityfile=/home/librarian/.ssh/id_rsa,dev,suid,dir_cache=no
 - /mnt/incoming bind-mounted to /srv/nfs/incoming
 - /srv/nfs/incoming exported through nfsv4
 - /srv/nfs/incoming nfsv4-mounted on workstation on /net/media/incoming

Listing the contents of /mnt/incoming or the bind-mounted version on
/srv/nfs/incoming works without problems, as does accessing files
residing in these directories.

Attempting to access the nfs-exported version of this filesystem from a 
workstation leads to sshfs aborting with the following assertion:

  [00035] OPENDIR
[00035] HANDLE   17bytes (0ms)
 unique: 66, success, outsize: 32
  unique: 68, opcode: READDIRPLUS (44), nodeid: 1, insize: 80, pid: 0
  sshfs: ../sshfs.c:2216: sftp_readdir_async: Assertion `offset == 0' failed.
  Aborted

When mounted with the directory cache enabled (dir_cache=yes) this
assertion occurs in cache_readdir instead.


-- System Information:
Debian Release: 11.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.39-1-pve (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sshfs depends on:
ii  fuse3   3.10.3-2
ii  libc6   2.31-13+deb11u3
ii  libfuse3-3  3.10.3-2
ii  libglib2.0-02.66.8-1
ii  openssh-client  1:8.4p1-5+deb11u1

sshfs recommends no packages.

sshfs suggests no packages.

-- no debconf information

Bug#1014843: opengnb: typo in the package description

[Frank Dietrich]

Source: opengnb
Version: 1.2.9.0-1
Severity: minor
Tags: patch
X-Debbugs-Cc: frank.dietr...@gmx.li

Dear Maintainer,

in the package description is a tiny typo. Please find a patch below.


diff -ur opengnb-1.2.9.0/debian/control opengnb-1.2.9.0-patch/debian/control
--- opengnb-1.2.9.0/debian/control  2022-06-21 11:21:22.0 +0200
+++ opengnb-1.2.9.0-patch/debian/control2022-07-13 07:40:49.627212347
+0200
@@ -22,7 +22,7 @@
  OpenGNB can add many nodes and LANs together into one big VPN.
  OpenGNB supports public index nodes to forward net packages.
  .
- OpenRNB support the following platforms:
+ OpenGNB support the following platforms:
  Linux, FreeBSD, OpenBSD, and macOS.
  .
  OpenGNB uses UDP by default. With the software gnb_udp_over_tcp


cheers
Frank


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -ur opengnb-1.2.9.0/debian/control opengnb-1.2.9.0-patch/debian/control
--- opengnb-1.2.9.0/debian/control  2022-06-21 11:21:22.0 +0200
+++ opengnb-1.2.9.0-patch/debian/control2022-07-13 07:40:49.627212347 
+0200
@@ -22,7 +22,7 @@
  OpenGNB can add many nodes and LANs together into one big VPN.
  OpenGNB supports public index nodes to forward net packages.
  .
- OpenRNB support the following platforms:
+ OpenGNB support the following platforms:
  Linux, FreeBSD, OpenBSD, and macOS.
  .
  OpenGNB uses UDP by default. With the software gnb_udp_over_tcp

Bug#1014201: spamprobe hangs in libdb; use MySQL instead?

[Frank Heckenbach]

Package: spamprobe
Version: 1.4d-14+b2
Severity: important
Tags: upstream

I posted this upstream at https://sourceforge.net/p/spamprobe/bugs/40/, but as 
expected got no reaction there.

Is anyone here maintaining spamprobe anymore, or am I on my own?

---

I had used spamprobe for many years without major problems. But recently it 
started hanging.

strace shows it blocks on a futex call which is strange enough since it's 
single-threaded and no other instances were running at the same time.

Once it happens, it seems to happen every time. Rebuilding the database helped, 
but only for a short while. After few days, it would hang again.

gdb shows the offending calls come from some libdb functions. Since I don't 
feel like debugging libdb, and you might not either, this got me thinking if 
using a file-based DB such as Berkeley is really the best option here.

Using a DB server such as MySQL might, apart from hopefully avoiding such 
locking bugs, be better for performance since it doesn't have to load the whole 
DB on each invocation, but can cache it if used frequently, as it normally does.

I see a similar request was made recently (well, 17 years ago ;) in 
https://sourceforge.net/p/spamprobe/feature-requests/23/ (with yet another 
reason), but got no replies.

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

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

Versions of packages spamprobe depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libgcc-s1 [libgcc1]10.2.1-6
ii  libgif75.1.9-2
ii  libjpeg62-turbo1:2.0.6-4
ii  libpng16-161.6.37-3
ii  libstdc++6 10.2.1-6

Versions of packages spamprobe recommends:
ii  procmail  3.22-26

spamprobe suggests no packages.

-- debconf-show failed

Bug#1006677: Seems to be fixed

[Ulbricht, Frank]

Hi there,

it looks like the causing problem (and related issues) is fixed. Will this fix 
be back-ported to something like LTS 17.0.4 or any other release?

Regards,
Frank Ulbricht

Bug#777584: wrap long lines

[Frank Heckenbach]

The limit according to RFC 2822 is 998 characters.
Current versions of exim4, e.g., enforce this limit.

So if you do wrapping, you might as well use the correct limit.

Of course, wrapping slightly alters the content.

If this is deemed inacceptable, you might need to MIME encode the
message (QP or base64).

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

[Frank Mehnert]

I really wonder if this hang has something to do with a dedicated setup
because not many users seem to be affected. Nevertheless the bug is really
annoying.

Bug#1011932: quiterss: notifications sound not played

[Frank Dietrich]

Package: quiterss
Version: 0.19.4+dfsg-1
Severity: normal
X-Debbugs-Cc: frank.dietr...@gmx.li

Dear Maintainer,

the package misses a dependency to "libqt5multimedia5-plugins".

When enabling a notifications sound for new news, the sound is not played.

The default notification sound file
"/usr/share/quiterss/sound/notification.wav"
exist on the system and can be played with a media player.

Using strace revealed following missing directory.

access("/usr/lib/x86_64-linux-gnu/qt5/plugins/mediaservice/.", F_OK) = -1
ENOENT (No such file or directory)

After installation of package "libqt5multimedia5-plugins" the sound is played
by QuiteRSS.

cheers
Frank


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
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=en_US.UTF-8, LC_CTYPE=en_US.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 quiterss depends on:
ii  libc62.33-7
ii  libgcc-s112.1.0-2
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5multimedia55.15.2-3
ii  libqt5network5   5.15.2+dfsg-16+b1
ii  libqt5printsupport5  5.15.2+dfsg-16+b1
ii  libqt5sql5   5.15.2+dfsg-16+b1
ii  libqt5sql5-sqlite5.15.2+dfsg-16+b1
ii  libqt5webkit55.212.0~alpha4-16
ii  libqt5widgets5   5.15.2+dfsg-16+b1
ii  libqt5xml5   5.15.2+dfsg-16+b1
ii  libsqlite3-0 3.38.5-1
ii  libstdc++6   12.1.0-2

quiterss recommends no packages.

quiterss suggests no packages.

-- no debconf information

Bug#1011113: chrpath: misreads, damages shared libraries with unexpected structure

[FeRD (Frank Dana)]

6_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-104-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chrpath depends on:
ii  libc6  2.31-0ubuntu9.9

chrpath recommends no packages.

chrpath suggests no packages.
>From 389098510c9edc4020ac9fb38c7ed6027848426f Mon Sep 17 00:00:00 2001
From: "FeRD (Frank Dana)" 
Date: Sun, 24 Apr 2022 19:12:19 -0400
Subject: [PATCH] Fix lookup of string table

Previously, the code assumed the first SHT_STRTAB section it
encountered was the dynamic string table. However, this is not
always the case.

Two new functions, read_section_names() and get_section_name(),
are responsible for reading the table of section names from the
ELF file, and retrieving section names from the imported table.

The search for the dynamic string table is now augmented by a
check that the section name is ".dynstr", before applying the
rpath offset to retrieve the rpath string.
---
 chrpath.c | 76 +--
 protos.h  |  3 +++
 2 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/chrpath.c b/chrpath.c
index 207e369..06920a8 100644
--- a/chrpath.c
+++ b/chrpath.c
@@ -50,6 +50,61 @@ Peeter
 #include 
 #include "protos.h"
 
+
+/**
+ * Reads the section names table from an ELF file into memory
+ */
+char*
+read_section_names(int fd, Elf_Ehdr ehdr)
+{
+  Elf_Shdr shdr;
+
+  const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
+  const size_t sh_off = EHDRWU(e_shoff);
+  const size_t sections_off = EHDRWU(e_shstrndx) * sz_shdr;
+
+  if (lseek(fd, sh_off + sections_off, SEEK_SET) == -1)
+  {
+perror ("positioning for section table");
+return NULL;
+  }
+
+  if (read(fd, , sz_shdr) != (ssize_t)sz_shdr)
+  {
+perror ("reading section header");
+return NULL;
+  }
+
+  /* +1 for forced trailing null */
+  char* strtab = (char *)calloc(1, SHDR_O(sh_size)+1);
+  if (strtab == NULL)
+{
+  perror ("allocating memory for string table");
+  return NULL;
+}
+
+  if (lseek(fd, SHDR_O(sh_offset), SEEK_SET) == -1)
+  {
+perror ("positioning for string table");
+return NULL;
+  }
+  if (read(fd, strtab, SHDR_O(sh_size)) != (ssize_t)SHDR_O(sh_size))
+  {
+perror ("reading string table");
+return NULL;
+  }
+  strtab[SHDR_O(sh_size)] = 0; /* make sure printed string is null terminated 
*/
+  return strtab;
+}
+
+/**
+ * Looks up the name for a section, using its offset in the table
+ */
+char*
+get_section_name(int name_off, char* section_names) {
+  return section_names + name_off;
+}
+
 /**
  * Reads an ELF file, and reads or alters the RPATH setting.
  *
@@ -128,31 +183,44 @@ chrpath(const char *filename, const char *newpath, int 
convert)
   return 2;
 }
 
+  char* section_names = read_section_names(fd, ehdr);
+  if (section_names == NULL) {
+free(dyns);
+elf_close(fd);
+return 1;
+  }
+
   if (lseek(fd, EHDRWU(e_shoff), SEEK_SET) == -1)
   {
 perror ("positioning for sections");
 free(dyns);
+free(section_names);
 elf_close(fd);
 return 1;
   }
 
+  const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
   for (i = 0; i < EHDRHU(e_shnum); i++)
   {
-const size_t sz_shdr = is_e32() ? sizeof(Elf32_Shdr) : sizeof(Elf64_Shdr);
 if (read(fd, , sz_shdr) != (ssize_t)sz_shdr)
 {
   perror ("reading section header");
   free(dyns);
+  free(section_names);
   elf_close(fd);
   return 1;
 }
-if (SHDR_W(sh_type) == SHT_STRTAB)
+if (SHDR_W(sh_type) != SHT_STRTAB)
+  continue;
+char* name = get_section_name(SHDR_W(sh_name), section_names);
+if (strcmp(name, ".dynstr") == 0)
   break;
   }
   if (i == EHDRHU(e_shnum))
 {
   fprintf (stderr, "No string table found.\n");
   free(dyns);
+  free(section_names);
   elf_close(fd);
   return 2;
 }
@@ -162,6 +230,7 @@ chrpath(const char *filename, const char *newpath, int 
convert)
 {
   perror ("allocating memory for string table");
   free(dyns);
+  free(section_names);
   elf_close(fd);
   return 1;
 }
@@ -171,6 +240,7 @@ chrpath(const char *filename, const char *newpath, int 
convert)
 perror ("positioning for string table");
 free(strtab);
 free(dyns);
+free(section_names);
 elf_close(fd);
 return 1;
   }
@@ -179,6 +249,7 @@ chrpath(const char *filename, const char *newpath, int 
convert)
 perror ("reading string table");
 free(strtab);
 free(dyns);
+free(section_names);
 elf_close(fd);
 return 1;
   }
@@ -190,6 +261,7 @@ chrpath(const char *filename, const char *newpath, int 
convert)
  

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#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#1010576: akonadi-server: Akonadi/Kontact hangs after resuming from standby

[Frank Mehnert]

Exact same behavior here. I have this behavior for about 6-8 weeks. After each 
resume I have to stop akonadi and then kill mariadb (normal kill is nossible 
due to apparmor, only kill -9 works). After that, akonadi works again.

Thanks!

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Frank Dietrich]

Package: ibus-typing-booster
Version: 2.15.25-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: frank.dietr...@gmx.li

Dear Maintainer,

   * What led up to the situation?

The shebang line in emoji-picker refers to /usr/bin/sh which does not point to
a Shell in Debian.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Running `/usr/bin/emoji-picker` fails with `/usr/bin/sh: bad interpreter: No
such file or directory`
Running it as `sh /usr/bin/emoji-picker` starts the emoji picker.

   * What outcome did you expect instead?

The emoji picker should start by calling the executable script.

In the upstream repository this commit lead to the in Debian broken executable.

https://github.com/mike-fabian/ibus-typing-
booster/commit/40718d53e02cd412940b1fd4086e4eb910baf6cb

The shebang was changed there from `/bin/sh` to `/usr/bin/sh`.

cheers
Frank



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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ibus-typing-booster depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  ibus 1.5.26-4
ii  libm17n-01.8.0-4
ii  m17n-db  1.8.0-3
ii  python3  3.10.4-1
ii  python3-dbus 1.2.18-3+b1
ii  python3-enchant  3.2.2-1
ii  python3-packaging21.3-1
ii  python3-xdg  0.27-2

ibus-typing-booster recommends no packages.

ibus-typing-booster suggests no packages.

-- no debconf information

Bug#1009301: acpid: acpi.path in container generates - systemd[1]: Condition check resulted in ACPI event daemon being skipped.

[Frank Dornheim]

Package: acpi
Version:1:2.0.32 Severity: normal

Dear Maintainer,

The package is also installed in containers for example lxc/lxd through 
dependencies. Systemd deactivates acpid with the line: 
'ConditionVirtualization=!container' in the section [Unit] in the file: 
'acpid.service'. The file watcher acpi.path does not have this setting, 
which leads to permanent errors in the log: systemd[1]: Condition check 
resulted in ACPI event daemon being skipped. Therefore, I suggest to 
also insert the line: 'ConditionVirtualization=!container' in the 
section: 'Unit' in the acpid.path file. I tested the solution.


Thanks Frank

-- System Information:
Debian Release: bullseye
  APT prefers testing
  APT policy: (950, 'testing'), (54, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux5.13.0-39-generic
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages acpi depends on:
ii  libc6  2.27

acpi recommends no packages.

acpi suggests no packages.

-- no debconf information

Bug#990428: Info received (Add fixed package to upcoming 11.3?)

[Frank Liu]

Debian 11.3 was released over the weekend, and the ifenslave fix in this
bug report is still not included.

Bug#990428: Add fixed package to upcoming 11.3?

[Frank Liu]

Hi,

I see Bullseye 11.3 is planned to release in two weeks:
https://lists.debian.org/debian-project/2022/03/msg00015.html

Is there a chance the fixed ifenslave version 2.13 be added?

Bug#1006828: cname from same domain fails to resolve if target is an dhcp host

[Frank Liu]

Package: dnsmasq
Version: 2.85-1

Here is the relevant dnsmasq config on Debian 11.2:

domain=test.example.com
cname=alias.test.example.com,client1.test.example.com
cname=alias.dummy.example.com,client1.test.example.com

"client1" is a dhcp client, and the dnsmasq server IP is 192.168.0.253

The problem is we can't resolve the name "alias.test.example.com",
though we can resolve the name "alias.dummy.example.com" which is out
of the domain "test.example.com".

$ dig -v
DiG 9.16.22-Debian

$ dig @192.168.0.253 alias.dummy.example.com alias.test.example.com
client1.test.example.com

; <<>> DiG 9.16.22-Debian <<>> @192.168.0.253 alias.dummy.example.com
alias.test.example.com client1.test.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29718
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alias.dummy.example.com. IN A

;; ANSWER SECTION:
alias.dummy.example.com. 0 IN CNAME client1.test.example.com.
client1.test.example.com. 0 IN A 192.168.0.70

;; Query time: 20 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:27 UTC 2022
;; MSG SIZE  rcvd: 114

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62870
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alias.test.example.com. IN A

;; ANSWER SECTION:
alias.test.example.com. 5 IN CNAME client1.test.example.com.

;; Query time: 20 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:27 UTC 2022
;; MSG SIZE  rcvd: 96

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40301
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;client1.test.example.com. IN A

;; ANSWER SECTION:
client1.test.example.com. 5 IN A 192.168.0.70

;; Query time: 16 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:27 UTC 2022
;; MSG SIZE  rcvd: 75

$ dig -t any @192.168.0.253 alias.dummy.example.com
alias.test.example.com client1.test.example.com

; <<>> DiG 9.16.22-Debian <<>> -t any @192.168.0.253
alias.dummy.example.com alias.test.example.com
client1.test.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24227
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alias.dummy.example.com. IN ANY

;; ANSWER SECTION:
alias.dummy.example.com. 0 IN CNAME client1.test.example.com.
client1.test.example.com. 0 IN A 192.168.0.70

;; Query time: 20 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:41 UTC 2022
;; MSG SIZE  rcvd: 114

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alias.test.example.com. IN ANY

;; ANSWER SECTION:
alias.test.example.com. 5 IN CNAME client1.test.example.com.

;; Query time: 20 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:41 UTC 2022
;; MSG SIZE  rcvd: 96

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31132
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;client1.test.example.com. IN ANY

;; Query time: 20 msec
;; SERVER: 192.168.0.253#53(192.168.0.253)
;; WHEN: Wed Mar 02 17:34:41 UTC 2022
;; MSG SIZE  rcvd: 59

Bug#1002010: find-completion: don't look for -exec etc command if completing before it

[Frank Loeffler]

Package: bash-completion
Version: 1:2.11-2

Hi,

the same happens with Debian stable (bash-completion version 2.11-2). 
The same patch applies, cleanly, to that version too, and fixes the 
issue there as well.


As the fix is that simple and prevents a rather annoying crash, I hope 
this could be pushed into stable.


cheers,

Frank Löffler

Bug#1003639: gdb sometimes doesn't set hardware breakpoint for no discernible reason

[Frank Heckenbach]

Package: gdb
Version: 10.1-1.7
Severity: normal

>From a coomplicated gdb session
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003638):

(gdb) p (float*)$2
$29 = (float *) 0x556e612bd530
(gdb) watch *(float*)$29
Hardware watchpoint 10: *(float*)$29
(gdb) d 10
[...]
(gdb) watch *(float*)$30
Watchpoint 21: *(float*)$30
(gdb) d 21
(gdb) p $30
$31 = (float *) 0x556e614692d0
(gdb) p $30==(float*)0x556e614692d0
$32 = 1
(gdb) watch *(float*)0x556e614692d0
Hardware watchpoint 22: *(float*)0x556e614692d0
(gdb) d 22

So watching a float at some address (*$2) creates a hardware
watchpoint, but at another one (*$30) only a software watchpoint
(which in this case was unusably slow).

But watching the same address typed explicitly (and verified with
"==" to rule out copy/paste error) gave a hardware watchpoint again
(which did help to find the other bug :).

Nothing in the docs or on the net I could find gives any explanation
when and why gdb uses hardware watchpoints (only an option to force
software watchpoints which is the opposite I want).

I don't see any reason here, so I suppose it's a bug. If not, it
would be useful to at least tell the user why it doesn't.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.8-1+b3
ii  libc6   2.31-13+deb11u2
ii  libdebuginfod1  0.183-1
ii  libexpat1   2.2.10-2
ii  libgcc-s1   10.2.1-6
ii  libipt2 2.0.3-1
ii  liblzma55.2.5-2
ii  libmpfr64.1.0-3
ii  libncursesw66.2+20201114-2
ii  libpython3.93.9.2-1
ii  libreadline88.1-1
ii  libsource-highlight4v5  3.1.9-3+b1
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  libxxhash0  0.8.0-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.31-13+deb11u2

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#1003638: mbeq: uninitialized field access corrupts output

[Frank Heckenbach]

Package: swh-plugins
Version: 0.4.17-2+fh1
Severity: important
Tags: upstream patch

mbeq_1197.xml:

float coefs[FFT_LENGTH / 2];

[...]

coefs[0] = 0.0f;
for (bin=1; bin < (FFT_LENGTH/2-1); bin++) {
coefs[bin] = ((1.0f-bin_delta[bin]) * gains[bin_base[bin]])
  + (bin_delta[bin] * gains[bin_base[bin]+1]);
}

[...]

for (i = 1; i < FFT_LENGTH/2; i++) {
comp[i] *= coefs[i];
comp[FFT_LENGTH-i] *= coefs[i];
}

The first loop leaves coefs[FFT_LENGTH/2-1] uninitialized because it
only runs while bin < FFT_LENGTH/2-1.

The second loop reads from coefs[FFT_LENGTH/2-1], boom!

With some bad luck (which I had, of course, and of course only in
hard to reproduce circumstances) the uninitialized value will be NaN
which due to the FFT poisons the whole output with NaN.

Fix (note the "-1" is not needed at all. Maybe someone thought so
because of the "+1" in the line below, but that doesn't apply to bin
at all):

--- mbeq_1197.xml
+++ mbeq_1197.xml
@@ -140,7 +140,7 @@
 
 // Calculate coefficients for each bin of FFT
 coefs[0] = 0.0f;
-for (bin=1; bin < (FFT_LENGTH/2-1); bin++) {
+for (bin=1; bin < (FFT_LENGTH/2); bin++) {
coefs[bin] = ((1.0f-bin_delta[bin]) * gains[bin_base[bin]])
  + (bin_delta[bin] * gains[bin_base[bin]+1]);
 }

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages swh-plugins depends on:
ii  libc6 2.31-13+deb11u2
ii  libfftw3-single3  3.3.8-2
ii  libgsm1   1.0.18-2

swh-plugins recommends no packages.

swh-plugins suggests no packages.

-- no debconf information

Bug#1003482: libre2-dev: re2.pc contains "-std=c++11"

[Frank Heckenbach]

Package: libre2-dev
Version: 20210201+dfsg-1
Severity: normal

re2.pc contains "-std=c++11". This conflicts with other "-std"
options, especially if one wants to use a newer standard (which
otherwise works with libre2, as indicated by its support for
string_view, e.g.).

In order to make sure it's used only with C++11 or newer, you may
want to check __cplusplus in the header instead.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libre2-dev depends on:
ii  libre2-9  20210201+dfsg-1

libre2-dev recommends no packages.

libre2-dev suggests no packages.

-- no debconf information

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Frank Terbeck]

Axel Beckert wrote:
[…]
>> With that, we could add the prefix based site-functions directory,
>> but deprecate its use.
>
> Ack, that thought came to me also after having read your mail
> half-through. It though has the danger that some so far not active
> plugins will suddenly start to work. So we add least need to
> debian/zsh.bug-script.
>
> Currenty it only checks for packages that ship files in
> /usr/share/zsh/vendor-completions/ and
> /usr/share/zsh/vendor-functions/.

True. Although "normal" function don't get activated automatically. Only
files that match ‘_*’ in $fpath get activated automatically by compinit,
if the user calls that function in their configuration files.


>> That way, packages that disrespect the zsh package's policy still
>> work, while keeping the possibility of a clean system, in case all
>> package adhere to the policy. We could file a bunch of bugs for the
>> packages that are currently using /usr/share/zsh/site-functions
>> right now.
>
> Debian prefers lintian warnings over mass bug filing. Mass bug filing
> needs to be discussed on the debian-devel mailing list first.

That is fair.


> What I now still wonder to (hopefully) address Joey's issue:
>
> Is there a way to build the Debian zsh (respectively probably the
> zsh-dev) package in a way so that locally installed Zsh extensions get
> cleanly installed into /usr/local/ while Debian packages still install
> stuff to /usr/ (preferably these vendor-* directories)?

Well, I  am not sure what  "plugins" do in terms  of installation proce-
dures. The  only such package that  I have written¹ ships  a script that
asks you for a directory that it should use for deployment.

If I were to do some sort of automatic site-local installation, I'd pro-
bably install to this: zsh -c '${fpath[1]}'


> I wonder if something like a dh_zsh helper could help here (i.e. for
> the vendor-* directory part) as well.

I suppose we could make it do this:

Install files from the source  directory, that are not generally instal-
led by  the upstream installation  process. I  think that this  is still
more often than not the case:

  dh_zsh -c -s examples/_foobar contrib/_quux
  dh_zsh -f -s examples/some-function


Similarly, move functions from the in the packaging root directory, in
case things get installed by the upstream installation procedure:

  dh_zsh -c -p /usr/local/share/zsh/site-functions/_foobar
  dh_zsh -f -p /usr/share/zsh/site-functions/some-function

The mnemonics here are:

  -c → Completion system function; put into vendor-completions
  -f → General, auto-loadable function file.
  -s → From Source directory
  -p → From package root directory.

I suppose we could also add a ‘-r’ option to make the process recursive.


In addition, we  could add an automatic mode for  stuff in the packaging
root directory, if called without  arguments, which should fix naïve in-
stallation procedures automatically, due to zsh's convention about names
for completion functions:

  - Scan these directories:
- /usr/local/share/zsh/site-functions
- /usr/share/zsh/site-functions
  - Move files matching ‘_*’ to vendor-completions
  - Move the other files to vendor-functions.
  - Remove those two directories (they should be empty now)


I think that should support most installation schemes.


WDYT?


Regards, Frank

Bug#934926: update

[Frank Terbeck]

Daniel Shahaf wrote:
[…]
> - Packages that are part of Debian should install to
>   /usr/share/zsh/vendor-*.
>
> - Upstream packages have three options:
>
>   + Install to /usr/local/share/zsh/site-functions (regardless of their
> own $PREFIX _and_ of zsh's $PREFIX)

This is precisely  the right fpath entry for site  local function files.
The Debian package set this to a /usr/local directory even when configu-
red with --prefix=/usr since before the current team took over.

This  is the  right thing  to do  in any  case, since  non-package files
should just be dropped into /usr/share/.

We  *added* the  ‘vendor-*’ directories  to get  fpath entries  that are
under the control of the package  system for packages to drop additional
functions into. It's been this way since about 2011.

A couple of years later (2014-ish) zsh upstream changed its compile time
configuration semantics  with respect  to site-function  directories: It
now ensures  that /usr/local/share/zsh/site-functions is  *always* there
and on top of the fpath variable.

This acknowledges  that /usr/local/  is the right  place for  site local
additions, which I don't think anybody disputes.

The change  in handling site-function  directories is that  compile time
configuration  also  adds a  PREFIX/share/zsh/site-functions  directory,
with lower priority than the one in /usr/local.

The reason  this doesn't  get added  on Debian right  now is  that we're
still  setting ‘--enable-site-fndir=/usr/local/share/zsh/site-functions’
explicitly. Dropping this setting would change this.

Since  Debian's ‘vendor-*’  directory handling  predates this  by years,
changing this,  effectively adding  a second path  for the  same purpose
seems inelegant, since it adds redundancy where none is needed.

This however, sucks:

% apt-file search usr/share/zsh/site-functions/ | wc -l
30

Because that is thirty functions that will not work.

When we  added the ‘vendor-*’ stuff,  we filed bug reports  for packages
that  tried this,  because  even  back then,  it  wouldn't have  worked,
because site-functions always was in /usr/local with Debian's zsh.

That resulted in this:

% apt-file search vendor-completions | wc -l
166


I am  not sure if  there's an elegant way  to resolve this,  because the
‘vendor-*’ directories  are the documented  way for zsh packages  to add
functions for more than a decade. I  don't think dropping them is a good
idea, because it would break backward compatibility. And as I said, just
adding the second  --prefix based site-functions entry  would litter the
system by added multiple destinations for the same purpose.

Maybe there's a way to add a  lintian check for the installation path of
zsh function files in Debian packages.  With that, we could add the pre-
fix based  site-functions directory,  but deprecate  its use.  That way,
packages  that disrespect  the zsh  package's policy  still work,  while
keeping the possibility of a clean system, in case all package adhere to
the policy. We could file a bunch of bugs for the packages that are cur-
rently using /usr/share/zsh/site-functions right now.


Regards, Frank

Bug#1003012: Fixing #1003012 in bullseye (was: Re: Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable))

[Frank Heckenbach]

Hi Salvatore,

> > Thanks for the quick fix!
> 
> Just in avoidance of doubt, thanks goes to Matthias, I just fixed the
> BTS metadata as the bug was not closed along with the upload.

Thanks to Matthias then! :)

> >From a security team perspective, we do not plan to release the fix as
> a DSA via the security-archive, but a fix would be welcome to be
> included in the next bullseye point release.
> 
> Apart the patch "014" for this issue, maybe it makes sense to pick up
> as well other of the applied patches (have not looked at the others).

Upstream did this; bash-5.1.16 includes this patch and other recent
patches.

> Matthias, would you prepare such an update? TTBOMK the next bullseye
> release will be around february 2022, according to the planning of the
> release team.

OK, that's too late for me, so I'm patching it myself. Thanks for
the info.

Frank

Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable)

[Frank Heckenbach]

Thanks for the quick fix!

However, it's not clear to me if the fix will go to
bullseye-security or at least bullseye-updates or only to testing.
(Is there some way to find this out on the web site or so?)

I need to know because now I have to either wait for the bullseye
package or backport it myself, and I'd like to avoid having to do
both (and thus rebooting my systems twice).

Frank

Bug#1003012: bash: Corrupted multibyte characters in command substitutions

[Frank Heckenbach]

Package: bash
Version: 5.1-2+b3
Severity: critical
Justification: breaks unrelated software
Tags: patch upstream l10n

I've reported this bug on bug-bash:
https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html

only to learn that it's known and not fixed for months (it was known
before bullseye was released, so a timely fix would have prevented
the bug ever reaching stable):
https://savannah.gnu.org/patch/?10035

I'm reporting it as critical because it causes silent data
corruption and potentially affects each bash script in the system.

Since the bash developers don't seem to take that seriously, I'm
asking the Debian maintainers to put out a fixed version ASAP to
prevent further damage -- hopefully as a security patch. (I'm no
expert in writing exploits, but I think it's quite possible such a
bug can be exploited. I hope you don't have to wait for an actual
exploit in order to fix the bug.)

Both reports listed above contain a patch. They're different, but
either one will fix the immediate problem.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   11.1+deb11u2
ii  debianutils  4.11.2
ii  libc62.31-13+deb11u2
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#1002457: rsvg-convert: incorrect text rendering with small font-size (regression)

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal
File: /usr/bin/rsvg-convert

Text with small font-size is rendered incorrectly. In the attached
exmples, letters are rendered on top of each other instead of next
to each other.

It was rendered correctly under buster (see font-tiny-2.44.10.png).
It also renders correctly in Firefox and Chromium.

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

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

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13+deb11u2
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

[Frank Heckenbach]

I wrote:

: Still broken in stable and testing.

Still broken in current stable, testing and unstable.

: upstream 4.1 still works out of the box.

Still does.

: Does anyone read these bug reports at all?

Apparently not. :(

Bug#1001646: libgeoip1 can't determine the country of an ipaddress, but www.maxmind.com does report it

[Frank B. Brokken]

Package: libgeoip1
Version: 1.6.12-8
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Our Internet provider assigned us address 185.202.110.161. The following
minimal C++ program reports: 

'185.202.110.161 not found in GeopIP database':

int main()
{
char const *ip = "185.202.110.161";

GeoIP *gi = GeoIP_open("/usr/share/GeoIP/GeoIP.dat", 
GEOIP_MEMORY_CACHE); 
if (!gi)
return 1;

char const *country = GeoIP_country_code_by_addr(gi, ip);
if (!country)
cout << ip << " not found in GeopIP database\n";
}


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

Since libgeoip1 lists www.maxmind.com] as its 'External Resource', I entered
the above address at https://www.maxmind.com/en/home

   * What was the outcome of this action?

The page https://www.maxmind.com/en/geoip2-precision-demo was opened and
showed the correct country and ISP.

   * What outcome did you expect instead?

Since www.maxmind.com correctly reported details like the address's country
and ISP, I had expected that libgeoip1 would also produce the correct
country. I tried several other (existing) addresses using the above program,
and it correctly produced the countries of those addresses


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

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

Versions of packages libgeoip1 depends on:
ii  libc6  2.32-5

Versions of packages libgeoip1 recommends:
ii  geoip-database  20191224-3

Versions of packages libgeoip1 suggests:
ii  geoip-bin  1.6.12-8

-- no debconf information

Bug#992133: firebird4.0 debian packaging

[Frank Doepper]

Hi Damyan.

Am 26.08.21 um 10:40 schrieb Damyan Ivanov:

Simply letting debhelper do the autoreconf seems to work and the build 
completes, no linker errors. This is in an up to date sid sbuild chroot.


Thank you for your ongoing work on firebird4.0, I've seen many commits. 
I've refreshed our jenkins/minibuildd setup and firebird4.0 now builds 
fine on sid and bookworm. Unfortunately build fails on bullseye, which is 
apparently related to autoconf 2.71 vs. 2.69:


 debian/rules binary
dh binary
   dh_update_autotools_config
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>'
mkdir -p builds/make.new/config
dh_autoreconf
aclocal: warning: couldn't open directory 'm4': No such file or directory
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 
'builds/make.new/config'.
libtoolize: copying file 'builds/make.new/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- --build x86_64-linux-gnu --enable-raw-devices 
--disable-rpath --with-gpre-cobol --enable-regen-codes --with-system-re2 
--with-system-editline --prefix=/usr/lib/x86_64-linux-gnu/firebird/4.0 
--with-fbsbin=/usr/sbin --with-fblib=/usr/lib/x86_64-linux-gnu 
--with-fbconf=/usr/lib/x86_64-linux-gnu/firebird/4.0 
--with-fbdoc=/usr/share/doc/firebird4.0-common-doc 
--with-fbudf=/usr/lib/x86_64-linux-gnu/firebird/4.0/UDF 
--with-fbsample=/usr/share/doc/firebird4.0-common-doc/examples 
--with-fbsample-db=/usr/share/doc/firebird4.0-common-doc/examples/empbuild 
--with-fbhelp=/var/lib/firebird/4.0/system 
--with-fbintl=/usr/lib/x86_64-linux-gnu/firebird/4.0/intl 
--with-fbmisc=/usr/lib/x86_64-linux-gnu/firebird/4.0/misc 
--with-fbsecure-db=/var/lib/firebird/4.0/system --with-fblog=/var/log/firebird 
--with-fbglock=/run/firebird4.0 --with-fblogfilename=firebird4.0.log 
--with-fbplugins=/usr/lib/x86_64-linux-gnu/firebird/4.0/plugins 
--with-fbmsg=/usr/lib/x86_64-linux-gnu/firebir!
d/4.0
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --build 
x86_64-linux-gnu --enable-raw-devices --disable-rpath --with-gpre-cobol 
--enable-regen-codes --with-system-re2 --with-system-editline 
--prefix=/usr/lib/x86_64-linux-gnu/firebird/4.0 --with-fbsbin=/usr/sbin 
--with-fblib=/usr/lib/x86_64-linux-gnu 
--with-fbconf=/usr/lib/x86_64-linux-gnu/firebird/4.0 
--with-fbdoc=/usr/share/doc/firebird4.0-common-doc 
--with-fbudf=/usr/lib/x86_64-linux-gnu/firebird/4.0/UDF 
--with-fbsample=/usr/share/doc/firebird4.0-common-doc/examples 
--with-fbsample-db=/usr/share/doc/firebird4.0-common-doc/examples/empbuild 
--with-fbhelp=/var/lib/firebird/4.0/system 
--with-fbintl=/usr/lib/x86_64-linux-gnu/fire!
bird/4.0/intl --with-fbmisc=/usr/lib/x86_64-linux-gnu/firebird/4.0/misc 
--with-fbsecure-db=/var/lib/firebird/4.0/system --with-fblog=/var/log/firebird 
--with-fbglock=/run/firebird4.0 --with-fblogfilename=firebird4.0.log 
--with-fbplugins=/usr/lib/x86_64-linux-gnu/firebird/4.0/plugins 
--with-fbmsg=/usr/lib/x86_64-linux-gnu/firebird/4.0
configure: error: cannot find install-sh, install.sh, or shtool in builds/make.new/config 
"."/builds/make.new/config

Maybe there is a workaround to make the autoreconf more compatible, 
letting me backport firebird4.0 to bullseye?


Viele Grüße,
Frank

Bug#1001070: command-not-found: crashes when entering an unknown command

[Frank Heckenbach]

Package: command-not-found
Version: 20.10.1-1
Severity: grave
Justification: renders package unusable

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

Bug #917455 was closed with:

  Marked as fixed in versions 20.10.1-1

This is *NOT* the case!

After upgrading to bullseye, which includes
command-not-found 20.10.1-1, the bug is there again!

% foo
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

The temporary fix still works:

  sudo chmod 644 /var/lib/command-not-found/commands.db

But after the next update, the permissions are set wrong again.

The actual fix is (and probably always has been) to set in
/sbin/update-command-not-found:

  os.umask (0o022)

I see no trace of this having been done. In fact, there's no
occurrence of "umask" anywhere in the sources (including Debian
patches) -- except for debian/changelog!??? (And a much older
changelog entry anyway.)

So it doesn't seem this bug was actually ever fixed.

Bug#783485: We need to talk ( get back to me today )

[Frank Miller]

Hello,

My name is Frank Miller, I'm contacting you concerning a certain bonded account 
in a bank that shares the same last name as yours, please contact me via email 
if you are interested to know more.

It will be beneficial to all parties concerned.

Regards,

Frank Miller.

Bug#755202: We need to talk ( get back to me today )

[Frank Miller]

Hello,

My name is Frank Miller, I'm contacting you concerning a certain bonded account 
in a bank that shares the same last name as yours, please contact me via email 
if you are interested to know more.

It will be beneficial to all parties concerned.

Regards,

Frank Miller.

Bug#783485: We need to talk ( get back to me today )

[Frank Miller]

Hello,

My name is Frank Miller, I'm contacting you concerning a certain bonded account 
in a bank that shares the same last name as yours, please contact me via email 
if you are interested to know more.

It will be beneficial to all parties concerned.

Regards,

Frank Miller.

Bug#997971: [Beolingus] FWD: RE: Bug#997971: Monat ist männlich!

[Frank Richter]

Hello,

let me kindly drive your attention to the bug report 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997971 .  As your online 
version 
https://dict.tu-chemnitz.de/dings.cgi?service=de-en=0=0=Monat= 
is correct, it is unclear to me who is the culprit: dict, the dictionaries 
your distribute, or the interface between the two.


I manage the Beolingus database – 
https://dict.tu-chemnitz.de/deutsch-englisch/Monat.html

and the database for ding: https://ftp.tu-chemnitz.de/pub/Local/urz/ding/de-en/

Both contain: Monat {m}; Monat {n} [Ös.] [ugs.]      month /mo./ /mth/

I'm afraid I don't know how fd-deu-eng converts the "ding database" to the 
freedict format. I assume there is an omission to include [ugs.] 
(umganfssprachlich = colloquial).


Frank



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#997988: mimedefang: reload with embedded perl is refused

[Frank Doepper]

Package: mimedefang
Version: 2.84-4+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

using embedded perl (like recommended) for mimedefang-multiplexor

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

md-mx-ctrl reread

   * What was the outcome of this action?

"Cannot destroy and recreate an embedded Perl interpreter safely on this 
platform.  Filter rules will NOT be reread"

   * What outcome did you expect instead?

mimedefang-multiplexor to be reloaded.

This is the same error as in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516913
which was solved via
https://sources.debian.org/patches/mimedefang/2.84-4/embperl.patch/
which is still included.

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

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

Versions of packages mimedefang depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  libc6   2.31-13+deb11u2
ii  libio-stringy-perl  2.111-3
ii  libmailtools-perl   2.21-1
ii  libmilter1.0.1  8.15.2-22
ii  libmime-tools-perl  5.509-1
ii  libperl5.32 5.32.1-4+deb11u2
ii  libunix-syslog-perl 1.1-3+b3
ii  perl [libmime-base64-perl]  5.32.1-4+deb11u2
ii  psmisc  23.4-2

mimedefang recommends no packages.

Versions of packages mimedefang suggests:
pn  clamav
pn  graphdefang   
ii  libarchive-zip-perl   1.68-1
ii  libhtml-parser-perl   3.75-1+b1
pn  sanitizer 
ii  sendmail  8.15.2-22
ii  spamassassin [libmail-spamassassin-perl]  3.4.6-1
pn  tk | wish 
pn  wv

-- Configuration Files:
/etc/mail/mimedefang-filter changed [not included]
/etc/mail/sa-mimedefang.cf [Errno 2] No such file or directory: 
'/etc/mail/sa-mimedefang.cf'

-- debconf-show failed

Bug#992841: Solved the problem

[Frank Ehmsen]

Hi,

so stupid. Microsoft Teams is only able to handle video resolutions
smaller than 1280x720.
Switch the output resolution to 1280x720 and it works. 
Please close the Bug as this is not a problen in Debian, V4L2 or obs-
studio.

Bye,

Frank


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

Bug#996872: librsvg2-bin: stroke-dasharray rendered wrong

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal

% cat a.svg



% rsvg-convert -f pdf -o a.pdf a.svg
%

The resulting PDF (attached) contains a thin line across the part of
the path that should not be drawn.

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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information


a.pdf
Description: Adobe PDF document

Bug#995757: module: inline class member function cannot use an extern thread_local int

[Frank Brokken]

Package: g++-11
Version: 11.2.0-7
Severity: normal

Dear Maintainer,

   * What led up to the situation?

While developing a module whose interface declares an extern thread_local int
and a class whose member accesses that int the compiler produces an internal
compiler error. The bug is observed when the member's implementation is
provided as an inline function, below the interface. If either instead of
'extern thread_local int' an 'extern int' is declared or if instead of an
inline function the function's implementation is provided in-class the
compiler bug isn't observed.

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

Here's the demo source:


/*
Define not THREAD_LOCAL and not INCLASS:no error
Define not THREAD_LOCAL and INCLASS:no error
Define THTREAD_LOCAL and not INCLASS:   internal compiler error
Define THTREAD_LOCAL and INCLASS:   no  error
*/

#define THREAD_LOCAL
#define INCLASS

module;

#include 

export module DemoMod;

export
{
#ifdef THREAD_LOCAL
extern thread_local int g_errno;
#else
extern int g_errno;
#endif

struct Demo
{
#ifdef INCLASS
void member()
{
g_errno = 0;
}
#else
void member();
#endif

};

#ifndef INCLASS
inline void Demo::member()
{
g_errno = 0;
}
#endif

}   // end export block



   * What was the outcome of this action?

If INCLASS is not defined then the compiler produces the following bugreport:


demo.cc:15:8: internal compiler error: in tree_node, at cp/module.cc:9061
   15 | export module DemoMod;
  |^~
0x9d4646 trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9061
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
0x9d466d trees_out::tree_node(tree_node*)
../../src/gcc/cp/module.cc:9090
0x9d29fa trees_out::core_vals(tree_node*)
../../src/gcc/cp/module.cc:5915
0x9d313e trees_out::tree_node_vals(tree_node*)
../../src/gcc/cp/module.cc:7056
0x9d5aff trees_out::tree_value(tree_node*)
../../src/gcc/cp/module.cc:8892
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


   * What outcome did you expect instead?

I would have expected that the compiler would correctly compile the source
file for all four combinations of defining THREAD_LOCAL and INCLASS


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-7
ii  gcc-11-base   11.2.0-7
ii  libc6 2.32-4
ii  libgmp10  2:6.2.1+dfsg-2
ii  libisl23  0.23-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-7
ii  libzstd1  1.4.8+dfsg-2.1
ii  zlib1g1:1.2.11.dfsg-2

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
pn  gcc-11-doc   

-- no debconf information

Bug#995000: g++-11: module partition defining a class won't compile

[Frank Brokken]

Package: g++-11
Version: 11.2.0-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

While performing some tests using modules I first defined a module defining a
class type. Its compilation completed flawlessly. Next I defined a module
partition defining a class type. It's compilation failed.

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

First the module that was successfully compiled:

I defined the following module interface (in, e.g., 'module.cc'):

-
export module mod;

export class Data
{
int d_value = 10;

public:
int value() const;
};
-

and the implementation of value() (in, e.g., 'value.cc'):

-
module mod;

int Data::value() const
{
return d_value;
}
-

to compile I issued:

g++-11 -c -std=c++20 -fmodules-ts module.cc value.cc

compilation completed flawlessly.


Next the module partition whose compilation failed:

I defined (in a difference directory as used for the above source files)
the following module partition interface (e.g., 'partition.cc)':

-
export module mod:partition;

export class Data
{
int d_value = 10;

public:
int value() const;
};
-

and the implementation of value() (in, e.g., 'value.cc'):

-
module mod:partition;

int Data::value() const
{
return d_value;
}
-

to compile I issued:

g++-11 -c -std=c++20 -fmodules-ts partition.cc value.cc

compilation of value failed.

   * What was the outcome of this action?

The compiler produced the following error messages:

value.cc:3:5: error: ‘Data’ has not been declared
3 | int Data::value() const
  | ^~~~
value.cc:3:19: error: non-member function ‘int value()’ cannot have 
cv-qualifier
3 | int Data::value() const
  |   ^
value.cc: In function ‘int value()’:
value.cc:5:12: error: ‘d_value’ was not declared in this scope; did you 
mean ‘value’?
5 | return d_value;
  |^~~

   * What outcome did you expect instead?

Since the compilation of the plain module completed without errors, and
since a partition is a subsection of a module, without any special
restrictions w.r.t the kind of elements it can contain, I would have expected
that the compilation of the partition's 'value.cc' would succeed as well. It's
OK to define mere variables or functions in partitions, but currently
implementations of members of classes whose interfaces are provided in module
partition interface files produces errors, which comes as a surprise.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-4
ii  gcc-11-base   11.2.0-4
ii  libc6 2.32-4
ii  libgmp10  2:6.2.1+dfsg-2
ii  libisl23  0.23-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-4
ii  libzstd1  1.4.8+dfsg-2.1
ii  zlib1g1:1.2.11.dfsg-2

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
pn  gcc-11-doc   

-- debconf-show failed

Bug#907615: tty0 missing

[Frank Wunderlich]

Hi,

is there any new state?

i tried the workaround:

# mknod /dev/tty0 c 4 0
# systemctl restart getty@tty1.service
# systemctl status getty@tty1.service

and then it works...till the next container-restart.../dev/tty0 is
missing again. Tried lxc-create in buster and bullseye host with
bullseye guest. Both are still affected.

regards Frank