Bug#1023993: Mosquitto 2.0.11-1.1+b3 unable to use websockets

[Gianfranco Costamagna]

libwebsockets (4.3.2-4) unstable; urgency=medium

  * Re-enable LWS_WITH_EXTERNAL_POLL support (closes: #1050195).

 -- Laszlo Boszormenyi (GCS)   Wed, 23 Aug 2023 22:13:50 +0200

Looks like fixed in sid/testing.

G.

On Sun, 13 Nov 2022 16:52:04 +0100 Tom van Leeuwen  
wrote:

Package: mosquitto
Version: 2.0.11-1.1+b3

The libwebsockets-dev package in Bookworm is compiled without 
"LWS_WITH_EXTERNAL_POLL=ON". This breaks compatibility with mosquitto, 
which requires this option to be set in libwebsockets 4.1.6 to use 
websockets.


Mosquitto is statically linked against libwebsockets in Bookworm. 
However, the linked version does not have the LWS_WITH_EXTERNAL_POLL=ON 
flag set either, since it is linked against libwebsockets.a file from 
the libwebsockets-dev package.


These discussions show that "LWS_WITH_EXTERNAL_POLL=ON" is required:

https://github.com/eclipse/mosquitto/blob/v2.0.15/src/mosquitto_broker_internal.h#L26
https://bugs.archlinux.org/task/70321
https://github.com/eclipse/mosquitto/issues/2060

Since mosquitto it is statically linked, the problematic libwebsockets 
code is inside that package as well.


Ideally, you would add "LWS_WITH_EXTERNAL_POLL=ON" to the build of 
libwebsockets-dev and rebuild mosquitto. Alternatively you could disable 
websocket support in mosquitto all together by removing the 
WITH_WEBSOCKETS=yes flag.


I have the config file attached (stored in /etc/mosquitto/conf.d) that 
results in unusable websockets, but testing the issue requires a 
publisher to get some data in mosquitto and a subscriber via websockets 
to reproduce the issue. There is no error message, there is simply no 
data provided to the subscriber. Let me know if you need a test since it 
is already documented that the "LWS_WITH_EXTERNAL_POLL=ON" flag is a 
requirement for mosquitto with websockets enabled.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051824: linux-patch-VER-rt.patch.xz went missing

[Helmut Grohne]

Package: linux-source-6.1
Version: 6.1~rc3-1~exp1
X-Debbugs-Cc: wa...@debian.org

Hi,

I noticed that linux-patch-VER-rt.patch.xz is missing from
linux-source-VER lately. I tracked this down to having gone missing
exactly when we moved from 6.0 to 6.1, i.e. all 6.0 builds include it
and all 6.1 builds lack it. Digging deeper, I couldn't identify a
regressing git commit, but Bastian's work on restructuring makefile
targets stands out. If looking at build logs, you can see that in
current builds ALL_FEATURESETS is no longer set and this is why the
relevant dependency is skipped.

gencontrol.py def do_main_makefile is probably relevant here. It ends
with:

makeflags = makeflags.copy()
makeflags['ALL_FEATURESETS'] = ' '.join(iter_featuresets(self.config))
super().do_main_makefile(makeflags, extra)

In former kernels, the super method was non-empty and consumed the
updated makeflags, but this is no longer the case, the super method now
simply says "pass", so this code block has effectively become a no-op.

On the flip side, I tried to see what would happen if we'd update the
global makeflags with ALL_FEATURESETS (e.g. by deleting the dict copy).
And indeed, once doing that the rt patch is included in the -source
package again. This probably is not the right solution, but I hope this
bit helps pin down the cause.

In any case, it seems evident that the deletion of
linux-patch-VER-rt.patch.xz is accidental rather than intentional. Would
you be able to restore its presence?

Helmut

Bug#1041504: moc: FTBFS with ffmpeg 6.0

[Shengjing Zhu]

Hi,

On Wed, Jul 19, 2023 at 09:48:41PM +0200, Sebastian Ramacher wrote:
> Source: moc
> Version: 1:2.6.0~svn-r3005-3
> Severity: important
> Tags: ftbfs sid trixie
> X-Debbugs-Cc: sramac...@debian.org
> 
> moc FTBFS with ffmpeg 6.0 (available in experimental):

I NMU 2.6.0~svn-r3005-3.1 which fixes building with ffmpeg 6.0.

Please see patch at https://salsa.debian.org/riesebie/moc/-/merge_requests/3

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Russ Allbery  writes:
> Russ Allbery  writes:

>> Maybe the right way to do this is just have two examples, one as the
>> default and another if you're using tmpfiles.d functionality added in a
>> specific version of systemd that's newer than the version shipped with
>> the stable version of Debian prior to the one you're targeting.

> Here's an updated version with that change plus some other minor fixes.

Er, right, helps to rebase first.  Here's the actual patch.

-- 
Russ Allbery (r...@debian.org)  

diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..fa3e5be 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages
 outside the system PATH must be encoded in UTF-8 and should be
 restricted to ASCII when it is possible to do so.
 
+.. _s-tmpfiles.d:
+
+Volatile and temporary files (``tmpfiles.d``)
+-
+
+Some packages require empty directories in ``/var`` or ``/etc``, or
+symlinks or files with trivial content in ``/var``, to implement their
+functionality.  Examples include directories under ``/var/cache`` that are
+writable by the package as cache areas, an initially-empty directory in
+``/etc`` intended for local overrides added by the local system
+administrator, or a file in ``/var`` that should default to a symlink
+elsewhere on the system but may be changed later.
+
+Rather than include these symlinks, files, or directories in the binary
+package or create them in package maintainer scripts, packages should use
+the ``tmpfiles.d`` mechanism to specify the files and directories that
+should be created.  This allows associating these files and directories
+with specific packages (not currently possible when creating them in
+maintainer scripts), and allows local administrators to delete the
+contents of directories such as ``/var/cache`` with the assurance that
+``tmpfiles.d`` can recreate the necessary file structure without
+reinstalling packages or re-running maintainer scripts.
+
+For information on how to specify files and directories that should be
+managed by the ``tmpfiles.d`` mechanism, see :manpage:`tmpfiles.d(5)`.
+
+If the files or directories are only needed by a system service or
+otherwise should only be created when that service is running, packages
+should define those files and directories in the ``systemd`` unit for the
+service (and, for alternative init systems, in the configuration for that
+init system) instead of using the ``tmpfiles.d`` mechanism.  See
+:ref:`s-services-dirs` for more details.
+
+The ``tmpfiles.d`` mechanism may also be used to create and manage files
+and directories under ephemeral file systems such as ``/tmp`` and
+``/run``, although these are more likely to be associated with a running
+service and in those cases should be defined in the ``systemd`` unit for
+the service.
+
+All packages that ship ``tmpfiles.d`` configuration should declare a
+dependency on::
+
+default-systemd-tmpfiles | systemd-tmpfiles
+
+If the package uses ``tmpfiles.d`` features that are not supported by all
+implementations of the ``systemd-tmpfiles`` virtual package in the stable
+release prior to the release being targeted, instead use::
+
+default-systemd-tmpfiles (>= v) | systemd-tmpfiles (>= v)
+
+where ``v`` is the version of ``systemd`` in which the features were
+introduced.
+
+All packages that ship ``tmpfiles.d`` configuration should arrange for
+that configuration to be processed during package installation.  This
+should be handled by the packaging helper framework; for example, packages
+using ``debhelper`` should use ``dh_installtmpfiles``, which will add the
+appropriate commands to the package maintainer scripts.
+
+The init system must ensure that ``tmpfiles.d`` configuration is applied
+during boot and that ``tmpfiles.d`` cleanup rules are invoked
+periodically.  See :manpage:`systemd-tmpfiles(8)` for more information on
+how to do this.
+
 .. [#]
If you are using GCC, ``-fPIC`` produces code with relocatable
position independent code, which is required for most architectures
diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 724074c..e43340f 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -50,6 +50,11 @@ absolute pathname. Maintainer scripts should also not reset the
 appending package-specific directories. These considerations really
 apply to all shell scripts.
 
+Maintainer scripts should not be used to create empty directories in
+``/var`` or ``/etc``, or symlinks or files with trivial content in
+``/var``.  Instead, use the ``tmpfiles.d`` mechanism to manage those
+directories and files.  See :ref:`s-tmpfiles.d` for more information.
+
 .. _s-idempotency:
 
 Maintainer scripts idempotency
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 64c0ff6..e80e9b4 100644

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Russ Allbery  writes:

> Maybe the right way to do this is just have two examples, one as the
> default and another if you're using tmpfiles.d functionality added in a
> specific version of systemd that's newer than the version shipped with
> the stable version of Debian prior to the one you're targeting.

Here's an updated version with that change plus some other minor fixes.

-- 
Russ Allbery (r...@debian.org)  

diff --git a/debian/changelog b/debian/changelog
index 4cead28..44a3710 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -24,17 +24,6 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium
 Seconded: Helmut Grohne 
 Seconded: Guillem Jover 
 Closes: #970234
-  * Policy: Binary and Description fields may be absent in .changes
-Wording: Russ Allbery 
-Seconded: Sam Hartman 
-Seconded: Guillem Jover 
-Closes: #963524
-  * Policy: systemd units are required to start and stop system services
-Wording: Luca Boccassi 
-Wording: Russ Allbery 
-Seconded: Luca Boccassi 
-Seconded: Sam Hartman 
-Closes: #1039102
 
  -- Sean Whitton   Wed, 14 Jun 2023 16:58:40 +0100
 
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index d5c9d68..4bab7df 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -278,7 +278,7 @@ The fields in this file are:
 
 -  :ref:`Source ` (mandatory)
 
--  :ref:`Binary ` (mandatory in some cases)
+-  :ref:`Binary ` (mandatory)
 
 -  :ref:`Architecture ` (mandatory)
 
@@ -292,7 +292,7 @@ The fields in this file are:
 
 -  :ref:`Changed-By `
 
--  :ref:`Description ` (mandatory in some cases)
+-  :ref:`Description ` (mandatory)
 
 -  :ref:`Closes `
 
@@ -812,16 +812,12 @@ See :ref:`s-descriptions` for further information on
 this.
 
 In a ``.changes`` file, the ``Description`` field contains a summary of
-the descriptions of the binary packages being uploaded. If no binary
-packages are being uploaded, this field will not be present.
-
-When used inside a ``.changes`` file, the ``Description`` field has a
-different format than in source or binary control files. It is a multiline
-field with one line per binary package. The first line of the field value
-(the part on the same line as ``Description:``) is always empty. Each
-subsequent line is indented by one space and contains the name of a binary
-package, a space, a hyphen (``-``), a space, and the short description
-line from that package.
+the descriptions for the packages being uploaded. For this case, the
+first line of the field value (the part on the same line as
+``Description:``) is always empty. It is a multiline field, with one
+line per package. Each line is indented by one space and contains the
+name of a binary package, a space, a hyphen (``-``), a space, and the
+short description line from that package.
 
 .. _s-f-Distribution:
 
@@ -931,8 +927,7 @@ every architecture. The source control file doesn't contain details of
 which architectures are appropriate for which of the binary packages.
 
 When it appears in a ``.changes`` file, it lists the names of the binary
-packages being uploaded, separated by whitespace (not commas). If no
-binary packages are being uploaded, this field will not be present.
+packages being uploaded, separated by whitespace (not commas).
 
 .. _s-f-Installed-Size:
 
diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..fa3e5be 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,70 @@ The name of the files and directories installed by binary packages
 outside the system PATH must be encoded in UTF-8 and should be
 restricted to ASCII when it is possible to do so.
 
+.. _s-tmpfiles.d:
+
+Volatile and temporary files (``tmpfiles.d``)
+-
+
+Some packages require empty directories in ``/var`` or ``/etc``, or
+symlinks or files with trivial content in ``/var``, to implement their
+functionality.  Examples include directories under ``/var/cache`` that are
+writable by the package as cache areas, an initially-empty directory in
+``/etc`` intended for local overrides added by the local system
+administrator, or a file in ``/var`` that should default to a symlink
+elsewhere on the system but may be changed later.
+
+Rather than include these symlinks, files, or directories in the binary
+package or create them in package maintainer scripts, packages should use
+the ``tmpfiles.d`` mechanism to specify the files and directories that
+should be created.  This allows associating these files and directories
+with specific packages (not currently possible when creating them in
+maintainer scripts), and allows local administrators to delete the
+contents of directories such as ``/var/cache`` with the assurance that
+``tmpfiles.d`` can recreate the necessary file structure without
+reinstalling packages or re-running maintainer scripts.
+
+For information on how to specify files and directories 

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#1051305: Request to Add 'loong64' to java-common's debian/java_defaults.mk

[panxuefeng]

Source: java-common
Version: 0.74
Tags: patch
Severity: wishlist
Usertags: loongarch64
User: debian-de...@lists.debian.org


Dear Maintainers,

I'm going to add loong64 support to the java-common package. Specifically, 
added loong64 support for java17_architectures and jvm_archdir_map variables in 
debian/java_defaults.mk file.

Please reveiw these modifications and give your valuable comments!

Thanks,
Xuefeng Pan

diff -Nru java-common-0.74/debian/changelog 
java-common-0.74+nmu1+loong64/debian/changelog
--- java-common-0.74/debian/changelog   2023-01-11 22:12:21.0 +
+++ java-common-0.74+nmu1+loong64/debian/changelog  2023-09-13 
03:20:13.0 +
@@ -1,3 +1,9 @@
+java-common (0.74+nmu1+loong64) UNRELEASED; urgency=medium
+
+ * Add loongarch support.
+
+ -- Xuefeng Pan   Wed, 13 Sep 2023 11:19:27 +
+
 java-common (0.74) unstable; urgency=medium
 
   * Team upload.
diff -Nru java-common-0.74/debian/java_defaults.mk 
java-common-0.74+nmu1+loong64/debian/java_defaults.mk
--- java-common-0.74/debian/java_defaults.mk2023-01-11 22:10:35.0 
+
+++ java-common-0.74+nmu1+loong64/debian/java_defaults.mk   2023-09-13 
03:18:17.0 +
@@ -3,7 +3,7 @@
 
 java17_architectures = \
alpha amd64 arm64 armel armhf i386 \
-   ia64 m68k mipsel mips64el \
+   ia64 loong64 m68k mipsel mips64el \
powerpc ppc64 ppc64el \
riscv64 s390x sh4 sparc64 x32
 java11_architectures = $(java17_architectures) \
@@ -34,7 +34,7 @@
 _java_host_cpu := $(if $(DEB_HOST_ARCH_CPU),$(DEB_HOST_ARCH_CPU),$(shell 
dpkg-architecture -qDEB_HOST_ARCH_CPU))
 jvm_archdir_map = \
alpha=alpha armel=arm armhf=arm arm64=aarch64 amd64=amd64 \
-   i386=i386 m68k=m68k mips=mips mipsel=mipsel mips64=mips64 
mips64el=mips64el \
+   i386=i386 loong64=loong64 m68k=m68k mips=mips mipsel=mipsel 
mips64=mips64 mips64el=mips64el \
powerpc=ppc ppc64=ppc64 ppc64el=ppc64le riscv64=riscv64 \
sparc64=sparc64 sh4=sh s390x=s390x ia64=ia64 x32=x32
 

Bug#1051823: ITP: libjs-simulate-event -- JavaScript library to trigger DOM events on any element

[Yadd]

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

* Package name: libjs-simulate-event
  Version : 1.4.0
  Upstream Contact: Blake Embrey 
* URL : https://github.com/blakeembrey/simulate-event
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript library to trigger DOM events on any element

libjs-simulate-event provide a simple way to trigger DOM events on any
element:
  * simulateEvent.simulate(document.body, 'click')

It's a build dependency of node-jupyterlab and will be maintaied under
JS Team umbrella

Bug#1039985: libjson-smart-java: buster-lts has a newer version than bullseye/bookworm/sid

[tony mancill]

On Fri, Jun 30, 2023 at 06:46:06PM +0200, Andreas Beckmann wrote:
> Package: libjson-smart-java
> Version: 2.2-2
> Severity: serious
> Tags: bullseye bookworm trixie sid
> 
> Hi,
> 
> during a test with piuparts I noticed your package cannot be upgraded
> from buster-lts to any newer release since buster-lts has a version
> newer than any later release:
> 
>  json-smart | 2.2-1 | stretch | source
>  json-smart | 2.2-2 | buster  | source
>  json-smart | 2.2-2 | bullseye| source
>  json-smart | 2.2-2 | bookworm| source
>  json-smart | 2.2-2 | trixie  | source
>  json-smart | 2.2-2 | sid | source
>  json-smart | 2.2-2+deb10u1 | buster-security | source

I am working on an upload of a new upstream version 2.5.0 that will take
care of trixie and sid.  Bastien, are you planning on uploading a
patched 2.2 to bullseye and bookworm?

Thanks,
tony

Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1

[Anibal Monsalve Salazar]

Installing adduser (3.137) fixed this bug for me.

Maybe there is a missing dependency on adduser (3.137).

Bug#1036277: Ship keama - The KEA Migration Assistant

[Athos Ribeiro]

On Mon, Sep 11, 2023 at 03:35:37PM +0530, Santiago Ruano Rincón wrote:


Do you think it would be possible to add an autopkgtest for keama?



Hi Santiago!

Thanks for having a look at this :)

I added an autopkgtest to run some upstream provided checks and also
changed d/rules to run the same checks during the package build.

I needed to perform some changes to ensure the tests will make the build
process halt on failures and removed one specific test which was
performing a DNS query.

Let me know your thoughts on this.

Thanks again!

Bug#972439: (no subject)

[Tiago Bortoletto Vaz]

retitle 972439 RFP: tailscale -- wireguard overlay network manager (client)
thanks

I'm refraining from packaging tailscale for Debian.
I ITP'ed without looking further, as I was excited to hack it during the going 
on Debconf.

Status:

 - Among its direct dependencies, 39 will need to be packaged.
 - I had a quick look at them, and many will have extra dependencies to be 
packaged as well.
 - Then I looked at the upstream view on a official Debian package for 
tailscale and got some extra discouragement:

https://github.com/tailscale/tailscale/issues/7847#issuecomment-1503731931

All in all, I wish good luck to the brave one who takes on this job.

Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1

[Anibal Monsalve Salazar]

Package: chrony
Version: 4.2-2
Severity: critical

# dpkg -i /mnt/apt/archives/chrony_4.4-1_i386.deb
(Reading database ... 34682 files and directories currently installed.)
Preparing to unpack .../archives/chrony_4.4-1_i386.deb ...
Failed to stop chronyd-restricted.service: Unit chronyd-restricted.service not 
loaded.
Unpacking chrony (4.4-1) over (4.3-4) ...
Setting up chrony (4.4-1) ...
Unknown option: comment
adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
[--disabled-password] [--disabled-login] [--add_extra_groups] USER
   Add a normal user

adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
[--disabled-login] [--add_extra_groups] USER
   Add a system user

adduser --group [--gid ID] GROUP
addgroup [--gid ID] GROUP
   Add a user group

addgroup --system [--gid ID] GROUP
   Add a system group

adduser USER GROUP
   Add an existing user to an existing group

general options:
  --quiet | -q  don't give process information to stdout
  --force-badname   allow usernames which do not match the
NAME_REGEX configuration variable
  --help | -h   usage message
  --version | -vversion number and copyright
  --conf | -c FILE  use FILE as configuration file

dpkg: error processing package chrony (--install):
 installed chrony package post-installation script subprocess returned error 
exit status 1
Processing triggers for man-db (2.11.2-3) ...
Errors were encountered while processing:
 chrony

Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Control: retitle -1 Post-/usr-merge paths for script interpreters

Simon pointed out that this bug is not yet ready to act on, which was very
helpful.  Thank you.  However, presumably the buildds will be /usr-merged
at some point in the not-too-distant future, and we do need to decide what
to do after that point.

I think the root problem behind this bug is that it is revealing we have
not made a decision about /bin and /usr/bin path references in Debian
after /usr-merge.  Various people, myself included, made assumptions about
what the policy would be, but we never actually decided anything that I am
aware of and people's assumptions are not matching.  I think we need to
talk about this directly, after which what to do with this bug will
probably become obvious.

So far as I can tell, there are three main possibilities:

(a) Although /bin and /usr/bin are merged (and likewise for the other
merged paths), Debian will continue to require (or at least recommend)
use of /bin paths for things such as /bin/sh that historically used
those paths.

(b) Since /bin and /usr/bin (and likewise for the other paths) are merged,
/bin/sh and /usr/bin/sh are equivalent.  Packages can use whichever
path they want, and Debian will end up with a mix of both references.

(c) Although /bin and /lib technically work due to the aliasing, they are
deprecated and everything in Debian should stop using those paths.
All paths should point to /usr/bin and /usr/lib now.

Although Luca made a few arguments in the direction of (c), my
understanding of his current patch is that it essentially implements (b)
for script interpreters, although without encoding into Policy an explicit
decision between these three options (quite understandably because he was
trying to deal with a narrower issue).  Several other people were, I
think, arguing for (a), but I'm not sure if they would continue to do so
when it's put in these terms.

Policy currently says nothing significant about this (hence most of the
text so-far discussed being informative) because, up until now, (a) was
the de facto policy.  If you didn't follow (a), you would get not-found
errors and your package would have an RC bug because it wouldn't work.

If we do nothing, we'll get (b).  I think that's reasonably obvious, since
there is no technical factor forcing either (a) or (c).  Both paths will
work without any noticable difference, so some people will use /bin and
some people will use /usr/bin.

That said, I would rather make an explicit choice rather than decide by
default, since otherwise this seems like the kind of thing where people
are going to get conflicting advice, which is frustrating for everyone.

If someone wants to argue for (a) or (c), I think the biggest problem with
either of them is an enforcement mechanism.  How are we going to check
whether packages are following the rules?  Lintian and a bunch of grep
patterns is sort of an unsatisfying 90% solution, and people will ignore
it or just not use Lintian.  There is also no technical reason why both
paths will not work, so people are going to get grumpy about being told
what to do and some people will view this as makework.  I think any
proposal to pick (a) or (c) needs to wrestle with that.

I will also say that it will be very hard to convince me that Debian
should give Policy advice like (a) or (c) but not actually enforce it
anywhere.  We have a long history to look at for how those sorts of
mandates go.  Conscientious packagers who read Policy carefully follow the
rules and go to extra effort to do so, but other people will never see
that advice or not pay attention to it.  That means that the effort is
mostly wasted, because no one can rely on the invariant that either (a) or
(c) is attempting to achieve.  I am not a big fan of asking people to do
extra work without some clear benefit from doing that work, which mostly
requires uniformity.

One last point about this decision: although there are a few style
recommendations in it, Policy is not a style guide.  The point of Policy
is to describe the things we should or must do, or at least that the
project as a whole wants to encourage, that have a concrete effect on the
quality of the distribution.  I'm reluctant to add more style advice to
Policy, particularly about things that are not specific to Debian.  If
we're going to require or recommend something, I think we need to have a
concrete goal in mind for what that requirement or recommendation is going
to achieve.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Peter Green]

On 12/09/2023 23:30, Faidon Liambotis wrote:

Control: reassign -1 rustc 1.68.2+dfsg1-1
Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)

On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:

The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
both testing and unstable's versions of wasmedge, and with both testing and
unstable's versions of wasi-lib.

Thanks for the report. Actually, I think the WasmEdge autopkgtests are
catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries
that do not work with neither WasmEdge, nor Wasmtime (the latter is not
in Debian).

And it seems the issue persists with rustc 1.69 :(

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37797497/log.gz


Very simple test case:

$ podman run --rm -it debian:sid  # or bookworm to test with rustc 1.67

root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32
[...]
root@ad697f1c195f:~# rustc -V
rustc 1.68.2
root@ad697f1c195f:~# cat > hello.rs 

Bug#1051821: a2jmidid: FTBFS: enable build for LoongArch

[zhangdandan]

Package: a2jmidid
Version: 9-3
Severity: normal
Tags: patch ftbfs
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

When compiling the package a2jmidid for loong64 in the Debian Package 
Auto-Building environment [1], The error message is as follows:

..Omit
../sigsegv.c: In function ‘signal_segv’:
../sigsegv.c:97:20: error: ‘NGREG’ undeclared (first use in this function)
97 | for(i = 0; i < NGREG; i++)
| ^
../sigsegv.c:97:20: note: each undeclared identifier is reported only 
once for each function it appears in

In file included from ../sigsegv.c:39:
../sigsegv.c:106:39: error: ‘mcontext_t’ has no member named ‘gregs’; 
did you mean ‘__gregs’?

106 | ucontext->uc_mcontext.gregs[i]
| ^
../log.h:47:134: note: in definition of macro ‘a2j_error’
..Omit

The full compilation log can be found at [2].

Please consider the patch I have attached.
BTW, the patch I provided in the attachment doesn't affect other 
architectures and compiles fine on the loongarch architecture.

If you have any questions, you can contact me at any time.

[1]:https://buildd.debian.org/status/package.php?p=a2jmidid=sid
[2]:https://buildd.debian.org/status/logs.php?pkg=a2jmidid=9-3=loong64

thanks,
Dandan Zhang

Description: Add support for loongarch
Last-Update: 2023-09-13

--- a2jmidid-9.orig/sigsegv.c
+++ a2jmidid-9/sigsegv.c
@@ -93,7 +93,7 @@ static void signal_segv(int signum, sigi
 a2j_error("info.si_addr  = %p", info->si_addr);
 #if !defined(__alpha__) && !defined(__ia64__) && \
 !defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__) && \
-!defined(__sh__) && !defined(__aarch64__) && !defined(__riscv)
+!defined(__sh__) && !defined(__aarch64__) && !defined(__riscv) && !defined(__loongarch__)
 for(i = 0; i < NGREG; i++)
 a2j_error("reg[%02d]   = 0x" REGFORMAT, i,
 #if defined(__powerpc__) && !defined(__powerpc64__)
@@ -106,7 +106,7 @@ static void signal_segv(int signum, sigi
 ucontext->uc_mcontext.gregs[i]
 #endif
 );
-#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64, riscv */
+#endif /* alpha, ia64, kFreeBSD, arm, hppa, aarch64, riscv, loongarch */
 
 #if defined(SIGSEGV_STACK_X86) || defined(SIGSEGV_STACK_IA64)
 # if defined(SIGSEGV_STACK_IA64)

Bug#1051808: [Pkg-rust-maintainers] Bug#1051808: rust-users: RUSTSEC-2023-0059

[Peter Green]

rust-users is currently unmaintained upstream.

In a fork a proposed patch can be found.

What is the rust-users situation with respect of Debian as it is
unmantained upstream?


So we have two options, patch it or move away from it to a fork

The crate "uzers" which is a fork of this crate was recently
uploaded to Debian and I have just uploaded version 0.11.3 of
it. I believe that said version includes a fix for this issue.

Uzers is listed as an alternative on the rustsec entry, but at
least so-far there doesn't seem to have been a whole lot of uptake.
crates.io only lists one reverse dependency of said fork, which
is itself a fork of exa.

Bug#1051820: exa is unmaintained, should we migrate to eza?

[Peter Green]

Package: exa
Version: 0.10.1-4

It has come to my attention that exa is unmaintained, with the last
upstream release being over 2 years ago. However there is a fork
"eza" which does appear to be maintained. Should we be preparing
a transition to it?

Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[наб]

On Wed, Sep 13, 2023 at 12:00:51AM +0200, Alexandre Detiste wrote:
> I think that the risk that some user start by themselves moving around
> some programs
> around the PATH directories and expect nothing to break is quiet moot.
I don't. Users love putting stuff in /usr/local/{,s}bin. And then
removing it. That's kinda what it's there for. Not a huge ask to have
"@daily nodejs pee poo" behave correctly regardless of whether I
recently (un)installed upstream node (not a hypothetical scenario).

> And I'm pretty sure I/we already broke some scripts everywhere without
> caring  too much.
> I do was using boot_daily directly from /lib/systemd/ ;
> that broke when the scripts were moved to /usr/libexec:
> https://www.mail-archive.com/debian-devel@lists.debian.org/msg377086.html
> 
> This guy using mail_on_failure has certainly some .service to adapt now:
> https://bugs.launchpad.net/ubuntu/+source/systemd-cron/+bug/1583743
Don't use random undocumented internals challenge 2020
(difficulty degree: impossible).

> But on the other hand having this exact path of the launched program
> in the generated .service make it much easier to debug.
To debug when it inevitably breaks because it's hard-coded
instead of being behind a path lookup like was written ‒ certainly.

If only we could put a big banner somewhere with the full job
definition in systemd! Then we wouldn't need to resort to this aid; alas.

And this is moot anyway since we only inline single-word programs,
so we could only do this transformation for single-word programs.
I cannot imagine anything that would be affected if we do /that/,
since there aren't any programs that are useful when you run them with
no arguments from a crontab /and/ you're managing them like that.

I.e. prefix
  if(auto pgm = this->which(this->command[0]); pgm && *pgm != this->command[0]) 
{
with
  if(this->command.size() == 1)
and you get maximum optimisation and usefulness without
‒ realistically ‒ any of the oddities.

> >  IMO we should trim the whole function ... KSH_SHELLS
> The ~/ path expansion was requested and provided by wavexx
> and is a really nice feature and will stay.
Yes, leave /that/ in, and axe everything after that imo.
That's my idyllic take.

> > needless magic (like this)
> generators are mostly built on magic by design;
> if people would not want automagic solution
> they would had been writing .service / .timer pairs
> for ten years already.
They want to run the shell program they wrote where a >/dev/null is the
same as a>/dev/null is the same as a> /dev/null is the same as
a > /dev/null; is the same as a > /dev/null && : is the same as…

Just because it's driving a generator instead of a persistent daemon
doesn't make the configuration any less configurationy.

(This also means that a>/dev/null may mean four different things:
   '/bin/a>/dev/null'
   /bin/sh -c 'a>/dev/null'
   /bin/a
   /bin/sh -c 'a'
 but. y'know. No-one calls programs this.)


signature.asc
Description: PGP signature

Bug#1051757: libunwind8 doesn't support loongarch64

[Weihao Li]

On Tue, 12 Sep 2023 15:52:22 +0800 Weihao Li  wrote:

Package: libunwind8
Version: 1.7.0~rc2-1
Severity: wishlist
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainer,

The current version of libunwind8 source package already provides 
support for the loongarch64, can simply add loong64 in control file to 
build loongarch64 binary package, hope to add support in future debian 
version.


Thanks
Weihao Li





I forgot to add the patch in the previous email, add it now :)

Weihao Li
diff -Nru libunwind-1.7.0~rc2/debian/control libunwind-1.7.0~rc2/debian/control
--- libunwind-1.7.0~rc2/debian/control  2022-12-16 21:50:28.0 +
+++ libunwind-1.7.0~rc2/debian/control  2023-02-12 23:19:52.0 +
@@ -9,7 +9,7 @@
 
 Package: libunwind-dev
 Section: libdevel
-Architecture: amd64 arm64 armel armhf hppa i386 ia64 mips mips64 mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
+Architecture: amd64 arm64 armel armhf hppa i386 ia64 loong64 mips mips64 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
 Multi-Arch: same
 Depends: ${misc:Depends}, libunwind8 (= ${binary:Version}), liblzma-dev 

 Conflicts: libunwind1-dev, libunwind7-dev
@@ -27,7 +27,7 @@
  This package includes the development support files. 
 
 Package: libunwind8
-Architecture: amd64 arm64 armel armhf hppa i386 ia64 mips mips64 mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
+Architecture: amd64 arm64 armel armhf hppa i386 ia64 loong64 mips mips64 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -46,7 +46,7 @@
 
 Package: libunwind-setjmp0-dev
 Section: libdevel
-Architecture: amd64 arm64 armel armhf hppa i386 ia64 mips mips64 mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
+Architecture: amd64 arm64 armel armhf hppa i386 ia64 loong64 mips mips64 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
 Depends: ${misc:Depends}, libunwind-dev (= ${binary:Version}), 
libunwind-setjmp0 (= ${binary:Version})
 Description: libunwind-based non local goto - development
  The unwind-setjmp library offers a libunwind-based implementation of
@@ -58,7 +58,7 @@
  This package includes the development support files
 
 Package: libunwind-setjmp0
-Architecture: amd64 arm64 armel armhf hppa i386 ia64 mips mips64 mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
+Architecture: amd64 arm64 armel armhf hppa i386 ia64 loong64 mips mips64 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4
 Pre-Depends:  ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: libunwind-based non local goto - runtime

Bug#1051305: Request to Add 'loong64' to java-common's debian/java_defaults.mk

[panxuefeng]

Hi all,

I am very sorry for not replying in time.

I'm a member of loongson jdk. loong64 jdk related work will be followed 
by us (Loongson jdk team).


For the java-common package, we will incorporate your comments and make 
changes to it.


Thanks

On Wed, 6 Sep 2023 10:37:52 -0700 tony mancill wrote:

> Hi Meng Sang,
>
> On Wed, Sep 06, 2023 at 09:19:49AM +0800, 桑猛 wrote:
> > Source: java-common
> > X-Debbugs-Cc: sangm...@loongson.cn
> > Version: 0.74
> > Tags: patch
> > Severity: wishlist
> > Usertags: loongarch64
> > User: debian-de...@lists.debian.org
> >
> > I am writing to request a modification to the 
`java17_architectures` variable in the `debian/java_defaults.mk` file of 
the `java-common` package.

> >
> > Specifically, I would like to request the addition of the 'loong64' 
architecture to the `java17_architectures` variable.

>
> Since this impacts the openjdk packages, which are maintained by the
> OpenJDK Team (distinct from the Debian Java Team), I'll wait to hear
> from that team before uploading.
>
> However, I believe your patch may also need to add an entry to the
> jvm_archdir_map. [0] Is the mapping loong64=loong64?
>
> Cheers,
> tony
>
> [0] 
https://salsa.debian.org/java-team/java-common/-/blob/master/debian/java_defaults.mk#L35-39

Bug#1050688: poetry: needs internet access during build?

[Emmanuel Arias]

Hi,

I can confirm that the next 4 tests needs internet to work:

* tests/installation/test_installer.py::test_installer_with_pypi_repository
* tests/installation/test_chef.py::test_prepare_directory_editable
* tests/installation/test_chef.py::test_prepare_directory
* tests/installation/test_chef.py::test_prepare_directory_with_extensions

I will thank you if you can tell me how run in a not internet builder.
My solution was just disconnect my RJ-45 from the computer to test the
no internet because I didn't found a solution from autopkgtest or sbuild
:-D.

Cheers,
Emmanuel


signature.asc
Description: PGP signature

Bug#972192: Has been fixed upstream

[Peter Chubb]

Hi Folks,
This bug is now fixed upstream at
https://sourceforge.net/p/rkhunter/rkh_code/ci/efb203b5008a82798f564da32a589de82a7643e3/

Peter C

Bug#1051819: fluidsynth: Consider building with pipewire support

[Kevin Otte]

Package: fluidsynth
Version: 2.3.1-2
Severity: wishlist

Dear Maintainer,

Please consider building fluidsynth with pipewire support.
While it is working adequately via the pulseaudio compatibility layer,
it would be nice to utilize the native support added in 2.3.0 as it is
the default sound server in Debian 12.

It looks like all that is needed is a Build-Depends on libpipewire-0.3-dev
to have cmake pick up on it.

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

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

Versions of packages fluidsynth depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u1
ii  libfluidsynth3   2.3.1-2
ii  libglib2.0-0 2.74.6-2
ii  libsdl2-2.0-02.26.5+dfsg-1
ii  libsystemd0  252.12-1~deb12u1

Versions of packages fluidsynth recommends:
ii  qsynth  0.9.9-1

fluidsynth suggests no packages.

-- no debconf information

Bug#1051818: unbound: floods journal (100%CPU unbound, 100%CPU sd-journald) with errors when it can't reply to control socket peer

[наб]

Package: unbound
Version: 1.17.1-2
Version: 1.18.0-2
Severity: normal

Dear Maintainer,

-- >8 --
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, const char * const * argv) {
struct sockaddr_un unbound_ctl;
unbound_ctl.sun_family = AF_UNIX;
strncpy(unbound_ctl.sun_path, argv[1], sizeof(unbound_ctl.sun_path));

int local_datas = socket(AF_UNIX, SOCK_STREAM, 0);
connect(local_datas, _ctl, sizeof(unbound_ctl));
#define LOCAL_DATAS "UBCT1 local_datas\n"
write(local_datas, LOCAL_DATAS, sizeof(LOCAL_DATAS) - 1);
while(sendfile(local_datas, 0, 0, 128 * 1024 * 1024))
;
}
-- >8 --



-- >8 --
$ { printf '%s\n' 'UBCT1 local_datas' ';; a' 'abc.def. 3600 in txt testupa' ';; 
b'; } > badzone
$ cc badzone.c -o badzone.run
$ sudo ./badzone.run /run/unbound.ctl < badzone
-- >8 --
(if you run badzone.run under strace it doesn't reliably reproduce;
 attaching strace to unbound may also affect this).



This yields unbound pegging one CPU and sd-journald pegging the other.
strace capturing this attached.

The journal now consists of, exclusively
-- >8 --
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 tarta unbound[3955248]: [3955248:0] error: could not 
send: Broken pipe
2023-09-13T02:13:40+0200 

Bug#1051817: unbound: local_datas without \4\n reuses last read buffer(?) and produces infinite error output

[наб]

ss.zst
Description: application/zstd


signature.asc
Description: PGP signature

Bug#1051817: unbound: local_datas without \4\n reuses last read buffer(?) and produces infinite error output

[наб]

Package: unbound
Version: 1.17.1-2
Version: 1.18.0-2
Severity: normal

Dear Maintainer,

In trying to reduce another bug, I got the following:

$ { printf '%s\n' 'UBCT1 local_datas' ';; a' 'abc.def. 3600 in txt testupa' ';; 
b'; } | sudo socat - UNIX-CONNECT:/run/unbound.ctl
error parsing local-data at line 1 position 4 ';; a': Syntax error, could not 
parse the RR
error parsing local-data at line 3 position 4 ';; b': Syntax error, could not 
parse the RR
error parsing local-data at line 4 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 5 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 6 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 7 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 8 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 9 position 0 '': Syntax error, could not parse 
the RR
error parsing local-data at line 10 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 11 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 12 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 13 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 14 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 15 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 16 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 17 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 18 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 19 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 20 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 21 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 22 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 23 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 24 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 25 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 26 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 27 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 28 position 0 '': Syntax error, could not 
parse the RR
...
error parsing local-data at line 56466 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56467 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56468 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56469 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56470 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56471 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56472 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56473 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56474 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56475 position 0 '': Syntax error, could not 
parse the RR
error parsing local-data at line 56476 position 0 '': Syntax error, could not 
parse the RR
^C


strace -f capturing this moment attached.

Appending printf '\4\n';
(as stolen from strace unbound-control local_datas)
makes it work correctly.

Nevertheless, "probably dont do that", as they say.

Best,
наб


-- System Information:
Debian Release: 12.1
  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 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unbound depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libnghttp2-14  1.52.0-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libpython3.11  3.11.2-6
ii  libssl33.0.9-1
ii  libsystemd0252.12-1~deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages unbound 

Bug#1051811: pytorch-vision: Failing autopkgtests

[Jeremy Bícha]

On Tue, Sep 12, 2023 at 6:08 PM Petter Reinholdtsen  wrote:
> [Jeremy Bícha]
> > Autopkgtest failures currently prevent migration to Testing even when
> > the autopkgtests have never passed on an architecture.
>
> As far as I know, a test that never succeeded will not be considered a
> regression and will not block migration.
>
> https://tracker.debian.org/pkg/pytorch-vision > claim the failing
> ppc64el and s390x tests are regression.  Is this wrong?

If you click ppc64el (or any architecture) from that page, it shows
the test history. That test has only been run once on that
architecture and it failed.

Currently, Debian is set up to block migration even for this case.
That is why pytorch-vision has not migrated to Testing despite meeting
the 5 day wait.

Ubuntu's migration system does not block for an autopkgtest that never
succeeded but Debian's is stricter, perhaps to discourage autopkgtests
being run that never pass? Debian's autopkgtest system may have been
looser earlier but it has been this way for a while now.

Thank you,
Jeremy Bícha

Bug#1051816: libfreetype 2.12.1 (bookworm) should not claim COLRv1 support

[Ben Wagner]

Package: freetype
Version: 2.12.1+dfsg-5

This is a request to remove the very experimental COLRv1 support from
libfreetype 2.12.1. The easiest means of doing so would be to patch
the PUT_COLOR_LAYERS_V1 macro [0] like

- #define PUT_COLOR_LAYERS_V1( a ) PUT_COLOR_LAYERS( a )
+ #define PUT_COLOR_LAYERS_V1( a ) NULL

This will make the public COLRv1 related methods consistently return
failure instead of attempting to parse a format somewhat different
from the actual specification. Note that this only affects 2.12.1.
Versions earlier than 2.12.0 did not have this code, and versions
2.13.0 and later have full COLRv1 support.

Unfortunately, it appears that FreeType 2.12.1 shipped with COLRv1
support enabled. This was unintentional, the intention was to have it
disabled by default until it was ready [1] in 2.13.0. The issue with
the partial implementation in 2.12.1 isn't just that it is incomplete
(does not implement any of the required VAR paint types) but also that
it is incompatible in a number of ways. Applications which attempt to
use the API will get very surprising and wrong results. After taking a
look at what might be done to alleviate this issue it appears the best
course of action is to simply disable COLRv1 in 2.12.1.

[0] 
https://salsa.debian.org/debian/freetype/-/blob/17a35994acc3084014304b9c60d35017fa254270/src/sfnt/sfdriver.c#L1246

[1] 2692b3215be4f106b714974c55f4ab80da25189c [sfnt] Remove temporary
runtime flag for variable 'COLR' v1.

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Faidon Liambotis]

Control: reassign -1 rustc 1.68.2+dfsg1-1
Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)

On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:
> The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
> both testing and unstable's versions of wasmedge, and with both testing and
> unstable's versions of wasi-lib.

Thanks for the report. Actually, I think the WasmEdge autopkgtests are
catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries
that do not work with neither WasmEdge, nor Wasmtime (the latter is not
in Debian).

Very simple test case:

$ podman run --rm -it debian:sid  # or bookworm to test with rustc 1.67

root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32
[...]
root@ad697f1c195f:~# rustc -V
rustc 1.68.2
root@ad697f1c195f:~# cat > hello.rs 

Bug#1051811: pytorch-vision: Failing autopkgtests

[Petter Reinholdtsen]

[Jeremy Bícha]
> Autopkgtest failures currently prevent migration to Testing even when
> the autopkgtests have never passed on an architecture.

As far as I know, a test that never succeeded will not be considered a
regression and will not block migration.

https://tracker.debian.org/pkg/pytorch-vision > claim the failing
ppc64el and s390x tests are regression.  Is this wrong?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[Alexandre Detiste]

0) I d like to hear what our dear user(s) think about this matter
or more generally about systemd-cron before going further.

John:

 I see that you use a "cron-monthly-000loaddelay.timer",
 and I guess it's purpose from it's name;
 and this workflow may need to be tweaked;
 the /etc/cron.{hourly|daily|monthly}/ are not anymore
 run in sequence through a single run-parts invocation;
 but through individual .timer / .service pairs.

1) I mixed up "1" and "2" in my last sentence:
I still prefer not to gratuitously break
past assumptions without a clear gain.


I think that the risk that some user start by themselves moving around
some programs
around the PATH directories and expect nothing to break is quiet moot.


And I'm pretty sure I/we already broke some scripts everywhere without
caring  too much.
I do was using boot_daily directly from /lib/systemd/ ;
that broke when the scripts were moved to /usr/libexec:
https://www.mail-archive.com/debian-devel@lists.debian.org/msg377086.html

This guy using mail_on_failure has certainly some .service to adapt now:
https://bugs.launchpad.net/ubuntu/+source/systemd-cron/+bug/1583743


But on the other hand having this exact path of the launched program
in the generated .service make it much easier to debug.

> Concretely, we already killed stuff like this:
> in the C++ rewrite as "brittle damage" ‒
> https://github.com/systemd-cron/systemd-cron/pull/101#issuecomment-1673266966.

The comment was about the removed part.

>  IMO we should trim the whole function ... KSH_SHELLS
The ~/ path expansion was requested and provided by wavexx
and is a really nice feature and will stay.

> needless magic (like this)

generators are mostly built on magic by design;
if people would not want automagic solution
they would had been writing .service / .timer pairs
for ten years already.



I'd like to close this bug before 2.1.2-1 hit testing.

Waiting for other bugs to pop up in the short time window :-)

Cheers

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Peter Green]

Package: wasmedge
Version: 0.13.3+dfsg-1
Severity:serious

The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
both testing and unstable's versions of wasmedge, and with both testing and
unstable's versions of wasi-lib.

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37793933/log.gz

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37778163/log.gz

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wasmedge/37770138/log.gz



 93s autopkgtest [14:54:23]: test capi-wasi-env: [---
 93s 1..2
 94s ok 1 build wasi_get_env.wasm with cargo/rustc
 94s not ok 2 build set_wasm_env with gcc
 94s # (in test file debian/tests/capi-wasi-env, line 24)
 94s #   `assert_output --partial "ENV1: VAL1"' failed
 94s #
 94s # -- output does not contain substring --
 94s # substring (1 lines):
 94s #   ENV1: VAL1
 94s # output (4 lines):
 94s #   [2023-09-12 14:54:24.910] [error] execution failed: unreachable, Code: 
0x89
 94s #   [2023-09-12 14:54:24.910] [error] In instruction: unreachable 
(0x00) , Bytecode offset: 0x9efb
 94s #   [2023-09-12 14:54:24.910] [error] When executing function name: 
"print_env"
 94s #   Execution Failed. Error message: unreachable
 94s # --
 94s #
 95s autopkgtest [14:54:25]: test capi-wasi-env: ---]
 95s autopkgtest [14:54:25]: test capi-wasi-env:  - - - - - - - - - - results - 
- - - - - - - - -
 95s capi-wasi-envFAIL non-zero exit status 1

Bug#1046800: texinfo: Fails to build source after successful build

[Preuße]

On 13.08.2023 21:21, Lucas Nussbaum wrote:

Hello,


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




dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/texinfo_7.0.3-2.diff.Y5YdBX
dpkg-source: info: Hint: make sure the version in debian/changelog matches the 
unpacked source tree
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2



I could address the issue partially by adding some files/dirs to 
d/clean, but some files are modified and must not be removed, else the 
build fails.


H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051814: neutron-vpnaas-dashboard: Fix unit test failures for Django 4.x

[Corey Bryant]

Package: neutron-vpnaas-dashboard
Version: Fix unit test failures for Django 4.x
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/fix-test-failures-with-Django-4.x.patch: Fix unit tests
that are failing with Django 4.2.4.


Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
neutron-vpnaas-dashboard-8.0.0/debian/patches/fix-test-failures-with-Django-4.x.patch
 
neutron-vpnaas-dashboard-8.0.0/debian/patches/fix-test-failures-with-Django-4.x.patch
--- 
neutron-vpnaas-dashboard-8.0.0/debian/patches/fix-test-failures-with-Django-4.x.patch
   1969-12-31 18:00:00.0 -0600
+++ 
neutron-vpnaas-dashboard-8.0.0/debian/patches/fix-test-failures-with-Django-4.x.patch
   2023-09-12 17:18:27.0 -0400
@@ -0,0 +1,72 @@
+From 9c46ffe619fe948363d0d8b1a533ae7214e65c60 Mon Sep 17 00:00:00 2001
+From: Corey Bryant 
+Date: Tue, 12 Sep 2023 17:13:51 -0400
+Subject: [PATCH] Fix unit test failures for Django 4.x
+
+These tests have started failing with Django 4.2.4 due to
+comparison of objects with strings. This change just compares
+the repr(object) with the existing strings.
+
+Closes-Bug: #2034952
+Change-Id: Ifce3ab76a659931a6753d4fa796ea2164f9accd8
+---
+ .../dashboards/project/vpn/tests.py   | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/neutron_vpnaas_dashboard/dashboards/project/vpn/tests.py 
b/neutron_vpnaas_dashboard/dashboards/project/vpn/tests.py
+index 9ba235e..b169a5a 100644
+--- a/neutron_vpnaas_dashboard/dashboards/project/vpn/tests.py
 b/neutron_vpnaas_dashboard/dashboards/project/vpn/tests.py
+@@ -255,7 +255,8 @@ class VPNTests(test.TestCase):
+ self.assertEqual(workflow.name, workflows.AddVPNService.name)
+ 
+ expected_objs = ['', ]
+-self.assertQuerysetEqual(workflow.steps, expected_objs)
++actual_objs = [repr(step) for step in workflow.steps]
++self.assertQuerysetEqual(actual_objs, expected_objs)
+ 
+ self.mock_network_list_for_tenant.assert_called_once_with(
+ helpers.IsHttpRequest(), self.tenant.id)
+@@ -331,7 +332,8 @@ class VPNTests(test.TestCase):
+ self.assertEqual(workflow.name, workflows.AddEndpointGroup.name)
+ 
+ expected_objs = ['', ]
+-self.assertQuerysetEqual(workflow.steps, expected_objs)
++actual_objs = [repr(step) for step in workflow.steps]
++self.assertQuerysetEqual(actual_objs, expected_objs)
+ self.mock_network_list_for_tenant.assert_called_once_with(
+ helpers.IsHttpRequest(), self.tenant.id)
+ 
+@@ -389,7 +391,8 @@ class VPNTests(test.TestCase):
+ self.assertEqual(workflow.name, workflows.AddIKEPolicy.name)
+ 
+ expected_objs = ['', ]
+-self.assertQuerysetEqual(workflow.steps, expected_objs)
++actual_objs = [repr(step) for step in workflow.steps]
++self.assertQuerysetEqual(actual_objs, expected_objs)
+ 
+ @helpers.create_mocks({api_vpn: ('ikepolicy_create', )})
+ def test_add_ikepolicy_post(self):
+@@ -448,7 +451,8 @@ class VPNTests(test.TestCase):
+ self.assertEqual(workflow.name, workflows.AddIPsecPolicy.name)
+ 
+ expected_objs = ['', ]
+-self.assertQuerysetEqual(workflow.steps, expected_objs)
++actual_objs = [repr(step) for step in workflow.steps]
++self.assertQuerysetEqual(actual_objs, expected_objs)
+ 
+ @helpers.create_mocks({api_vpn: ('ipsecpolicy_create', )})
+ def test_add_ipsecpolicy_post(self):
+@@ -525,7 +529,8 @@ class VPNTests(test.TestCase):
+  'addipsecsiteconnectionaction>',
+  '', ]
+-self.assertQuerysetEqual(workflow.steps, expected_objs)
++actual_objs = [repr(step) for step in workflow.steps]
++self.assertQuerysetEqual(actual_objs, expected_objs)
+ 
+ self.mock_ikepolicy_list.assert_called_once_with(
+ helpers.IsHttpRequest(),
+-- 
+2.34.1
+
diff -Nru neutron-vpnaas-dashboard-8.0.0/debian/patches/series 
neutron-vpnaas-dashboard-8.0.0/debian/patches/series
--- neutron-vpnaas-dashboard-8.0.0/debian/patches/series2023-06-19 
10:42:42.0 -0400
+++ neutron-vpnaas-dashboard-8.0.0/debian/patches/series2023-09-12 
17:18:33.0 -0400
@@ -1 +1,2 @@
 

Bug#1051813: MIA: updating the uploaders bug is way too old

[Ben Tris]

Package: qa.debian.org
Severity: important
X-Debbugs-Cc: benatt...@gezapig.nl, debian-l10n-de...@lists.alioth.debian.org, 
m...@qa.debian.org

Dear Maintainer,

The dl10n sorce package has two bug reports one from mia team and one from the
uploader.
Christian Perrier request for removal is from april 2018. #847531
The mia request for removal is from april 2019. #927663
Eitherway, it's already more than 4 years ago.
I wonder if someone would reconsider if knowing this. (that is why made this
important)

Bug#1050766: natpmp_declspec.h missing?

[Antti Järvinen]

Dear libnatpmp-dev maintainer,

please check out https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050766
where classified-ads fails to build due to missing natpmp_declspec.h
with version 20230423-1 of libnatpmp-dev. I don't see any package
providing the missing file natpmp_declspec.h, is there any hope?

--
Antti, having package not compiling

Bug#1051812: RFP: vosk-api -- Offline speech recognition API

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: vosk-api
  Version : 0.3.45
  Upstream Contact: Alpha Cephei 
* URL : https://alphacephei.com/vosk/
* License : Apache-2.0
  Programming Lang: Jupyter, C++, Python, Java, ...
  Description : Offline speech recognition API

Vosk is an offline open source speech recognition toolkit. It enables
speech recognition for 20+ languages and dialects - English, Indian
English, German, French, Spanish, Portuguese, Chinese, Russian,
Turkish, Vietnamese, Italian, Dutch, Catalan, Arabic, Greek, Farsi,
Filipino, Ukrainian, Kazakh, Swedish, Japanese, Esperanto, Hindi,
Czech, Polish.

Vosk models are small (50 Mb) but provide continuous large vocabulary
transcription, zero-latency response with streaming API,
reconfigurable vocabulary and speaker identification.

Speech recognition bindings implemented for various programming
languages like Python, Java, Node.JS, C#, C++, Rust, Go and others.

Vosk supplies speech recognition for chatbots, smart home appliances,
virtual assistants. It can also create subtitles for movies,
transcription for lectures and interviews.

Vosk scales from small devices like Raspberry Pi or Android smartphone
to big clusters.



Debian has been shipping speech recognition software for a
while, mostly in the form of Sphinx, which is... well, it's not as
good as one would imagine those things to be.

Historically, such programs used to be extremely inaccurate and
largely in the realm of sci-fi and play things, but recent advances in
machine learning have shown tremendous progress in this area, which
makes it possible make use of (free!) software to enable voice-driven
applications of all sorts.

vosk is an API layer that can be used by other programs to implement
such solutions, and I think it would be a great addition to Debian.

The models are small and all free although the licenses vary:

https://alphacephei.com/vosk/models

Also, it could be possible to just package the API bits without
shipping the models in Debian, which of course would be less useful,
but more useful than nothing.

I'm not exactly sure what our policy is on models, actually: the
license of the models above is "free" in the sense that you can get
the binary and do what you want with it, but i'm not sure it would
pass the smell test of "wait, but where's the training data" kind of
stuff. I leave that to people more familiar with those sticky issues
and focus this RFP on the software side of things.

Also bewarned that I'm only peripherally familiar with ML and current
developments in AI.  I mostly fell (again) on vosk because of Numen:

https://numenvoice.org/

There are other models out there, that might be better targets. For
example,  "is a tensor library for machine learning
to enable large models and high performance on commodity hardware. It
is used by llama.cpp and whisper.cpp". But the latter two are on
relatively shakier legal grounds, as far as Debian is concerned.

There's also Mozilla's , "an
open source embedded (offline, on-device) speech-to-text engine which
can run in real time on devices ranging from a Raspberry Pi 4 to high
power GPU servers."

And there's a whole area of "home assistants" that have their own way
of doing things. This is just one of them, and I would be happy to
hear what's the best solution for this problem space.

Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[наб]

Control: tag -1 + confirmed upstream

On Tue, Sep 12, 2023 at 10:11:58PM +0200, Alexandre Detiste wrote:
> In v1.x the trailing "> /dev/null" was purposely chopped of the end of the 
> line
> because there wasn't an OnSucces= handler anyway and the goal
> was to further parse the bash-one liner.
> 
> Some of the brittle bash-parsing has already been dropped of from 2.x.
Concretely, we already killed stuff like this:
if (len(self.command) == 6 and
self.command[0] == '[' and
self.command[1] in ['-x','-f','-e'] and
self.command[2] == self.command[5] and
self.command[3] == ']' and
self.command[4] == '&&' ):
self.testremoved = self.command[2]
self.command = self.command[5:]

if (len(self.command) == 5 and
self.command[0] == 'test' and
self.command[1] in ['-x','-f','-e'] and
self.command[2] == self.command[4] and
self.command[3] == '&&' ):
self.testremoved = self.command[2]
self.command = self.command[4:]
in the C++ rewrite as "brittle damage" ‒
https://github.com/systemd-cron/systemd-cron/pull/101#issuecomment-1673266966.

The only substitutions left in decode_command() that do explicit damage
to the line are
if(auto pgm = this->which(this->command[0]); pgm && *pgm != 
this->command[0]) {
if(!this->command.command0)
++this->command.command.b;
this->command.command0 = std::move(pgm);
}
which dereferences the first word so we can avoid going through
/bin/sh copied-line.sh for single-word lines
(which, I've just realised, breaks when stuff lands in/is removed from,
 say /usr/local/bin, and systemd isn't reloaded ‒ imagine
   cp /bin/id /usr/local/bin
   systemd daemon-reload
   rm /usr/local/bin/id
 ‒ and now a "@daily id" job no longer works!
   since it tries executing /usr/local/bin/id!;
 IMO we should trim the whole function before
   if(!std::binary_search(std::begin(KSH_SHELLS), std::end(KSH_SHELLS), 
vore::basename(this->shell)))
 and axe KSH_SHELLS, and always generate a scriptlet)
and
if(this->command.size() > 2 && this->command.command.e[-2] == 
">"sv && this->command.command.e[-1] == "/dev/null"sv)
this->command.command.e -= 2;
if(this->command.size() > 1 && this->command.command.e[-1] == 
">/dev/null"sv)
this->command.command.e -= 1;
which you're seeing.

> We can either [1] remove the code that chop of the /dev/null
I agree. This had, maybe, potentially, some minute degree of merit
before we did normal cron-style mail.

Now that we behave like cron, it's just knowing-better-than-the-user.

> or [2] isolate it to only run when CRON_MAIL_SUCCESS=never
> (a setting that allow users to revert to the previous behaviour).
The user has all the controls to configure this precisely as they need now,
this is clearly confusing, since it goes against the explicit and overt
user configuration.

> I personally prefer "1" because of my own past habits
Agree, just kill it.

> even if "2" will look cleaner from a new point of view..
I don't think it is, really. Respect what the user wrote,
don't do needless magic (like this), and users will be happy.

Maybe add a changelog note that
"Fix: sd-cron-g no longer damages the line by stripping >[ ]/dev/null".


signature.asc
Description: PGP signature

Bug#1051577: iproute2: obsolete conffiles

[Luca Boccassi]

On Mon, 11 Sept 2023 at 15:57, Daniel Gröber  wrote:
>
> Hi Luca,
>
> On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > I want to question whether removing these conffiles is a good idea at
> > > all. I'm probably one of the few people that actually muck around in there
> > > but it seems like this is going to break things for any users that do.
> >
> > As far as I understand dpkg's conffile machinery should recognize if
> > you changed anything, and leave it in place. Upstream moved the
> > default ones to /usr, so we just follow what they do.
>
> Right. Think of an admin having to adjust these config files though:
> previously they could just `editor /etc/iproute2/rt_tables` and get on with
> things. Now anyone needing to do that will have to do a doubletake, figure
> out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2
> now, copy that over and finally edit.
>
> Is that friction really warrented to cater to a specialized niche use-case?
>
> Please consider overriding upstream's decision here.

Yes, it is warranted, both because it's exactly the correct behaviour
for a package, and also because we are certainly not spending time and
resources to go against upstream choices, especially when they are the
right choices.

Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream sources, and split the fonts according to upstream

[Amr Ibrahim]

 Ursprüngliche Nachricht 
Von: fab...@greffrath.com
An: Amr Ibrahim 
Kopie: 1041...@bugs.debian.org
Betreff: Re: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream
sources, and split the fonts according to upstream
Datum: 12.09.2023 14:23:19


Hi Fabian,

> the fonts appear to be organized into different subdirectories with 
> varying content.

True. If you go to https://notofonts.github.io/ and look at any font, you'll see
that there is a "Source repository" selection, which opens the font's source on
GitHub.

For example, Noto Arabic  has its source at
, and so on.


> Do you know upstream's stance on this? Is hinted/ttf always preferable 
> over unhinted/* and what's the matter with the fonts in googlefonts/*? 
> And how about the unhinted/variable-ttf, unhinted/slim-variable-ttf and 
> unhinted/otf variants?

Sorry, I don't have answers to that.


> They offer a snapshow of the entire repository for download in the 
> Releases section:
> 
> https://github.com/notofonts/notofonts.github.io/releases
> 
> These could be downloaded, have the undesired fonts stripped off, get 
> repacked and split up into individual Debian packages.

Or the individual fonts can be packaged from their own sources, which I
mentioned above. Whichever the Debian maintainer finds more practical.


Best,
Amr

Bug#1051577: iproute2: obsolete conffiles

[Luca Boccassi]

Control: severity -1 serious

(stop migration until I have time to further fix it)

On Mon, 11 Sept 2023 at 15:56, Bastian Blank  wrote:
>
> On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > As far as I understand dpkg's conffile machinery should recognize if
> > you changed anything, and leave it in place. Upstream moved the
> > default ones to /usr, so we just follow what they do.
>
> Actually using rm_conffile is wrong.  This moves the file to
> *.dpkg-bak.  However the expected behaviour is to keep them around
> without renaming, just removed from the dpkg database.

I see - I will do that next week, as I am travelling this week, so
bumping severity to stop migration

Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date

[Russ Allbery]

Guillem Jover  writes:

> How about the attached patch, based on the text in deb-substvars(5)?

This looks great, thank you.  Seconded.

> From 024d94daeb0ab0e7c447868a1b8f9ff953850404 Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Tue, 12 Sep 2023 22:47:27 +0200
> Subject: [PATCH] Update Installed-Size algorithm used by dpkg since 1.18.0

> The previous algorithm relied entirely on du(1) computing the used
> size, but depended on the filesystem in use on the build system.

> The new algorithm used by dpkg since 1.18.0 (implemented in
> commit 9ed7d4d47b73ffe67e1f7d31f899a1dfd43d490b), guarantees a
> constant and reproducible size regardless of the build system
> filesystem being used. Although it is still an approximation of
> the actual size that the package will use on the installed system.

> Closes: #793499
> ---
>  policy/ch-controlfields.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 45776ea..2871658 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -939,8 +939,9 @@ space required to install the named package. Actual 
> installed size may
>  vary based on block size, file system properties, or actions taken by
>  package maintainer scripts.
>  
> -The disk space is given as the integer value of the estimated installed
> -size in bytes, divided by 1024 and rounded up.
> +The disk space is given as the accumulated size of each regular file and
> +symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other
> +filesystem object type.
>  
>  .. _s-f-Files:

-- 
Russ Allbery (r...@debian.org)  

Bug#1051719: markdown-mode.el produces excessive warnings

[Nicholas D Steeves]

Control: tag -1 upstream

Thanks for reporting!

Daniel Kahn Gillmor  writes:

> I get a lot of warnings from markdown-mode when i launch emacs.  the
> buffer contains the following:
[snip]
> I'm using emacs 1:29.1+1-5 with emacsen-common 3.0.5.
>
> This is well over 50% of all the warnings that are announced by emacs
> for the set of elpa packages i have installed.
>
> Looks to me like most or all of these warnings should be cleaned up,
> which would make it easier to see meaningful/substantive warnings if
> they do appear.

Agreed!  Are you interested in forwarding this bug upstream to
https://jblevins.org/projects/markdown-mode, or would you prefer to wait
for someone else to do so?  The reason this is important is because
Emacs29 compatibility affects more than just Debian users, so the fix
shouldn't be limited to just us.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date

[Guillem Jover]

Hi!

On Fri, 2015-07-24 at 18:04:41 +0200, Guillem Jover wrote:
> Package: debian-policy
> Version: 3.9.7.0
> Severity: wishlist

> As discussed in the debian-policy list, the Installed-Size algorithm
> as implemented in dpkg-gencontrol changed due to #650077. So the
> current wording is out-of-sync. Please see the thread starting at
> ,
> with the current implementation
> .

How about the attached patch, based on the text in deb-substvars(5)?

Thanks,
Guillem
From 024d94daeb0ab0e7c447868a1b8f9ff953850404 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 12 Sep 2023 22:47:27 +0200
Subject: [PATCH] Update Installed-Size algorithm used by dpkg since 1.18.0

The previous algorithm relied entirely on du(1) computing the used
size, but depended on the filesystem in use on the build system.

The new algorithm used by dpkg since 1.18.0 (implemented in
commit 9ed7d4d47b73ffe67e1f7d31f899a1dfd43d490b), guarantees a
constant and reproducible size regardless of the build system
filesystem being used. Although it is still an approximation of
the actual size that the package will use on the installed system.

Closes: #793499
---
 policy/ch-controlfields.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 45776ea..2871658 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -939,8 +939,9 @@ space required to install the named package. Actual installed size may
 vary based on block size, file system properties, or actions taken by
 package maintainer scripts.
 
-The disk space is given as the integer value of the estimated installed
-size in bytes, divided by 1024 and rounded up.
+The disk space is given as the accumulated size of each regular file and
+symlink rounded to 1 KiB used units, and a baseline of 1 KiB for any other
+filesystem object type.
 
 .. _s-f-Files:
 
-- 
2.40.1

Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream sources, and split the fonts according to upstream

[Amr Ibrahim]

 Ursprüngliche Nachricht 
Von: Jonas Smedegaard 
Antwort an: Jonas Smedegaard , 1041...@bugs.debian.org
An: 1041...@bugs.debian.org
Betreff: Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new
upstream sources, and split the fonts according to upstream
Datum: 12.09.2023 15:07:43


Hi Jonas,

> The URI you point at is confusing, however: Upstream use git both to
> track _sources_ for the Noto fonts and as a means to _distribute_
> precompiled fonts - and notofonts.github.io is (mainly, at least) about
> the latter.

Yes, it's kind of confusing.


> The change needed is not only to shift to a different source location,
> but also to change to actually compile the fonts from source, not only
> redistribute precompiled font files as has been done until now.

True. If you go to https://notofonts.github.io/ and look at any font, you'll see
that there is a "Source repository" selection, which opens the font's source on
GitHub.

For example, Noto Arabic  has its source at
, and so on.


> That is a different issue.  Please report issues individually, not
> bundled, as it is much easier to merge if issues turns out to be too
> similar than to split a bundled of issues being discussed together.

> Regarding this issue specifically, don't bother, however: It is a
> duplicate of an ancient issue already solved since quite some time - see
> bug#805021 or the source package fonts-noto-cjk.

Sorry, my mistake. noto-cjk has already been packaged separately at
, and now pointing to the new
upstream location on GitHub.


Best,
Amr

Bug#1051355: 117.0.5938.62 released as stable version

[Leandro Cunha]

Hi,

The version 117.0.5938.62 released for Linux, Mac and Windows and include
16 CVEs fixes.

https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_12.html

https://developer.chrome.com/blog/new-in-chrome-117

>

Bug#1051811: pytorch-vision: Failing autopkgtests

[Jeremy Bícha]

Source: pytorch-vision
Version: 0.15.2-1
Severity: serious

pytorch-vision added autopkgtests in version 0.15.2-1. However, the
autopkgtests are failing on ppc64el and s390x. Autopkgtest failures
currently prevent migration to Testing even when the autopkgtests have
never passed on an architecture.

Thank you,
Jeremy Bícha

Bug#1051763: dpkg: Please backport support for loong64 to oldstable and stable

[Guillem Jover]

Tags: fixed -1 1.21.21

On Tue, 2023-09-12 at 12:05:47 +0200, John Paul Adrian Glaubitz wrote:
> Source: dpkg
> Version: 1.21.22
> Severity: normal
> User: debian-de...@lists.debian.org
> Usertags: loong64
> X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn

> In order to be able to add loong64-specific changes to source packages,
> the dpkg version on the infrastructure servers, in particular DAK,
> needs to be able to recognize loong64 in d/control.

> Since the servers are running oldstable and stable and loong64 support
> was only added to dpkg 1.22.0,

This was introduced in dpkg 1.21.10, reverted in 1.21.19 and reintroduced
in 1.21.21, but that was after the 1.22.x series had already been branched
(so it got cherry picked from git main at the time, and that's why it
looked like it got introduced only in 1.22.0).

> I would like to ask for loong64 to be backported to the dpkg version
> in oldstable and stable.

I guess I could backport it to dpkg 1.20.x for oldstable, but if the
infra servers are going to be upgraded soon (at least out of oldstable
to stable), then perhaps there's no point in bothering the release-team
with this?

Thanks,
Guillem

Bug#1051810: base-passwd: Unused w3m build dependency

[Gioele Barabucci]

Package: src:base-passwd
Version: 3.6.2
Tags: patch

Dear base-passwd maintainers,

`w3m` is listed as a build dependency for base-passwd but it does not 
seem to be used at all during the build process.


A MR that fixes this issue is available at:

https://salsa.debian.org/debian/base-passwd/-/merge_requests/14

Regards,

--
Gioele Barabucci

Bug#1051809: base-passwd: Support for build profile

[Gioele Barabucci]

Package: src:base-passwd
Version: 3.6.2
Tags: patch

Dear base-passwd maintainers,

`docbook` and `docbook-tools` are kept as build dependencies even when 
the  build profile is used.


A MR that fixes this issue is available at:

https://salsa.debian.org/debian/base-passwd/-/merge_requests/14

Regards,

--
Gioele Barabucci

Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[Alexandre Detiste]

Control: tag -1 +confirmed

Hi,

I confirm your problem.

In v1.x the trailing "> /dev/null" was purposely chopped of the end of the line
because there wasn't an OnSucces= handler anyway and the goal
was to further parse the bash-one liner.

Some of the brittle bash-parsing has already been dropped of from 2.x.

We can either [1] remove the code that chop of the /dev/null
or [2] isolate it to only run when CRON_MAIL_SUCCESS=never
(a setting that allow users to revert to the previous behaviour).

I personally prefer "1" because of my own past habits
even if "2" will look cleaner from a new point of view..




--- a/src/bin/systemd-crontab-generator.cpp
+++ b/src/bin/systemd-crontab-generator.cpp
@@ -497,6 +497,9 @@ struct Job {
this->command.command0 = std::move(pgm);
}

+   if(this->cron_mail_success != cron_mail_success_t::never)
+   return;
if(this->command.size() > 2 &&
this->command.command.e[-2] == ">"sv && this->command.command.e[-1] ==
"/dev/null"sv)
this->command.command.e -= 2;
if(this->command.size() > 1 &&
this->command.command.e[-1] == ">/dev/null"sv)

Le mar. 12 sept. 2023 à 21:12, John Flinchbaugh
 a écrit :
> Dear Maintainer,
>
> I can put a simple command with a redirect to a file or /dev/null, and
> systemd-cron continues to email the output of the command. See the
> following excerpt from the email, which shows the command I'm running:

> 2023-09-12T18:44:00+ nucleus.hjsoft.com systemd[1]: Starting 
> cron-john-john-3.service - [Cron] "* * * * *   ls -la > /dev/null"...
>
> I would have not expected to see the output in email.
>
> Work-around:
> I can get the redirect to work, if I change the cron entry to:
> 
> * * * * *   bash -lc "ls -la > /dev/null"

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

[Nicholas D Steeves]

Control: tag -1 = upstream fixed-upstream

Max Nikulin  writes:

Hi Max, thank you for investigating this, and thank you for the links
confirming it was fixed :)

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

So 9.6.10 or possibly 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.

> \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).

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1051744: linux-image-6.1.0-12-amd64: DVB unable to load module dvb_usb_mxl111sf

[Salvatore Bonaccorso]

Control: forcemerge 1051613 -1

Hi,

On Mon, Sep 11, 2023 at 09:45:33PM -0700, Steve VanDevender wrote:
> Package: src:linux
> Version: 6.1.52-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> As of linux-image-6.1.0-12, I can no longer use my Hauppage WinTV-Aero-M as
> one of its necessary kernel modules (lgdt3305) now fails to load.
> 
> 2023-09-11T19:35:12.938596-07:00 glitch kernel: [39125.513119] usb 1-1.2: new 
> hi
> gh-speed USB device number 4 using ehci-pci
> 2023-09-11T19:35:13.046533-07:00 glitch kernel: [39125.622902] usb 1-1.2: New 
> US
> B device found, idVendor=2040, idProduct=c61b, bcdDevice= 0.00
> 2023-09-11T19:35:13.046551-07:00 glitch kernel: [39125.622915] usb 1-1.2: New 
> US
> B device strings: Mfr=1, Product=2, SerialNumber=3
> 2023-09-11T19:35:13.046554-07:00 glitch kernel: [39125.622919] usb 1-1.2: 
> Produc
> t: WinTV Aero-M
> 2023-09-11T19:35:13.046555-07:00 glitch kernel: [39125.622922] usb 1-1.2: 
> Manufa
> cturer: Hauppauge
> 2023-09-11T19:35:13.046556-07:00 glitch kernel: [39125.622925] usb 1-1.2: 
> Serial
> Number: 4034988989
> 2023-09-11T19:35:14.198544-07:00 glitch kernel: [39126.776720] usb 1-1.2: 
> dvb_us
> b_v2: found a 'Hauppauge WinTV-Aero-M' in warm state
> 2023-09-11T19:35:14.198566-07:00 glitch kernel: [39126.776775] usb 1-1.2: 
> dvb_usb_v2: will pass the complete MPEG2 transport stream to the software 
> demuxer
> 2023-09-11T19:35:14.198569-07:00 glitch kernel: [39126.776847] dvbdev: DVB: 
> registering new adapter (Hauppauge WinTV-Aero-M)
> 2023-09-11T19:35:14.198571-07:00 glitch kernel: [39126.776853] usb 1-1.2: 
> media controller created
> 2023-09-11T19:35:14.200945-07:00 glitch kernel: [39126.777182] dvbdev: 
> dvb_create_media_entity: media entity 'dvb-demux' registered.
> 2023-09-11T19:35:14.478543-07:00 glitch kernel: [39127.053919] failing 
> symbol_get of non-GPLONLY symbol lgdt3305_attach.
> 2023-09-11T19:35:14.478563-07:00 glitch kernel: [39127.053925] DVB: Unable to 
> find symbol lgdt3305_attach()
> 2023-09-11T19:35:14.478566-07:00 glitch kernel: [39127.054502] 
> dvb_usb_mxl111sf: probe of 1-1.2:1.0 failed with error -5
> 2023-09-11T19:35:14.478567-07:00 glitch kernel: [39127.054527] usbcore: 
> registered new interface driver dvb_usb_mxl111sf
> 
> In 6.1.0-11 and earlier, it would successfully load like this:
> 
> 2023-09-03T20:56:46.678283-07:00 glitch kernel: [698673.786292] usb 1-1.2: 
> new h
> igh-speed USB device number 22 using ehci-pci
> 2023-09-03T20:56:46.786379-07:00 glitch kernel: [698673.896208] usb 1-1.2: 
> New U
> SB device found, idVendor=2040, idProduct=c61b, bcdDevice= 0.00
> 2023-09-03T20:56:46.786406-07:00 glitch kernel: [698673.896215] usb 1-1.2: 
> New U
> SB device strings: Mfr=1, Product=2, SerialNumber=3
> 2023-09-03T20:56:46.786408-07:00 glitch kernel: [698673.896217] usb 1-1.2: 
> Produ
> ct: WinTV Aero-M
> 2023-09-03T20:56:46.786410-07:00 glitch kernel: [698673.896218] usb 1-1.2: 
> Manufacturer: Hauppauge
> 2023-09-03T20:56:46.786411-07:00 glitch kernel: [698673.896219] usb 1-1.2: 
> SerialNumber: 4034988989
> 2023-09-03T20:56:46.786412-07:00 glitch kernel: [698673.896755] usb 1-1.2: 
> dvb_usb_v2: found a 'Hauppauge WinTV-Aero-M' in warm state
> 2023-09-03T20:56:46.786413-07:00 glitch kernel: [698673.896791] usb 1-1.2: 
> dvb_usb_v2: will pass the complete MPEG2 transport stream to the software 
> demuxer
> 2023-09-03T20:56:46.786417-07:00 glitch kernel: [698673.896844] dvbdev: DVB: 
> registering new adapter (Hauppauge WinTV-Aero-M)
> 2023-09-03T20:56:46.786418-07:00 glitch kernel: [698673.896847] usb 1-1.2: 
> media controller created
> 2023-09-03T20:56:46.786419-07:00 glitch kernel: [698673.897142] dvbdev: 
> dvb_create_media_entity: media entity 'dvb-demux' registered.
> 2023-09-03T20:56:47.425649-07:00 glitch kernel: [698674.536902] MxL111SF 
> detected, v8_200 (0x18)
> 2023-09-03T20:56:47.425666-07:00 glitch kernel: [698674.536929] usb 1-1.2: 
> DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3305 VSB/QAM 
> Frontend)...
> 2023-09-03T20:56:47.425668-07:00 glitch kernel: [698674.536953] dvbdev: 
> dvb_create_media_entity: media entity 'LG Electronics LGDT3305 VSB/QAM 
> Frontend' registered.
> 2023-09-03T20:56:47.425669-07:00 glitch kernel: [698674.537087] usb 1-1.2: 
> DVB: registering adapter 0 frontend 1 (MaxLinear MxL111SF DVB-T 
> demodulator)...
> 2023-09-03T20:56:47.425669-07:00 glitch kernel: [698674.537099] dvbdev: 
> dvb_create_media_entity: media entity 'MaxLinear MxL111SF DVB-T demodulator' 
> registered.
> 2023-09-03T20:56:47.425670-07:00 glitch kernel: [698674.537175] usb 1-1.2: 
> DVB: registering adapter 0 frontend 2 (LG Electronics LG2161 ATSC/MH 
> Frontend)...
> 2023-09-03T20:56:47.425671-07:00 glitch kernel: [698674.537184] dvbdev: 
> dvb_create_media_entity: media entity 'LG Electronics LG2161 ATSC/MH 
> Frontend' registered.
> 2023-09-03T20:56:47.474216-07:00 glitch kernel: [698674.583615] tveeprom: 
> Hauppauge model 126001, rev F2G4, serial# 4034988989
> 

Bug#567033: Decide if we should continue recommending /usr/games

[Josh Triplett]

On Mon, Sep 11, 2023 at 07:11:30PM +0100, Simon McVittie wrote:
> Games are often written for performance more than correctness, and
> frequently do non-ideal things or have unfixed security issues. If we
> separate them into /usr/games and avoid putting that directory in root's
> PATH, then tab completion mistakes can't result in root accidentally
> running a game.
> 
> Similarly, I think (although I have no evidence) it's more common to
> install non-free games, and non-free game managers like Steam, than
> non-free utility/application software. If we put those in /usr/games, the
> root can't accidentally run those as a result of a tab-completion mistake.

Doing this by PATH alone seems of relatively limited value in a world in
which:
- Many (possibly *most*) users don't typically *log in* as root
  directly, and use something like sudo to explicitly run things as root
  instead, outside of recovery scenarios. And it seems fairly unlikely
  to explicitly "sudo somegame".
- Many non-text-based games may be launched from a GUI. And the
  text-based games seem unlikely to have massive unfixed security
  issues that arise just from *invocation*.
- On the average single-user system, most of the value is in the user's
  data *in their account*, and if something had a security issue
  allowing remote access, it'd likely be trivial to escalate to root
  anyway by any number of means, since that user ultimately has root
  access. If we have games with unfixed security issues, those need
  fixing (or sandboxing) *anyway* and putting them in /usr/games doesn't
  seem like a substantive mitigation.

Bug#1051808: rust-users: RUSTSEC-2023-0059

[Salvatore Bonaccorso]

Source: rust-users
Version: 0.11.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ogham/rust-users/issues/55
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

There is the RUSTSEC-2023-0059 advisory for rust-users:
https://rustsec.org/advisories/RUSTSEC-2023-0059.html
https://github.com/ogham/rust-users/issues/55

rust-users is currently unmaintained upstream.

In a fork a proposed patch can be found.

What is the rust-users situation with respect of Debian as it is
unmantained upstream?

Regards,
Salvatore

Bug#1051807: openjdk-17-jre: system look defaults to non-native Metal theme, GTK theme isn't enabled by default

[Gregor Riepl]

Package: openjdk-17-jre
Version: 17.0.9~4ea-1
Severity: normal
X-Debbugs-Cc: onit...@gmail.com

The OpenJDK version in Debian includes the GTK+ theme, but the
SystemLookAndFeelClassName is set to the default Swing Metal theme.
Manually loading the GTK+ theme works, but this is very unportable and
shouldn't be necessary.

Instead, the following code should use the native GTK+ theme:

import java.awt.*;
import javax.swing.*;
public class Test {
public static void main(String[] args) {
try {
System.out.println("System look class: " +
UIManager.getSystemLookAndFeelClassName());
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
// This shouldn't be necessary:
//
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
} catch (Exception e) {
System.err.println("Can't find native look: " + e);
}
JFrame frame = new JFrame();
frame.getContentPane().setLayout(new FlowLayout());
frame.setSize(new Dimension(200, 200));
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().add(new JButton("Button 1"));
frame.getContentPane().add(new JButton("Button 2"));
frame.getContentPane().add(new JButton("Button 3"));
frame.setVisible(true);
}
}

Is this by design, or would it be possible to change the system theme to the
native one?
Metal doesn't really fit well with most modern desktops, and the GTK+ theme
would at least make Java applications match the system GTK theme.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable'), (300, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 openjdk-17-jre depends on:
ii  libc62.37-7
ii  libgif7  5.2.1-2.5
ii  libgl1   1.6.0-1
ii  libglib2.0-0 2.77.3-1
ii  libgtk-3-0   3.24.38-4
ii  libgtk2.0-0  2.24.33-2
ii  libharfbuzz0b8.0.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libpng16-16  1.6.40-1
ii  libx11-6 2:1.8.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  libxtst6 2:1.2.3-1.1
ii  openjdk-17-jre-headless  17.0.9~4ea-1
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages openjdk-17-jre recommends:
ii  fonts-dejavu-extra   2.37-8
ii  libatk-wrapper-java-jni  0.40.0-3

openjdk-17-jre suggests no packages.

-- no debconf information

Bug#1051806: RFP: hyprland-protocols -- Wayland protocol extensions for Hyprland.

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+swa...@tracker.debian.org, werdah...@riseup.net
Control: block 1040971 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: hyprland-protocols
  Version : 0.2
  Upstream Contact: vaxerski 
* URL : https://github.com/hyprwm/hyprland-protocols
* License : BSD-3-Clause
  Programming Lang: n/a, xml files
  Description : Wayland protocol extensions for Hyprland.

I'd appreciate it if someone could package those wayland extensions.
They are embedded as a submodule in the hyprland source.
My packaging (sans gbp) is here [0]; feel free to use it. I do not
have time to maintain unfortunately it as I already maintain a lot of other 
packages.

best,

werdahias

[0] https://salsa.debian.org/werdahias/hyprland-protocols

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmUAuzIVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1+nQP/jceSUHvaspmWhOFTImAHO8+LcMb
MpdRHd8ZQ5b4yTm8RXPOvA/LVL1RFtv8+M8F966/O+1bOfJfismkgYyYG2SL+bVf
/P30aGmAyZhiuzZ0lvUgM73xOjvaXpmwwbC49TA+tNIdEBrIqHeuerbSG/m1fpQb
LbCT9jlHghYMjQ2MdGDS4y3SNI1+YpcStXBRh0i24j3O0+sDvBgclDjqx8SMfPmt
Zwm5lfnsty2osPg54/kloV3z0JP/mpnF5bKJY8zbA9KvC0Cm+MeOmeOrAREftGEI
8xuPRz1gQAIAg1gAnbnXm6lYUOWdv5yVjMujEMbFD//PlTcRLW7PU8oUJUTlDyvG
yf8DSmrM3CFL25r4qBTVB+jUIB1UX2szPdR8AHdzpA3dSr+8GVGmfyJtFc5/anDV
cUtp9p2Q75k3kNq8IdwzRij4z/d39aG//C38Lj8H/S3o3Ln+MVNFRI8uTP/ibHHl
MvyrrLcgmU2DVm/OXVj9R+wqoTopWboz+OWtKK4PVxNS1lA2icVM9ylxc6rZbG7j
B9+MlMd4AYmtfMuEz/cTnmvnyU5Q2hJB2iK3S1sZkWs0D7FRxZy2jaWydS906SZQ
nzFjQGlChMtkvvSaNwyWR/L1Q2QSS/aSV6K2KH0TlR6VGhgOSVBcZOOW+vFl8wQc
pfUMhzZ+vOf4NDdg
=Q7fr
-END PGP SIGNATURE-

Bug#1051724: zbar: CVE-2023-40889 CVE-2023-40890

[Boyuan Yang]

Control: forwarded -1 https://github.com/mchehab/zbar/issues/263

On Mon, 11 Sep 2023 21:15:17 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
 wrote:
> Source: zbar
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for zbar.
> 
> CVE-2023-40889[0]:
> | A heap-based buffer overflow exists in the qr_reader_match_centers
> | function of ZBar 0.23.90. Specially crafted QR codes may lead to
> | information disclosure and/or arbitrary code execution. To trigger
> | this vulnerability, an attacker can digitally input the malicious QR
> | code, or prepare it to be physically scanned by the vulnerable
> | scanner.
> 
> https://hackmd.io/@cspl/B1ZkFZv23
> 
> CVE-2023-40890[1]:
> | A stack-based buffer overflow vulnerability exists in the
> | lookup_sequence function of ZBar 0.23.90. Specially crafted QR codes
> | may lead to information disclosure and/or arbitrary code execution.
> | To trigger this vulnerability, an attacker can digitally input the
> | malicious QR code, or prepare it to be physically scanned by the
> | vulnerable scanner.
> 
> https://hackmd.io/@cspl/H1PxPAUnn
> 
> It is unclear if these were reported upstream, could you please sync
> up with them?

Upstream bug report marked in the Forwarded: field.

 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2023-40889
> https://www.cve.org/CVERecord?id=CVE-2023-40889
> [1] https://security-tracker.debian.org/tracker/CVE-2023-40890
> https://www.cve.org/CVERecord?id=CVE-2023-40890
> 
> Please adjust the affected versions in the BTS as needed.

Currently it is unclear about all the affected versions, so I will
leave this part as-is for now.

Thanks,
Boyuan Yang


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

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Salvatore Bonaccorso]

Hi Timo,

On Tue, Sep 12, 2023 at 01:39:59PM +0200, Timo Sigurdsson wrote:
> Hi Pablo,
> 
> Pablo Neira Ayuso schrieb am 12.09.2023 00:57 (GMT +02:00):
> 
> > Hi Timo,
> > 
> > On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
> >> Hi,
> >> 
> >> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
> >> which broke nftables ruleset loading on one of my machines with lots
> >> of "Operation not supported" errors. I've reported this to the
> >> Debian project (see link below) and Salvatore Bonaccorso and I
> >> identified "netfilter: nf_tables: disallow rule addition to bound
> >> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
> >> that introduced the regression. Salvatore also found that this issue
> >> affects the 5.10 stable tree as well (observed in 5.10.191), but he
> >> cannot reproduce it on 6.4.13 and 6.5.2.
> >> 
> >> The issue only occurs with some rulesets. While I can't trigger it
> >> with simple/minimal rulesets that I use on some machines, it does
> >> occur with a more complex ruleset that has been in use for months
> >> (if not years, for large parts of it). I'm attaching a somewhat
> >> stripped down version of the ruleset from the machine I originally
> >> observed this issue on. It's still not a small or simple ruleset,
> >> but I'll try to reduce it further when I have more time.
> >> 
> >> The error messages shown when trying to load the ruleset don't seem
> >> to be helpful. Just two simple examples: Just to give two simple
> >> examples from the log when nftables fails to start:
> >> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not
> >> supported
> >> tcp option maxseg size 1-500 counter drop
> >> ^
> >> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not
> >> supported
> >> tcp dport sip-tls accept
> >> 
> > 
> > I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
> > this is not reproducible with v1.0.7 and v1.0.8.
> > 
> >> Since the issue only affects some stable trees, Salvatore thought it
> >> might be an incomplete backport that causes this.
> >> 
> >> If you need further information, please let me know.
> > 
> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> > kernel check that rejects adding rules to bound chains. The incorrect
> > bytecode adds the chain binding, attach it to the rule and it adds the
> > rules to the chain binding. I have cherry-picked these three patches
> > for nftables v1.0.6 userspace and your ruleset restores fine.
> 
> hmm, that doesn't explain why Salvatore didn't observe this with
> more recent kernels.
> 
> Salvatore, did you use newer userspace components when you tested
> your 6.4.13 and 6.5.2 builds?

It does explain now because understanding the issue better. While one
while experinting should only change each one constraint for the
6.4.13 and 6.5.2 testing I indeed switched to a Debian unstable
system, which has newer userpace nftables and so not triggering the
issue. This was missleading for the report.

> As for the regression and how it be dealt with: Personally, I don't
> really care whether the regression is solved in the kernel or
> userspace. If everybody agrees that this is the best or only viable
> option and Debian decides to push a nftables update to fix this,
> that works for me. But I do feel the burden to justify this should
> be high. A kernel change that leaves users without a working packet
> filter after upgrading their machines is serious, if you ask me. And
> since it affects several stable/longterm trees, I would assume this
> will hit other stable (non-rolling) distributions as well, since
> they will also use older userspace components (unless this is
> behavior specific to nftables 1.0.6 but not older versions). They
> probably should get a heads up then.

So if it is generally believed on kernel side there should not happen
any further changes to work with older userland, I guess in Debian we
will need to patch nftables. I'm CC'ing Arturo Borrero Gonzalez
, maintainer for the package. The update should go
ideally in the next point releases from October (and maybe released
earlier as well trough the stable-updates mechanism).

FWIW: In Debian bullseye we have 0.9.8 based nftables, in bookworm
1.0.6, so both will need those fixes.

As 0ebc1064e487 is to address CVE-2023-4147 other distros picking the
fix will likely encounter the problem at some point. It looks Red Hat
has taken it (some RHSA's were released), I assume Ubuntu will shortly
as well release USN's containing a fix.

Regards,
Salvatore

Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[John Flinchbaugh]

Package: systemd-cron
Version: 2.1.2-1
Severity: normal

Dear Maintainer,

I can put a simple command with a redirect to a file or /dev/null, and
systemd-cron continues to email the output of the command. See the
following excerpt from the email, which shows the command I'm running:

Process: 3729378 ExecStart=/bin/sh 
/run/systemd/generator/cron-john-john-3.sh (code=exited, status=0/SUCCESS)
   Main PID: 3729378 (code=exited, status=0/SUCCESS)
CPU: 28ms
2023-09-12T18:44:00+ nucleus.hjsoft.com systemd[1]: Starting 
cron-john-john-3.service - [Cron] "* * * * *   ls -la > /dev/null"...
2023-09-12T18:44:00+ nucleus.hjsoft.com sh[3729380]: total 80
2023-09-12T18:44:00+ nucleus.hjsoft.com sh[3729380]: drwxr-xr-x  18 root 
root  4096 Aug 31 16:21 .
2023-09-12T18:44:00+ nucleus.hjsoft.com sh[3729380]: drwxr-xr-x  18 root 
root  4096 Aug 31 16:21 ..
2023-09-12T18:44:00+ nucleus.hjsoft.com sh[3729380]: lrwxrwxrwx   1 root 
root 7 Oct  5  2022 bin -> usr/bin
2023-09-12T18:44:00+ nucleus.hjsoft.com sh[3729380]: drwxr-xr-x   2 root 
root  4096 Aug 30  2011 boot


I would have not expected to see the output in email.

Work-around:
I can get the redirect to work, if I change the cron entry to:

* * * * *   bash -lc "ls -la > /dev/null"



-- Package-specific info:
-- output of systemctl list-timers
NEXT  LEFT LAST   PASSED 
UNIT   ACTIVATES
Tue 2023-09-12 18:50:35   95ms ago Tue 2023-09-12 18:37:28 13min ago 
apt-listbugs.timer apt-listbugs.service
Tue 2023-09-12 18:51:0024s Tue 2023-09-12 18:50:00   34s ago 
cron-john-john-1.timer cron-john-john-1.service
Tue 2023-09-12 18:51:0024s Tue 2023-09-12 18:50:00   34s ago 
cron-john-john-3.timer cron-john-john-3.service
Tue 2023-09-12 19:00:00   9min -   - 
cron-sendmail-smmsp-0.timercron-sendmail-smmsp-0.service
Tue 2023-09-12 19:00:00   9min -   - 
cron-tiger-root-0.timercron-tiger-root-0.service
Tue 2023-09-12 19:02:00  11min -   - 
cron-logcheck-logcheck-0.timer cron-logcheck-logcheck-0.service
Tue 2023-09-12 19:49:00  58min Tue 2023-09-12 18:49:00  1min 34s ago 
cron-debsecan-daemon-0.timer   cron-debsecan-daemon-0.service
Wed 2023-09-13 00:00:005h 9min -   - 
cron-john-john-2.timer cron-john-john-2.service
Wed 2023-09-13 00:00:005h 9min Tue 2023-09-12 00:00:00   18h ago 
logrotate.timerlogrotate.service
Wed 2023-09-13 01:14:21 6h Tue 2023-09-12 03:39:18   15h ago 
plocate-updatedb.timer plocate-updatedb.service
Wed 2023-09-13 02:32:06 7h Tue 2023-09-12 13:52:16  4h 58min ago 
apt-daily.timerapt-daily.service
Wed 2023-09-13 04:00:00 9h -   - 
cron-backup-root-0.timer   cron-backup-root-0.service
Wed 2023-09-13 05:05:0010h -   - 
cron-john-john-0.timer cron-john-john-0.service
Wed 2023-09-13 05:06:0310h Tue 2023-09-12 05:06:03   13h ago 
systemd-tmpfiles-clean.timer   systemd-tmpfiles-clean.service
Wed 2023-09-13 05:21:0410h Tue 2023-09-12 05:21:04   13h ago 
chkrootkit.timer   chkrootkit.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-aptitude.timer  cron-daily-aptitude.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-checksecurity.timer cron-daily-checksecurity.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-cleanup_mqueue.timercron-daily-cleanup_mqueue.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-find.timer  cron-daily-find.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-locate.timercron-daily-locate.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-makewhatiscron.timercron-daily-makewhatiscron.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-rpm.timer   cron-daily-rpm.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-sendmail.timer  cron-daily-sendmail.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-slocate.timer   cron-daily-slocate.service
Wed 2023-09-13 06:10:0011h Tue 2023-09-12 06:10:00 - 
cron-daily-tripwire.timer  cron-daily-tripwire.service
Wed 2023-09-13 06:30:34  

Bug#1051804: aom: Autopkgtest regression on s390x with aom v3.7.0

[Boyuan Yang]

Source: aom
Version: 3.7.0-1~exp1
Severity: serious
Forwarded: https://bugs.chromium.org/p/aomedia/issues/detail?id=3487

Current aom 3.7.0 will raise autopkgtest regression on s390x. The following
commands will raise an error:

ffmpeg -y -f lavfi -i testsrc=duration=1:size=320x240:rate=30 -pix_fmt 
yuv420p input.y4m
aomenc -o encoded.webm input.y4m
aomdec -o decoded.yuv encoded.webm

the error output of aomdec is as follows:

Warning: Failed to decode frame 1: Corrupt frame detected
Warning: Additional information: Invalid intrabc dv

It is believed to be some endian handling error in the source code, and
the bug is forwarded upstream pending investigation.

Thanks,
Boyuan Yang


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

Bug#1051801: document DEB_BUILD_OPTIONS value nopgo

[Russ Allbery]

Helmut Grohne  writes:

> more and more packages implement a technique called profile guided
> optimization. The general idea is that it performs a build that is
> instrumented for profiling first. It then runs a reasonable workload to
> collect profiling data, which in turn is used to guide the optimizer of
> a second build which is not thus instrumented. The idea is that this
> second build probably is faster than a regular build.

> Quite obviously this approach completely breaks cross building. It also
> is unclear how it affects reproducible builds since such builds depend
> on the performance characteristics of the system performing the build.
> This makes it very obvious that the pgo technique has downsides that
> warrant disabling it in some situations.

> A number of packages have agreed on disabling such optimization when
> DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages:
>  * binutils
>  * cross-toolchain-base
>  * gcc-VER
>  * halide
>  * pythonVER

> I'll also be filing a patch for foot to support this option.

> Is this sufficient coverage to document the option already?

Yes, I think that's plenty.  I would love to have Policy be a bit more
proactive about documenting things like this.

> Proposed wording:

> This tag requests that any optimization performed during the build
> should not rely on performance characteristics captured during the
> build. Such optimization is usually called profile guided
> optimization.

Could you specifically mention cross-building (and possibly reproducible
builds) as an example of why someone may want to set this option?  I think
having those sorts of explanations add a lot of value to Policy, since
they help explain to the reader how Debian is designed beyond just a
mechanical set of instructions.

If you have a chance, feel free to send a proposed diff to add this to the
DEB_BUILD_OPTIONS section.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051803: ITS: freespace2

[Sébastien Noel]

Source: freespace2
Version: 3.7.4+repack-1.1 
Severity: important
X-Debbugs-CC: pkg-games-de...@lists.alioth.debian.org

Dear maintainer,

After looking at your freespace2 package [1], I found that this package
received no maintainer updates in the past 5 years and was not in good
shape. It has a FTBFS bug [2] and it was removed from testing
6 months ago.
As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan to maintain the package under the umbrella of the
Debian Games Team, to package the latest upstream release, clean up
packaging and review/fix all Debian bug reports.
A MR has already been posted to Salsa [3]

Full disclosure: I will need a sponsor to upload the package in the
archive.

Please let me know whether you are still willing to maintain this
package. If you find it necessary to pause the ITS process,
please let me know immediately by replying this bug report.

[1] https://tracker.debian.org/pkg/freespace2
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012232
[3] https://salsa.debian.org/onlyjob/freespace2/-/merge_requests/1

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Bill Allombert]

On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote:
> To take an example that I've been trying to get rid of for over a decade,
> many of the /usr/share/common-licenses/BSD references currently in the
> archive are incorrect.  There are a few cases where the code is literally
> copyrighted only by the Regents of the University of California and uses
> exactly that license text, but this is not the case for a lot of them.  It
> looks like a few people have even tried to say "use common-licenses but
> change the name in the license" rather than reproducing the license text,
> which I don't believe meets the terms of the license (although it's of
> course very unlikely that anyone would sue over it).

Note that my proposal makes detecting the discrepancy more visible rather
than less, since you can compare the generated copyright file with
the actual license statement without chasing files.

Also, overengineering aside, the copyright generator could support 
parameter substitution to accomodate small discrepancies in license.
For example an option to replace in /usr/share/common-licenses/BSD the
line 
"Copyright (c) The Regents of the University of California."
by whatever is required when generating DEBIAN/copyright.

Cheers,
Bill

Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal

[Simon McVittie]

Control: tags -1 + patch fixed-upstream

On Mon, 11 Sep 2023 at 15:12:42 +0100, Simon McVittie wrote:
> On Fri, 08 Sep 2023 at 11:22:30 +0100, Simon McVittie wrote:
> > I can suggest a patch, but I don't use XFCE myself, so I don't know what
> > XFCE users or developers would want.
> 
> I'm hoping that the upstream issue will lead to a clearer picture of how
> the XFCE team see this working in future, and maybe a patch that can
> easily be backported.

They've applied a MR for 4.18.4 adding the simplest version of
xfce-portals.conf that I previously suggested:
https://gitlab.xfce.org/xfce/xfce4-session/-/merge_requests/47

smcv

Bug#1009815: debmutate.watch: Use perl-compatible regular expressions

[Michael R. Crusoe]

On Tue, 23 Aug 2022 17:55:38 +0200 Bastian Germann  wrote:
> On Mon, 18 Apr 2022 15:22:27 + Jelmer Vernooij 
 wrote:
> > debmutate.watch currently uses Python's default re module, which 
supports a

> > slightly different syntax.
> >
> > We should ideally switch to the pcre module.
>
> I see that you have packaged and switched to that module. It would 
have been nicer to package the pcre2 module because
> pcre introduced one more dependency on pcre3 which should be phased 
out one day. There is already a mass bug filing and

> transition tracker for that.

I packaged a pcre2 python module and it is in the NEW queue: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051798


Here is a commit that uses that package with fixes for the new library 
to close this issue and avoid demutate being removed from testing: 
https://salsa.debian.org/crusoe/debmutate/-/commit/d55d327c2dd5dd9d225bff665b56959ca9019b59


--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051802: RM: python3-typed-ast -- ROM; Upstream end-of-life, replaced by "ast" standard library in Python 3.8+

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python3-typed-...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:python3-typed-ast

Archival notice: https://pypi.org/project/typed-ast/

> The ast module of Python 3.8+ supports all features of typed_ast. 
typed_ast does not support parsing code that uses syntax introduced in 
Python 3.8 onwards. We recommend using ast on Python 3.8 or above.


--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051801: document DEB_BUILD_OPTIONS value nopgo

[Helmut Grohne]

Package: debian-policy
Version: 4.6.2.0
Severity: wishlist
X-Debbugs-Cc: 
debian-cr...@lists.debian.org,rb-gene...@lists.reproducible-builds.org

Hi,

more and more packages implement a technique called profile guided
optimization. The general idea is that it performs a build that is
instrumented for profiling first. It then runs a reasonable workload to
collect profiling data, which in turn is used to guide the optimizer of
a second build which is not thus instrumented. The idea is that this
second build probably is faster than a regular build.

Quite obviously this approach completely breaks cross building. It also
is unclear how it affects reproducible builds since such builds depend
on the performance characteristics of the system performing the build.
This makes it very obvious that the pgo technique has downsides that
warrant disabling it in some situations.

A number of packages have agreed on disabling such optimization when
DEB_BUILD_OPTIONS contains nopgo. I'm aware of the following packages:
 * binutils
 * cross-toolchain-base
 * gcc-VER
 * halide
 * pythonVER

I'll also be filing a patch for foot to support this option.

Is this sufficient coverage to document the option already? If not, this
bug report can serve as a central point for discussing it and its
adoption.

Proposed wording:

This tag requests that any optimization performed during the build
should not rely on performance characteristics captured during the
build. Such optimization is usually called profile guided
optimization.

The proposed tag intentionally is fairly narrow. It does not cover link
time optimization. It also does not cover the case where profiling
information is recorded ahead of upload and included in the source
package[1]. In both cases, neither cross building nor reproducibility is
impacted.

As for cross builds, it is not clear to me where we want to put the
responsibility to disable pgo. At the time of this writing, most
packages automatically disable pgo when performing a cross build. On the
flip side, we could have any cross builder set nopgo like they set
nocheck already. Doing so would allow performing a pgo-enabled cross
build to i386 on amd64 while still benefiting from the larger address
space for instance. I consider this aspect to be a separate matter
though.

Helmut

[1] 
https://lists.reproducible-builds.org/pipermail/rb-general/2022-June/002638.html

Bug#1051800: foot FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: foot
Version: 1.15.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

foot fails to cross build from source, because it builds for the build
architecture. Looking closer, the reason is that it doesn't use
dh_auto_configure. It cannot, because it does a pgo build. pgo means
running a first build and using the profile to optimize a second build,
but that "run" part is what we totally cannot do at all for cross
builds. So this becomes pgo vs cross.

I propose supporting the value "nopgo" in DEB_BUILD_OPTIONS. This is not
passed by buildds and therefore regular builds of foot will continue to
be pgo. When cross building or adding nopgo to DEB_BUILD_OPTIONS, the
build will degrade to a normal non-pgo build.

Note that foot also is unreproducible according to
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/foot.html
and I strongly suspect that adding nopgo would make it reproducible.

I am not asking to disable pgo by default.

Helmut
diff --minimal -Nru foot-1.15.3/debian/changelog foot-1.15.3/debian/changelog
--- foot-1.15.3/debian/changelog2023-08-15 09:34:04.0 +0200
+++ foot-1.15.3/debian/changelog2023-09-11 08:53:12.0 +0200
@@ -1,3 +1,11 @@
+foot (1.15.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Support DEB_BUILD_OPTIONS=nopgo and enable it for cross.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Sep 2023 08:53:12 +0200
+
 foot (1.15.3-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru foot-1.15.3/debian/rules foot-1.15.3/debian/rules
--- foot-1.15.3/debian/rules2023-08-15 09:34:04.0 +0200
+++ foot-1.15.3/debian/rules2023-09-11 08:53:10.0 +0200
@@ -3,17 +3,29 @@
 # optimize=-lto because the pgo script handles lto by itself
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
 
-# According to upstream's INSTALL.md, -O2 with PGO can create issues
-export DEB_CFLAGS_MAINT_STRIP = -O2
-
 %:
dh $@ --builddir=build
 
+ifneq (,$(filter nopgo,$(DEB_BUILD_OPTIONS)))
+DISABLE_PGO=1
+endif
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+DISABLE_PGO=1
+endif
+
+ifneq (1,$(DISABLE_PGO))
+# According to upstream's INSTALL.md, -O2 with PGO can create issues
+export DEB_CFLAGS_MAINT_STRIP = -O2
+
 # meson setup is run by ./pgo/pgo.sh
 override_dh_auto_configure:
 
 override_dh_auto_build:
./pgo/pgo.sh partial . build --prefix=/usr --wrap-mode=nodownload
+else:
+override_dh_auto_configure:
+   dh_auto_configure -- --wrap-mode=nodownload
+endif
 
 execute_after_dh_auto_install:
rm debian/tmp/usr/share/doc/foot/LICENSE

Bug#1050180: freeradius 3.2.1+dfsg-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1050180 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: freeradius
Version: 3.2.1+dfsg-4+deb12u1

Explanation: ensure TLS-Client-Cert-Common-Name contains correct data

Bug#699001: elpa-notmuch should depend on notmuch

[David Bremner]

Benjamin Moody  writes:

> Package: elpa-notmuch
> Version: 0.31.4-2
> Followup-For: Bug #699001
>
> Dear Maintainer,
>
> The notmuch-emacs package has been replaced with elpa-notmuch.
> However, this bug still seems relevant; M-x notmuch doesn't work if
> notmuch isn't installed.  elpa-notmuch should at least have a
> "Recommends: notmuch", or more likely a "Depends".
>
> I have no idea whether the version coupling issue is still relevant.

Recommends seems reasonable to me. Depends is too strong because it is
possible (and more or less sensible) to use elpa-notmuch without a local
notmuch install.

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Jonas Smedegaard  writes:

> Strictly speaking it is not (as I was more narrowly focusing on) that
> the current debian/copyright spec leaves room for *ambiguity*, but
> instead that there is a real risk of making mistakes when replacing with
> centrally defined ones (e.g. redefining a local "Expat" from locally
> meaning "MIT-ish legalese as stated in this project" to falsely mean
> "the MIT-ish legalese that SPDX labels MIT").

Right, the existing copyright format defines a few standard labels and
says that you should only use those labels when the license text matches,
but it doesn't stress that "matches" means absolutely word-for-word
identical.  I suspect, although I haven't checked, that we've made at
least a few mistakes where some license text that's basically equivalent
to Expat is labelled as Expat even though the text is not word-for-word
identical.  Given that currently all labels in debian/copyright are
essentially local and the full text is there (except for common-licenses,
where apart from BSD the licenses normally are used verbatim), this is not
currently really a bug.  But we could turn it into a bug quite quickly if
we relied on the license short name to look up the text.

To take an example that I've been trying to get rid of for over a decade,
many of the /usr/share/common-licenses/BSD references currently in the
archive are incorrect.  There are a few cases where the code is literally
copyrighted only by the Regents of the University of California and uses
exactly that license text, but this is not the case for a lot of them.  It
looks like a few people have even tried to say "use common-licenses but
change the name in the license" rather than reproducing the license text,
which I don't believe meets the terms of the license (although it's of
course very unlikely that anyone would sue over it).

A quick code search turns up the following examples, all of which I
believe are wrong:

https://sources.debian.org/src/mrpt/1:2.10.0+ds-3/doc/man-pages/pod/simul-beacons.pod/?hl=35#L35
https://sources.debian.org/src/gridengine/8.1.9+dfsg-11/debian/scripts/init_cluster/?hl=7#L7
https://sources.debian.org/src/rust-hyphenation/0.7.1-1/debian/copyright/?hl=278#L278
https://sources.debian.org/src/nim/1.6.14-1/debian/copyright/?hl=64#L64
https://sources.debian.org/src/yade/2023.02a-2/debian/copyright/?hl=78#L78

An example of one that probably is okay, although ideally we still
wouldn't do this because there are other copyrights in the source:

https://sources.debian.org/src/lpr/1:2008.05.17.3+nmu1/debian/copyright/?hl=15#L15

This problem potentially would happen a lot with the BSD licenses, since
the copyright-format document points to SPDX and SPDX, since it only cares
about labeling legally-equivalent documents, allows the license text to
vary around things like the name of the person you're not supposed to say
endorsed your software while still receiving the same label.

We therefore cannot use solely SPDX as a way of determining whether we can
substitute the text of the license automatically for people, because there
are SPDX labels for a lot of licenses for which we'd need to copy and
paste the exact license text because it varies.  At least if I understand
what our goals would be.

(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1051799: Please remove the homepage and vcs field. Or remove this package completely!!!

[Ben Tris]

Source: mhddfs
Version: 0.1.39+nmu2
Severity: important
X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org

Dear Maintainer,

The Russian site asks to login if you select english. The vcs link prompts
directly to login and you get stuc.
I think currently would like to see this package be removed from debbian
completely.


-- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Jamie Heilman]

Funny, I had this problem (unbootable system, couldn't find net.mod
even though it was there ls on the grub_rescue prompt didn't see it)
with a XFS V4 partition, and rebuilding that as V5 and copying
everything over seemed to have fixed it... but maybe I just got lucky
on the first try.  Interestingly, once I've got grub actually able to
load normal.mod it doesn't seem to have problems finding any files on
the V4 partition.  For the sake of comparison here's are the full
details of the two (lvm) volumes in question:

The partition that initially broke w/2.12~rc1-9:

# xfs_db -r /dev/mapper/S-root
xfs_db> version
versionnum [0xb4b4+0xa] = 
V4,NLINK,DIRV2,ATTR,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT

# xfs_info /dev/mapper/S-root
meta-data=/dev/mapper/S-root isize=256agcount=4, agsize=524288 blks
 =   sectsz=512   attr=2, projid32bit=0
 =   crc=0finobt=0, sparse=0, rmapbt=0
 =   reflink=0bigtime=0 inobtcount=0 nrext64=0
data =   bsize=4096   blocks=2097152, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0, ftype=0
log  =internal log   bsize=4096   blocks=2560, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


And the partition that seems to be working OK (but maybe it's just
luck?):

# xfs_db -r /dev/mapper/S-root23
xfs_db> version
versionnum [0xb4a5+0x18a] = 
V5,NLINK,DIRV2,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT,CRC,FTYPE,FINOBT,SPARSE_INODES,REFLINK,INOBTCNT,BIGTIME

# xfs_info /dev/mapper/S-root23
meta-data=/dev/mapper/S-root23   isize=512agcount=4, agsize=524288 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=1, sparse=1, rmapbt=0
 =   reflink=1bigtime=1 inobtcount=1 nrext64=0
data =   bsize=4096   blocks=2097152, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0, ftype=1
log  =internal log   bsize=4096   blocks=16384, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


Do we know if the breakage related to bigtime feature?


-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs

[Gregor Riepl]

Package: podman
Version: 4.5.1+ds1-2
Followup-For: Bug #1050993
X-Debbugs-Cc: onit...@gmail.com
Control: found -1

Thanks for upgrading the package, but it looks like the issue isn't fixed in
4.5 after all.

After upgrading and removing /etc/containers/storage.conf (to revert to default
behavior), I'm now facing the following error:

ERRO[] User-selected graph driver "vfs" overwritten by graph driver
"overlay" from database - delete libpod local files
("/home/user/.local/share/containers/storage") to resolve.  May prevent use of
images created by other tools

This indicates that the vfs driver was autoselected, despite overlay being
available.

In fact, if I explicitly run podman with the option "--storage-driver overlay",
it works fine.


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

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

Versions of packages podman depends on:
ii  conmon   2.1.6+ds1-1
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.37-7
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  libsqlite3-0 3.43.0-1
ii  libsubid41:4.13+dfsg1-1+b1
ii  runc 1.1.5+ds1-1+b2

Versions of packages podman recommends:
ii  buildah1.30.0+ds1-3
ii  dbus-user-session  1.14.10-1
ii  slirp4netns1.2.0-1
ii  tini   0.19.0-1
ii  uidmap 1:4.13+dfsg1-1+b1

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  
ii  fuse-overlayfs  1.10-1
ii  iptables1.8.9-2

-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: 
'/etc/cni/net.d/87-podman-bridge.conflist'

-- no debconf information

Bug#1051798: ITP: python-pcre2 -- Python bindings for the PCRE2 regular expression library

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: python-pcre2 -- Python bindings for the PCRE2 regular 
expression library

Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name : python-pcre2
Version : 0.2.0+ds
Upstream Author : grtetrault
* URL : https://github.com/grtetrault/pcre2.py
* License : BSD-3-clause
Programming Lang: Python
Description : Python bindings for the PCRE2 regular expression library
This package contains Python bindings for PCRE2. PCRE2 is the revised 
API for
the Perl-compatible regular expressions (PCRE) library created by Philip 
Hazel.

.
For original source code, see the official PCRE2 repository:
https://github.com/PCRE2Project/pcre2

Upstream publishes to https://pypi.org/project/pcre2/ and has made 
recent releases.


--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#792854: [pkg-dhcp-devel] Bug#792854: isc-dhcp-client: Dhclient fails to set hostname

[Daniele Palumbo]

The patch from #604883 does not help.

The current logic is clear (dhclient-script file):
# current host name is empty, '(none)' or 'localhost' or differs from 
new one from DHCP
if [ -z "$current_hostname" ] ||
   [ "$current_hostname" = '(none)' ] ||
   [ "$current_hostname" = 'localhost' ] ||
   [ "$current_hostname" == "$old_host_name" ]; then
   if [ "$new_host_name" != "$current_host_name" ]; then
   hostname "$new_host_name"
   fi

according to bug #667647 and the script:
- old_host_name is the hostname sent by the client to the DHCP server
- current_hostname is the current return value of hostname(1)
- new_host_name is the proposed hostname from DHCP (option 12)

The new hostname is set if one of that conditions are true:
- current_hostname is not set
- current_hostname is "(none)"
- current_hostname is "localhost"
- current_hostname is the same as the old_host_name

mind that current_hostname will be practically always old_host_name.

The bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667647
Is accurate describing it, and the documentation shall be changed, as this is a 
misbehavior compared to all the other clients, and compared to the 
specification of DHCP.

The patch is rather simple:

--- dhclient-script_old   2023-02-20 08:19:43.0 +
+++ dhclient-script 2023-09-12 18:08:25.172475371 +0100
@@ -128,7 +128,7 @@
 if [ -z "$current_hostname" ] ||
[ "$current_hostname" = '(none)' ] ||
[ "$current_hostname" = 'localhost' ] ||
-   [ "$current_hostname" = "$old_host_name" ]; then
+   [ "$current_hostname" != "$old_host_name" ]; then
if [ "$new_host_name" != "$current_host_name" ]; then
hostname "$new_host_name"
fi

The logic would be then that if the hostname is different from the one provided 
(not the same) the proposed hostname is used.


Best,

Bug#1051644: adduser: [INTL:pt] Update on Portuguese translation of MANPAGE

[Américo Monteiro]

A terça-feira, 12 de setembro de 2023 13:21:25 WEST Marc Haber escreveu:
> Control: tags -1 moreinfo
> 
> Hi Américo,
Hi


> 
> thanks for your work. Can you please give the translation a meaningful
> copyright clause, it surely isn't copyright 2010 by the FSF.

# Copyright (C) 2010 Free Software Foundation, Inc.
This was allready in the original template and I believe we're not suppose to 
change it. Anyway... I didn't wrote it.


# Américo Monteiro , 2010 - 2023.
This means I'm the translator of this manual since 2010 to 2023 and this has 
nothing to do with copyright

Some of this files have a line saying something like
"This file can be distributed under the same license of the package "name""
but this doen't


> 
> Thank you in advance.
> 
> Greetings
> Marc

Best regards
Américo

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-12 18:15:27)
> Jonas Smedegaard  writes:
> 
> > If you mean to say that ambiguous MIT declarations exist in
> > debian/copyright files written using the machine-readable format, then
> > please point to an example, as I cannot imagine how that would look.
> 
> I can see it: people use License: Expat but then include some license that
> is essentially, but not precisely, the same as Expat.  If we then tell
> people that they can omit the text of the license and we'll fill it in
> automatically, they'll remove the actual text and we'll fill it in with
> the wrong thing.
> 
> This is just a bug in handling the debian/copyright file, though.  If we
> take this approach, we'll need to be very explicit that you can only use
> whatever triggers the automatic inclusion of the license text if your
> license text is word-for-word identical.  Otherwise, you'll need to cut
> and paste it into the file as always.

Ah, right.  I see it now.

Strictly speaking it is not (as I was more narrowly focusing on) that
the current debian/copyright spec leaves room for *ambiguity*, but
instead that there is a real risk of making mistakes when replacing with
centrally defined ones (e.g. redefining a local "Expat" from locally
meaning "MIT-ish legalese as stated in this project" to falsely mean
"the MIT-ish legalese that SPDX labels MIT").

If you disagree, then please shout, as then I am still missing your
point here...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#699001: elpa-notmuch should depend on notmuch

[Benjamin Moody]

Package: elpa-notmuch
Version: 0.31.4-2
Followup-For: Bug #699001

Dear Maintainer,

The notmuch-emacs package has been replaced with elpa-notmuch.
However, this bug still seems relevant; M-x notmuch doesn't work if
notmuch isn't installed.  elpa-notmuch should at least have a
"Recommends: notmuch", or more likely a "Depends".

I have no idea whether the version coupling issue is still relevant.

Bug#1051796: thunderbird not displaying message headers correctly.

[js jb]

I've noticed that the behavior described in this bug tends to happen in 
messages whose attachments were deleted.
thanks

Bug#1051797: libtk-img-doc: dpkg extraction error during upgrading

[Davide Prina]

Package: libtk-img-doc
Version: 1:1.4.14+dfsg-2
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net

Dear mainteiner,

during the upgrade of the package from version 1:1.4.15+dfsg-1 to
version 1:1.4.14+dfsg-2 I have the following error:

dpkg: errore nell'elaborare l'archivio 
/tmp/user/0/apt-dpkg-install-f3K6IA/18-libtk-img-doc_1%3a1.4.15+dfsg-1_all.deb 
(--unpack):
 tentata sovrascrittura di "/usr/share/doc/libtk-img/README.gz" presente anche 
nel pacchetto libtk-img:amd64 1:1.4.15+dfsg-1

I try to translate:
dpkg: error processing the archive 
/tmp/user/0/apt-dpkg-install-f3K6IA/18-libtk-img-doc_1%3a1.4.15+dfsg-1_all.deb 
(--unpack):
 try to overwrite of "/usr/share/doc/libtk-img/README.gz" present also in the 
package libtk-img:amd64 1:1.4.15+dfsg-1

Ciao
Davide

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

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

libtk-img-doc depends on no packages.

libtk-img-doc recommends no packages.

Versions of packages libtk-img-doc suggests:
ii  libtk-img  1:1.4.15+dfsg-1

-- no debconf information

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Andres Salomon]

reassign 1051787 libwebp
thanks


Actually I'm mistaken, we're building against the system libwebp so 
there's no need to update chromium at all for this CVE. The webp fix is 
the only (linux) change that chromium made between .180 and .187.





On Tue, Sep 12 2023 at 11:34:26 AM -04:00:00, Andres Salomon 
 wrote:

clone 1051787 -1
reassign -1 libwebp
thanks

This bug's actually in libwebp. Unfortunately we're still embedding 
it in chromium, so we likely need to fix both chromium *and* libwebp 
in debian. There hasn't been a libwebp release yet, but the two 
relevant git commits are


and what appears to be a followup fix to that,



On Tue, Sep 12 2023 at 09:12:40 AM -06:00:00, Jeffrey Cliff 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team >


Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and 
The Citizen

Lab at The University of Torontoʼs Munk School on 2023-09-06



Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

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

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051796: thunderbird: message headers NOT displayed in message list or message for some, not all, messages, OK in evolution, balsa

[js]

Package: thunderbird
Version: 1:117.0~b5-1
Severity: important

Dear Maintainer,

==

   * What led up to the situation?
 Thunderbird is my default mail client. Inbox has about 1300 mails
 in it and occassionally messages appear garbled (ie message headers
 not displayed or selected message in list doesn't match preview
 pane). Up to now, this was easily corrected by repairing the
 folder.

 Today (Sept 12) this is not the case: repairing the folder **very briefly 
**
 displays the headers correctly and then they disappear.

 Note that the mail folders themselves are fine: opening another
 email client (I tried evolution, balsa, claws-mail) displays
 correctly all the message headers missing from thunderbird.

 This is limited to thunderbird display of message headers. When replying
 to a message with empty From, To, Subject, thunderbird correctly
 fills in the missing fields (list of recipients, subject, etc.)

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Repaired the folder several times, upgraded dbus and rebooted, but
 problem persists.

   * What outcome did you expect instead?
 In the past this behavior has sometimes happened, only in
 thunderbird (but not in other mail clients) and folder repair fixed
 it.


==

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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.8-1
ii  fontconfig   2.14.2-3
ii  kdialog  4:22.12.3-1
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.37-5
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-3
ii  libfreetype6 2.13.1+dfsg-1
ii  libgcc-s113.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.2-1
ii  libgtk-3-0   3.24.38-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.14+ds-1
ii  libstdc++6   13.2.0-1
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
ii  myspell-es [myspell-dictionary]   1.11-20
ii  myspell-fr [myspell-dictionary]   1.4-30
ii  myspell-he [myspell-dictionary]   1.4-3.1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- no debconf information

Bug#1051747: p11tool should use libssl3

[Andreas Metzler]

On 2023-09-12 Philipp Marek via Pkg-gnutls-maint 
 wrote:
> > Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
> > Please doublecheck.


> I believe I do?


> location:
> $ which p11tool
> /usr/bin/p11tool
[...]

Thank you.

I suspect the culprit might be one of pkcs11 modules you are using, not
p11-toool itself.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1051747: p11tool should use libssl3

[Philipp Marek]

Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
Please doublecheck.



I believe I do?


location:
$ which p11tool
/usr/bin/p11tool

no symlink or such stuff:
$ ls -al /usr/bin/p11tool
-rwxr-xr-x 1 root root 339720  6. Sep 18:26 /usr/bin/p11tool

file comes from:
$ dpkg-query -S /usr/bin/p11tool
gnutls-bin: /usr/bin/p11tool

package's files are not modified:
$ debsums gnutls-bin
/usr/bin/certtool
 OK
/usr/bin/danetool
 OK
/usr/bin/gnutls-cli  
 OK
/usr/bin/gnutls-cli-debug
 OK
/usr/bin/gnutls-serv 
 OK
/usr/bin/ocsptool
 OK
/usr/bin/p11tool 
 OK
/usr/bin/psktool 
 OK
/usr/share/doc/gnutls-bin/changelog.Debian.amd64.gz  
 OK
/usr/share/doc/gnutls-bin/changelog.Debian.gz
 OK
/usr/share/doc/gnutls-bin/changelog.gz   
 OK
/usr/share/doc/gnutls-bin/copyright  
 OK
/usr/share/doc/gnutls-bin/examples/certtool.cfg  
 OK
/usr/share/man/man1/certtool.1.gz
 OK
/usr/share/man/man1/danetool.1.gz
 OK
/usr/share/man/man1/gnutls-cli-debug.1.gz
 OK
/usr/share/man/man1/gnutls-cli.1.gz  
 OK
/usr/share/man/man1/gnutls-serv.1.gz 
 OK
/usr/share/man/man1/ocsptool.1.gz
 OK
/usr/share/man/man1/p11tool.1.gz 
 OK
/usr/share/man/man1/psktool.1.gz 
 OK
/usr/share/man/man1/tpmtool.1.gz 
 OK


$ LC_ALL=C dpkg-query -l gnutls-bin
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description

+++-==---===
ii  gnutls-bin 3.8.1-4+b1   amd64GNU TLS library - 
commandline utilities


is there something that I overlooked?

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

On Tue, Sep 12, 2023 at 05:27:15PM +0100, Simon McVittie wrote:
> On Tue, 12 Sep 2023 at 10:52:16 -0400, Paul Tagliamonte wrote:
> > I have NSS set up to talk with OpenSC
> 
> "NSS" is unfortunately ambiguous in this context. Is this the glibc Name
> Service Switch (the thing that for example libnss-systemd integrates
> with), or Mozilla's Netscape Security Services (libnss3), or some secret
> third thing also named NSS?

Ah, very sorry. libnss3.

I usually use OpenSC in the following configuration:

```
modutil -add "OpenSC" \
  -libfile /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \
  -dbdir sql:$HOME/.pki/nssdb
```

However, when I went to confirm my notes[1] against my running system, I
found it to be in a different state (using onepin-opensc-pkcs11.so,
which is new to me):

| An aside:
|
| [1]: My notes are in the form of manpages for stuf I do infrequently but
| want to remember. Here's a markdon of the yubkey manpage when I noodle
| with using it in OpenSC mode, in case this is helpful for more
| information: https://gist.github.com/paultag/2c35b62e85a032856c2cb97345c3d24d
|
| That's from 2017, so the world has changed quite a bit, and some of it
| is bad / outdated advice, so I'd just use it to help understand likely
| system configuration than best practice -- for instance, don't use
| pkcs#11 for ssh keys anymore pls :)

Related output when using `modutil -list -dbdir sql:$HOME/.pki/nssdb`

I'm seeing a slightly different configuration (hurmm, odd):

```
  2. OpenSC smartcard framework (0.22)
library name: /usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
   uri: 
pkcs11:library-manufacturer=OpenSC%20Project;library-description=OpenSC%20smartcard%20framework;library-version=0.23
 slots: 1 slot attached
status: loaded

 slot:
token:
  uri: pkcs11:
```

dpkg output from the packages I know about off the top of my head that
would be involved that aren't in the last report:

ii  opensc   0.23.0-1   
   amd64Smart card utilities with support for PKCS#15 
compatible cards
ii  opensc-pkcs11:amd64  0.23.0-1   
   amd64Smart card utilities (PKCS#11 module)
ii  libnss3:amd642:3.92-1   
   amd64Network Security Service libraries
ii  libnss3-dev:amd642:3.92-1   
   amd64Development files for the Network Security Service 
libraries
ii  libnss3-tools2:3.92-1   
   amd64Network Security Service tools
ii  libykpiv-dev:amd64   2.2.0-1.1  
   amd64Development files for the YubiKey PIV Library
ii  libykpiv2:amd64  2.2.0-1.1  
   amd64Library for communication with the YubiKey PIV 
smartcard
ii  pcscd2.0.0-1
   amd64Middleware to access a smart card using PC/SC 
(daemon side)
ii  libccid  1.5.2-1
   amd64PC/SC driver for USB CCID smart card readers

-- 
:wq


signature.asc
Description: PGP signature

Bug#1051795: m2crypto: Fails testsuite with OpenSSL 3.1

[Sebastian Andrzej Siewior]

Package: m2crypto
Version: 0.38.0-4
Severity: important
Control: affects -1 + src:openssl
Control: tags -1 + upstream patch fixed-upstream

Hi,

As far as I can tell, m2crypto compiles and passes the testsuite if
compiled and run against openssl 3.0 or 3.1. What currently fails is if
m2crypto is compiled against 3.0 adn the testsuite run against 3.1. This
can be seen
https://release.debian.org/britney/pseudo-excuses-experimental.html

https://ci.debian.net/data/autopkgtest/unstable/amd64/m/m2crypto/37743405/log.gz

I did a little testing and noticed that upstream already took care of
this with commit
957df43e0e16e ("OpenSSL changed error message yet again.")

https://gitlab.com/m2crypto/m2crypto/-/commit/957df43e0e16e6649bf4834c21ae63d0a80d9095

I can confirm that this change fixes the problem.
The commit in question is part of m2crypto 0.39.0. Could you please
upload m2crypto 0.39.0? :)

Sebastian

Bug#1051794: paje.app: Please add original homepage (exists)

[Ben Tris]

Source: paje.app
Version: 1.98-1.1
Severity: wishlist
X-Debbugs-Cc: benatt...@gezapig.nl

Dear Maintainer,

This home page is well made.
homepage: https://paje.sourceforge.net/


-- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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

Bug#1051747: p11tool should use libssl3

[Andreas Metzler]

On 2023-09-12 Philipp Marek via Pkg-gnutls-maint 
 wrote:
> Package: gnutls-bin
> Version: 3.8.1-4+b1
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at

> After removing libssl1.1:amd64=1.1.1o-1 I can't run p11tool any more:

> # LD_DEBUG=libs p11tool
>1708431: find library=libcrypto.so.1.0.1 [0]; searching
>...
>1708431: find library=libcrypto.so.1.0.0 [0]; searching
[..]


Are you actually testing /usr/bin/p11tool as shipped by gnutls-bin?
Please doublecheck.

cu Andreas

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Simon McVittie]

On Tue, 12 Sep 2023 at 10:52:16 -0400, Paul Tagliamonte wrote:
> I have NSS set up to talk with OpenSC

"NSS" is unfortunately ambiguous in this context. Is this the glibc Name
Service Switch (the thing that for example libnss-systemd integrates
with), or Mozilla's Netscape Security Services (libnss3), or some secret
third thing also named NSS?

Whichever one it is, can you be more specific about what was involved in
"setting it up to talk with OpenSC"?

smcv

Bug#1051793: simple-cdd: GNUPGHOME is not always passed correctly to gpg

[Jonathan Hettwer (bauen1)]

Package: simple-cdd
Version: 0.6.9
Severity: normal
X-Debbugs-Cc: j24...@gmail.com, j24...@gmail.com

Dear simple-cdd Authors and/or Maintainers,

When `GNUPGHOME` is not set, simple-cdd defaults it to `$PWD/tmp/gpg-keyring`, 
this is
done in 
.

However if `GNUPGHOME` is set internally like this, then it is not always 
passed along to all calls to `gpg` in 
.

For example running `simple-cdd` in a rootless podman container where only 
parts of my home directory are mounted in, leaving ~ as
a read-only empty directory.

Because `GNUPGHOME` is not passed a long in at least 
,
 this results in the following error:

> gpg: Fatal: can't create directory '/home/jh/.gnupg': Read-only file system
> Traceback (most recent call last):
>   File "/usr/bin/simple-cdd", line 674, in 
> scdd.read_configuration()
>   File "/usr/bin/simple-cdd", line 179, in read_configuration
> verify_release_keys.extend(gnupg.list_valid_keys(keyring_file))
>   File "/usr/lib/python3/dist-packages/simple_cdd/gnupg.py", line 82, in 
> list_valid_keys
> keys_raw = subprocess.check_output(["gpg",
>^^^
>   File "/usr/lib/python3.11/subprocess.py", line 466, in check_output
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
>^
>   File "/usr/lib/python3.11/subprocess.py", line 571, in run
> raise CalledProcessError(retcode, process.args,
> subprocess.CalledProcessError: Command '['gpg', '--batch', 
> '--no-default-keyring', '--keyring', 
> '/usr/share/keyrings/debian-archive-keyring.gpg', '--list-keys', 
> '--with-colons']' returned non-zero exit status 2.

I suspect the same is also true for 
.

Thanks a lot, Jonathan Hettwer (bauen1)

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Jonas Smedegaard  writes:

> If you mean to say that ambiguous MIT declarations exist in
> debian/copyright files written using the machine-readable format, then
> please point to an example, as I cannot imagine how that would look.

I can see it: people use License: Expat but then include some license that
is essentially, but not precisely, the same as Expat.  If we then tell
people that they can omit the text of the license and we'll fill it in
automatically, they'll remove the actual text and we'll fill it in with
the wrong thing.

This is just a bug in handling the debian/copyright file, though.  If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical.  Otherwise, you'll need to cut
and paste it into the file as always.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051792: sed: Support for build profile

[Gioele Barabucci]

Package: src:sed
Version: 4.9-1
Tags: patch

Dear sed maintainers,

even when the  build profile is used, `texinfo` remains a 
required build dependency.


A MR that fixes this issue is available at:

https://salsa.debian.org/debian/sed/-/merge_requests/2

Regards,

--
Gioele Barabucci

Bug#1051706: debian-archive-keyring: maintainer scripts remove Stable key

[Jonathan Wiltshire]

Hi,

On Mon, Sep 11, 2023 at 04:32:09PM +0300, Martin-Éric Racine wrote:
> Maintainer scripts in 2023.4 remove the Bookworm key. Bookworm is the current 
> Stable release.
> 
> Unpacking debian-archive-keyring (2023.4) over (2023.3) ...
> Setting up debian-archive-keyring (2023.4) ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-stable.gpg ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-security-automatic.gpg ...
> Removing obsolete conffile 
> /etc/apt/trusted.gpg.d/debian-archive-bookworm-automatic.gpg ...
> 
> Perhaps this was meant to remove the keys of older releases instead?

No, this sounds like the clean-up behaviour I intended. Do you not have the
equivalent .asc key fragments still on disk?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1051791: Patch: add InRelease files with signature

[Cyprien Nicolas]

Package: debarchiver
Version: 0.11.7
Severity: important
Tags: patch

Dear Maintainer,

We use debarchiver for a company repository, and since we started
upgrading our servers to Bookworm, our hosts fail to verify our
repository:

W: Pas d'entrée de hachage dans le fichier Release 
/var/lib/apt/lists/partial/debian.octopuce.fr_octopuce_dists_bookworm_Release
E: Le dépôt http://debian.octopuce.fr/octopuce bookworm Release ne fournit que 
de faibles informations de sécurité.

Sorry for the French, I no longer have the full LC_ALL=C output, the
first one said "No Hash entry in Release file", and the second one
someting about "weak security".

With respect to #825123, we checked our signing key (rsa2048) and the
default signature algorithm (sha256) but the issue is unreleated.

We found out that the InRelease file is not generated by
debarchiver. We patched debarchiver to do so, along with the
Release.gpg file, and now the repository is verified.

I'm not sure how to add patches with reportbug yet, so I put it inline
here:

-*- Patch Begins here -*-
--- debarchiver.orig2021-09-07 15:10:31.0 +0200
+++ debarchiver 2023-09-12 17:23:12.171618835 +0200
@@ -1302,17 +1302,26 @@
  3);
 if ($gpgkey) {
 unlink("$path/Release.gpg");
+unlink("$path/InRelease");
if ($gpgpassfile) {
cmdaction("cat $gpgpassfile | gpg --batch --no-tty -a -b -s -u 
$gpgkey " .
  "--pinentry-mode loopback --passphrase-fd 0 -o 
$path/Release.gpg $path/Release",
  "Sign Release file for $path with key '$gpgkey'",
  3);
+   cmdaction("cat $gpgpassfile | gpg --batch --no-tty --clearsign -u 
$gpgkey " .
+ "--pinentry-mode loopback --passphrase-fd 0 -o 
$path/InRelease $path/Release",
+ "Sign InRelease file for $path with key '$gpgkey'",
+ 3);
}
else {
cmdaction("gpg -a -b -s -u $gpgkey " .
  "-o $path/Release.gpg $path/Release",
  "Sign Release file for $path with key '$gpgkey'",
  3);
+   cmdaction("gpg --clearsign -u $gpgkey " .
+ "-o $path/InRelease $path/Release",
+ "Sign InRelease file for $path with key '$gpgkey'",
+ 3);
}
 }
 unlink("$configpath");
-*- Patch Ends here -*-

Kind regards,
Cyprien

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

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

Versions of packages debarchiver depends on:
ii  adduser3.134
ii  apt-utils  2.6.1
ii  dpkg-dev   1.21.22
ii  opalmod0.2.2.1

Versions of packages debarchiver recommends:
ii  mailutils [mailx]   1:3.15-4
ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2

Versions of packages debarchiver suggests:
pn  devscripts  
ii  gnupg   2.2.40-1.1

-- Configuration Files:
/etc/cron.d/debarchiver changed:
MAILTO=""
*/5 * * * * debarchiver /usr/local/bin/debarchiver-patch-inrelease 
--scanall -so | logger -t debarchiver -p daemon.info

/etc/debarchiver.conf changed:
$destdir = "/var/www/debian/octopuce/dists";
$inputdir = "/var/lib/debarchiver/incoming";
$copycmd = "mv -f";
$rmcmd = "true";
$vrfycmd = "dscverify";
$cinstall = "installed";
$verifysignatures = 1;
$ignoredestcheck = 0;
$verifysignaturesdistinput = 0;
$bzip = 1;
 %distinputdirs =
(
oldoldoldstable => 'oldoldoldstable',
oldoldstable => 'oldoldstable',
oldstable => 'oldstable',
stable => 'stable',
testing => 'testing',
unstable => 'unstable',
experimental => 'experimental'
);
@distributions = ('oldoldoldstable', 'oldoldstable','oldstable', 'stable', 
'testing', 'unstable', 'experimental');
$majordefault = "main";
 %distmapping =
(
oldoldoldstable => 'stretch',
oldoldstable => 'buster',
oldstable => 'bullseye',
stable => 'bookworm',
testing => 'trixie',
unstable => 'sid',
experimental => 'experimental',
);
@architectures = ('i386', 'amd64', 'all');
@sections = ('main', 'contrib', 'non-free');
  @mailtos = ('packa...@octopuce.fr');
$mailfrom = "debarchi...@debian.octopuce.fr";
%release = ('origin' => "debian.octopuce.fr",
'label' => "Octopuce official repository",
'description' => "Octopuce-specific packages official 
repository");
$cachedir = '/var/cache/debarchiver';
$gpgkey = "AB4B62BCAB86B190C0543F84F83BC4CC8181979A";
$gpgpassfile = "";
1;


-- no debconf information
--- 

Bug#1051790: ITP: xdg-desktop-portal-lxqt -- xdg-desktop-portal implemenation for libfm-qt xdg-desktop-portal that is using Qt/KF5/libfm-qt

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+l...@tracker.debian.org

* Package name: xdg-desktop-portal-lxqt
  Version : 0.4.0
  Upstream Contact: tsujan
* URL : https://github.com/lxqt/xdg-desktop-portal-lxqt
* License : LGPL-2.1+
  Programming Lang: C
  Description : xdg-desktop-portal implemenation for libfm-qt

 The package will be maintained under LXQt team.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1051514: grub-common: Please remove grub-common.service from boot hot path

[Julian Andres Klode]

On Sun, Sep 10, 2023 at 03:45:52PM +0200, Paul Menzel wrote:
> Dear Andres,
> 
> 
> Thank you for your reply.
> 
> Am 10.09.23 um 13:54 schrieb Julian Andres Klode:
> > On Sat, Sep 09, 2023 at 12:21:29AM +0200, Paul Menzel wrote:
> > > Package: grub-common
> > > Version: 2.12~rc1-9
> > > Severity: normal
> 
> > > The unit `grub-common.service` is installed to the multi-user.target and
> > > therefore run during boot-up, slowing down the boot, especially as shell
> > > commands are used.
> > > 
> > > ```
> > > $ systemctl cat grub-common.service
> > > # /lib/systemd/system/grub-common.service
> > > [Unit]
> > > Description=Record successful boot for GRUB
> > > After=suspend.target hibernate.target hybrid-sleep.target
> > > suspend-then-hibernate.target
> > > ConditionPathExists=/boot/grub/grub.cfg
> > > 
> > > [Service]
> > > Type=oneshot
> > > Restart=no
> > > ExecStartPre=/bin/sh -c '[ -s /boot/grub/grubenv ] || rm -f
> > > /boot/grub/grubenv; mkdir -p /boot/grub'
> > > ExecStart=grub-editenv /boot/grub/grubenv unset recordfail
> > > ExecStartPost=/bin/sh -c 'if grub-editenv /boot/grub/grubenv list | grep 
> > > -q
> > > initrdless_boot_fallback_triggered=1; then echo "grub: GRUB_FORCE_PARTUUID
> > > set, initrdless boot paniced, fallback triggered."; fi'
> > > StandardOutput=kmsg
> > > 
> > > [Install]
> > > WantedBy=multi-user.target suspend.target hibernate.target
> > > hybrid-sleep.target suspend-then-hibernate.target
> > > ```
> > 
> > As you can see, there are no Before relations in the service,
> > so grub-common is not in the hot path, nothing depends on it
> > having finished startup.
> > 
> > I'm sure this was well intended and not a troll attempt, but
> > systemd doesn't start services in a sequence, so services can
> > run in parallel and there is in general very little ordering
> > requirements.
> 
> That is exactly, what I was saying. Due to the missing ordering, systemd
> starts this service as early as possible causing pressure on the possibly
> scarce system resources at the beginning. So care has to be taken
> introducing these things. Looking into decreasing the start time of an
> Ubuntu system once, grub-common showed up there, so it will make the startup
> time of quite a lot of Debian systems longer now too. Please keep in mind,
> that Debian is also run on older systems.

I think bug reports like this are ill-advised, it is not our decision
to make how to start services and abusing timers for this is wrong.

If you want units that do not contribute to the target to run only
when idle, then my suggestion would be to add such a feature to
systemd itself rather than go around trying to hack each such instance
with timers.

That said, I strongly disagree with the assessment. Boot is not
interactive so it is less of a priority to have it fast vs having
a performant interactive session.

On the extreme, if you boot into your desktop and then it eats up
all your cores and locks up the UI on your resource constrained
device that's a worse experience than waiting longer at boot and
then having things work correctly.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051789: RM: sphinxcontrib-youtube -- RoQA; abandoned packaging, MIA

[William Desportes]

Package: ftp.debian.org
Severity: normal
Usertags: rm-request
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

Due to #943690 and the current packaging status, please proceed with deleting 
the package sphinxcontrib-youtube.
The package is not maintained, no new version since 2014. Only one version was 
uploaded.

--
William Desportes