Bug#1069353: plantuml: Re: nncp: FTBFS on arm64: make[1]: *** [debian/rules:21: override_dh_auto_build] Error 1

[Max Nikulin]

On 07/06/2024 18:24, Andrej Shadura wrote:

That was totally a bug in plantuml. My fault that I forgot to merge it
with another bug report for the same issue.


Thanks, Andrej. I see that the package have returned to testing.

I am sorry that I missed https://bugs.debian.org/1068999 I was surprised 
that a working version suddenly disappeared from trixie.

Bug#1069353: plantuml: Re: nncp: FTBFS on arm64: make[1]: *** [debian/rules:21: override_dh_auto_build] Error 1

[Max Nikulin]

On Sat, 20 Apr 2024 14:09:44 +0200 Lucas Nussbaum wrote:

Source: nncp
Severity: serious
Justification: FTBFS

[...]

Caused by: java.lang.RuntimeException: Fontconfig head is null, check your 
fonts or fonts configuration


John, for nncp it was certainly a high priority bug, but why severity is 
the same for plantuml?


Perhaps fonts were missed in nncp build environment, but I am not sure 
that it is a plantuml failure. From my point of view, it should not be a 
reason to remove the package from testing.

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#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#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#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#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#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#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#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#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#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#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#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#1004082: "qemu -display spice-app" fails due to missed spice+unix scheme in remote-viewer.desktop

[Max Nikulin]

Package: virt-viewer
Version: 7.0-2+b1
Severity: minor

Try the following command (optionally add something like
-cdrom ubuntu.iso):
 qemu-system-x86_64 -display spice-app
Actual result:

qemu-system-x86_64: info: Launching display with URI: 
spice+unix:///tmp/.XXGMF1/spice.sock
qemu-system-x86_64: Failed to launch spice+unix:///tmp/.XXGMF1/spice.sock URI: 
The specified location is not supported
qemu-system-x86_64: You need a capable Spice client, such as virt-viewer 8.0

Expected result:
no such error, with additional arguments VM is started.

Actually virt-viewer-7.0 (buster-sid) supports spice+unix scheme
but it is not specified in remote-viewer.desktop.

Upstream commit fixing this issue is included since v8.0 tag:

https://gitlab.com/virt-viewer/virt-viewer/-/commit/c4f6142f15c4e51cbf427f5f1bf1fc6ac0e10d88
remote-viewer: add handling of spice+unix and spice+tls schemes
2018-07-27T15:12:00Z

Accordingly to https://virt-manager.org/download/
virt-viewer 11.0 is available since Friday November 18th, 2021

I hope, the best way to fix the issue is to package new version,
however I have not tried to build it, so some complications may exist.

Workaround:
Add to ~/.config/mimeapps.list
 >8 
[Added Associations]
x-scheme-handler/spice+unix=remote-viewer.desktop
 8< 

Besides qemu shortcut it will allow to launch handler using e.g.
xdg-open spice+unix:///path/to/socket