Bug#1071036: update-mime does not escape semicolon in .desktop Exec entries

[Max Nikulin]

Package: mailcap
Version: 3.70+nmu1

During processing media type handlers from .desktop files, the
update-mime tool does not escapes ";" in Exec entries when it creates
mailcap entries. As a result, tools reading mailcap files treat command
part after first semicolon as flags.

See
https://lists.debian.org/msgid-search/6328be76-2961-49f9-abd4-9e79ba26c...@dybdal.dk
Bookworm's /etc/mailcap seems to break s-nail.
debian-user, Mon, 6 May 2024 14:53:10 +0200

For example, Emacs uses rather complex commands to explicitly pass
DISPLAY value to emacs server and to escape arguments of --eval commands:

grep Exec /usr/share/applications/emacsclient*
/usr/share/applications/emacsclient.desktop:Exec=sh -c "if [ -n 
\\"\\$*\\" ]; then exec emacsclient --alternate-editor= 
--display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient 
--alternate-editor= --create-frame; fi" sh %F
/usr/share/applications/emacsclient-mail.desktop:Exec=bash -c 
"u=\\${1///}; u=\\${u//\\"/\\"}; 
exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" --eval 
\\"(message-mailto \\"\\$u\\")\\"" bash %u
/usr/share/applications/emacsclient-mail.desktop:Exec=bash -c 
"u=\\${1///}; u=\\${u//\\"/\\"}; 
exec emacsclient --alternate-editor= --create-frame --eval 
\\"(message-mailto \\"\\$u\\")\\"" bash %u


To reproduce the issue you may use the following file (replace emacs
with xterm, xmessage, etc., name is chosen to get high priority).

 8<  /usr/share/applications/a-bug-mailcap.desktop
[Desktop Entry]
Name=A Bug Mailcap
Type=Application
Icon=emacs
Comment=Semicolon escaping in mailcap entries
Exec=sh -c "if ! emacs -Q --title IF \\"\\$1\\"; then emacs -Q --title 
ELSE; fi" sh-c %f

MimeType=text/x-java;
 >8 

run update-mime

run-mailcap --debug --norun "test.java"
# ...
Processing file "test.java" of type "text/x-java" (encoding=none)...
 - checking mailcap entry "text/x-java; sh -c "if ! emacs -Q --title IF 
\\"\\$1\\"; then emacs -Q --title ELSE; fi" sh-c %s; test=test -n 
"$DISPLAY""

 - program to execute: sh -c "if ! emacs -Q --title IF \\"\\$1\\"
 - running test: test -n "$DISPLAY"  (result=0=true)
 - filename contains shell meta-characters; aliased to 
'/tmp/tmp.YK5LRgdFPM'

 - executing: sh -c "if ! emacs -Q --title IF \"\$1\" then run-mailcap pass proper command (quoted semicolons are logged as 
invalid UTF-8 characters):


 - program to execute: sh -c "if ! emacs -Q --title IF \\"\\$1\\"� then 
emacs -Q --title ELSE� fi" sh-c %s

 - running test: test -n "$DISPLAY"  (result=0=true)
 - filename contains shell meta-characters; aliased to 
'/tmp/tmp.SrojfTimdb'
 - executing: sh -c "if ! emacs -Q --title IF \"\$1\"; then emacs -Q 
--title ELSE; fi" sh-c /tmp/tmp.SrojfTimdbsh -c "if ! emacs -Q --title 
IF \"\$1\"; then emacs -Q --title ELSE; fi" sh-c /tmp/tmp.SrojfTimdb


Not being a perl programmer, I expect in ReadDesktopEntries in
update-mime something like

# Ensure odd number of backslashes before semicolons.
exec =~ s/((?:)*)\\?(;)/\1\\\2/g;

However I expect more issues since I have not noticed code converting
\s, \n, \r, \t escapes, see
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s04.html
"Possible value types" in Desktop Entry Specification

Likely a more complex function is necessary to unquote Exec value from
.desktop files and to properly escape the result for shell and mailcap.

Please, either fix quoting of semicolons or ignore complex commands.

P.S. BASH fallback code in xdg-open has even more severe issues with
parsing of complex Exec entries. Fortunately, for most of users it
delegates handling of URIs to desktop environments.

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Thu, 18 Apr 2024 20:31:45 +0300 Antti-Pekka Känsälä wrote:


so I don't expect anything further.


Please, consider closing this bug by sending response to
1068122-d...@bugs.debian.org

Accordingly to https://www.debian.org/Bugs/Developer


Normally, the only people that should close a bug report are the
submitter of the bug and the maintainer(s) of the package against which
the bug is filed.

Bug#761600: Still using deprecated pam_env.so user_readenv option

[Max Bowsher]

I just found my way to this bug nearly 10 years later whilst wanting to
report the same issue still persists.

PAM upstream changed the default of user_readenv from 1 to 0 in
https://github.com/linux-pam/linux-pam/commit/f83fb5f25263356391d71da595def409e8dd90f7
and subsequently added explicit deprecation of the feature in
https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784

Other default /etc/pam.d/ files in Debian that invoke pam_env.so, do not
include user_readenv=1 - SSH is an unexpected outlier in this regard.

One further surprise: whilst the nomenclature tends to lead people in the
direction of believing ~/.pam_environment is a user addition to
/etc/environment, it is not, it is actually a user addition to
/etc/security/pam_env.conf. I am uncertain if this was originally intended,
or was a historic coding error normalized by time. Previous versions of the
man page text hint at the latter -
https://github.com/linux-pam/linux-pam/issues/6.


In view of all these things, I believe there is an excellent case for
dropping "user_readenv=1" from debian/openssh-server.sshd.pam.in

Bug#620927: We could fix this by upstreaming the Ubuntu diff to include pam_env.so in sudo's PAM config

[Max Bowsher]

I found this bug when in the same circumstance of /etc/environment proxy
settings not applying to sudo sessions.

I understand the rationale for "wontfix"-ing the previously suggested fix
of changing /etc/sudoers.

However, Ubuntu have been carrying a patch for the past 12 years which
addresses the issue in a different, potentially more acceptable way, and I
haven't been able to find any evidence in bug trackers of forwarding that
diff back to Debian being discussed, so I'm bringing it up here:

```
diff --git a/debian/etc/pam.d/sudo b/debian/etc/pam.d/sudo
index 96e8906a..7819ab18 100644
--- a/debian/etc/pam.d/sudo
+++ b/debian/etc/pam.d/sudo
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 sessionrequired   pam_limits.so

+sessionrequired   pam_env.so readenv=1 user_readenv=0
+sessionrequired   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session-noninteractive
diff --git a/debian/etc/pam.d/sudo-i b/debian/etc/pam.d/sudo-i
index d6385222..584b2d8e 100644
--- a/debian/etc/pam.d/sudo-i
+++ b/debian/etc/pam.d/sudo-i
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 sessionrequired   pam_limits.so

+sessionrequired   pam_env.so readenv=1 user_readenv=0
+sessionrequired   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session
```

Including pam_env.so in sudo's PAM configuration would apply system-wide
environment settings to sudo sessions, in a way which is generally
consistent with the existing Debian PAM configurations for cron, login,
sshd, and su.

The Ubuntu bug in which these changes were originally made 12 years ago was
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/982684, and proxy
settings are cited as motivation there as well.

Bug#1070150: Loading of expl3.ltx **extremely** slow on emulated runs

[Max Chernoff]

Hi Norbert,

On Thu, 2024-05-02 at 17:44 +0900, Norbert Preining wrote:
> sorry, but I don't understand!!
>
> On Wed, 01 May 2024, Max Chernoff wrote:
> > I don't think that this is TeX-related. From a Fedora 39 x86_64 host:
>
> Your data:
>
> > $ podman run --arch arm64 --rm -it --pull always debian:stable /bin/bash
> [...]
> > real0m52.253s
>
>
> > $ podman run --arch arm64 --rm --pull always -it debian:sid /bin/bash
> [...]
> > real3m52.398s
>
> That is a 4 times increase, ok, this does a lot of things. IN
> particular, apt uses fsync a lot.

I noticed that everything seemed much slower when trying to install the
TeX in the container, so I thought that it might be that the entire
system is slower, not just TeX.

> But what I measured in the emails is *only* the loading of one text
> file, without IO ops.

There's quite a bit of IO. From my host system:

   $ sudo strace -ffe read fmtutil-sys --byfmt lualatex 2>&1 | wc -l
   21440

But I've done some further testing, and my initial guess was completely
wrong (sorry). This *does* appear to be an issue particular to the
Debian TeX binaries. Using the attached file "factorial.tex" (you can
change the "1" inside the file to "1000" if you're impatient), on my
host system I get:

   $ time luatex --ini ./factorial.tex
   This is LuaTeX, Version 1.17.0 (TeX Live 2023)  (INITEX)
restricted system commands enabled.
   (./factorial.tex)
   No pages of output.
   Transcript written on factorial.log.

   real0m3.952s
   user0m3.921s
   sys 0m0.030s

and inside an arm64 sid container I get:

   $ apt install --no-install-recommends texlive-binaries
   $ wget 
'https://ftp.math.utah.edu/pub/tex/historic/systems/texlive/2023/tlnet-final/archive/luatex.aarch64-linux.tar.xz'
   $ tar xf luatex.aarch64-linux.tar.xz
   $ cd bin/aarch64-linux

   $ time luatex --ini ~/factorial.tex
   This is LuaTeX, Version 1.17.0 (TeX Live 2023/Debian)  (INITEX)
   (/root/factorial.tex)
   No pages of output.
   Transcript written on factorial.log.

   real 17m49.488s
   user 17m49.395s
   sys  0m0.016s

   $ time ./luatex --ini ~/factorial.tex
   warning: kpathsea: configuration file texmf.cnf not found [...]
   This is LuaTeX, Version 1.17.0 (TeX Live 2023)  (INITEX)
   (/root/factorial.tex)
   No pages of output.
   Transcript written on factorial.log.

   real 0m42.353s
   user 0m42.319s
   sys  0m0.021s

Last year, there was a similar problem where the main TeX Live LuaTeX
binaries were compiled with full debug symbols, but that was a ~50%
slowdown, not a 25x slowdown. See the thread starting at

   https://tug.org/pipermail/luatex/2023-August/007853.html

or some more detailed benchmarks at

   https://tug.org/pipermail/luatex/2023-August/007875.html
   https://tug.org/pipermail/luatex/2023-August/007864.html

Looking through the build logs

   
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/texlive-bin_2023.20230311.66589-9.rbuild.log.gz

it looks like the LuaTeX binaries were compiled with "-g -O2", but
running "readelf" and "objdump" shows that they're stripped, so I don't
think that that's the issue here.

And this issue appears to affect all engines: I also tried testing with
pdfTeX (comment out the \directlua line, and add the --etex command line
flag), and for 1000 iterations I got:

   Debian Sidarm64  LuaTeX: 0m15.392s
   Debian Sidarm64  pdfTeX: 0m7.914s
   TeX Live 2023 arm64  LuaTeX: 0m0.737s
   TeX Live 2023 x86_64 pdfTeX: 0m0.156s
   TeX Live 2023 x86_64 LuaTeX: 0m0.156s

I'm not sure what's going on here, but hopefully this gives you some
clues.

Thanks,
-- Max
\catcode`\{=1
\catcode`\}=2
\catcode`\#=6

\directlua{tex.enableprimitives("", tex.extraprimitives("etex"))}

\def\factorial#1{%
\ifnum#1=0
1%
\else%
\numexpr\factorial{\numexpr#1 - 1\relax} * #1\relax%
\fi%
}


\def\loop#1\repeat{\def\body{#1}\iterate}
\def\iterate{\body \let\next=\iterate \else\let\next=\relax\fi \next}
\let\repeat=\fi

\def\out{}
\countdef\n=0

\loop\ifnum\n<1
\edef\out{\out \the\factorial{12}}
\advance\n by 1
\repeat

\end

Bug#1070150: Loading of expl3.ltx **extremely** slow on emulated runs

[Max Chernoff]

Hi Norbert,

On Thu, 2024-05-02 at 08:44 +0900, norb...@preining.info wrote:
> at Debian they got a report that loading expl3.ltx when building formats
> is **extremely** slow when running under emulations:
>
> 1070150 at bugs.debian.org
>
> Running fmtutil output through ts (timestamp utility from moreutils):
>
> May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1 branch)
> May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
> May 01 14:51:15 
> (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks,
> May 01 14:51:19 document commands, control, par, spacing, files, font 
> encodings, lengths,
>
> That is 23 **minutes** to load expl3-code.tex. Ok, the file is nearly 4k
> lines, but still, 23 minutes seems to be excessive.

I don't think that this is TeX-related. From a Fedora 39 x86_64 host:

$ podman run --arch arm64 --rm -it --pull always debian:stable /bin/bash

$ apt update && \
  apt install -y moreutils && \
  apt install -y --download-only python3-minimal
[...]

$ time apt install -y python3-minimal | ts
May 02 05:27:51 Reading package lists...
May 02 05:27:52 Building dependency tree...
May 02 05:27:52 Reading state information...
May 02 05:27:52 The following additional packages will be installed:
May 02 05:27:52   ca-certificates krb5-locales libexpat1 libgpm2 
libgssapi-krb5-2 libk5crypto3
May 02 05:27:52   libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 
libnsl2
May 02 05:27:52   libpython3.11-minimal libpython3.11-stdlib libreadline8 
libsqlite3-0 libssl3
May 02 05:27:52   libtirpc-common libtirpc3 media-types openssl python3.11 
python3.11-minimal
May 02 05:27:52   readline-common
May 02 05:27:52 Suggested packages:
May 02 05:27:52   gpm krb5-doc krb5-user python3.11-venv python3.11-doc 
binutils
May 02 05:27:52   binfmt-support readline-doc
May 02 05:27:53 The following NEW packages will be installed:
May 02 05:27:53   ca-certificates krb5-locales libexpat1 libgpm2 
libgssapi-krb5-2 libk5crypto3
May 02 05:27:53   libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 
libnsl2
May 02 05:27:53   libpython3.11-minimal libpython3.11-stdlib libreadline8 
libsqlite3-0 libssl3
May 02 05:27:53   libtirpc-common libtirpc3 media-types openssl 
python3-minimal python3.11
May 02 05:27:53   python3.11-minimal readline-common
[...]
May 02 05:28:40 done.

real0m52.253s
user0m51.889s
sys 0m7.453s

$ exit

$ podman run --arch arm64 --rm --pull always -it debian:sid /bin/bash

$ apt update && \
  apt install -y moreutils && \
  apt install -y --download-only python3-minimal
[...]

$ time apt install -y python3-minimal | ts
May 02 05:29:22 Reading package lists...
May 02 05:29:26 Building dependency tree...
May 02 05:29:26 Reading state information...
May 02 05:29:30 Installing:
May 02 05:29:30   python3-minimal
May 02 05:29:30
May 02 05:29:30 Installing dependencies:
May 02 05:29:30   ca-certificates libpython3.11-minimal media-types
readline-common
May 02 05:29:30   libexpat1   libpython3.11-stdlib  openssl
May 02 05:29:30   libgpm2 libreadline8t64   python3.11
May 02 05:29:30   libncursesw6libsqlite3-0  python3.11-minimal
May 02 05:29:30
May 02 05:29:30 Suggested packages:
May 02 05:29:30   gpm python3.11-venv python3.11-doc binutils 
binfmt-support readline-doc
[...]
May 02 05:32:56 done.

real    3m52.398s
user3m54.177s
sys 0m7.514s

$ exit

Thanks,
-- Max

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Tue, 9 Apr 2024 14:34:36 +0300 Antti-Pekka Känsälä wrote:

> > I am worried Gmail in a Firefox tab is able to break out of Firefox
> > somehow, gaining unauthorized access to 128 files on a mounted USB
stick.

For my initial bug report, I just quickly did a "wc -l" on a long initial
printout, so I was mistaken to claim those were distinct files, I don't
know if they were.  But now I think it is strange that the same file should
be open so many times, it is wasteful at least and could lead to a cause
for the clinging.


The file is opened once accordingly to the output you posted. It is how 
lsof reports usage in the case of multithread applications. Perhaps 
other ways to deal with files exist, but I am in doubts concerning real 
benefits for multithread applications related to privacy.


As to access to other files, you may try to figure out if Firefox uses 
file picker provided by desktop-portal. Behavior may be different for 
flatpak/snap and deb packages. I am unsure if XFCE uses some 
desktop-portal implementation. This feature is intended to control what 
files an application may access, however in the case of deb package 
there is no barriers.



Maybe it has to do with semi-legitimate virus scanning,


You should know better if you have virus scanning software installed. 
From my point of view, some file indexer should be more probable 
variant (however it should ignore removable devices at least by default).



I continue to worry about my USB stick security.


You may find processes accessing specific files using autitd.

What actions do you expect from Debian maintainers? (I am not a maintainer.)

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Mon, 1 Apr 2024 21:32:41 +0300 Antti-Pekka Känsälä wrote:

Closing the Gmail tab will not help.


I rarely use gmail web UI. At least in the case of KDE, Firefox releases
file descriptor a few seconds after compose dialog is closed. It seems
even closing the tab is not necessary. It was a file on an internal
drive, but I do not think it matters.


appe@renaissance:~$ lsof | grep -i KINGSTON
x-www-bro 83803 appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83807 glean.dis appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg

[...]

From my point of view it is in contradiction with the original complain:


I am worried Gmail in a Firefox tab is able to break out of Firefox
somehow, gaining unauthorized access to 128 files on a mounted USB stick.


Isn't /media/appe/KINGSTON/noname/file4.gpg the file you attached? What 
are other 127 files?

Bug#1068343: adb: move-log-file-to-proper-dir.patch is incorrect (CVE-2012-5564)

[Max Nikulin]

Package: adb
Version: 1:29.0.6-28

This is a follow-up to
- #688280 android-tools: CVE-2012-5564: android-tools-adb creates a file 
with a static file name in /tmp

- #823792 adb creates its log file in /tmp

adb still creates log files in /tmp and
move-log-file-to-proper-dir.patch aimed to use /run/user
for log files does not work as expected.

The upstream bug
https://issuetracker.google.com/issues/37008476
"The adb server has a hardcoded write to /tmp/adb.log."
was marked as "Won't fix".

It seems, stat is incorrectly called for the expected file name, so the 
test fails after reboot. The directory name should be used instead.

I expect something like

+const char *xdg_dir = getenv("XDG_RUNTIME_DIR");
+std::string log_dir = xdg_dir ? xdg_dir
+  : android::base::StringPrintf("/run/user/%u", getuid());
+struct stat st = {0};
+if (stat(log_dir.c_str(), ) == 0) {
+  return log_dir + "/adb.log";
+}

I do not consider it as a serious security issue since
"sysctl fs.protected_symlinks" is set by default nowadays.
https://docs.kernel.org/admin-guide/sysctl/fs.html#protected-symlinks

Perhaps there are cases (a lab for students) when somebody may create a
file with a UID of another user (e.g. /tmp/adb.1001.log) causing some
annoyance. As a workaround the following snippet may be sourced when
user environment is initialized:

if [ -z "$ANDROID_ADB_LOG_PATH" ]; then
android_adb_log_dir="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"
if [ -d "$android_adb_log_dir" ]; then
export ANDROID_ADB_LOG_PATH="$android_adb_log_dir/adb.log"
else
printf "%s: does not exist, adb log would be created in %s\n" \
"$android_adb_log_dir" "${TMPDIR:-/tmp}" 1>&2
fi
fi

I believe, the patch should be either dropped or fixed. In the latter
case log file location should be documented in
/usr/share/doc/adb/README.Debian

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Sun, 31 Mar 2024 12:51:52 +0300 Antti-Pekka Johannes Känsälä wrote:


https://lists.debian.org/debian-user/2024/03/msg00721.html


Notice that this thread is broken into many part. (Perhaps because gmail 
does not support In-Reply-To in mailto: links)



I am worried Gmail in a Firefox tab is able to break out of Firefox
somehow, gaining unauthorized access to 128 files on a mounted USB stick.


Output of the command to confirm the statement was not provided.

From my point of view, something close to valid behavior was described.

- If a file from an external drive is chosen for  
then it is reasonable to expect that it can be used later when a form is 
submitted or an e-mail with the attachment is sent. Users are free to 
select another file, so eagerly reading the file to memory is not always 
reasonable. As a result it may be impossible to unmount the drive 
immediately.
- File icons should appear in the file chooser and it may assume 
determining media types of these files.


So precise description of steps and observed effects is necessary to 
make this bug report convincing.

Bug#1067630: fixed in emacs 1:29.3+1-1

[Max Nikulin]

On 25/03/2024 15:47, Sean Whitton wrote:

On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:


On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
Debian stable?


Neither are necessary.


Do you mean that somebody is working on backporting changes to 28.2 in 
bookworm already? This bug is closed. Have I missed other ones for 
elpa-org in unstable and for emacs in stable?

Bug#1067630: fixed in emacs 1:29.3+1-1

[Max Nikulin]

On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 
in Debian stable?

Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"

[Max Nikulin]

Control: found -1 1:28.2+1-15

On Sun, 24 Mar 2024 16:53:55 -0300 David Bremner wrote:

** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode.
This is for security reasons, to avoid evaluating malicious Lisp code.


Emacs-28 in Debian 12 bookworm requires the fix as well.

Source: org-mode
versions 9.5 and 9.6 till 9.6.23 are affected as well.


** LaTeX preview is now by default disabled for email attachments.
To get back previous insecure behavior, set the variable
'org--latex-preview-when-risky' to a non-nil value.


This one is rather old, so almost certainly even Emacs-26 is affected.
On the other hand its severity is not so high and only users having 
latex packages installed are affected.


See also
Ihor Radchenko to emacs-orgmode… [ANN] Emergency bugfix release: Org 
mode 9.6.23. Sun, 24 Mar 2024 17:16:50 +. 
https://list.orgmode.org/871q7zbldp.fsf@localhost



The fix for LaTeX evaluation requires Emacs 29.3 and will not work for
the earlier Emacs versions. If upgrading Emacs is not viable, as a
workaround, you can set `org-preview-latex-default-process' to 'verbatim
- this will disable LaTeX previews and avoid the vulnerability.

Bug#1063505: udhcpd provides unknown virtual package dhcpd

[Max-Julian Pogner]

Package: udhcpd
Version: 1:1.36.1-6
Severity: normal
X-Debbugs-Cc: max-jul...@pogner.at

Dear Maintainer,

The package 'udhcpd' declares 'Provides: dhcpd', making 'dhcpd' a
virtual package.

I read debian policy 4.6.2.0 section 3.6. [1] such, that there is a
SHOULD NOT requirement that only virtual packages listed in the
authoritative list of virtual package names [2] are used.
However, 'dhcpd' is not currently listed.

This Provides was added to debian/control back in 2009 and left
unchanged since, maybe there was a different situation back then.

I would think it proper that only an official package maintainer (or
debian developer) requests the addition of the virtual package to the
list. But maybe i can suggest the naming 'dhcp-server' instead of
'dhcpd', as it aligns with the already existing virtual package
'dhcp-client'.

best regards,

Max


[1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual-pkga
[2] https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

Bug#1063504: udhcpc does not Provides: dhcp-client

[Max-Julian Pogner]

Package: udhcpc
Version: 1:1.36.1-6
Severity: normal
X-Debbugs-Cc: max-jul...@pogner.at

Dear Maintainer,


The relationship 'Provides: dhcp-client' seems to be missing from 
udhcpc's DEBIAN/control file.

However, i have a feeling this might be intentional, so i would like
ask the oppinion of the package maintainers.

Considerations:

* https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

  This list specifies the virtual package "dhcp-client" as "a DHCP client".
  I could not find a more comprehensive defintion of what does or does not
  fall under said virtual package.

* 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components

  isc-dhcp-client is listed as deprecated component of bookworm, and
  udhcpc is mentioned as replacement for the user with the ifupdown
  package.

* The ifupdown (v0.8.41)

  Here the relationship is 'Recommends: isc-dhcp-client | dhcp-client',
  with dhcp-client currently being provided by dhcpcanon, dhcpcd-base,
  and isc-dhcp-client.

* I have found no active or archived bug in bugs.debian.org for the
  udhcpc package or src:busybox package regarding the matter of
  provided virtual package(s) by the udhcpc package.


My Take:

I think that udhcpc should also declare provides dhcp-client if and
when the usage by ifupdown "just works" for the most common real
use-cases.

I am currently testing the replacement of isc-dhcp-client with
udhcpc for my use-case, but am already predetermined to assume that
udhcpc already **is** a drop-in replacement for isc-dhcp-client.

I have only briefly considered the system-wide (as in: other debian
users around the world) impact of adding the Provides. Because ifupdown
still lists isc-dhcp-client as primary choice for dhcp-client, i would
expect that only users explicitly choosing udhcpc are "affected"
insomuch as their choice is not listed as one of the possibilities
instead of them just knowing that this choice also exists.
  Also regarding the system-wide effect, i have briefly looked at the
relationships of other packages recommending dhcp-client:

netctl ... just "Recommends: dhcp-client" without preferred choice.
  How does apt make the actual choice in this case? Just by
  alphabetical order of package names?
madwimax ... "Recommends: dhcp3-client | dhcp-client"
ifupdown-ng ... "Recommends: isc-dhcp-client | dhcp-client"
whereami ... "Depends: perl, fping | iputils-ping | netbase | dhcp-client | 
isc-dhcp-client"
  I'm not really sure why the dependencies would be like that,
  instead of listing them as Recommends.


So the question finally is: Is there something bad happening if
udhcpc (also) "Provides: dhcp-client"?


best regards,

Max


PS: i created a merge-request in salsa as a company to this bug report.
Would it be better etiquette for this bug to set a patch tag or not?

The URL of the merge request is:
https://salsa.debian.org/installer-team/busybox/-/merge_requests/13

Bug#1061291: Acknowledgement (composer: recommends missing: php-curl)

[Max-Julian Pogner]

Dear Maintainers,

as a post-scriptum note:

Maybe this is a missing dependency-detection in dh_phpcomposer and 
actually this dependency should pop up as part of the 
${phpcomposer:Debian-recommend} substvar?


Or maybe the upstream's composer.json should list php-curl?
But i don't find the location where to place it, since the composer json 
file format[1] has "require" and "suggest", but no "recommends" 
dependency section.


best regards,

Max



[1] https://getcomposer.org/doc/04-schema.md#suggest


On 22/01/2024 10:39, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

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

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

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

Your message has been sent to the package maintainer(s):
  Debian PHP PEAR Maintainers 

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

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

Bug#1061291: composer: recommends missing: php-curl

[Max-Julian Pogner]

Package: composer
Version: 2.6.6-1
Severity: normal
X-Debbugs-Cc: max-jul...@pogner.at

Dear Maintainer,

When using the command `composer upgrade`, composer displays a warning

> Composer is operating significantly slower than normal because you
> do not have the PHP curl extension enabled.

When the package 'php-curl' is installed, no warning appears with that
command. I would have expected that php-curl is listed as a Recommends-
dependency when composer is slowed down otherwise.
A detailed report follows (some output removed and replaced by '[...]').


   * What led up to the situation?

I created a minimal test for this bug as follows:

  $ echo "today is: $(date)"
  today is: Mon 22 Jan 10:37:33 CET 2024
  $ docker container run -ti --rm debian:sid
  root@c16e8b892f02:/# apt update
  [...]
  root@c16e8b892f02:/# apt install --install-recommends --yes composer
  [...]
  root@c16e8b892f02:/# mkdir /project
  root@c16e8b892f02:/project# cd /project
  root@c16e8b892f02:/project# composer require slim/slim
  [...]

Now using the command `composer upgrade` gives out the warning:

  root@c16e8b892f02:/project# composer upgrade
  Composer is operating significantly slower than normal because you do not 
have the PHP curl extension enabled.
  [...]

However, when installing php-curl, the warning is no longer there:

  root@c16e8b892f02:/project# apt install --yes php-curl
  [...]
  root@c16e8b892f02:/project# composer upgrade
  [..no warning..]


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

Installing the package 'php-curl' made the warning go away.
Hoever, compose works fine without 'php-curl' being installed.
Note: The actual speed-effect was not meassured.


   * What did you expect instead?

I would have expected, that composer would have a 'Recommends:'
dependency on any package that is not strictly necessary but is warned
about.


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages composer depends on:
ii  jsonlint  1.10.1-1
ii  php-cli   2:8.2+93
ii  php-common2:93
ii  php-composer-ca-bundle1.4.0-1
ii  php-composer-class-map-generator  1.1.0-1
ii  php-composer-metadata-minifier1.0.0-2
ii  php-composer-pcre 3.1.1-1
ii  php-composer-semver   3.4.0-1
ii  php-composer-spdx-licenses1.5.8-1
ii  php-composer-xdebug-handler   3.0.3-2
ii  php-json-schema   5.2.13-1
ii  php-psr-log   1.1.4-2
ii  php-react-promise 3.1.0-1
ii  php-seld-signal-handler   2.0.2-1
ii  php-symfony-console   5.4.34+dfsg-2
ii  php-symfony-filesystem5.4.34+dfsg-2
ii  php-symfony-finder5.4.34+dfsg-2
ii  php-symfony-process   5.4.34+dfsg-2
ii  php8.2-cli [php-cli]  8.2.12-1+b1

Versions of packages composer recommends:
ii  git1:2.43.0-1
ii  unzip  6.0-28

Versions of packages composer suggests:
pn  fossil  
pn  mercurial   
pn  php-zip 
pn  subversion  

-- no debconf information

Bug#1021370: pipewire: build with bluez5-codec-aac=enabled

[Max Nikulin]

On 13/01/2024 02:17, Jeremy Bícha wrote:

On Fri, Jan 12, 2024 at 11:12 AM Max Nikulin  wrote:

An alternative may be building a separate package for the contrib
repository section that contains just the aac codec plugin.


I would prefer getting fdk-aac-free into Debian main. It has been in
the NEW queue for roughly 2 years.


I suggested a separate contrib package because after reading #981285 I 
decided that there is a little chance that package can be moved to main.


"Changes" in
https://ftp-master.debian.org/new/fdk-aac-free_2.0.2-3.html
(I hope NEWS file advertises it as well) contains a better description 
of intentions in comparison to the request to ftpmasters in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981285#64

I was confused by
https://fedoraproject.org/wiki/Licensing/FDK-AAC

[UPDATE: As of some date in August 2022, the FDK-AAC license is expected
to be reclassified as not-allowed (essentially, non-free) because of its
"no patent licenses" feature. This is not expected to have an impact on
the continued packaging of fdk-aac-free in Fedora.]
Maybe another message to ftpmasters could help. One that clearly states 
the steps taking to resolve licensing issues.


It may be offered to add new set of binary packages, e.g. 
libfdk-aac2-free having Provides: libfdk-aac2 and Conflicts: 
libfdk-aac2. However duplication increases maintenance burden in the 
case of security bugs.


So it is necessary to identify friction points related to fdk-aac-free.

Bug#1021370: pipewire: build with bluez5-codec-aac=enabled

[Max Nikulin]

On Fri, 07 Oct 2022 00:11:56 +0200 KeyofBlueS wrote:


please build pipewire with aac codec support enabled.


An alternative may be building a separate package for the contrib 
repository section that contains just the aac codec plugin.


I have no experience with meson, so I have no idea if it is possible to 
force it to ignore everything besides the specific plugin. As a proof of 
concept I have tried the following Makefile. Perhaps more flags should 
be added.


# - atomic_dep?
top_srcdir ?= .
top_builddir ?= $(top_srcdir)
builddir ?= $(top_srcdir)

spaversion = $(shell sed -n -e "s/^spaversion *= *'\(.*\)'$$/\1/p" 
$(top_srcdir)/meson.build)

pkgname = libspa-$(spaversion)
plugindir = $(shell pkg-config --variable=plugindir $(pkgname))
installdir = $(plugindir)/bluez5
# toplevel default_options
plugin_CFLAGS += --std=gnu11 -fPIE
# toplevel cc_flags
plugin_CFLAGS += -D_GNU_SOURCE -DFASTPATH
# toplevel common_flags
plugin_CFLAGS += -fvisibility=hidden -fno-strict-aliasing
# AVX and SSE flags perhaps may be ignored since
# computations should be done inside the linked library
# bluez5 codec_args
plugin_CFLAGS += -DCODEC_PLUGIN
# spa pkgconfig
plugin_CFLAGS += $(shell pkg-config --cflags $(pkgname))
# required for shared library
plugin_CFLAGS += -fPIC
plugin_CFLAGS += $(shell pkg-config --cflags fdk-aac)
ALL_CFLAGS = $(plugin_CFLAGS) $(CFLAGS)
ALL_LDLIBS = $(LDLIBS) $(shell pkg-config --libs fdk-aac)

bluez5_dir = $(top_srcdir)/spa/plugins/bluez5
aac_codec = $(builddir)/libspa-codec-bluez5-aac.so
plugin_LIBRARIES += $(aac_codec)
plugin_OBJECTS += $(builddir)/a2dp-codec-aac.o $(builddir)/media-codecs.o

all: $(plugin_LIBRARIES)
clean:
$(RM) $(plugin_LIBRARIES) $(plugin_OBJECTS)

# Not $(LD) due to $(LDFLAGS)
# ld: unrecognized option '-Wl,-z,relro'
$(aac_codec): $(plugin_OBJECTS)
$(CC) -o $@ -shared $(LDFLAGS) $^ $(ALL_LDLIBS)

$(builddir)/%.o: $(bluez5_dir)/%.c
$(CC) -o $@ $(CPPFLAGS) $(ALL_CFLAGS) -c $<

install: $(plugin_LIBRARIES)
install -D --target-directory $(DESTDIR)$(installdir) 
$(plugin_LIBRARIES)

.PHONY: all clean install

--- 8< --- debian/rules --- 8< ---
#!/usr/bin/make -f

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_LDFLAGS_MAINT_APPEND = -Wl,-z,defs

%:
dh $@

# Custom Makefile instead of configure script
override_dh_auto_configure:
override_dh_makeshlibs:

Bug#803265: bluetooth.service: sap-server: Operation not permitted (1)

[Max Nikulin]

Control: tag -1 + patch

On Wed, 17 Nov 2021 16:36:58 +0200 Matti Kurkela wrote:
As packaged, the SAP server component no longer has any actual 
implementation to access a card reader: the upstream removed the last 
actual implementation (for the long-dead STE U8500 platform) in 
2017-07-13. Only the dummy implementation in sap-dummy.c is left:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/sap?id=3a140aa35b7b7dc1d7b031eec40590187f70a980

[...]> Starting bluetoothd with the option "--noplugin=sap" by default (as
already suggested) would be one way to do it. Another way would be to 
patch the `bootstrap-configure` file in the source root directory, to 
change `--enable-sap` to `--disable-sap`.


In its current form, the SIM Access Profile support of BlueZ is only 
useful for developers, and even that requires modifying 
/etc/dbus-1/system.d/bluetooth.conf before it will do anything other 
than display an error message on Bluetooth service start-up. This is 
true of both the version in bullseye and the current unstable version.


It seems since


"build: Add option to enable SAP profile"
2016-11-17 14:15:42 +0200

the SAP plugin is not built by default.
Ubuntu does not have --enable-sap in their
https://git.launchpad.net/ubuntu/+source/bluez/tree/debian/rules
for a long time, see
https://git.launchpad.net/ubuntu/+source/bluez/commit/debian/rules?id=3df71d750c11c4fffdaa59e56064ae3471e60b8c

I suggest to drop --enable-sap from debian/rules (see the attached 
patch) to not confuse users troubleshooting their bluetooth issues.


As an alternative, src/bluetooth.service.in may be patched to disable 
this plugin:


ExecStart=@pkglibexecdir@/bluetoothd --noplugin=sapDo not build SIM Access Profile (sap) plugin

The sap plugin is not enabled by default,
unlikely useful nowadays, and causes a warning
on daemon startup due to missed D-Bus policy in
/etc/dbus-1/system.d/bluetooth.conf
See also: 

(Closes: #803265)

--- bluez/debian/rules.orig	2024-01-03 09:39:10.381835631 +
+++ bluez/debian/rules	2024-01-03 09:41:34.515448901 +
@@ -19,7 +19,6 @@
 	--enable-library \
 	--enable-test \
 	--enable-nfc \
-	--enable-sap \
 	--enable-monitor \
 	--enable-udev \
 	--enable-obex \

Bug#1017988: bluez: systemd: ConfigurationDirectory 'bluetooth' already exists but the mode is different

[Max Nikulin]

Control: tag -1 upstream
Control: forwarded -1 https://github.com/bluez/bluez/issues/414

On Tue, 23 Aug 2022 10:56:27 -0600 Kevin Locke wrote:


systemd[1234]: ConfigurationDirectory 'bluetooth' already exists but the mode 
is different. (File system: 755 ConfigurationDirectoryMode: 555)

[...]

[Service]
ConfigurationDirectory=bluetooth
ConfigurationDirectoryMode=0555


These lines were added to fix

"systemd failed to set up mount namespacing for /var/lib/bluetooth"
and it seems the intention was to have the `/etc/bluetooth` directory
read-only. Actually the effect is the opposite. `ProtectSystem=strict`
causes `/` being mounted read-only and `ConfigurationDirectory` causes
`/etc/` mounted as writable.

So the extra directives decrease degree of protection against various 
potential vulnerabilities in bluetoothd. Otherwise the reported warning 
may be considered harmless.


As a workaround you may create the following configuration drop-in file
/etc/systemd/system/bluetooth.service.d/disable-configuration-directory.conf

 8< 
[Service]
ConfigurationDirectory=
ConfigurationDirectoryMode=
 >8 

To apply updated configuration run

systemctl daemon-reload
systemctl restart bluetooth.service

Bug#1057371: bash completion for fscrypt

[Max Nikulin]

Package: fscrypt
Version: 0.3.3-1+b6
Severity: wishlist

Please, add the bash completion file to the fscrypt package.
It is available in the package sources, see
https://sources.debian.org/src/fscrypt/0.3.3-1/cmd/fscrypt/fscrypt_bash_completion/
it should be installed to
/usr/share/bash-completion/completions/fscrypt

As a workaround users may put it to
~/.local/share/bash-completion/completions/fscrypt
for a while.

Bug#1056303: pg_createcluster destroys data directory under certain conditions

[Max Kellermann]

Package: postgresql-common
Version: 248
Severity: critical

When I tried to use "pg_createcluster" to configure my pre-existing
PostgreSQL data directory with a new Debian install, it deleted the
whole cluster with all databases instead.  (This serious data loss
justifies "severity critical" according to
https://www.debian.org/Bugs/Developer#severities)

Steps to reproduce:

 pg_createcluster 15 test
 cp /etc/postgresql/15/test/postgresql.conf /var/lib/postgresql/15/test/
 rm -r /etc/postgresql/15/test
 pg_createcluster 15 test

This creates a new cluster just for the demo, then deletes the
configuration directory, after copying the postgresql.conf to the data
directory.

I expect the second "pg_createcluster" call to find the existing data
directory and configure it; and it tries to do so indeed:

 Configuring already existing cluster (configuration: /etc/postgresql/15/test, 
data: /var/lib/postgresql/15/test, owner: 103:111)

After it finds and moves a "postgresql.conf", it however fails to find
"pg_hba.conf"

 Error: move_conffile: required configuration file 
/var/lib/postgresql/15/test/pg_hba.conf does not exist

This fails the whole operation, and apparently, "pg_createcluster"
tries to roll back by invoking "pg_dropcluster 15 test 2>/dev/null",
destroying all pre-existing data.

If "postgresql.conf" does not exist (or is empty), "pg_dropcluster" is
not invoked.

Bug#1055212: librust-pyo3-dev: 0.17 version does not support sub-interpreters and leads to ImportError

[Max Carrara]

On Tue, 7 Nov 2023 15:50:10 +0100 Max Carrara  wrote:
> On Thu, 02 Nov 2023 13:31:16 +0300 Andrew Kornilov  
> wrote:
> > Package: librust-pyo3-dev
> > Version: 0.17.3-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: akorni...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > 
> >* PyO3 0.17 introduced a serious regression/issue with related software
> > (ceph, mod_wsgi and so on). Here is the issue with all the links and 
> > detailed
> > description: https://github.com/PyO3/pyo3/issues/3451
> >* PyO3 0.20 seems to have this fixed according to the included PR
> > https://github.com/PyO3/pyo3/pull/3446
> 
> I'm currently in the process of backporting the PR. So far PyO3 compiles; 
> there
> are some tests that don't yet pass, however. Will hopefully be able to provide
> a patch series soon.
> 

The backport of the aforementioned PR didn't fix the issue regarding
sub-interpreters, unfortunately. Will have to wait until this is fixed
upstream in PyO3.

I do want to note though that this isn't a "regression" per se; this
check was introduced to PyO3 because PyO3 isn't sound under the presence
of multiple sub-interpreters. So, this check is basically a security measure.

Bug#1055212: librust-pyo3-dev: 0.17 version does not support sub-interpreters and leads to ImportError

[Max Carrara]

On Thu, 02 Nov 2023 13:31:16 +0300 Andrew Kornilov  wrote:
> Package: librust-pyo3-dev
> Version: 0.17.3-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: akorni...@gmail.com
> 
> Dear Maintainer,
> 
> 
>* PyO3 0.17 introduced a serious regression/issue with related software
> (ceph, mod_wsgi and so on). Here is the issue with all the links and detailed
> description: https://github.com/PyO3/pyo3/issues/3451
>* PyO3 0.20 seems to have this fixed according to the included PR
> https://github.com/PyO3/pyo3/pull/3446

I'm currently in the process of backporting the PR. So far PyO3 compiles; there
are some tests that don't yet pass, however. Will hopefully be able to provide
a patch series soon.

Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

On 30/10/2023 10:28, Osamu Aoki wrote:

On Thu, 2023-09-21 at 21:56 +0700, Max Nikulin wrote:

On 18/09/2023 20:12, Osamu Aoki wrote:


     APT::Default-Release "testing";

I think this don't drive people to set this to "stable" as much.


  From my point of view it is a bit better, but hardly noticeable. And it
is still misleading for Debian users since testing has security updates
as well, thus not so trivial regexp is preferred. apt.conf(5) has more
examples, but neither of them is close to what might be used in real life:


Although, repository for testing security updates exists, it is hardly used in
practice.


I feel some kind of miscommunication here. I was trying to say that

APT::Default-Release "stable";

prevents updates from stable-security (bookworm-security). This 
repository is rather important, it is configured by installer, it is 
mentioned in various docs, e.g.

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics

deb http://security.debian.org/debian-security bookworm-security main 
non-free-firmware contrib non-free


I would not call it "hardly used". I agree that testing-security 
repository is currently empty, but I assume, it may not be so during 
late freeze stages. Moreover, having example for "testing", users may 
try to blindly apply it for "stable".



Updated text:

The target release archive can be set by the command line option, e.g., 
"apt-get
install -t testing some-package"


Thank you for improving of the docs. I consider the issue as fixed.

Bug#1053749: systemd-sysusers: on WSL1, /etc/passwd lock fails, breaks other dpkg postinst

[Max P.]

Package: systemd
Version: 254.5-1
Severity: normal
X-Debbugs-Cc: max+b...@prehl.us

Dear Maintainer,

I am new to submitting bug reports so please bear with me.

I am running Debian Sid in WSL1. As of a few releases ago, systemd and 
systemd-timesyncd started using systemd-sysusers in their dpkg postinst
scripts. It was during some system upgrades that I found out that 
systemd-sysusers is quite broken on the WSL1 system due to a bad lock 
implementation.

You can see several reports in this post:
- https://superuser.com/a/1805742/1298503

I was able to work around this issue by following some of the advice in
the thread.  Moving the postinst scripts temporarily, then running dpkg
--configure, then putting them back.

It was while exploring these scripts that I found the references to
systemd-sysusers.

I tried using systemd-sysusers on it's own and it will not work AT ALL,
it only produces the error:

`Failed to take /etc/passwd lock: Permission denied`

Because it was so badly broken, i also opened a report on the systemd
upstream repo:
- https://github.com/systemd/systemd/issues/29512

I'm hoping at the very least that Debian can build in some fallbacks in
the postinst scripts so that we are still able to update our systems on
WSL1 without intense workarounds.


-- Package-specific info:

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

Kernel: Linux 4.4.0-19041-Microsoft (UP)
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: unable to detect

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-2
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-2
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-2
ii  libp11-kit00.25.0-4
ii  libseccomp22.5.4-1+b3
ii  libselinux13.5-1
ii  libssl33.0.11-1
ii  libsystemd-shared  254.5-1
ii  libsystemd0254.5-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-2
ii  systemd-dev254.5-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-1
ii  systemd-timesyncd [time-daemon]  254.5-1

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1
pn  libqrencode4  
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
pn  polkitd   
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1
pn  dracut 
pn  initramfs-tools
pn  libnss-systemd 
ii  libpam-systemd 254.5-1
ii  udev   254.5-1

-- no debconf information

Bug#1041708: Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

On 18/09/2023 20:12, Osamu Aoki wrote:


Since　Bug#1041708 was mentioned, I CC it.


It is marked as "done", so perhaps you need to reopen it if you expect
some actions.


I propose to replace this line with

APT::Default-Release "testing";

I think this don't drive people to set this to "stable" as much.


From my point of view it is a bit better, but hardly noticeable. And it
is still misleading for Debian users since testing has security updates
as well, thus not so trivial regexp is preferred. apt.conf(5) has more
examples, but neither of them is close to what might be used in real life:


Default-Release

Default release to install packages from if more than one version is
available. Contains release name, codename or release version. Examples:
'stable', 'testing', 'unstable', 'bookworm', 'trixie', '4.0', '5.0*'.
See also apt_preferences(5).


I believe that explicit warnings against usage of APT::Default-Release
will be helpful for users.

I have not noticed issues with regexp and "apt-get source" or synaptic
in bookworm. Either they exist or not, mention of regexp as an option is
valuable from my point of view (with or without a warning concerning
lack of support in some tool). It will affect decision of those who are
aware of regexp from the bullseye release notes.

Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

On 16/09/2023 15:37, Osamu Aoki wrote:

So my first thought was replace it with:

- Release definition in "/etc/apt/apt.conf" configuration file started with
"APT::Default-Release"

But As I read complicationa it causes from your messages, let's drop it.  I
don't use it anyway.


Since the "APT::Default-Release" option is present in the document for 
years, I would prefer to see a warning close to the current place where 
it is mentioned. Consider somebody is asked about this setting and their 
opens the reference to provide a link. Completely disappeared mention 
may make them thinking that it was seen in another document.


I do not insist however. I admit that removing obsolete material 
completely is widely used practice, so I am OK with your plan to just 
drop it.


From my point of view, it is worst variant when "APT::Default-Release" 
is described without the not so trivial regexp or without a warning 
concerning complications. This feature evolved into a kind of pitfall.


Thank you for your work on debian-reference.

Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

Package: debian-reference
Version: 2.100

The "2.7.7. Tweaking candidate version with apt-pinning" section
in "Chapter 2. Debian package management" recommends


The target release archive can be set by several methods.

- "/etc/apt/apt.conf" configuration file with "APT::Default-Release "stable";" 
line
- command line option, e.g., "apt-get install -t testing some-package"


https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version

Unfortunately "APT::Default-Release "stable";" prevents installing of 
updates from stable-security and stable-updates repositories. So this 
option should be either just dropped or a warning should be added to 
alert users who remembers it from previous release.


Accordingly to the Debian 11 bullseye release notes acceptable value for 
default release may be



APT::Default-Release "/^bullseye(|-security|-updates)$/";


https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
"5.1.3. Changed security archive layout"
in "Chapter 5. Issues to be aware of for bullseye"

However there are opinions that this option should be considered as 
deprecated:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041708#38
apt man pages

https://lists.debian.org/debian-security/2022/01/msg00022.html
Re: Bullseye security.debian.org codename misconfigured?
Sat, 22 Jan 2022 21:07:09 +0100

There is a similar bug against debian-handbook
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041706
filed during the following discussion
https://lists.debian.org/debian-security/2023/07/msg00011.html
"Setting APT::Default-Release prevents installation of security updates 
in bookworm!?"


In my case it was bookworm with the backports repository added to test a 
wifi issue and trixie to get firefox-esr 115 earlier than it will appear 
in stable. By setting APT::Default-Release I was going to prevent 
upgrade kernel from backports to testing when I noticed missed security 
updates. I decided to use apt pinning instead.


I have seen doubts concerning support of APT::Default-Release in
synaptic and regexps in "apt source PKG", but I have not noticed any
problem. So I am unsure if it can be an *additional* argument against
APT::Default-Release.

I admit that some users may need purely stable release without security 
updates (e.g. to test upgrades from particular versions), but I believe 
this case is too specific to be covered in the manual.


Either removing mention of the setting or adding a warning against 
APT::Default-Release should prevent users from making their 
configuration insecure.

Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export

[Max Nikulin]

On 13/09/2023 03:12, Nicholas D Steeves wrote:

Changes will be included into the next major Org mode release.


So 9.6.10 or possibly 9.7.0.


The patch is committed to the main branch, but not to bugfix, so >= 9.7.0.


#+language: de
#+latex_header: \usepackage[AUTO]{babel}

results in

\usepackage[ngerman]{babel}
\hypersetup{
   % ...
   pdflang={German}}

It is a bit different from Org mode 9.5 however


I assume you mean 9.5.x, and that this will affect uses who upgrade from
Debian 12/bookworm (or older) to future 13/trixie.


yes


\usepackage[germanb]{babel}
\hypersetup{
   % ...
   pdflang={Germanb}}


Hm, this looks like something that should probably be noted in upstream
org-mode release notes, which would also eventually trickle down to
Emacs release (due to its bundled copy of org-mode).


There are no modifications of the ORG-NEWS file in the commit. Perhaps 
more significant changes are coming.


I am in doubts if pre-1996 "traditional" orthography (germanb) was 
really intentional for "de". Perhaps post-1996 "reformed" style 
(ngerman) is closer to user expectations. I do not speak German however, 
so I can not judge if it was really a bug or (an obscure from my point 
of view) feature. Long language mapping list was added at once.


Anyway those who need namely older "germanb" may use

#+language: de
#+latex_header: \usepackage[english,germanb]{babel}

instead of "AUTO"

#+language: de
#+latex_header: \usepackage[english,AUTO]{babel}

Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

[Max Nikulin]

I hope,

firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

is a really harmless message and

options iwlwifi enable_ini=0

has no side effects besides suppressing attempts of loading this file.

The real issue that a missed firmware file is first thing to suspect in
the case of firmware crashes (likely caused by some other bug). It takes
time to estimate real severity of the message by looking up for bug reports.

It would be great to see clearly expressed intentions in logs like
"optional development-only firmware" or "iterating to find latest
available version" instead of obscure "failed to load" that may mean
anything from critical error to logging of a routine action.

The message appears during boot of linux-image-amd64_6.4.4-3~bpo12+1
backport kernel.

Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export

[Max Nikulin]

H.-Dirk Schmitt writes:

> In difference to the 9.5 version the setting `#+LANGUAGE: de-de` is not 
working any more.
> The option of the babel LaTeX package is in this case now empty.
>
> An easy mitigation is to use instead `de-de` the `de` language code.


The following upstream commit restored "de-de" language definition:

893c5d085 2023-09-08 19:33:25 +0200 Juan Manuel Macias: ox-latex.el: 
Fixes and improvements in `org-latex-language-alist'.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=893c5d085

See the emacs-orgmode mailing list thread for details
https://list.orgmode.org/orgmode/877coywan5@posteo.net/
Juan Manuel Macías. Re: [patch] Fixes and improvements in 
org-latex-language-alist. Sun, 10 Sep 2023 11:06:06 +


Changes will be included into the next major Org mode release.

#+language: de
#+latex_header: \usepackage[AUTO]{babel}

results in

\usepackage[ngerman]{babel}
\hypersetup{
 % ...
 pdflang={German}}

It is a bit different from Org mode 9.5 however

\usepackage[germanb]{babel}
\hypersetup{
 % ...
 pdflang={Germanb}}

Bug#1051442: libnss-mdns can not access /run/avahi-daemon after reinstalling avahi-daemon due to its postrm script

[Max Nikulin]

Package: avahi-daemon
Version: 0.8-10
Severity: normal

I was experimenting with multicast name resolution performed by
libnss-mdns and libnss-resolve when I got the following failure.

apt purge avahi-daemon
# some experiments with systemd-resolved
apt install avahi daemon
getent hosts somehost.local

Nothing returned despite at this moment mdns4_minimal was present in
/etc/nsswitch.conf. Using strace I have find the reason of failure:

connect(3, {sa_family=AF_UNIX, sun_path="/run/avahi-daemon/socket"}, 
110) = -1 EACCES (Permission denied)


ls -ld /run/avahi-daemon
drwx-- 2 avahi avahi 80 Sep  8 10:43 /run/avahi-daemon

However it should be

drwxr-xr-x 2 avahi avahi 80 Sep  8 11:07 /run/avahi-daemon

I believe that the reason is

/var/lib/dpkg/info/avahi-daemon.postrm
# Cleanup /run/avahi-daemon, see #448539
f=/run/avahi-daemon
if [ -d "$f" ]; then
rmdir "$f" || { chown root:root "$f" && chmod 00700 "$f"; }
fi

This code snippet is not ready to current behavior of avahi-daemon
process that does not remove its PID file (#876342) and the socket
(#849454) on exit.

Purging configuration files for avahi-daemon (0.8-10) ...
rmdir: failed to remove '/run/avahi-daemon': Directory not empty

Behavior of mDNS may be surprising due to "SOA local" heuristics in
libnss-mdns and unicast settings of ISP provider. It is unfortunate that
the package script contributes to this mess as well. I admit that purge 
and install again without reboot in between scenario is not frequent.


Perhaps the /run/avahi-daemon directory should be removed by rm -r or by
another not so shy method. Anyway files in /run do not survive reboot.

Workaround:
systemctl stop avahi-daemon.service
rm -r /run/avahi-daemon/

Bug#1044133: apt-cacher-ng: please provide a native systemd .timer

[Max Nikulin]

Notice that the cron package is not installed by default in Debian 12 
bookworm, so a systemd .timer unit will make acng maintenance script 
working even in minimal configuration.


I think, the approach used by apt is applicable to apt-cacher-ng as 
well: /lib/systemd/system/apt-daily.timer and 
/lib/systemd/system/apt-daily.service files for systemd and 
/etc/cron.daily/apt-compat has the following check


if [ -d /run/systemd/system ]; then
exit 0
fi

Both the .service unit and the cron job execute 
/usr/lib/apt/apt.systemd.daily helper.


On Sun, 13 Aug 2023 16:41:57 +0200 Alexandre Detiste wrote:

but fails when run through systemd-cron.

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

> Could not make a valid request to the server.
> Please visit
> 
http://UNIX-DOMAIN-SOCKET/acng-report.html?doExpire=Start+Expiration=aOe
> and check special conditions.


I do not see the issue with pure systemd timer.

May it happen that apt-cacher-ng process was not running for some reason 
when the maintenance task was started? Another hypothesis is that 
generated systemd unit is running in so strict isolation that network is 
unavailable to it.


Check Protect*, Private* and similar properties in the output of

  systemctl show cron-daily-apt-cacher-ng.service
  systemctl cat cron-daily-apt-cacher-ng.service

Bug#1042415: ruby-aws-partitions: Package missing partitions.json

[Max Maton]

Package: ruby-aws-partitions
Version: 1.653.0-1
Followup-For: Bug #1042415

This also occurs on bookworm. After manually creating the file I also
had to manually create partitions-metadata.json for the package to work.

-- 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-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-aws-partitions depends on:
ii  ruby  1:3.1

ruby-aws-partitions recommends no packages.

ruby-aws-partitions suggests no packages.

-- no debconf information

Bug#1049454: mpd: purge script will forget a PulseAudio cookie in /var/lib/mpd/.config

[Max Kellermann]

On 2023/08/16 13:23, Alexandre Detiste  wrote:
> Some other packages have similar problems...
> Here HOME=/ and users get tiny useless files at the root of the filesystem:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042725

Just because others are doing it just as wrong doesn't prove libpulse
correct.  If you delete those files during purge, you're sidestepping
the problem instead of fixing it.

> /var/lib/lightdm/.cache

Cache file, forgot to set CacheDirectory or didn't obey
$XDG_CACHE_DIRECTORY.  Either way it's a bug that can be fixed easily.

> /var/lib/lightdm/.config/pulse
> /var/lib/lightdm/.config/pulse/*

Belongs in $XDG_RUNTIME_DIR, not in $XDG_CONFIG_HOME.  Can be fixed
easily.

> /var/lib/lightdm/.dbus
> /var/lib/lightdm/.dbus/session-bus
> /var/lib/lightdm/.dbus/session-bus/*

What the  is ~/.dbus?  Looks like runtime files that belong in
$XDG_RUNTIME_DIR, not in $HOME.

Bug#1049454: mpd: purge script will forget a PulseAudio cookie in /var/lib/mpd/.config

[Max Kellermann]

On 2023/08/16 02:05, Alexandre Detiste  wrote:
> Package: mpd
> Version: 0.23.12-1
> Severity: minor
> User: cruft...@packages.debian.org
> Usertags: cruft
> 
> Hi,
> 
> On purge, the script will leave behind this useless PulseAudio cookie.

This file was not created by MPD, so I'm not sure if the MPD package
is the right place to delete it.  Deleting ".config" seems so
arbitrary - and, additionally, ".config" isn't even the right place
for runtime data.  Whoever put it there should be changed to store it
in /run, where it will be cleaned up automatically.

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Max Nikulin]

On 05/08/2023 16:35, Bastien wrote:

Max Nikulin writes:


I do not see any value in having this bug in the open state, but I am
leaving decision up to you.


I tested with the latest Org version and the bug is still there.


Bastien, similar issues have been raised on the emacs-orgmode mailing 
lists enough times. An example:


Nicolas Goaziou. c47b535bb origin/main org-element: Remove dependency on 
‘org-emphasis-regexp-components’

Thu, 18 Nov 2021 13:35:19 +0100.
https://list.orgmode.org/87y25l8wvs@nicolasgoaziou.fr :

I disagree. Priority should be given to the first object being started.
This is, IMO, the only sane way to handle syntax.


On 05/08/2023 16:35, Bastien wrote:

May I suggest to the OP (Josef?) to share the bug upstream on the
Org-mode list, if not already done?


Nicholas D Steeves added the link to the mailing list archive, see 
comments in the bug tracker.



Even if it's a minor gotcha, it deserves to be fixed.


It is not minor issue, it is design of parser as it was implemented by 
Nicolas Goaziou. I do not mind to get behavior similar to pandoc, but I 
can not estimate required efforts. Perhaps it would be a breaking change 
for some users.



Bugs are reported on the mailing list and tracked on
https://updates.orgmode.org.


An almost identical issue is tracked there as "Double colon :: in 
description breaks link and forces list item to become descriptive one". 
Another example of a record with similar origin related to parsing 
approach: "Bug: PDF Export of Link fails [9.4.6]"


I see 2 ways:
- Serious change of the org-element parser.
- More prominently documenting current behavior.

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Max Nikulin]

On 05/08/2023 13:08, Carsten Schoenert wrote:


Could you please cut all these additions into own peaces/patches?
By this it's more visible what the addition of adding a specific handler
is made of. And using git blame will make it easier to find what content
was added by which commit.


See the attached files. They do not include text/x-calendar present in 
the original patch. I am in doubts if it frequently appears in the wild.


Frankly speaking, I have see a little value in splitting a commit that 
changes just single line. I would not even try to add multiple MimeType 
entries even if they would be supported by some frameworks. I believe 
the comment was detailed enough to review entries of the list.


I decided to try git sparse-checkout and I was significantly more 
optimistic how much data I have to get to make a series of commits 
changing just single line. 1G is too much from my point of view. Perhaps 
shallow clone could reduce it by several times.From 686cdc23ac3b6019db6fb2b7ebbc685fd08b6353 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 17:55:59 +0700
Subject: [PATCH 1/4] d/thunderbird.desktop: Add IANA MIME type for .vcf vcard

Add registered text/vcard MIME type (RFC6350) in addition to
text/x-vcard.
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index 7ac4b218cb..c3e4be07ff 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 190d4f66d5e04eb6b21f7da1de575b624d4fc1a9 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:08:33 +0700
Subject: [PATCH 2/4] d/thunderbird.desktop: Add mid: URI to MIME types

Allow to handle mid: links supported since Thunderbird-87.
See RFC 2392 Content-ID and Message-ID Uniform Resource Locators.
(Closes: #1008159)
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index c3e4be07ff..96f79da0c2 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 5bd7a4741b38369e72b023ed473e03432a484ec4 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:11:15 +0700
Subject: [PATCH 3/4] d/thunderbird.desktop: Add webcal: URI to MIME types

Allow to handle webcal: and webcals: links (iCalendar).
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index 96f79da0c2..d3f4b492fd 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird
-- 
2.25.1

From 1cd3524b4dd3036bfdb8759db9a7dad4b05914f4 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 8 Aug 2023 18:14:05 +0700
Subject: [PATCH 4/4] d/thunderbird.desktop: Add news: URI to MIME types

Allow to handle links to USENET articles having news: URI scheme
<news://news.gmane.io/u02v26$1qu$1...@ciao.gmane.io>
---
 debian/thunderbird.desktop | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird.desktop b/debian/thunderbird.desktop
index d3f4b492fd..b036ff5412 100644
--- a/debian/thunderbird.desktop
+++ b/debian/thunderbird.desktop
@@ -9,7 +9,7 @@ Type=Application
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/news;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thund

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Max Nikulin]

On 03/08/2023 22:03, Nicholas D Steeves wrote:

Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf
:: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100


This is not a bug. -  :: *is* description list syntax, no matter how
you look at it. You can easily work around this, e.g., by starting the
link on the next line.


I read the thread upstream, and see what you mean, and upstream's
perspective makes sense.  How do you feel about keeping this bug open,


I do not see any value in having this bug in the open state, but I am 
leaving decision up to you. I rarely visit list of bugs for the elpa-org 
and org-mode packages.



because this "gotcha" should be documented somewhere.  I'm not sure if
org-mode's documentation would be the best place, because it's non-free.


In my opinion, the "first wins" rule should be prominently stressed in 
Org mode syntax description and it should be done in some general 
section, not in description of items

https://orgmode.org/worg/org-syntax.html#Items
It should help to make behavior of pandoc, org-ruby, etc. more 
consistent. However I can not suggest specific wording.


Despite some conflict of licenses, I do not think it is possible to 
avoid reading of the Org mode manual. It may benefit from a note on 
ambiguous syntax. Currently it has some references to zero width space 
hack only

https://orgmode.org/manual/Escape-Character.html
that has some drawbacks and not applicable to links.
https://orgmode.org/manual/Link-Format.html
Discusses escaping of brackets only disregarding possible interference 
with other markup structures.

https://orgmode.org/manual/Plain-Lists.html
does not mention possible issues as well.

Besides the manual, there are online-only (unless you clone the 
repository) docs at https://orgmode.org/worg/ If you are more 
comfortable with Debian wiki, you may create a page with tricks there. 
Perhaps it would be more "visible" to users than the bug report.



For future readers of this bug, Brian G Powell wrote some nice style
suggestions for avoiding this pitfall, so here is the link:

   
https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=gocx3rkq...@mail.gmail.com/#t


While I agree with Brian in general, in this particular case I would 
consider a more concise variant: breaking "::" by insertion of some 
characters:


- [[shell:cat ~/tmp | grep "asdf :"": "]] does +not+ work.

More checkers may be added to `org-lint' to catch similar pitfalls.


Indeed!  Please go ahead and give this bug a more useful title.


It falls in a rather generic class of
"Enclosing markup may lead to unexpected parsing results"
perhaps
"Double colon unexpectedly converts an item into description list"
would be better

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Max Nikulin]

On Sun, 21 Feb 2016 11:37:01 +0100 Sébastien Delafond wrote:


thanks for your report. As this seems to be a pure upstream problem,
could you please follow up on it using the org-mode mailing list[0] ?
Once that's done, feel free to add a link to your post in the Debian
BTS.


I think, this issue can be closed as not a bug:

Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf 
:: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100

https://list.orgmode.org/878u2a57r2@nicolasgoaziou.fr/T/#u


This is not a bug. -  :: *is* description list syntax, no matter how
you look at it. You can easily work around this, e.g., by starting the
link on the next line.

With more details in e.g.

Sun, 28 Feb 2016 00:03:13 +0100
https://list.orgmode.org/87h9gtdadq@nicolasgoaziou.fr/

Another example of similar confusion:

Bug with exporting list with link item containing "::" to markdown
https://list.orgmode.org/CABGRHLkLGXYgGNm4CXK_LjOTGTpsLO=5aWD=fypd1amy2qd...@mail.gmail.com/T/#u

And a related issue: try to export text where /italics breaks the link 
[[https://lists.debian.org/msgid-search/?m=zitsdg4dp0wxd...@powdarrmonkey.net][Bits 
from the Release Team: a trixie customer]] due to adjacent slash and 
question mark./


It is a price for lightweight markup and it is how org-element parser works.

P.S. Behavior of Org parser in pandoc may be different.

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.

[Max Nikulin]

On 06/07/2023 06:02, Nicholas D Steeves wrote:

"H.-Dirk Schmitt" writes:

A „clean solution“ should avoid duplicated distribution of the same
functionality – especially if one „shadows“ the other.


Can upstream be convinced of this „clean solution“?


If I remember correctly, Richard Stallman considers Org mode as an 
important part of Emacs. On the other hand there are users who prefer to 
have Org newer than built-in version, fortunately it is developed in a 
separate repository.


I am unsure that it is reasonable to split Emacs Debian package into a 
squad of smaller ones if an elpa-* counterpart is available. Perhaps it 
is easier to review elpa-* packages after packaging of new Emacs 
versions. I do not see much sense in painstakingly avoiding load shadowing.



For example a script that parses our Emacs' built-in
version, and that files release critical bugs against an elpa-foo
package when it's older than the Emacs built-in version.


package.el is created for interactive usage (`list-packages'), so the 
script will have to rely on internal variable and functions. When the 
package source file is known, `lm-header' may be used to obtain specific 
fields. It is doable, but unlikely straightforward.


P.S. Thanks for packaging of Org-9.6. I did not notice the experimental 
package.

Bug#907495: please ship the x11idle binary

[Max Nikulin]

On Sat, 03 Jun 2023 23:06:00 -0400 Nicholas D Steeves wrote:

> On 27/03 09:26, Michal Politowski wrote:
>> Actually I think there is no need to compile x11idle.  As the footnote
>> https://orgmode.org/manual/Resolving-idle-time.html#DOCF82 says,
>> Debian already provides xprintidle, which seems to work for me.
>> 
>> Maybe elpa-org could just suggest that package and change the default

>> for org-clock-x11idle-program-name?

...

Pending upload to experimental:

https://salsa.debian.org/emacsen-team/org-mode/-/commit/67d33aa4f2a26b8449f0f2ecb4404cdb2ad969a1


Next Org mode release will discover xprintidle out of the box:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1810c625d

Ihor Radchenko to emacs-orgmode…
[PATCH] Change default value of org-clock-x11-idle-program-name.
Tue, 24 Jan 2023 12:41:33 +.
https://list.orgmode.org/87zga83y0y.fsf@localhost

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here

[Max Nikulin]

Thank you for fixing of the https://bugs.debian.org/1035650 bug that was 
a duplicate of this one. I am glad to see that a dummy elpa-org package 
has been landed to bookworm.


Have you decided to keep this issue open to package Org-9.6 and to 
implement emacs-pkg-* provides or it was just forgotten in the changelog 
message and it should be closed?

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Max Chernoff]

Hi all,

> Version: 2018.20181218.49446-1+deb10u1

> This is LuaTeX, Version 1.07.0 (TeX Live 2019/dev/Debian)

> LaTeX2e <2018-12-01>

This is a very odd set of versions. "2018.20181218.49446" implies
TL2018, but your LuaTeX banner says "TeX Live 2019/dev/Debian". TL2019
contains LuaTeX version 1.07.0 and LaTeX version 2018-12-01, so this
looks like TL19 to me. And having "/dev" in the banner for a released
version is also quite odd.

> cat > test.tex < \documentclass{article}
> \begin{document}
> foo
> \end{document}
> EOF
> lualatex test.tex

Works with the upstream versions.

TeX Live 2019:

   $ type -p lualatex
   /tmp/tl2019/bin/x86_64-linux/lualatex
   
   $ grep -E '^[[:space:]]*(version|date)[[:space:]]*= "' $(kpsewhich 
luaotfload-configuration.lua)
   version = "2.96", --TAGVERSION
   date = "2019-02-14", --TAGDATE
   
   $ cat ./test.tex 
   \documentclass{article}
   \begin{document}
   foo
   \end{document}
   
   $ lualatex ./test.tex 
   This is LuaTeX, Version 1.10.0 (TeX Live 2019/CVE-2023-32700 patched) 
restricted system commands enabled.
   (./test.tex
   LaTeX2e <2018-12-01>
   
   luaotfload | main : initialization completed in 0.035 seconds
   (/tmp/tl2019/texmf-dist/tex/latex/base/article.cls
   Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
   (/tmp/tl2019/texmf-dist/tex/latex/base/size10.clo)) (./test.aux) 
[1{/tmp/tl2019
   /texmf-dist/fonts/map/pdftex/updmap/pdftex.map}] (./test.aux))
377 words of node memory still in use:
  2 hlist, 1 vlist, 1 rule, 2 glue, 3 kern, 1 glyph, 4 attribute, 44 
glue_spec
   , 4 attribute_list, 1 write nodes
  avail lists: 2:15,3:2,4:2,5:22,6:1,7:16,9:7
   

   Output written on test.pdf (1 page, 2696 bytes).
   Transcript written on test.log.

TeX Live 2018:

   $ type -p lualatex
   /tmp/tl2018/bin/x86_64-linux/lualatex
   
   $ grep -E '^[[:space:]]*(version|date)[[:space:]]*= "' $(kpsewhich 
luaotfload-configuration.lua)
 version   = "2.8",
   
   $ cat ./test.tex
   \documentclass{article}
   \begin{document}
   foo
   \end{document}
   
   $ lualatex ./test.tex
   lualatex ./test.tex
   This is LuaTeX, Version 1.07.0 (TeX Live 2018/CVE-2023-32700 patched) 
restricted system commands enabled.
   (./test.tex
   LaTeX2e <2018-04-01> patch level 2
   (using write cache: /tmp/tl2018/texmf-var/luatex-cache/generic)(using read 
cach
   e: /tmp/tl2018/texmf-var/luatex-cache/generic 
/home/mseven/.texlive2018/texmf-v
   ar/luatex-cache/generic)
   luaotfload | main : initialization completed in 0.055 seconds
   Babel <3.18> and hyphenation patterns for 1 language(s) loaded.
   (/tmp/tl2018/texmf-dist/tex/latex/base/article.cls
   Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
   (/tmp/tl2018/texmf-dist/tex/latex/base/size10.clo(load luc: 
/tmp/tl2018/texmf-v
   ar/luatex-cache/generic/fonts/otl/lmroman10-regular.luc))) (./test.aux)
   [1{/tmp/tl2018/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}] (./test.aux))
355 words of node memory still in use:
  2 hlist, 1 vlist, 1 rule, 2 glue, 3 attribute, 45 glue_spec, 3 
attribute_lis
   t, 1 write nodes
  avail lists: 2:15,3:3,4:1,5:22,6:1,7:16,8:1,9:6
   

   Output written on test.pdf (1 page, 2613 bytes).
   Transcript written on test.log.

> Short question: the web page for the security issue [1] lists a few 
> patches. I downloaded a few of them, but no one is matches to the 
> CVE-2023-32700.patch in the texlive-bin_2018.20181218.49446-1+deb10u1 
> diff. Which patch did you use?

> I don't see any patch differences though.

Your patch [1] is wrong. That patch just cherry-picks 5650c067 [2]:

   +static int io_kpse_popen (lua_State *L) {
   +  const char *filename = NULL;
   +  const char *mode = NULL;
   +  LStream *p = NULL;
   +  filename = luaL_checkstring(L, 1);
   +  mode = luaL_optstring(L, 2, "r");
   +  /* Check filename with kpse.check_permission . */
   +  lua_getglobal(L,"kpse");
   +  lua_getfield(L, -1, "check_permission");

But kpse.check_permission wasn't added until TL2020 [3], meaning that
any call to this io.kpsepopen/io.popen is guaranteed to fail. This is
actually lucky though -- 5650c067 contains a different security
vulnerability that is only resolved in b8b71a25 [4].

To fix this, there are 3 options (pick 1):

   1. Cherry-pick *both* 5650c067 and b8b71a25
  
   2. Follow the instructions in [5]
  
   3. Apply the appropriate patch from [6]

Option (3) will the easiest, but it will only work if your LuaTeX source
very closely corresponds to the source in an upstream TL release.
Otherwise, you'll need to do option (2). Option (1) is the same as
option (2), except I've already gone to the trouble of reducing the
patch to the bare minimum.

Thanks,
-- Max

[1]: 
https://github.com/debian-tex/texlive-bin/blob/bu

Bug#1034344: Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Max Nikulin]

On 29/05/2023 17:59, Paul Gevers wrote:


On 29-05-2023 12:51, Max Nikulin wrote:
I am unaware of another dash implementation. Do you mean ash from 
which dash was forked?


No, I understood from Andrej that dash *internally* has two ways to do 
the matching. One embedded implementation, and one using system library 
calls.


Thank you for clarification, I did not realized that you were writing 
about glob/fnmatch implementation that supports [^c] negation in glibc 
while the internal alternative treats its as a literal. Other libc 
variants are out of the scope of the debian package.

Bug#1034344: Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Max Nikulin]

On 29/05/2023 17:30, Paul Gevers wrote:

On 29-05-2023 12:02, Max Nikulin wrote:

Strictly speaking, behavior of circumflex is *unspecified* in POSIX:


... A bracket expression
    starting with an unquoted  character produces 
unspecified

    results.


Right. Maybe better to say it now matches the other implementation (dash 
has two implementations and they were behaving differently).


I am unaware of another dash implementation. Do you mean ash from which 
dash was forked? I have checked 
https://en.wikipedia.org/wiki/Debian_Almquist_shell and noticed that 
busybox ash implementation was derived from dash, but the similar issue 
is still open in their tracker.


I would recommend users to check scripts by the "shellcheck" static 
analyzer, but I am unsure if such suggestion is suitable for release 
notes or for Debian news in the dash package.

https://www.shellcheck.net/wiki/SC3026

Bug#1034344: Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Max Nikulin]

On 29/05/2023 02:53, Paul Gevers wrote:

Our (crafted with Andrej) proposal is here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/181


from the diff:

... as a literal
character, as was always the intended POSIX-compliant
behavior.


Strictly speaking, behavior of circumflex is *unspecified* in POSIX:


... A bracket expression
starting with an unquoted  character produces unspecified
results.


Moreover, it is intentionally left unspecified:
https://www.austingroupbugs.net/view.php?id=1558

Bug#1035650: elpa-org version older than built-in Org in bookworm

[Max Nikulin]

On 09/05/2023 05:00, Nicholas D Steeves wrote:

It's what at least two users want


Intention of my bug report is to ensure that it was a conscious decision 
to keep a bit outdated Org version. I hope, only a small part of users 
will really notice the difference with built-in version. I consider 
Org-9.6 as desired, but unrealistic, a dummy package as a compromise.



Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.


If you are against equivs then elpa-org dependency must be dropped from 
elpa-org-contrib. Unfortunately the latter requires a change of a 
package in testing.



You're describing the "dummy package" approach.  I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key)


There is a minor issue with the dummy package approach. Some (I hope 
rare) users may try to install emacs-27 from bullseye and dummy elpa-org 
(if it would be uploaded to bookworm at all of course) getting Org 
version (emacs built-in) significantly less than they may expect from 
the version of the elpa-org Debian package.


The following consideration are mostly concerning trixie, but still 
might affect current decision.


Adding Org version to emacs-el "Provides" is a reasonable idea since 
org-contrib, at least formally, does not require latest Org release, 
however it is possible that Package-Requires inside the .el file was not 
up to date. So likely org-contrib may be run with built-in Org.


However I think "elpa-org" is a bit confusing name for virtual package. 
Something like emacs-pkg-org in both emacs-el and elpa-org may be better.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033400#25

suggests to not ship Org in the emacs-el Debian package. Certainly it is 
possible to split built-in Org into a separate package and to add it to 
"Recommends" of emacs-el. However it increases maintenance cost while 
benefits are not clear to me. Perhaps it is better to discuss splitting 
in #1033400.


I think, users who relies on latest Org features and fixes, stick to 
other methods than elpa-org Debian package (and sometimes are bitten by 
e.g. package.el bugs). It is another reason to respect Debian release 
policy, but be more carefully with updates in future.

Bug#1035442: evolution: renders mail body only in one line after security update of libwebkit2gtk-4.0-37 to 2.40.1-1~deb11u1

[Max]

Package: evolution
Version: 3.38.3-1+deb11u1
Severity: important
X-Debbugs-Cc: deb-b...@ns4me.de

Dear Maintainer,

after installing some security updates evolution renders the mail body only in 
one line.
The mail body widget is still clickable and you can still mark the body.
It seems like the widget is not resized to fit the body.

The Problem occures after installing to following updates:
* gir1.2-webkit2-4.0 to 40.1-1~deb11u1
* libwebkit2gtk-4.0-37 to 2.40.1-1~deb11u1
* gir1.2-javascriptcoregtk-4.0 to 2.40.1-1~deb11u1
* libjavascriptcoregtk-4.0-18 to 2.40.1-1~deb11u1

After downgrading these libs evolution works fine:

apt-get install libwebkit2gtk-4.0-37=2.38.5-1~deb11u1 
libjavascriptcoregtk-4.0-18=2.38.5-1~deb11u1 
gir1.2-webkit2-4.0=2.38.5-1~deb11u1 
gir1.2-javascriptcoregtk-4.0=2.38.5-1~deb11u1

Cheers
Max

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

Kernel: Linux 5.10.0-22-amd64 (SMP w/3 CPU threads)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolution depends on:
ii  dbus   1.12.24-0+deb11u1
ii  evolution-common   3.38.3-1+deb11u1
ii  evolution-data-server  3.38.3-1+deb11u2
ii  libc6  2.31-13+deb11u6
ii  libcamel-1.2-623.38.3-1+deb11u2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1+deb11u2
ii  libedataserver-1.2-25  3.38.3-1+deb11u2
ii  libevolution   3.38.3-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u3
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.38.5-1~deb11u1
ii  libxml22.9.10+dfsg-6.7+deb11u4
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1+deb11u1
ii  evolution-plugin-pstimport   3.38.3-1+deb11u1
ii  evolution-plugins3.38.3-1+deb11u1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
ii  evolution-ews   3.38.3-1+deb11u1
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2+deb11u2
ii  network-manager 1.30.6-1+deb11u1

-- no debconf information

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Max Kellermann]

On 2023/04/11 17:40, Andreas Henriksson  wrote:
> I think 2 is better myself and I'm attaching a proof of concept
> debdiff to implement it. (You might want to make a cleaner version.)

Agree.  I think your patch looks quite clean, and if it were submitted
to me, I'd merge it (the same would probably be necessary for the user
units).

Maybe I'd go as far and remove the Meson options; they should never
have been there in the first place.  When those options were authored
and submitted to me long ago (in 2011 by commit 83f6498aac), I didn't
know systemd exposes those directories in its pkg-config file.

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Max Kellermann]

On 2023/04/11 15:11, Andreas Henriksson  wrote:
> The culprit seems to be that mpd falls back on hard-coded path (instead
> of failing) when systemd.pc is not found!

What does this have to do with systemd.pc?  It isn't used anywhere.

Bug#1025069: pipewire: audio broken, only says Dummy Output (on plain bookworm install)

[Max Dmitrichenko]

Package: pipewire-pulse
Version: 0.3.65-3
Followup-For: Bug #1025069
X-Debbugs-Cc: dmitr...@gmail.com

I'm confirming this issue. After upgrade from bullseye to bookworm sound in KDE 
disappeared. I was
able to restore it after manually installing wireplumber.


-- 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 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.65-3

Versions of packages pipewire-pulse recommends:
ii  wireplumber  0.4.13-1

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.65-3
pn  pulseaudio-utils  

-- no debconf information

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Max Nikulin]

Control: tags -1 +patch

I have noticed that besides mid: (Message-ID) protocol more URI schemes 
supported by thunderbird are missed in the .desktop file. It can open 
e.g. .ics files from https://, but I do not think it should be added.


For symmetry I have added x-/non-x- counterparts to text/calendar and 
text/vcard types.


See the attachment for a patch.More MIME file types and URI scheme handlers in thunderbird.desktop

  * Thunderbird is capable to handle more URI schemes:
-  USENET news links,
- mid: RFC 2392 - Content-ID and Message-ID Uniform Resource Locators,
- webcal: and webcals: calendars in iCalendar format,
- add alternatives for .ics and .vcf files.
(Closes: #1008159)

--- thunderbird_102.9.1-1/debian/thunderbird.desktop	2023-03-18 12:09:36.0 +
+++ thunderbird/debian/thunderbird.desktop	2023-04-01 10:17:39.553667864 +
@@ -9,7 +9,7 @@
 Version=1.0
 Icon=thunderbird
 Categories=Network;Email;News;GTK;
-MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
+MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/news;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/x-calendar;text/vcard;text/x-vcard;
 StartupWMClass=thunderbird-default
 StartupNotify=true
 Name[ast]=Veceru de corréu Thunderbird

Bug#1033405: rename: Switch --nono is sensitive to location

[Max Görner]

Package: rename
Version: 2.01-1
Severity: important

Dear Maintainer,

I tried to rename a bunch of files using `rename`/`file-rename`. I
checked carefully that both names point to the same program.

Since I wasn't sure about the correctness of renaming rule, I
**appended** the switch `--nono`. So, the final command I executed was
`rename 's/.*(S\d\d)_(E\d\d).*/$1$2$_/' --nono *`. Unfortunately, this
directly renamed all files! If I move `--nono` before the pattern,
everything behaves as expected: `rename --nono 's/.*(S\d\d)_(E\d\d).*/$1$2$_/' 
*`

The man page does not point out this behaviour as well. According to the
man page, giving `--nono` will stop `file-rename` to apply any changes.
In particular it is not mentioned that `--nono` must be given as first
argument and will have no effect otherwise.

I find this behaviour highly dangerous and it deleted some important
files I need to dig out from my backups now.

I think the preferred fix would be make `--nono` work regardless of its
position. A less favourable improvement could be to explicitly mention
the behaviour in the man page.

Thank you very much.

Regards
Max Görner


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

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

Versions of packages rename depends on:
ii  perl  5.36.0-7

rename recommends no packages.

rename suggests no packages.

-- no debconf information

Bug#1033326: ruby-rails: Rails app using development environment blocks all access with 'Blocked host'

[Max Maton]

Package: ruby-rails
Version: 2:6.0.3.7+dfsg-2+deb11u1
Severity: important
X-Debbugs-Cc: i...@maxmaton.nl, t...@security.debian.org

Dear Maintainer,

Using rails 2:6.0.3.7+dfsg-2+deb11u1 we can no longer run our app using
`RAILS_ENV=development rails s`.
Curling the server (`curl http://127.0.0.1:3000`) results in an error
message:

Blocked host: 127.0.0.1
To allow requests to 127.0.0.1, add the following to your environment 
configuration:

config.hosts << "127.0.0.1"

Adding this configuration setting does not allow connections to go
through. Running the curl command using the package in bullseye works.

I was able to find this online but I'm not sure if it's related: 
https://rubyonrails.org/2021/12/15/Rails-6-0-4-4-and-6-1-4-4-have-been-released
Changelog: 
https://github.com/rails/rails/compare/v6.0.4.3...v6.0.4.4#diff-401b1f2d4b94c52328880f3baca952f374f24903245327fc4c4527d6d5655a0c

Best regards,

Max Maton


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

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

Versions of packages ruby-rails depends on:
ii  ruby-actioncable  2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionmailbox2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionmailer 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionpack   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actiontext   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionview   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activejob2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activemodel  2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activerecord 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activestorage2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activesupport2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-bundler  2.2.5-2
ii  ruby-railties 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-sprockets-rails  3.2.1-1

ruby-rails recommends no packages.

ruby-rails suggests no packages.

-- no debconf information

Bug#1031027: libprometheus-cpp-core1.0: Library is built w/o optimization enabled

[Max Dmitrichenko]

Package: libprometheus-cpp-core1.0
Version: 1.0.0-1
Severity: important
X-Debbugs-Cc: dmitr...@gmail.com

The CMakeList.txt of the library doesn't contain default CMAKE_BUILD_TYPE to be 
set to Release. Neither this variable is not set in debian/rules file. So the 
resulting library is build with no optimization enabled which hits performance 
by factor of around 2x.


-- 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, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libprometheus-cpp-core1.0 depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

libprometheus-cpp-core1.0 recommends no packages.

libprometheus-cpp-core1.0 suggests no packages.

-- no debconf information

Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

[Max Bell]

This bug has been present since at least the 5.14 kernel. It's
profoundly annoying and shouldn't have been allowed to slip into
production release. Maybe someone could fix the problem this year?
It's really pathetic when things that worked perfectly 20 years ago
are broken because of shoddy code changes made since.

On 2/3/23, Vincent Lefevre  wrote:
> On 2023-01-23 03:11:59 +0100, Vincent Lefevre wrote:
>> On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote:
>> > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote:
>> > >  I still see this misbehavior with xterm 210-3.1 and
>> > > linux-image-2.6.17-2-686 2.6.17-9.
>> >
>> > I can see it (now) with a 2.6.15 kernel (814 lines copied).
>> > I also note that Branden got no followup from the kernel people.
>>
>> This also occurs with
>>
>> Linux zira 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1
>> (2023-01-18) x86_64 GNU/Linux
>>
>> and xterm, mlterm and GNOME Terminal at least. This would confirm
>> a kernel pty bug (unless this is a documented pty limitation, in
>> which case the applications would have to take it into account...
>> but they could try to implement a workaround in any case).
>>
>> For me, with the above kernel, the limit is 4095 bytes.
>>
>> An annoying consequence is that Ctrl-C no longer works, which can
>> yield buggy commands executed by the shell after an accidental
>> paste while a foreground X command is running (presumably because
>> bracketed paste is not in effect, so that each newline character
>> validates each line as a command). See
>>   https://lists.debian.org/debian-user/2023/01/msg00520.html
>
> Actually, in my case (where I do a large paste after starting a
> command that doesn't consume input, typically an X command), this is
> a different, but related issue. The characters are not really lost,
> but delayed. Still, the behavior is incorrect: the characters,
> including Ctrl-C, are kept in some xterm buffer, so that the Ctrl-C
> doesn't have an immediate effect: it takes effect only near the end
> of the paste (after the command has ended), and this is too late.
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
>

Bug#1030108: libmimalloc2.0: Build type is not specified during configure phase of packages. It kills performance.

[Max Dmitrichenko]

Package: libmimalloc2.0
Version: 2.0.9+ds-1~dbp2
Severity: important
X-Debbugs-Cc: dmitr...@gmail.com

There is no -DCMAKE_BUILD_TYPE release in debian/rules 
override_dh_auto_configure target. The package is built with
CMAKE_BUILD_TYPE equal to None. This renders its performance unusable - 
actually far more worse that even libc's malloc.

I've discovered it when backported this package to bullseye and noticed that 
its performance is awful but local build of the same
version is pretty much good.

Please add this flag until bookworm is completly frozed!


-- 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, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libmimalloc2.0 depends on:
ii  libc6  2.31-13+deb11u5

libmimalloc2.0 recommends no packages.

libmimalloc2.0 suggests no packages.

-- no debconf information

Bug#1026070: Right Click works again

[max+reportbug]

Dear Maintainer,

I just wanted to inform you that right click on the desktop works again as 
intended. I did an
`apt full-upgrade` yesterday and today. Only with the upgrade today (~8:30am
CET) right click started to function correctly again.


Thank you very much for your efforts.

Bug#1022972: Konsole works again

[Max Görner]

Dear Maintainer,

I just wanted to inform you that Konsole works again as intended. I did an
`apt full-upgrade` yesterday and today. Only with the upgrade today (~8:30am
CET) Konsole started to function correctly again.

Thank you very much for your efforts.

Bug#1026062: kded5: kded crashes with signal 11

[Max Görner]

Package: kded5
Version: 5.101.0-1
Followup-For: Bug #1026062

Dear Maintainer,

I just wanted to confirm that I am affected too. I experience the issue
since 5.100 and now with 5.101.0-1. Also, checking for updates in
Discover reproduces the bug for me too. However, kded5 crashes in other
situations too but I couldn't really see a clear pattern so far.


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

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

Versions of packages kded5 depends on:
ii  libc6  2.36-6
ii  libkf5configcore5  5.101.0-1
ii  libkf5coreaddons5  5.101.0-1
ii  libkf5crash5   5.101.0-1
ii  libkf5dbusaddons5  5.101.0-1
ii  libkf5service-bin  5.101.0-1
ii  libkf5service5 5.101.0-1
ii  libqt5core5a   5.15.6+dfsg-5
ii  libqt5dbus55.15.6+dfsg-5
ii  libqt5gui5 5.15.6+dfsg-5
ii  libqt5widgets5 5.15.6+dfsg-5
ii  libstdc++6 12.2.0-10

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

Bug#1026374: sight: provide dicomxplorer executable

[Max Nikulin]

Package: libsight
Version: 21.1.1-3
Severity: wishlist

Please, consider providing dicomxplorer executable similar to the 
sightviewer wrapper built from the "sight" source package (developing by 
IRCAD).


https://sight.pages.ircad.fr/sight-doc/Introduction/src/applications.html#dicomxplorer
https://sight.pages.ircad.fr/sight/

DicomXplorer

DicomXplorer is a simple medical image viewer that can connect to a PACS
to retrieve DICOM data. It supports CT-scan and MRI images.


Currently most of its files are a part of the libsight package:

/usr/share/sight/dicomxplorer/about/about.html
/usr/share/sight/dicomxplorer/about/vrrender_128.png
/usr/share/sight/dicomxplorer/configurations/dicomXplorerBase.xml
/usr/share/sight/dicomxplorer/configurations/sdb.xml
/usr/share/sight/dicomxplorer/dicomXplorer.icns
/usr/share/sight/dicomxplorer/dicomXplorer.ico
/usr/share/sight/dicomxplorer/plugin.xml
/usr/share/sight/dicomxplorer/profile.xml

I expect these files and /usr/bin/dicomxplorer (similar to 
/usr/bin/sightviewer) are shipped in a separate package or merged with 
sightviewer and sightcalibrator tiny packages into e.g. sight-bin or 
sight-apps.


A workaround: copy /usr/bin/sightviewer to dicomxplorer and replace 
"SightViewer" with "dicomxplorer".


I got a CD with CT and a proprietary viewer that I have not managed to 
get running under wine. Out of curiosity I have decided to try what 
DICOM viewers are available for Linux. DicomXplorer has more convenient 
projections layout than amide. Perhaps I faced come bugs in it or I just 
have not discovered all its control knobs, so I can not say that 
dicomxplorer (and sightviewer) is unambiguously better than amide. 
Anyway, it does not look like significant maintenance burden, so, I 
suppose, an additional DICOM viewer application will be an improvement.

Bug#1026070: kde-plasma-desktop: Right click on desktop and taskbar has no effect

[Max Görner]

Hello again,

I was able to find out a little bit more.

As I wrote I experience the issue on my second computer running on Debian
Testing too. However, a second user of that computer reported that she does
not suffer from that right click issue. So I tried to create a test user on
that second computer too and for this test user the issue did not appear
neither.

So, to sum up: On my Thinkpad both my main user and the fresh test user
experience the right click issue. On my PC only my main user, but neither the
permanent second user nor the fresh test user experienced the issue.

I cannot think of any actual relevant difference. The only thing that comes to
my mind is that the Thinkpad has the keyboard Neo2 configured as main layout,
so I even type in the passphrase for the whole disk encryption in Neo2. The
PC uses some more usual German variant.

I would be very glad if you would have any suggestion what I could do to
narrow down the issue a bit more.


When I created the test users, I noticed that each and every time KDE
complained about that the folder `~/.config/kdedefaults` was missing. I would
expect that after running `adduser` or adding a new user using KDE's settings
dialog KDE would be bootstrap itself. Instead, there are error messages in
`.xsession-errors` and the desktop background stays black.

Should I file a separate bug for this or is this behaviour already known?


Best Regards
Max Görner

Bug#1026070: kde-plasma-desktop: Right click on desktop and taskbar has no effect

[Max Görner]

Hi Aurélien,

thank you for your quick reply.


There are many people running testing and/or unstable, me included, for whom 
this bug doesn't happen. So we'll need a bit more analysis if we want to get it 
fixed.

Could you try creating a new user (without an existing $HOME directory) on one 
of the machines where you see the bug and report back if the new user still has 
the issue ?

I created a new user via `adduser` and the problem persisted for it.
Interestingly, that user had a black background and not some default
background image. The .xsession-errors contains some complaints about missing
/home/kdetest.config/kdedefaults, but I did not try to resolve this.


Also can you find anything meaningful in the system log at the time where you 
right click or during the load of the user session ?


The section of my .xsession-erros for today:

Xsession: X session started for mgoerner at Mi 14. Dez 09:18:06 CET 2022
dbus-update-activation-environment: setting
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting
XAUTHORITY=/home/mgoerner/.Xauthority
localuser:mgoerner being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1

The .xsession-errors for the new created user:


Xsession: X session started for kdetest at Mi 14. Dez 11:58:00 CET 2022
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
dbus-update-activation-environment: setting DISPLAY=:1
dbus-update-activation-environment: setting 
XAUTHORITY=/home/kdetest/.Xauthority
localuser:kdetest being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
QIODevice::read (QFile, "/home/kdetest/.config/kdedefaults/package"): 
device not open
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kcminputrc" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kcminputrc
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kwinrc" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kwinrc
QDBusConnection: error: could not send signal to service "" path 
"//home/kdetest/.config/kdedefaults/kwinrc" interface "org.kde.kconfig.notify" member 
"ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kwinrc
QPixmap: QGuiApplication must be created before calling defaultDepth().
QPixmap: QGuiApplication must be created before calling defaultDepth().

Neither `journalctl` nor `sudo journalctl` show anything of interest after
right clicking somewhere. Are there other logs I should have a look at?



Lastly if you could have a look at the upstream bugs.kde.org platform and
look for a similar bug report that would be useful. I'll have a look too when
I can.

I will do so and report if I find something.


Best
Max Görner

Bug#1026070: kde-plasma-desktop: Right click on desktop and taskbar has no effect

[Max Görner]

Package: kde-plasma-desktop
Version: 5:135
Severity: important

Dear Maintainer,


about the same time as bug #1022972 appeard, after an update about one
and half months ago, right clicks stopped to have an effect in certain
situations.

Previously, when doing an right click on the desktop, a context menu
opened. One of the elements of that context menu was an element that
opened an appearance settings menu which allowed me to configure the
background image. This context menu does not appear anymore.

Also, a right click on the taskbar, which holds Kickoff, the icons of
open windows, the clock and the tray bar, has no effect neither. Thus I
am able neither to change its position nor to add or remove any widgets.

I experience the very same problem on two machines that run Debian
Bookworm. I do not experience it on a machine that runs Ubuntu 22.04, if
that is of any help.

In #1022972 it was found that the keyboard layout had an effect on the
issue. This is not the case here. I added normal German layout as a
secondary layout, but the problem persists even when I change to it.

Best Regards
Max

[1]: About the same time as bug #1022972 appeared.


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

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

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:21.08.0+5.135
ii  plasma-desktop4:5.26.4-1
ii  plasma-workspace  4:5.26.4.1-1
ii  udisks2   2.9.4-4
ii  upower0.99.20-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.26.4-1
ii  sddm  0.19.0-4
ii  xserver-xorg  1:7.7+23

Versions of packages kde-plasma-desktop suggests:
ii  kdeconnect  21.12.3-2

-- no debconf information

Bug#369953: revisiting strict variable handling in confmodule

[Max-Julian Pogner]

Hi,

bumping this bug, as it still exists in 1.5.80.
I have now also create a merge request on salsa:
https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/12

please apply this patch.

cheers,
Max

Bug#1022972: Acknowledgement (konsole: Konsole does not handle arrow keys correctly anymore)

[Max Görner]

Max, Nathanael, could you confirm that you're too using Neo2, or similarly
"exotic" layouts? Otherwise we're probably looking at different issues.

Indeed, I use Neo2.


This can be traced down to the keyboard configuration of konsole. When going
to: Edit Current Profile... -> Keyboard -> Default (XFree 4) -> Edit...

and then using the "input" field for testing, it can be observed that for the
arrow up key, different rules trigger depending on the keyboard layout:

Layout   Rule Escape Sequence
de neo   Up-Shift+Ansi+AnyModifier\E[1;1A
us   Up-Shift+Ansi-AppCursorKeys-AnyModifier  \E[A

This workaround worked for me. I used some "normal" German variant, though.

Best regards
Max Görner

Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Max Kellermann]

On 2022/11/11 19:59, Daniel Kozar  wrote:
> Package: mpd
> Version: 0.23.9-1+b3
> Severity: important
> X-Debbugs-Cc: dkk...@gmail.com
> 
> MPD stopped being able to run after upgrading to 0.23.9-1+b3. The relevant 
> journal messages are :
> 
> mpd[8301]: terminate called after throwing an instance of 'std::runtime_error'
> mpd[8301]:   what():  io_uring_get_sqe() failed
> 
> Downgrading to 0.23.9-1+b2 or setting "auto_update" to "no" fixes this 
> problem.

b2 was built with liburing 2.2, but b3 was built with liburing 2.3.  See build 
logs:

 
https://buildd.debian.org/status/fetch.php?pkg=mpd=amd64=0.23.9-1%2Bb2=119004=1
 
https://buildd.debian.org/status/fetch.php?pkg=mpd=amd64=0.23.9-1%2Bb3=1668073210=1

This could be a liburing ABI breakage?

Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Max Kellermann]

On 2022/11/11 20:52, Max Kellermann  wrote:
> This could be a liburing ABI breakage?

This upstream commit looks like an ABI breakage:

 
https://github.com/axboe/liburing/commit/f5cd4eb2b50840510a4c6bbe5ba34a5a2058a2ae

The bug report should be moved to liburing.

Bug#1023623: dolphin: In file rename dialog: Delete and Backspace act on file, not on text

[Max Görner]

Package: dolphin
Version: 4:22.08.1-1
Severity: important

Dear Maintainer,

I don't use Dolphin often, so I cannot say since when this issue exists. 
However, I only noticed it on 5th of November.

I tried to rename a bunch of files using Dolphin. So I selected one file, 
pressed F2 and entered a new text. Now, if I made a typo, I was unable to 
correct this. If I hit the backspace or delete key, Dolphin interpreted the key 
as command, not as text alteration. Thus, upon backspace the parent folder was 
opened. Upon delete the file was removed. You can imagine that this was very 
annoying.

A workaround was to select some text and enter the correction. That would 
replace the selection.

Best Regards
Max Görner

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

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

Versions of packages dolphin depends on:
ii  baloo-kf5 5.98.0-1+b1
ii  kinit 5.98.0-1
ii  kio   5.98.0-1
ii  libc6 2.35-4
ii  libdolphinvcs54:22.08.1-1
ii  libkf5activities5 5.98.0-1
ii  libkf5baloo5  5.98.0-1+b1
ii  libkf5baloowidgets5   4:22.08.1-1
ii  libkf5bookmarks5  5.98.0-1
ii  libkf5codecs5 5.98.0-1
ii  libkf5completion5 5.98.0-1
ii  libkf5configcore5 5.98.0-2
ii  libkf5configgui5  5.98.0-2
ii  libkf5configwidgets5  5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5crash5  5.98.0-1
ii  libkf5dbusaddons5 5.98.0-1
ii  libkf5filemetadata3   5.98.0-1
ii  libkf5i18n5   5.98.0-1+b1
ii  libkf5iconthemes5 5.98.0-2+b1
ii  libkf5itemviews5  5.98.0-1
ii  libkf5jobwidgets5 5.98.0-1
ii  libkf5kcmutils5   5.98.0-1
ii  libkf5kiocore55.98.0-1
ii  libkf5kiofilewidgets5 5.98.0-1
ii  libkf5kiogui5 5.98.0-1
ii  libkf5kiowidgets5 5.98.0-1
ii  libkf5newstuff5   5.98.0-1
ii  libkf5newstuffwidgets55.98.0-1
ii  libkf5notifications5  5.98.0-1
ii  libkf5parts5  5.98.0-1
ii  libkf5service-bin 5.98.0-1
ii  libkf5service55.98.0-1
ii  libkf5solid5  5.98.0-1
ii  libkf5textwidgets55.98.0-1
ii  libkf5widgetsaddons5  5.98.0-1
ii  libkf5windowsystem5   5.98.0-1
ii  libkf5xmlgui5 5.98.0-1+b1
ii  libkuserfeedbackcore1 1.2.0-2
ii  libkuserfeedbackwidgets1  1.2.0-2
ii  libpackagekitqt5-11.0.2-1
ii  libphonon4qt5-4   4:4.11.1-4
ii  libqt5core5a  5.15.6+dfsg-2
ii  libqt5dbus5   5.15.6+dfsg-2
ii  libqt5gui55.15.6+dfsg-2
ii  libqt5widgets55.15.6+dfsg-2
ii  libqt5xml55.15.6+dfsg-2
ii  libstdc++612.2.0-3
ii  phonon4qt54:4.11.1-4

Versions of packages dolphin recommends:
ii  ffmpegthumbs  4:22.04.2-1
ii  kdegraphics-thumbnailers  4:21.12.3-1
ii  kimageformat-plugins  5.98.0-1+b1
ii  kio-extras4:22.04.3-1+b1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#1023607: 50-depmod.install fails if kmod is not installed

[Max Kellermann]

Package: systemd
Version: 252-2

My computer has custom-built kernels without module support, and
therefore I did not install kmod.  When installing a kernel package, I get:

 /usr/lib/kernel/install.d/50-depmod.install: 28: exec: depmod: not found

This script comes with the systemd package, but systemd does not
depend on kmod, and doing so would be the wrong solution; the proper
solution is to check whether "depmod" is installed in the script.

Bug#1022972: Additional information

[Max Görner]

I want to add two pieces of additional information.

First, I removed nvidia-kernel-dkms and rebooted. The problem persists so I
guess this package does not affect the bug.

Second, similar to the aforementioned problem with keepasxc, I cannot finish
entering a password into pinentry, which is used by the gpg-agent to get the
private key's passphrase. I have to click on the OK button. I am unsure
whether this is related to the problem with the arrow keys, though.

Bug#1022972: konsole: Konsole does not handle arrow keys correctly anymore

[Max Görner]

Package: konsole
Version: 4:22.08.1-1
Severity: important

Dear Maintainer,

I ran `apt update` followed by `apt full-upgrade` today. I also
installed nvidia-kernel-dkms. Since then Konsole does not process arrow
keys correctly.

Note that according to my /var/log/dpkg.log Konsole was not updated
today. Anyhow, it is Konsole that seems to be broken to me.

The issue is that when inside Konsole pressing one of the arrow keys
will insert a character instead of moving the cursor. This behaviour is
specific to Konsole only. Programs running in the terminal, e.g. Vim and
Tmux, still properly react on arrow keys.

Some of the keys inserted are: UP->A, DOWN->B, LEFT->D, RIGHT->C,
Pos1->H, END->F.

This effectively broke Konsole for me and I switched to a different
terminal emulator. I'd love to switch back to Konsole as soon as
possible.


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

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

Versions of packages konsole depends on:
ii  kio5.98.0-1
ii  konsole-kpart  4:22.08.1-1
ii  libc6  2.35-3
ii  libkf5configcore5  5.98.0-1
ii  libkf5configwidgets5   5.98.0-1
ii  libkf5coreaddons5  5.98.0-1
ii  libkf5crash5   5.98.0-1
ii  libkf5dbusaddons5  5.98.0-1
ii  libkf5globalaccel-bin  5.98.0-1
ii  libkf5globalaccel5 5.98.0-1
ii  libkf5guiaddons5   5.98.0-2
ii  libkf5i18n55.98.0-1+b1
ii  libkf5kiowidgets5  5.98.0-1
ii  libkf5notifyconfig55.98.0-1
ii  libkf5service-bin  5.98.0-1
ii  libkf5service5 5.98.0-1
ii  libkf5widgetsaddons5   5.98.0-1
ii  libkf5windowsystem55.98.0-1
ii  libkf5xmlgui5  5.98.0-1+b1
ii  libqt5core5a   5.15.6+dfsg-2
ii  libqt5gui5 5.15.6+dfsg-2
ii  libqt5widgets5 5.15.6+dfsg-2
ii  libstdc++6 12.2.0-3

konsole recommends no packages.

Versions of packages konsole suggests:
pn  lrzsz  

-- no debconf information

Bug#1021087: [syscom] Bug#1020998: mirror.csclub.uwaterloo.ca: syncscript

[Max Erenberg]

Package: mirrors
X-Debbugs-Cc: David Bartley 
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hello Julian,

> I was checking some things in the Debian mirror universe and noticed
> a problem with your mirror:
>
> o The tracefile
>   
> http://mirror.csclub.uwaterloo.ca/debian/project/trace/mirror.csclub.uwaterloo.ca
>   suggests that you are not using ftpsync.
>
>   Please use our ftpsync script to mirror Debian.
>
>   It should produce better trace files, and do the mirroring in a way that
>   ensures the mirror is in a consistent state even during updates.
>
>   
> http://mirror.csclub.uwaterloo.ca/debian/project/ftpsync/ftpsync-current.tar.gz

Thank you for bringing this to our attention. We are using ftpsync now.

--
Max Erenberg
Systems Committee
Computer Science Club of the University of Waterloo

Bug#1020998: [syscom] Bug#1020998: mirror.csclub.uwaterloo.ca: syncscript

[Max Erenberg]

Hello Julian,

> I was checking some things in the Debian mirror universe and noticed
> a problem with your mirror:
>
> o The tracefile
>   
> http://mirror.csclub.uwaterloo.ca/debian/project/trace/mirror.csclub.uwaterloo.ca
>   suggests that you are not using ftpsync.
>
>   Please use our ftpsync script to mirror Debian.

Thank you for bringing this to our attention. We are using ftpsync now.

--
Max Erenberg
Systems Committee
Computer Science Club of the University of Waterloo

Bug#1003798: fluxbox: replace FbRootWindow::depth with maxDepth

[Max Nikulin]

The issue was reported earlier for fluxbox-1.3.5 package as
https://bugs.debian.org/743772

Bug#743772: fluxbox: Cannot move Gnome 3.12 applications

[Max Nikulin]

Tags: patch

The issue was fixed after fluxbox-1.3.7 release and 1.4 has not
completed. I have backported the fix to version 1.3.5 currently
available in Debian.

Notice that the same bug is reported for experimental as
https://bugs.debian.org/1003798

More information is available in
http://git.fluxbox.org/fluxbox.git/commit/?id=dcdde4d32c93d01df205bc06d7dfcbd356be031f
https://sourceforge.net/p/fluxbox/bugs/1102/
https://sourceforge.net/p/fluxbox/bugs/1058/

The problem is quite severe though it is not 100% reproducible.
As a workaround, restart fluxbox.Backport of the following commit:

From dcdde4d32c93d01df205bc06d7dfcbd356be031f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Thomas=20L=C3=BCbking?= 
Date: Sat, 25 Jun 2016 22:25:48 +0200
Subject: replace FbRootWindow::depth with maxDepth

The depth member of FbWindow was abused to store the maximum depth
but that gets overridden with geometry changes of the root window
(screen layout changes) so we store and read the value explicitly while
::depth() maintains the actual depth of the root window

The result of this is that frames for ARGB windows were created with a
wrong depth and failed to reparent the client window.

BUG: 1102
BUG: 1058
---
 src/FbRootWindow.cc | 7 ---
 src/FbRootWindow.hh | 2 ++
 src/FbWinFrame.cc   | 4 ++--
 src/Screen.cc   | 2 +-
 4 files changed, 9 insertions(+), 6 deletions(-)

--- a/src/FbRootWindow.cc
+++ b/src/FbRootWindow.cc
@@ -30,7 +30,8 @@
 m_colormap(0),
 m_decorationDepth(0),
 m_decorationVisual(0),
-m_decorationColormap(0) {
+m_decorationColormap(0),
+m_maxDepth(depth()) {
 
 Display *disp = FbTk::App::instance()->display();
 
@@ -55,9 +56,9 @@
 
 for (int i = 0; i < vinfo_nitems; i++) {
 if ((DefaultDepth(disp, screen_num) < vinfo_return[i].depth)
-&& (depth() < vinfo_return[i].depth)){
+&& (m_maxDepth < vinfo_return[i].depth)){
 m_visual = vinfo_return[i].visual;
-setDepth(vinfo_return[i].depth);
+m_maxDepth = vinfo_return[i].depth;
 }
 
 if((m_decorationDepth < vinfo_return[i].depth)
--- a/src/FbRootWindow.hh
+++ b/src/FbRootWindow.hh
@@ -41,6 +41,7 @@
 int decorationDepth() const { return m_decorationDepth; }
 Visual *decorationVisual() const { return m_decorationVisual; }
 Colormap decorationColormap() const { return m_decorationColormap; }
+int maxDepth() const { return m_maxDepth; }
 
 private:
 Visual *m_visual;
@@ -49,6 +50,7 @@
 int m_decorationDepth;
 Visual *m_decorationVisual;
 Colormap m_decorationColormap;
+int m_maxDepth;
 };
 
 #endif // FBROOTWINDOW_HH
--- a/src/FbWinFrame.cc
+++ b/src/FbWinFrame.cc
@@ -60,8 +60,8 @@
  ButtonMotionMask | EnterWindowMask |
  LeaveWindowMask, true, false,
  client_depth, InputOutput,
- ((client_depth == 32) && (screen.rootWindow().depth() == 32) ? screen.rootWindow().visual() : CopyFromParent),
- ((client_depth == 32) && (screen.rootWindow().depth() == 32) ? screen.rootWindow().colormap() : CopyFromParent)),
+ (client_depth == screen.rootWindow().maxDepth() ? screen.rootWindow().visual() : CopyFromParent),
+ (client_depth == screen.rootWindow().maxDepth() ? screen.rootWindow().colormap() : CopyFromParent)),
 m_layeritem(window(), *screen.layerManager().getLayer(ResourceLayer::NORMAL)),
 m_titlebar(m_window, 0, 0, 100, 16,
ButtonPressMask | ButtonReleaseMask |
--- a/src/Screen.cc
+++ b/src/Screen.cc
@@ -427,7 +427,7 @@
 "using visual 0x%lx, depth %d\n",
 "informational message saying screen number (%d), visual (%lx), and colour depth (%d)").c_str(),
 screenNumber(), XVisualIDFromVisual(rootWindow().visual()),
-rootWindow().depth());
+rootWindow().maxDepth());
 #endif // DEBUG
 
 FbTk::EventManager *evm = FbTk::EventManager::instance();

Bug#1017164: mpd: FTBFS: ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined reference to `av_malloc(unsigned long)'

[Max Kellermann]

On 2022/08/14 09:16, Lucas Nussbaum  wrote:
> Relevant part (hopefully):
> > /usr/bin/ld: src/decoder/plugins/libdecoder_plugins.a.p/FfmpegIo.cxx.o: in 
> > function `AvioStream::Open()':
> > ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined 
> > reference to `av_malloc(unsigned long)'
> > collect2: error: ld returned 1 exit status

Upstream bug report: https://github.com/MusicPlayerDaemon/MPD/issues/1582

Upstream fix: 
https://github.com/MusicPlayerDaemon/MPD/commit/59792cb0b801854ee41be72d33db9542735df754

Will soon be released as 0.23.9.

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Max Bell]

Why isn't the bug being fixed? That is obviously the correct solution.

On 8/3/22, Richard B. Kreckel  wrote:
> This is issue 157 upstream:
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
> Apparently, they do not want to revert it.
>
> So, should Debian build with --disable-thread-safety-constructor, at
> least for a while?
>
> (Remember that this bug will soon block other packages from migrating,
> e.g. thunderbird 102.)
>
>   -richy.
> --
> Richard B. Kreckel
> 
>
>

Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1

[Max Bell]

Assuming this issue effects only one app is defective. Fix the broken
compatibly with legacy code as this solves it for all programs. And
does not require rewriting an unknown number of apps, that probably
don't have maintainers to fix things, to keep working vs. being
rendered unusable.

On 7/30/22, Jed Davis  wrote:
> FVWM's problem here appears to be that it calls XCheckIfEvent with a
> callback that ends up trying to call XFlush; XCheckIfEvent holds the display
> lock while calling the callback and XFlush also locks the display, causing a
> self-deadlock.  I provoked this by iconifying a window with a key bind, and
> in this case it seems to have something to do with the resulting expose
> events (see stack below).  This reentrancy may not be ideal behavior on
> FVWM's part, but this is code which has (seemingly) worked for a long time.
>
> I also came up with a different workaround: instead of rebuilding libx11, I
> rebuilt FVWM with the following definition added:
>
> Status XInitThreads(void)
> {
> return 0;
> }
>
> The executable precedes its libraries in the symbol search path, so this
> turns off X11 thread safety entirely, but only for fvwm; it doesn't appear
> to use threading, either directly or indirectly, and I'm assuming that
> situation isn't likely to change in the immediate future.  This isn't a
> great solution, but it works for me for now.
>
> If it helps, here's the interesting part of the stack trace from the
> deadlock:
>
> #3  0x7f01a975a968 in _XLockDisplay (dpy=0x55ca735f4090) at
> ../../src/locking.c:466
> #4  0x7f01a974e5c2 in XFlush (dpy=0x55ca735f4090) at
> ../../src/Flush.c:38
> #5  0x55ca7248be1b in dispatch_event (e=0x55ca736ec2f8) at
> events.c:4105
> #6  0x55ca7248c0cc in _pred_weed_handle_expose (display=,
> event=, arg=) at events.c:266
> #7  0x55ca724ff3b9 in _fev_pred_weed_if (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:176
> #8  0x55ca724ff43f in _fev_pred_check_peek (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc686fb0 "p\363Or\312U") at FEvent.c:144
> #9  0x7f01a97489aa in XCheckIfEvent (dpy=0x55ca735f4090,
> event=event@entry=0x7ffebc686ef0, predicate=predicate@entry=0x55ca724ff420
> <_fev_pred_check_peek>, arg=arg@entry=0x7ffebc686fb0 "p\363Or\312U") at
> ../../src/ChkIfEv.c:59
> #10 0x55ca724ffdc0 in FCheckPeekIfEvent (display=,
> event_return=event_return@entry=0x7ffebc6870e0,
> predicate=predicate@entry=0x55ca724ff370 <_fev_pred_weed_if>,
> arg=arg@entry=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:590
> #11 0x55ca724fff17 in FWeedIfEvents (display=,
> weed_predicate=weed_predicate@entry=0x55ca7248c0b0
> <_pred_weed_handle_expose>, arg=arg@entry=0x0) at FEvent.c:527
> #12 0x55ca7248cfba in handle_all_expose () at events.c:4545
> #13 0x55ca724be911 in __raise_or_lower_window (t=t@entry=0x55ca7361c250,
> mode=mode@entry=SM_RAISE, allow_recursion=allow_recursion@entry=1,
> is_new_window=is_new_window@entry=0,
> is_client_request=is_client_request@entry=0) at stack.c:1141
>
> --Jed
>
>

Bug#1010594: [PATCH] Bug#1010594: debhelper: Dh_Lib.pm uses _strip_spaces with undef argument

[Max-Julian Pogner]

Control: tags -1 +patch


Hi,

> You can do control messages when following up on the bug, but you have
> to prefix them with "Control: " (in addition to them being in the
> top). The bug number "-1" is in this case pre-sent to the bug you sent
> to.
>
> I have included an example above, which also serves to mark it as
> pending because I have merged your patch. Thanks for your
> contribution! :)

I will remember for next time, thanks! :-)


> Perl has this weirdness where `return` and `return undef` behaves
> differently when the sub is called in `list` context.

I see, it feels weirdly logical that it is like that. And no, i was 
definitely not aware of this.
Then i would rather do it correctly. Attached is a patch on top of the 
first patch.




and if it removes the warning for the cause that triggered this bug report


Yes, no warnings anymore for all my use-cases.


cya,

MaxFrom 3badd79adc9197a34d72cf0c1bd1f0c8ba1d51ae Mon Sep 17 00:00:00 2001
From: Max-Julian Pogner 
Date: Sun, 15 May 2022 10:49:25 +0200
Subject: [PATCH 2/2] Dh_Lib.pm: prefer `return` over `return undef`

They behave differently depending on the context (e.g. list, scalar, etc)
the sub is called in.
---
 lib/Debian/Debhelper/Dh_Lib.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
index be79befa..41bc76f5 100644
--- a/lib/Debian/Debhelper/Dh_Lib.pm
+++ b/lib/Debian/Debhelper/Dh_Lib.pm
@@ -1764,7 +1764,7 @@ sub getpackages {
 
 sub _strip_spaces {
 	my ($v) = @_;
-	return undef if not defined($v);
+	return if not defined($v);
 	$v =~ s/^\s++//;
 	$v =~ s/\s++$//;
 	return $v;
-- 
2.35.2

Bug#1010594: [PATCH] Bug#1010594: debhelper: Dh_Lib.pm uses _strip_spaces with undef argument

[Max-Julian Pogner]

tags +patch

thanks

(can i also send control commands here, or only to 
cont...@bugs.debian.org? i will know after sending this email)



Hi Niels,

> I am inclined to go with option C by having `_strip_spaces` cope with
> its input being undefined and just immediately returning (or skipping
> the stripping part).
>

I have created a patch and attached it to this mail.

Using command `debbuild` the package builds and i installed the 
resulting deb package and it seems to work; plus one of the many 
messages says:


> All tests successful.

So maybe all is fine? However my perl foo is not good enough to know how 
to test whether a perl warning is issued.



> Thanks for considering to provide a patch, it is very appreciated. :)
> I have already applied your patch from #1010591.  If you prefer, you
> are also very welcome to use salsa.debian.org to provide a merge
> request at
> https://salsa.debian.org/debian/debhelper/-/merge_requests

I have registered for an account now, but am of-course awaiting approval.


cya,

Max
From fb9e71aadaab92f9d4275a32593aed009c500d14 Mon Sep 17 00:00:00 2001
From: Max-Julian Pogner 
Date: Sat, 14 May 2022 21:48:01 +0200
Subject: [PATCH] Dh_Lib.pm: _strip_spaces now explicitly returns undef on
 undef argument.

_strip_spaces sometimes get's used to process optional source fields
such as for example the 'Section:' field. In this case, the argument
to _strip_spaces would be undef and without this patch perl issues a
warning message.

This patch makes _strip_space simply return undef in this case, assuming
that the caller of _strip_spaces is prepared to handle missing (optional)
source field as undef.

See bugs.debian.org: #1010594
---
 debian/changelog   | 3 +++
 lib/Debian/Debhelper/Dh_Lib.pm | 1 +
 2 files changed, 4 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 1430e816..a7788c48 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,9 @@ debhelper (13.7.2) UNRELEASED; urgency=medium
 
   [ Max-Julian Pogner ]
   * Dh_Lib.pm: Remove double semi-colon.  (Closes: #1010591)
+  * Dh_Lib.pm: _strip_spaces now explicitly returns undef on undef
+argument.
+(Closes: #1010594)
 
   [ Andrea Pappacoda ]
   * cmake.pm: Set FETCHCONTENT_FULLY_DISCONNECTED to true.  This
diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
index 11053102..be79befa 100644
--- a/lib/Debian/Debhelper/Dh_Lib.pm
+++ b/lib/Debian/Debhelper/Dh_Lib.pm
@@ -1764,6 +1764,7 @@ sub getpackages {
 
 sub _strip_spaces {
 	my ($v) = @_;
+	return undef if not defined($v);
 	$v =~ s/^\s++//;
 	$v =~ s/\s++$//;
 	return $v;
-- 
2.35.2

Bug#1010594: debhelper: Dh_Lib.pm assumes source "Section:" field is required, but it's documented as optional

[Max-Julian Pogner]

Package: debhelper
Version: 13.7.1
Severity: normal
X-Debbugs-Cc: max-jul...@pogner.at

Dear Maintainer,

   * What led up to the situation?

When using ``dh_testdir``, the following error messages appeared to me:

> Use of uninitialized value $v in substitution (s///) at 
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 1767, <$fd> line 9.
> Use of uninitialized value $v in substitution (s///) at 
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 1768, <$fd> line 9.

However, dh_testdir to the best of my knowledge continued normally after that.


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

My investigation suggests, that Dh_Lib.pm assumes the source field "Section:" 
to be present always in the file ``debian/control``, although 
https://manpages.debian.org/sid/dpkg-dev/deb-src-control.5.en.html documents 
the "Section" source field to be optional (in that other source fields are 
explicitly marked "required" or "recommended", but this source field is 
neither).

I therefore think, that either

   a) the documentation deb-src-control is incomplete and the source field 
"Section:" should be marked as required there, or
   b) the Dh_Lib.pm should assign some default value to variable 
$source_section after the loop ``while (<$fd>) {`` in lines 1786 to 1835 has 
finished, or
   c) Dh_Lib.pm line 1994, which reads
  
  > $package_sections{$package} = _strip_spaces($field_values{'section'} // 
$source_section);;

  should be changed to cope with the possibility that variable 
$source_section has value ``undef``, or
   d) something else?


Please advise what would be the next step, maybe i can provide a patch then.


best regards,

Max



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

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

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.7
ii  dpkg-dev 1.21.7
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.7.1
ii  libdpkg-perl 1.21.7
ii  man-db   2.10.2-1
ii  perl 5.34.0-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#1010591: debhelper: Double semi-colon in Dh_Lib.pm line 1994

[Max-Julian Pogner]

Package: debhelper
Version: 13.7.1
Severity: minor
Tags: patch
X-Debbugs-Cc: max-jul...@pogner.at

Dear Maintainer,

I had output of dh_testdir I had not the knowledge to interpret correctly.
Therefore i inspected the source code, among other files also

  file usr/share/perl5/Debian/Debhelper/Dh_Lib.pm

there i noticed in line 1994 a "spelling" error; the line is ended with two 
semi-colons instead of one.

Original line reads:

> $package_sections{$package} = _strip_spaces($field_values{'section'} // 
> $source_section);;

But it shoud read:

> $package_sections{$package} = _strip_spaces($field_values{'section'} // 
> $source_section);

I will attach a patch to this bug report.


I think this is a perfect opportunity for me to learn using `reportbug` without 
kicking up too much dust. Please consider applying this patch, for spelling 
errors are very important to be fixed! :-)

best regards,

Max


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.7
ii  dpkg-dev 1.21.7
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.7.1
ii  libdpkg-perl 1.21.7
ii  man-db   2.10.2-1
ii  perl 5.34.0-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information
>From 63cd06b455adc01718288635aa9350c512f02b5e Mon Sep 17 00:00:00 2001
From: Max-Julian Pogner 
Date: Thu, 5 May 2022 08:55:37 +0200
Subject: [PATCH] Dh_Lib.pm: Fix Double semi-colon in Dh_Lib.pm line 1994

---
 lib/Debian/Debhelper/Dh_Lib.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
index 76101783..11053102 100644
--- a/lib/Debian/Debhelper/Dh_Lib.pm
+++ b/lib/Debian/Debhelper/Dh_Lib.pm
@@ -1991,7 +1991,7 @@ sub _parse_debian_control {
$package_types{$package} = 
_strip_spaces($field_values{'package-type'} // 'deb');
$package_arches{$package} = $arch;
$package_multiarches{$package} = 
_strip_spaces($field_values{'multi-arch'} // '');
-   $package_sections{$package} = 
_strip_spaces($field_values{'section'} // $source_section);;
+   $package_sections{$package} = 
_strip_spaces($field_values{'section'} // $source_section);
$package_cross_type{$package} = $cross_type;

push(@{$packages_by_type{'all-listed-in-control-file'}}, $package);
 
-- 
2.35.2

>From 63cd06b455adc01718288635aa9350c512f02b5e Mon Sep 17 00:00:00 2001
From: Max-Julian Pogner 
Date: Thu, 5 May 2022 08:55:37 +0200
Subject: [PATCH] Dh_Lib.pm: Fix Double semi-colon in Dh_Lib.pm line 1994

---
 lib/Debian/Debhelper/Dh_Lib.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
index 76101783..11053102 100644
--- a/lib/Debian/Debhelper/Dh_Lib.pm
+++ b/lib/Debian/Debhelper/Dh_Lib.pm
@@ -1991,7 +1991,7 @@ sub _parse_debian_control {
$package_types{$package} = 
_strip_spaces($field_values{'package-type'} // 'deb');
$package_arches{$package} = $arch;
$package_multiarches{$package} = 
_strip_spaces($field_values{'multi-arch'} // '');
-   $package_sections{$package} = 
_strip_spaces($field_values{'section'} // $source_section);;
+   $package_sections{$package} = 
_strip_spaces($field_values{'section'} // $source_section);
$package_cross_type{$package} = $cross_type;

push(@{$packages_by_type{'all-listed-in-control-file'}}, $package);
 
-- 
2.35.2

Bug#999679: caja: Caja inserts hyphens into filenames

[Max E]

Dear maintainer:

Upstream Caja ticket for this issue is here:
https://github.com/mate-desktop/caja/issues/1583

Upstream developers have root-caused the issue as backwards incompatibility
between newer versions of the compiled Pango libraries and older versions of
the Pango headers. If Caja is built against the older headers and then run
with the latest Pango .so libraries, we get this hyphenation behavior.

To test this, I grabbed the sources to Caja 1.24.0, exactly matching the
version currently in Bullseye, and rebuilt them myself. Lo and behold, the
hyphenation behavior disappears.

So to resolve this issue in Bullseye, all that's needed is to rebuild the
package & version bump, with no other changes required.

Regards,
-Max

Bug#1010272: Installation Report Debian 11.2

[Max Euer]

Package: installation-reports

Boot method:  DVD
Image version:Debian GNU/Linux 11.2.0 _Bullseye_ - Official amd64 
NETINST 20211218-11:12

Date: 31st Mar 2022

Machine:AMD A4-4000 APU with Radeon(tm) HD Graphics
BIOS: MSI FM2-A75MA-P33
Partitions: 
/dev/sda1 FAT32 - unused
 sda2 FAT16 PCDOS
 sda6 swap
 sda6 swap
 sda7 Debian ext4

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

Initial boot:   [O ]
Detect network card:    [O ]
Configure network:  [O ]
Detect media:   [O ]
Load installer modules: [O ]
Clock/timezone setup:   [O ]
User/password setup:    [E ]
Detect hard drives: [O ]
Partition hard drives:  [E ] Warning: Device 0x0800: Inconsistent 
partition table, 2nd entry

Install base system:    [O ]
Install tasks:  [O ]
Install boot loader:    [O ]
Overall install:    [E ]

Comments/Problems:
1st BOOT AFTER THE INSTALLATION I WAS UNABLE TO LOG IN AS ROOT [WRONG 
PASSWORD]

LOG IN AS A USER DID WORK.
I HAD TO DO A RESCUE REBOOT OR
BOOT WITH KERNEL CMD-LINE root=/dev/sda7 init=/bin/bash rw ,
THEN DO PASSWD , RE-ENTERING THE PASSWORD, AFTER THAT ALL WAS WELL
ONGOING PROBLEM AT LEAST SINCE DEBIAN 8

THERE WAS ANOTHER DIFFICULTY WITH THE VGA CARD: WORDS WERE SHIFTED MUCH 
TOO FAR

TO THE LEFT WHICH COULD NOT BE CORRECTED BY THE MONITOR [ACER].
EVENTUALLY ADDING A KERNEL OPTION append="video=VGA-1:800x600R-16@60"
DID THE TRICK HOWEVER HOW TO PHRASE THAT SENTENCE WAS HARD TO FIND!

--
Max Euer - Oud Lemiers 18 - NL6295AT Lemiers -
T  NL0618403128,D024079539727 - E  euer@googlemail.com

Bug#1009181: File suffix for message mbox links should be .eml

[Max Nikulin]

On 10/04/2022 03:54, Don Armstrong wrote:


The only real difference between a single message in an mbox and a
complete mbox is From escaping.


I had an impression that MUA may decode messages from 7-bit transfer 
encoding including quoted-printable and base64 fragments in headers 
before saving .eml files. I rarely use .eml files, so I may be wrong, 
and I do ask for such transformation from debbugs.



Frankly, using the extension to determine mime time is bad practice, but
it's a common bad practice.


In this particular case even libmagick is not a rescue, both 
application/mbox and message/rfc866 are detected as text/plain. Though 
my opinion is that thunderbird should have some option to make intention 
clear.

Bug#1009181: File suffix for message mbox links should be .eml

[Max Nikulin]

Package: debbugs-web

- Open any bug page and copy "mbox" link for particular message (not 
mbox folder for the whole discussion).

- Check "content-disposition" header in server response to such request

curl -I 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009036;mbox=yes;msg=5'


HTTP/2 200
date: Fri, 08 Apr 2022 10:04:43 GMT
server: Apache
cache-control: public, max-age=86400
content-disposition: attachment; filename="bug_1009036_message_5.mbox"
x-content-type-options: nosniff
x-frame-options: sameorigin
referrer-policy: no-referrer
x-xss-protection: 1
permissions-policy: interest-cohort=()
strict-transport-security: max-age=15552000
etag: 95464ed9b7121e98437a0a1c28d57650
x-clacks-overhead: GNU Terry Pratchett
content-type: message/rfc822

Notice that the default file name to save the message has ".mbox" suffix 
while freedesktop mime database entry assumes ".eml" for the 
"message/rfc822" mime type:

https://sources.debian.org/src/shared-mime-info/1.10-1/freedesktop.org.xml.in/#L5466
As a result if "message/rfc822" mime type is associated with 
thunderbird.desktop file then the application starts composition of a 
new message with the .mbox file as attachment instead of displaying the 
downloaded message.


I have not managed to convince thunderbird developers that there should 
be a way to tell the application that some file should be opened namely 
as a message no matter what is the name and the extension of the file. 
They believe that current heuristics is correct and ".mbox" suffix means 
collection of messages in "application/mbox" mail box. Thunderbird does 
not support opening a mbox file outside of its mail directories.


While I am still thinking that such behavior is partially a thunderbird 
fault, I suppose, debbugs should follow conventions and use .mbox file 
suffix only for downloading of the whole discussion.


Single message should be saved to an .eml file.

Bug#1009036: Use rel="nofollow" for links recognized in user messages

[Max Nikulin]

Package: debbugs

Please, consider adding the rel="nofollow" attribute to the links found 
in the text of user messages. Such value tells search engines that the 
link should not increase page rank of the target page. I hope, it will 
make debbugs sites less attractive for spammers, at least for those of 
them who try to promote some sites posting comments with links. The 
approach with ... links is used by 
various forum and blog engines.


Originally I asked administrators of debbugs.gnu.org concerning missed 
of "reply" mailto: links on that instance and they said that it is 
intentional change to avoid spam. I have no experience related to 
struggling with mail spam, however I have seen recommendations for web 
content to mark links in user comments as nofollow otherwise a site will 
be attacked by spammers. I have realized that that there is no such 
attribute on bugs.debian.org (or I was lucky to check only links to 
white-listed domains) and I have seen some spam messages in various reports.

Bug#1008861: network-manager-ssh: uses incorrect local tap interface

[Max Filippov]

Package: network-manager-ssh
Version: 1.2.11-1
Severity: normal

Hello,

on a Debian system with /bin/sh pointing to dash network-manager-ssh
incorrectly decides that tap0 is available for use as a local interface.
When tap0 is in use by some other application this results in inability
to connect to the ssh-based VPN.

My expectation is that network-manager-ssh should be able to find an
unused tap interface name regardless of the default shell type.

I have reported it and proposed a fix to the upstream here:
  
https://github.com/danfruehauf/NetworkManager-ssh/pull/105/commits/82b4217e89e1abb5554609c6096b2e21c4e4eab2

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

Kernel: Linux 5.10.0-11-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 network-manager-ssh depends on:
ii  libc6   2.31-13+deb11u3
ii  libglib2.0-02.66.8-1
ii  libnm0  1.30.0-2
ii  openssh-client  1:8.4p1-5
ii  sshpass 1.09-1+b1

Versions of packages network-manager-ssh recommends:
ii  network-manager-ssh-gnome  1.2.11-1

network-manager-ssh suggests no packages.

-- no debconf information

-- 
Thanks.
-- Max

Bug#1008159: Add mid: scheme handler to thunderbird.desktop

[Max Nikulin]

Package: thunderbird
Version: 1:91.7.0-2
Severity: minor

Since thunderbird-87 it is possible to open particular messages from 
command line through their Message-ID's:


thunderbird 'mid:23bc2bd1b0affd193daf52c8f4372...@smtp.spaceroots.org'

See e.g. https://bugzilla.mozilla.org/264270 The "mid:" URI scheme is 
defined in https://www.rfc-editor.org/rfc/rfc2392.html "Content-ID and 
Message-ID Uniform Resource Locators"


However to open links from other application, "mid:" scheme should be 
advertised in the thunderbird.desktop file:



MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;text/calendar;text/x-vcard;

instead of


MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;

Please, adjust this field in the desktop file. To check that the change 
has effect the following command may be used:


xdg-open 'mid:23bc2bd1b0affd193daf52c8f4372...@smtp.spaceroots.org'

Notice that it is not an upstream issue. Thunderbird developers left 
desktop integration up to maintainers of Linux distributions. E.g. in 
Ubuntu the thunderbird.desktop" file has been updated already for the 
upcoming release, see https://bugs.launchpad.net/bugs/1960614


Long time ago it was possible to create similar links to particular 
messages using thunderlink extension but migration from XUL to 
WebExtension add-ons broke it. Support of the "mid:" scheme restores 
linking of mail messages from other applications.


Workaround: add to the ~/.config/mimeapps.list file

[Added Associations]
x-scheme-handler/mid=thunderbird.desktop;

[Default Applications]
x-scheme-handler/mid=thunderbird.desktop;

Bug#1006914: Acknowledgement (fonts-noto-color-emoji: Most emojis not displayed at all in Plasma)

[Max Görner]

I forgot to provide the link to bug ticket #1006685. It is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006685.

Bug#1006914: fonts-noto-color-emoji: Most emojis not displayed at all in Plasma

[Max Görner]

Package: fonts-noto-color-emoji
Version: 2.034-1
Severity: normal

Dear Maintainer,

I use KDE on Debian Bullseye and Bookworm. For several years most emojis did
not work, neither in the Konsole terminal nor in the title bar of
windows nor in notifications. However, recently I learned that emojis
work when using Xfce on Debian and even inside the Xfce terminal under
KDE.

I reported bug #1006685 [1] against kde-plasma-desktop. There it was
found that the required font configuration file is not provided.

I would assume that a font package should provide the required
configuration for all desktop environments of the distribution.
Therefore I am opening a bug for fonts-noto-color-emoji. If I am
mistaken I would be glad to learn which package I should file a bug
against.

Thank you very much.


Best Regards
Max Görner


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

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

-- no debconf information

Bug#1006685: kde-plasma-desktop: KDE does not display Emojis correctly

[Max Görner]

Hi Norbert,


I used a different config file, but just found this here which indicates
that it is related to hinting:

https://bugs.freedesktop.org/show_bug.cgi?id=104542

Thank you very much for finding this.

Meanwhile, I had a look at how Kubuntu is configured in this regard.

I copied two files from Kubuntu's /etc/fonts/conf.avail/, 50-user.conf and
56-kubuntu-noto.conf and put them to Debian's /etc/fonts/conf.avail and
~/.config/fontconfig/conf.d/, respectively.

Then I refreshed the fonts cache using `sudo fc-cache -fv`, just as you
suggested. For everyone landing here: **It was crucial to relogin!**

Now I have working emoji support wherever I expect it. Thank you very much!

I could not find a primary source for both files, so I attached them to this
e-mail. Hopefully they will arrive in Debian's bug ticket frontend.



So maybe this is not related to KDE directly, but I still think its an
unfortunate situation, and fixing at would significantly improve the user
experience? Would it make sense to file another bug report against the
appropriate package, e.g. fontconfig?


My guess is that the fonts-noto-emoji or so should ship a fontconfig
file that activates it, best with the above.

I will open a bugreport for that package.


Again, thank you very much for your help. I think this bug report can be
closed now.


Best Regards
Max Görner



  http://www.w3.org/2005/11/its; version="1.0">

  

  Load per-user customization files

fontconfig/conf.d
fontconfig/fonts.conf

~/.fonts.conf.d
~/.fonts.conf





  
  /usr/share/fonts/croscore
  /usr/share/fonts/crosextra
  /usr/share/fonts/dejavu
  /usr/share/fonts/ko-nanum
  /usr/share/fonts/lohit-cros
  /usr/share/fonts/monotype
  /usr/share/fonts/noto
  /usr/share/fonts/notocjk
  /usr/share/fonts/roboto
  /usr/share/fonts/tibt-jomolhari
  
  
serif

  Tinos
  Noto Serif
  Noto Serif CJK SC
  Noto Naskh Arabic
  Noto Serif Thai
  Noto Serif Armenian
  Noto Serif Georgian
  Noto Serif Devanagari
  Noto Serif Hebrew
  Noto Serif Bangali
  Noto Serif Gujarati
  Noto Serif Kannada
  Noto Serif Malayalam
  Noto Serif Tamil
  Noto Serif Telugu
  Lohit Punjabi
  Lohit Oriya
  Noto Serif Khmer
  Noto Serif Lao
  Noto Serif Ethiopic
  Noto Serif Myanmar
  Noto Serif Sinhala
  Jomolhari
  Noto Color Emoji
  Noto Sans Symbols
  Noto Sans Symbols2
  DejaVu Serif

  
  
sans-serif

  Arimo
  Noto Sans
  Noto Sans CJK SC
  Noto Sans Arabic
  Noto Sans Thai
  Noto Sans Devanagari
  Noto Sans Tamil
  Noto Sans Hebrew
  Noto Sans Bengali
  Noto Sans Telugu
  Noto Sans Kannada
  Noto Sans Malayalam
  Noto Sans Gurmukhi
  Noto Sans Gujarati
  Noto Sans Oriya
  Noto Sans Armenian
  Noto Sans Georgian
  Noto Sans Khmer
  Noto Sans Lao
  Noto Sans Ethiopic
  Noto Sans Myanmar
  Noto Sans Sinhala
  Jomolhari
  Noto Sans Coptic
  Noto Sans Deseret
  Noto Sans TaiTham
  Noto Sans CanadianAboriginal
  Noto Sans Yi
  Noto Sans Tifinagh
  Noto Sans Adlam
  Noto Sans Cherokee
  Noto Sans Chakma
  Noto Sans Osage
  Noto Color Emoji
  Noto Sans Symbols
  Noto Sans Symbols2
  DejaVu Sans

  
  
monospace

  Cousine
  Noto Sans Mono
  Noto Sans Mono CJK SC
  Noto Naskh Arabic
  Noto Sans Thai
  Noto Sans Devanagari
  Noto Sans Tamil
  Noto Sans Bengali
  Noto Sans Telugu
  Noto Sans Kannada
  Noto Sans Malayalam
  Noto Sans Gurmukhi
  Noto Sans Gujarati
  Noto Sans Oriya
  Noto Sans Armenian
  Noto Sans Georgian
  Noto Sans Ethiopic
  Noto Sans Myanmar
  Noto Sans Sinhala
  Noto Sans Tibetan
  Noto Sans Coptic
  Noto Sans Deseret
  Noto Sans TaiTham
  Noto Sans Cherokee
  Noto Sans Chakma
  Noto Sans Osage
  Noto Color Emoji
  Noto Sans Symbols
  Noto Sans Symbols2
  Droid Sans Fallback
  DejaVu Sans Mono

  
  
ui-sans

  Noto Sans UI
  Noto Sans CJK SC
  Noto Naskh Arabic UI
  Noto Sans Thai UI
  Noto Sans Devanagari UI
  Noto Sans Tamil UI
  Noto Sans Hebrew
  Noto Sans Bengali UI
  Noto Sans Telugu UI
  Noto Sans Kannada UI
  Noto Sans Malayalam UI
  Noto Sans Gurmukhi UI
  Noto Sans Gujarati UI
  Noto Sans Oriya UI
  Noto Sans Armenian
  Noto Sans Georgian
  Noto Sans Khmer UI
  Noto Sans Lao UI
  Noto Sans Ethiopic
  Noto Sans Myanmar UI
  Noto Color Emoji
  Noto Symbols
  Droid Sans Fallback
  DejaVu Sans

  
 
  

  zh


  14


  14

  
  
  

Arimo
true
hintfull
false
  
  

Chrome Droid Sans
true
hintslight
true
  
  
   

Bug#1006685: kde-plasma-desktop: KDE does not display Emojis correctly

[Max Görner]

Hi Norbert,

thank you very much for your reply.


[...]
- added configuration to /etc/fonts/local.conf (easily findable on the
 internet what is necessary)

I really tried, but I could not find a guide how to do so. I found
https://wiki.archlinux.org/title/Font_configuration but it seems not to have a
section to configure fallback fonts.

Could you point me to a guide or maybe post your XML snippet here? It would
help me a lot.



This is not specific to KDE, but to fontconfig and how Debian handles
fallback fonts.

So maybe this is not related to KDE directly, but I still think its an
unfortunate situation, and fixing at would significantly improve the user
experience? Would it make sense to file another bug report against the
appropriate package, e.g. fontconfig?


Best regards
Max Görner

Bug#1006685: kde-plasma-desktop: KDE does not display Emojis correctly

[Max Görner]

Package: kde-plasma-desktop
Version: 5:111
Severity: normal

Dear Maintainer,

for several years KDE on Debian seems to be unable to display emojis
correctly. I experience this problem on Debian testing and on Debian stable.

One can reproduce it by running `echo "Heart Face Emoji 殺"` in Konsole
or by opening https://www.youtube.com/watch?v=YaYoJziCgto in Fireofox or
Konqueror. The emojis will be displayed only as blank rectangles.

The problem does not occur on Ubuntu. It also does not occur when using
Debian/Xfce and when using the Xfce-Terminal from within a Plasma
session. Thus, I can have a Konsole and Xfce-Terminal side by side with
the former showing the problem and the latter not so.

I reproduced the problem by setting up a Debian/Testing in a virtual
machine yesterday.

I tried to set a different font, but to no avail. Maybe I have not tried
hard enough. However, I think Emojis should be displayed properly in the
default configuration.


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

Kernel: Linux 5.16.10 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:20.12.0+5.111
ii  plasma-desktop4:5.20.5-4
ii  plasma-workspace  4:5.20.5-6
ii  udisks2   2.9.2-2+deb11u1
ii  upower0.99.11-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.20.5-1
ii  sddm  0.19.0-3
ii  xserver-xorg  1:7.7+22

Versions of packages kde-plasma-desktop suggests:
ii  kdeconnect  20.12.3-2

-- no debconf information

Bug#1006223: "stack smashing detected" error in ld while linking with Map-file specified

[Max A. Dednev]

Package version (2.26.20160125+Atmel3.6.2-3) patch level was incremented 
by me while building patched version.
So, the original package version with bug reported is 
2.26.20160125+Atmel3.6.2-2


--
Max A. Dednev

Bug#1006223: binutils-avr: "stack smashing detected" error in ld while linking with Map-file specified

[Max A. Dednev]

Package: binutils-avr
Version: 2.26.20160125+Atmel3.6.2-3
Severity: important
Tags: patch
X-Debbugs-Cc: mded...@yandex.ru

Dear Maintainer,

binutils-avr ld crashes with error "*** stack smashing detected ***:
terminated" if map-file generation is enabled with -Map=mapfile.map command
line option.

Example compilation log:

--- LOG start ---
avr-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling: main.c
avr-gcc -c -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK  -Os -Wall -Wstrict-
prototypes -Wa,-adhlns=main.lst  -std=gnu99  main.c -o main.o

Linking: atmega64.elf
avr-gcc -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK  -Os -Wall -Wstrict-
prototypes -Wa,-adhlns=main.o  -std=gnu99  main.o  --output atmega64.elf
-Wl,-Map=atmega64.map,--cref-lm
collect2: fatal error: ld terminated with signal 6 [Аварийный останов]
compilation terminated.
*** stack smashing detected ***: terminated
make: *** [makefile:391: atmega64.elf] Ошибка 1
--- LOG end ---

I've found, that stack overflow is in ldmain.c add_archive_element() function
at sprintf() call. Proposed patch is:

Index: binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c
===
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/ld/ldmain.c
2020-01-12 11:11:48.0 +0300
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c  2022-02-21
17:36:14.889230109 +0300
@@ -846,11 +846,8 @@

   if (! header_printed)
{
- char buf[100];
-
- sprintf (buf, _("Archive member included "
- "to satisfy reference by file (symbol)\n\n"));
- minfo ("%s", buf);
+ minfo (_("Archive member included "
+  "to satisfy reference by file (symbol)\n\n"));
  header_printed = TRUE;
}


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

Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages binutils-avr depends on:
ii  libc6   2.31-13+deb11u2
ii  zlib1g  1:1.2.11.dfsg-2

binutils-avr recommends no packages.

Versions of packages binutils-avr suggests:
ii  binutils  2.35.2-2
Index: binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c
===
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/ld/ldmain.c 
2020-01-12 11:11:48.0 +0300
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c  2022-02-21 
17:36:14.889230109 +0300
@@ -846,11 +846,8 @@
 
   if (! header_printed)
{
- char buf[100];
-
- sprintf (buf, _("Archive member included "
- "to satisfy reference by file (symbol)\n\n"));
- minfo ("%s", buf);
+ minfo (_("Archive member included "
+  "to satisfy reference by file (symbol)\n\n"));
  header_printed = TRUE;
}