Bug#1037574: android-platform-system-tools-hidl: diff for NMU version 10.0.0+r36-3.1

[Marcos Talau]

Control: tags 1037574 + pending


Dear maintainer,

I've prepared an NMU for android-platform-system-tools-hidl (versioned as 
10.0.0+r36-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru android-platform-system-tools-hidl-10.0.0+r36/debian/changelog android-platform-system-tools-hidl-10.0.0+r36/debian/changelog
--- android-platform-system-tools-hidl-10.0.0+r36/debian/changelog	2022-10-29 23:09:15.0 +0530
+++ android-platform-system-tools-hidl-10.0.0+r36/debian/changelog	2023-09-10 14:10:48.0 +0530
@@ -1,3 +1,11 @@
+android-platform-system-tools-hidl (10.0.0+r36-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix_ftbfs_gcc-13.patch: New. Fix FTBFS with gcc-13.
+Thanks to Adrian Bunk (Closes: #1037574).
+
+ -- Marcos Talau   Sun, 10 Sep 2023 14:10:48 +0530
+
 android-platform-system-tools-hidl (10.0.0+r36-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru android-platform-system-tools-hidl-10.0.0+r36/debian/patches/fix_ftbfs_gcc-13.patch android-platform-system-tools-hidl-10.0.0+r36/debian/patches/fix_ftbfs_gcc-13.patch
--- android-platform-system-tools-hidl-10.0.0+r36/debian/patches/fix_ftbfs_gcc-13.patch	1970-01-01 05:30:00.0 +0530
+++ android-platform-system-tools-hidl-10.0.0+r36/debian/patches/fix_ftbfs_gcc-13.patch	2023-09-10 13:53:12.0 +0530
@@ -0,0 +1,15 @@
+Description: Fix the build with gcc 13
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1037574
+Last-Update: 2023-09-10
+
+--- android-platform-system-tools-hidl-10.0.0+r36.orig/hashing/include/hidl-hash/Hash.h
 android-platform-system-tools-hidl-10.0.0+r36/hashing/include/hidl-hash/Hash.h
+@@ -16,6 +16,7 @@
+ 
+ #pragma once
+ 
++#include 
+ #include 
+ #include 
+ 
diff -Nru android-platform-system-tools-hidl-10.0.0+r36/debian/patches/series android-platform-system-tools-hidl-10.0.0+r36/debian/patches/series
--- android-platform-system-tools-hidl-10.0.0+r36/debian/patches/series	2022-10-29 23:01:43.0 +0530
+++ android-platform-system-tools-hidl-10.0.0+r36/debian/patches/series	2023-09-10 13:52:26.0 +0530
@@ -2,3 +2,4 @@
 yacc_pure_parser.diff
 corrects-spell.patch
 cache-bison-2.7-intermediate-source.patch
+fix_ftbfs_gcc-13.patch

Bug#1037878: ultracopier: diff for NMU version 2.2.6.0-1.1

[Thomas Preud'homme]

Thanks, much appreciated. Feel free to upload it right away.

Best regards,
Thomas

On 10 September 2023 09:12:35 WEST, Marcos Talau  wrote:
>Control: tags 1037878 + patch
>Control: tags 1037878 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for ultracopier (versioned as 2.2.6.0-1.1) and
>uploaded it to DELAYED/2. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>

Bug#1037913: zytrax: diff for NMU version 0+git20201215-1.1

[Marcos Talau]

Control: tags 1037913 + pending


Dear maintainer,

I've prepared an NMU for zytrax (versioned as 0+git20201215-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru zytrax-0+git20201215/debian/changelog zytrax-0+git20201215/debian/changelog
--- zytrax-0+git20201215/debian/changelog	2020-12-15 11:13:08.0 +0530
+++ zytrax-0+git20201215/debian/changelog	2023-09-10 14:20:16.0 +0530
@@ -1,3 +1,11 @@
+zytrax (0+git20201215-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/01-fix_ftbfs_gcc-13.patch: New. Fix FTBFS with gcc-13.
+Thanks to Adrian Bunk (Closes: #1037913).
+
+ -- Marcos Talau   Sun, 10 Sep 2023 14:20:16 +0530
+
 zytrax (0+git20201215-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru zytrax-0+git20201215/debian/patches/01-fix_ftbfs_gcc-13.patch zytrax-0+git20201215/debian/patches/01-fix_ftbfs_gcc-13.patch
--- zytrax-0+git20201215/debian/patches/01-fix_ftbfs_gcc-13.patch	1970-01-01 05:30:00.0 +0530
+++ zytrax-0+git20201215/debian/patches/01-fix_ftbfs_gcc-13.patch	2023-09-10 14:19:51.0 +0530
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with gcc-13
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/1037913
+Last-Update: 2023-09-10
+
+--- zytrax-0+git20201215.orig/globals/base64.h
 zytrax-0+git20201215/globals/base64.h
+@@ -2,6 +2,7 @@
+ #define _BASE64_H_
+ 
+ #include "vector.h"
++#include 
+ #include 
+ 
+ std::string base64_encode(const Vector _buffer);
diff -Nru zytrax-0+git20201215/debian/patches/series zytrax-0+git20201215/debian/patches/series
--- zytrax-0+git20201215/debian/patches/series	1970-01-01 05:30:00.0 +0530
+++ zytrax-0+git20201215/debian/patches/series	2023-09-10 14:19:13.0 +0530
@@ -0,0 +1 @@
+01-fix_ftbfs_gcc-13.patch

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Salvatore Bonaccorso]

Hi Antonio,

On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> On Sat, Sep 09, 2023 at 10:23:32PM +0200, Salvatore Bonaccorso wrote:
> > Source: mutt
> > Version: 2.2.9-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerabilities were published for mutt.
> > 
> > CVE-2023-4874[0]:
> > | Null pointer dereference when viewing a specially crafted email in
> > | Mutt >1.5.2 <2.2.12
> > 
> > 
> > CVE-2023-4875[1]:
> > | Null pointer dereference when composing from a specially crafted
> > | draft message in Mutt >1.5.2 <2.2.12
> > 
> > Make sure to include all three commits referenced from [2], the last
> > one is technically not part of the two CVEs, but another crash found
> > by upstream.
> > 
> > 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-4874
> > https://www.cve.org/CVERecord?id=CVE-2023-4874
> > [1] https://security-tracker.debian.org/tracker/CVE-2023-4875
> > https://www.cve.org/CVERecord?id=CVE-2023-4875
> > [2] 
> > http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/56.html
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> Thanks for raising this, I'm uploading the new packages with the fixes today.

FWIW, I have done the bookworm-security upload already to
security-master, and still working on the bullseye-security one (with
plan to release the DSA tonight ideally).

Regards,
Salvatore

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Salvatore Bonaccorso]

Hi Antonio,

On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote:
> On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > Thanks for raising this, I'm uploading the new packages with the fixes 
> > today.
> 
> apparently someone else did a NMU with the new version and incorrectly closed
> the bug.

You mean the NMU by Sebastian?

> I reopened the bug because stable needs to be addressed (which I will do today
> as I just wrote) and then it's probably worth investigating how to integrate
> those NMU into the git repo

Actually you do not need to reopen. A bug can be closed with mutliple
versions, that is 2.2.12-0.1 closes it, but as well so does then the
2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one.

I think that was not the case several years ago, but nowdays BTS can
handle that, and will reflect it nicely as well in the version graph.

Or were you meaning something different?

Regards,
Salvatore

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Adam Borowski]

On Sat, Sep 09, 2023 at 11:24:04PM +0200, Gunnar Hjalmarsson wrote:
> After our conversation I made two installs for test purposes:
> 
> 1. Debian 12 with GNOME
>Result: fonts-noto-core was not included by default.
> 
> 2. Debian trixie with GNOME
>Result: fonts-noto-core was included by default.
> 
> I suspect that the change can be explained by this commit:
> https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde

There's a lot of Debian outside GNOME -- and in fact, if you are already
using their metapackages, you don't need more.  I'd prefer for non-GNOME
metapackages to be universal, and thus what a particular desktop already
depends or does not depend on is not a concern for me.

Thus: OP's request is neither mooted nor vindicated by whatever GNOME does.

> > Alas, noto has the downside of making font pickers next to useless,
> > as it declares every single of languages it supports as a separate
> > font family. So instead off just "Noto Sans" "Noto Mono" "Noto
> > Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
> > Klingon" and so on, making the list of available fonts one big noto
> > fest.
> 
> If you assume that users often want to change much, I can understand that
> you see that as a disadvantage. OTOH, a user who wants to do it differently
> can uninstall fonts-noto-core and with that get a significantly shorter
> list.

Noted.  You don't care about fonts just whether a particular character is
covered, me and other people in the Fonts Team obviously have more interest
in distinct fonts.  That's the diff between eg. linguists vs layout
designers, different people have different priorities.

> Myself is involved in changing the default selection of fonts and font
> configuration for Ubuntu. In that context we focus on offering the users a
> sensible default

Aye!

> which most users are comfortable with, and the way Noto
> provides different fonts for different scripts and purposes is an advantage
> to achieve that Ubuntu is about to prefer Noto for most scripts, but to the
> extent exceptions proves to be motivated, that can be handled relatively
> easy via font configuration.

As this metapackage was written by me, I'm kind of concerned I use "royal
we" too much and say stuff about the opinions of Debian Fonts team more
than warranted -- but, with paragraph^^ above, perhaps the description and
the focus of this metapackage could be changed, to explicitly cater to a
different audience?  Having multiple metapackages do essentially the same
thing is kind of redundant.

> Something that would have been harder with
> DejaVu Sans as the preferred font.

DejaVu has a decent but not universal coverage; it's included on the list
more for technical legacy reasons, just like Windows-compatible fonts are.

> I have no firm opinion, at least not yet, on the role of fonts-recommended
> and whether the proposed change is motivated. But I just posted a list
> message about the ongoing transition from DejaVu to Noto, to reach a broader
> audience:

> https://lists.debian.org/debian-devel/2023/09/msg00053.html

I'm behind reading mailing lists, but I agree 100% with what other members
of the Fonts Team said.  Noto is ugly, a bit too disk heavy for 60% of
keyboard-attached boxen I use, and pollutes font lists too much.


Besides, Noto can be said to be a metapackage by itself, providing a large
set of fonts -- even if it claims to be a single font, it presents hundreds
of them to the system and UI interfaces.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄ No known relations of clouds to air or water.

Bug#1051605: RFS: rednotebook/2.31+ds-1~bpo12+1 -- Modern desktop diary and personal journaling tool

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rednotebook":

 * Package name : rednotebook
   Version  : 2.31+ds-1~bpo12+1
   Upstream contact : Jendrik Seipp 
 * URL  : https://rednotebook.app
 * License  : GPL-2+, CC0-1.0, LGPL-3+, GPL-3+
 * Vcs  : https://github.com/jendrikseipp/rednotebook
   Section  : text

The source builds the following binary packages:

  rednotebook - Modern desktop diary and personal journaling tool

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/rednotebook/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.31+ds-1~bpo12+1.dsc

Changes since the last upload:

 rednotebook (2.31+ds-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Twitter: kathenasorg
* Instagram: kathenasorg




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

Bug#1051612: rust-papergrid: Unsatisifiable dependencies

[Jeremy Bícha]

Source: rust-papergrid
Version: 0.9.1-1
Severity: serious

rust-papergrid is uninstallable (and therefore unstable to migrate to
Testing) because it depends on librust-ansi-str-0.8+default-dev and
ibrust-ansitok-0.2+default-dev but rust-ansi-str and rust-ansitok are
not in Debian.

Thank you,
Jeremy Bícha

Bug#1051615: rust-minijinja: Uninstallable dependencies

[Jeremy Bícha]

Source: rust-minijinja
Version: 0.34.0-1
Severity: serious

rust-minijinja is uninstallable (and therefore unstable to migrate to
Testing) because it depends on librust-aho-corasick-1-dev but
aho-corasick is only at version 0.7.19 in Debian.

It also depends on librust-v-htmlescape-0.15+default-dev but
rust-v-htmlescape isn't available in Debian.

Thank you,
Jeremy Bícha

Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

[Russ Allbery]

This patch from a while back is still waiting for one more second before
it can be merged for the next Policy release.  It previously got one
second from Wouter.  I revised the patch to mention the experimental suite
as well as the backports suites.

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

>From 6a4e1b261f5f5765fa164e4bfd063f67d40a9a47 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Tue, 20 Sep 2022 19:11:54 -0700
Subject: [PATCH] Improve alternative build dependency discussion

Alternatives in build dependencies are normally (except for
backports) handled specially by autobuilders to try to maintain
consistent builds.  This was documented in Policy, but in a
footnote that people often didn't see.

Move this text into the main body of the discussion of build
dependencies and reword it for additional clarity.  Add a pointer
to this discussion where alternative dependencies are introduced.
---
 policy/ch-relationships.rst | 61 +++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 5074428..e8978af 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -15,7 +15,10 @@ control fields of the package, which declare dependencies on other
 packages, the package names listed may also include lists of alternative
 package names, separated by vertical bar (pipe) symbols ``|``. In such a
 case, that part of the dependency can be satisfied by any one of the
-alternative packages.  [#]_
+alternative packages. (Alternative dependencies in ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` are interpreted
+specially by Debian autobuilders. See :ref:`Relationships between source
+and binary packages ` for more details.)
 
 All of the fields may restrict their applicability to particular versions
 of each named package. This is done in parentheses after each individual
@@ -620,6 +623,47 @@ earlier for binary packages) in order to invoke the targets in
 ``Build-Conflicts-Arch`` fields must be satisfied when these targets
 are invoked.
 
+Alternative dependencies are allowed in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's
+autobuilders normally discard the dependencies after the first. This is
+done to give alternative dependencies a consistent interpretation that
+reduces the risk of inconsistencies between repeated builds. If, for
+example, the first-listed dependency would normally be available but is
+temporarily not installable, the autobuilder fails rather than install a
+subsequent dependency that may significantly change the behavior of the
+package.
+
+More specifically, Debian autobuilders perform the following
+transformation on alternative dependencies in the ``Build-Depends``,
+``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields:
+
+#. Discard any alternatives that are restricted to architectures that do
+   not match the host architecture.
+#. Discard any alternatives specifying different package names than the
+   now-first alternative. (Alternatives specifying the same package name
+   are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.)
+
+For example, an autobuilder for the ``amd64`` architecture would treat the
+following dependency::
+
+foo-special [armhf] | foo (<= 4) | foo (>= 4.2) | bar
+
+as if it were::
+
+foo (<= 4) | foo (>= 4.2)
+
+The normal effect is to use only the first alternative that is valid on
+the relevant architecture and fail if that alternative is not installable.
+
+While this rule for build dependencies may limit the usefulness of
+alternatives, they can still be used to provide flexibility when building
+the package outside of Debian's autobuilders.
+
+The autobuilders for the Debian backports suite do not perform this
+transformation and instead use the same dependency resolution rules as
+normal package installations to choose which alternative dependency to
+install.
+
 .. _s-built-using:
 
 Additional source packages used to build the binary - ``Built-Using``
@@ -666,21 +710,6 @@ requirements to retain the referenced source packages.  It should not
 be added solely as a way to locate packages that need to be rebuilt
 against newer versions of their build dependencies.
 
-.. [#]
-   While ``Build-Depends``, ``Build-Depends-Indep`` and
-   ``Build-Depends-Arch`` permit the use of alternative dependencies,
-   those are only used for the backports suite on the Debian autobuilders.
-   On the other suites, after reducing any architecture-specific restrictions
-   for the build architecture in question, all but the first alternative are
-   discarded except if the alternative is the same package name as the first.
-   The latter exception is useful to specify version ranges like
-   ``foo (rel x) | foo (rel y)``. This is to reduce the risk of inconsistencies
-   between repeated rebuilds.  While 

Bug#1050172: ITS: mah-jong

[Nicolas Boullis]

Hello,

On Mon, Aug 21, 2023 at 06:28:05PM +0800, xiao sheng wen wrote:
> 
> The current maintainer of mah-jong is Nicolas Boullis , 
> he is not active now.
> 
> The mah-jong has new upstream version.
> 
> I want ITS mah-jong.

You’re absolutely right, I haven’t given the mah-jong mackage any love 
for too many years. If you’re willing to take over maintenance for this 
package, please go ahead.


Cheers,

-- 
Nicolas Boullis


signature.asc
Description: PGP signature

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Russ Allbery]

Simon McVittie  writes:

> Here are some updated patches for Policy, incorporating this requirement.

> I have not attempted to incorporate the corner case involving
> build-profiles. I think if we were going to do that, it would require
> documenting build-profiles first (#757760), and maybe even then it's too
> much of a corner-case to be documenting unless/until it actually
> happens.

I also second these changes.  In the name of expediency, and since I
believe all the proposed wording changes were informative, I applied these
patches for the next release and made the wording changes suggested by
Holger and Sean.  Attached are the changes as committed.

Subsequent to this work, we added the non-free-firmware archive area.
Simon's patch therefore doesn't add a statement to that section about
whether source packages in non-free-firmware are allowed to produce
binaries in non-free, or if source packages in non-free are allowed to
produce binaries in non-free-firmware, and I don't know what the answer to
that is.

Would the following wording be correct?

If a source package is in the *non-free-firmware* archive area, then
each of the binary packages that it produces must also be in the
*non-free-firmware* archive area.

Please let me know, and I will propose some follow-up wording for that.

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

diff --git a/debian/changelog b/debian/changelog
index 66d6fa0..a5e3e3e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,11 @@ debian-policy (4.6.3.0) UNRELEASED; urgency=medium
 Seconded: Russ Allbery 
 Seconded: Holger Levsen 
 Closes: #1035733
+  * Policy: Source packages in main may build binary packages in contrib
+Wording: Simon McVittie 
+Seconded: Holger Levsen 
+Seconded: Russ Allbery 
+Closes: #994008
 
  -- Sean Whitton   Wed, 14 Jun 2023 16:58:40 +0100
 
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index c7cd340..eb8978a 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -136,6 +136,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+If a source package is in the *main* archive area, then at least one of
+its binary packages must be in the *main* archive area, and each of the
+remaining packages must be in either the *main* or *contrib* archive
+area. Each binary package's archive area is indicated by its ``Section``
+field: see :ref:`s-subsections`.
+
+Source packages in *main* with a mixture of *main* and *contrib* binary
+packages are more complex for archive tooling to handle, and therefore
+should be limited to situations where it would be inconvenient to split
+the source package. If it is straightforward to split the source package
+into a *main* part and a *contrib* part that are built separately, then
+those parts should be represented as separate source packages.
+
+When a *main* source package has a mixture of *main* and *contrib* binary
+packages, the source package and the *main* binary packages must follow
+the requirements for *main* packages, but the *contrib* binary packages
+may follow the weaker requirements for *contrib* packages. In particular,
+source packages in *main* must not have build dependencies outside *main*,
+but the *contrib* binary packages may have runtime dependencies outside
+*main*.
+
 .. [2]
See `What Does Free Mean? `_ for
more about what we mean by free software.
@@ -192,6 +213,10 @@ Examples of packages which would be included in *contrib* are:
 - wrapper packages or other sorts of free accessories for non-free
   programs.
 
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
 .. _s-non-free:
 
 The non-free archive area
@@ -214,6 +239,10 @@ In addition, the packages in *non-free*
 - must meet all policy requirements presented in this manual that it is
   possible for them to meet.  [4]_
 
+If a source package is in the *non-free* archive area, then each of the
+binary packages that it produces must also be in the *non-free* archive
+area.
+
 .. [4]
It is possible that there are policy requirements which the package
is unable to meet, for example, if the source is unavailable. These
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 54a473b..6009819 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -44,6 +44,13 @@ Version 4.7.0
 
 Unreleased.
 
+2.2.1
+Document that source packages in the *main* archive area may build
+binary packages in the *contrib* archive area, although this is
+discouraged unless the source package is inconvenient to split.  This
+does not relax the requirement that source packages in *main* must not
+have build dependencies outside of *main*.
+
 2.2.2
 The ``non-free-firmware`` 

Bug#1051355: Processed: your mail

[Leandro Cunha]

Hi,

Em dom., 10 de set. de 2023 15:01, Andres Salomon 
escreveu:

> Unfortunately 117 *also* segfaults on sid.
>
> I'm tempted to try a newer clang, but probably not 15 since debian's
> planning to remove it. 16, I guess?
>

Arch is already with Clang 16 and I tested Chromium 117 in a vm that I
installed here and it was working normally.

>

Bug#1051633: clamtk: uploader email address maybe invalid (Andreas Cadhalpun)

[Ben Tris]

Source: clamtk
Version: 6.07-1.1
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org

Dear Maintainer,

The email under uploader Andreas Cadhalpun is now
 this is not found in qa.
I could not find more info.


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/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#1050638: clamav 0.103.10+dfsg-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1050638 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.103.10+dfsg-0+deb11u1

Explanation: new upstream stable release

Bug#1050639: clamav 1.0.3+dfsg-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1050639 = 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: clamav
Version: 1.0.3+dfsg-1~deb12u1

Explanation: new upstream stable release  

Bug#1051509: libclamunrar 1.0.3-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1051509 = 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: libclamunrar
Version: 1.0.3-1~deb12u1

Explanation: new upstream stable release

Bug#1051639: xskat: Homepage doesn't exist anymore

[Marco Moock]

Package: xskat
Version: 4.0-8
Severity: minor

Dear Maintainer,


http://xskat.de that is listed as the homepage for the project, doesn't provide 
it anymore. It is now a blog about philosophy.
I don't know if another homepage exists.

-- 
kind regards
Marco

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

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

Versions of packages xskat depends on:
ii  libc6 2.37-8
ii  libx11-6  2:1.8.6-1

xskat recommends no packages.

xskat suggests no packages.

-- no debconf information

Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates

[Manphiz]

David Bremner  writes:

> Manphiz  writes:
>
>>
>> Hi sten,
>>
>> When trying to pick a new upstream to rebase, I found that pulling
>> either upstream repo will result in an incompatible git history versus
>> the current debian/master branch on salsa.  I wonder how I should handle
>> this?  Is it OK to force push to master?  Will it affect existing
>> annotated tags?
>
> Please don't force push the public history. There are various ways to
> "fake merge" that are preferable.

Hi David,

Any pointers to the "fake merge" approaches?  Would like to take a look.

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#941808: java-package: depends on transitional libgl1-mesa-glx

[Sebastian Ramacher]

Control: severity -1 serious
Control: tags -1 sid trixie

On 2019-10-05 23:28:58 +0200, Thorsten Glaser wrote:
> Package: java-package
> Version: 0.62
> Severity: important
> 
> libgl1-mesa-glx is a transitional dummy package for
>   Depends: libgl1, libglx-mesa0
> and could be safely uninstalled except java-package
> Depends on it.
> 
> Please change the dependency to the depended-on packages.

libgl1-mesa-glx got removed from unstable and java-package is holding it
back from being removed from testing. Raising the severity accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1051561: RoM as well

[Kunal Mehta]

Thanks for filing, just adding/confirming as maintainer that src:zimlib 
should be removed now. :)


-- Kunal

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Sun, Sep 10, 2023 at 10:38:45AM +0200, Timo Sigurdsson wrote:
> Package: linux
> Version: 6.1.52-1
> Severity: grave
> 
> Dear Maintainers,
> 
> linux-image-6.1.0-12-amd64 causes a serious regression in nftables.
> After upgrading one of my machines, nftables fails to start -
> leaving the system without an active firewall.
> 
> Doing
> `nft -cf /etc/nftables.conf'
> throws many "Operation not supported" errors on rulesets that have been in 
> place for months wihtout issues.
> 
> 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
> 
> 
> Downgrading to linux-image-6.1.0-11-amd64 resolves the issue.
> 
> Notes: I'm running a local rebuild of linux-image-amd64 with a few
> additional symbols enabled. But since these symbols are totally
> unrelated to the netfilter subsystem and there are no changes to the
> source itself, I'm certain, this affects the original Debian build
> as well. Whether it only affects certain architectures or rulesets,
> I can't say, though.
> 
> I'm cc'ing debian-secur...@debian.org because the update came via
> the stable-security channel.

This is defintively not 'grave' but I keep it for the time beeing at
RC level and might be adjusted later.

Would it be possible to provide a minimal set of rules triggering the
issue? Can you reproduce the issue with the official build?

Regards,
Salvatore

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

[Luca Boccassi]

On Sun, 10 Sept 2023 at 11:31, Simon McVittie  wrote:
>
> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> > Luca, am I right that service directories are specific to, well, services?
> > If so, what would you think of moving them to Policy 9.3 alongside the
> > other discussion of systemd units?  They feel out of place here, since
> > packages that do not use services cannot use this functionality
>
> I'm not Luca, but I think you're correct here.

Moved as suggested. Also incorporated your suggestion on the versioned
virtual package dependency verbatim.

> > Luca Boccassi  writes:
> > > +Packages might need additional files or directories to implement their
> > > +functionality. Directories that are located under ``/var/`` or
> > > +``/etc/``, and files that are located under ``/var/``, should not be
> > > +created manually via maintainer scripts, but instead be declaratively
> > > +defined via the `tmpfiles.d
> > > +`_
> > > +interface.  Files and directories under ephemeral filesystems such as
> > > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets.
> >
> > I understand the empty directory part, but I don't believe "files that are
> > located under /var" is correct unless you specifically mean *empty* files
> > (and even then, I'm not clear on precisely when this would be needed).
> > For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
> > maintainer script, and I can see no possible way that action could (or
> > should) be handled by the tmpfiles.d mechanism.
>
> In general tmpfiles.d handles files that exist only as metadata: symbolic
> links (for which the target is the only interesting fact), empty files
> (for which the existence and ownership/permissions are the only interesting
> facts), directories (ditto) and so on.
>
> It can also handle files that have static initial contents that do not
> vary between systems, but can change in a system-specific way later,
> with initial contents either hard-coded in the tmpfiles.d snippet (for
> short text strings) or copied from somewhere below /usr (canonically
> /usr/share/factory).
>
> Files generated by non-trivial imperative code, like machine-specific
> initial contents (/var/lib/dbus/machine-id) or some sort of compiler
> (/var/lib/gnubg/gnubg_ts0.bd, as far as I can tell), are out of scope for
> tmpfiles.d, so I think you're right to be concerned that Luca's wording
> as written is asking gnubg to do something that is unimplementable.
> ch-maintainerscripts.rst has the same issue.
>
> Perhaps "files with trivial contents that are located under /var" would be
> a good wording that is not overly specific about implementation details,
> covers the 90% case, and leaves room for exceptions by declaring packages
> like dbus and gnubg to be non-trivial?

I have reworded as suggested, citing symlinks or short fixed strings
as examples.

> If /var/lib/gnubg/gnubg_ts0.bd is deterministically compiled from
> files shipped in the .deb as a time/space trade-off, is only written
> during package management operations, and is otherwise read-only, then
> perhaps it should live in /usr, but that's orthogonal to wanting to use
> tmpfiles.d where feasible. (Prior art for similar situations includes
> Python bytecode, glibc locales, GLib gschemas.compiled and giomodule.cache,
> and so on.)

We don't have to handle it with this change/bug and as mentioned I've
already reworded it as suggested, but to clarify my thinking there,
the place I was coming from was the factory reset and first boot
angle. When doing a first boot with only the OS vendor tree under /usr
and nothing else, you want to get to a working system, and if there
are complex files created under /var by maintainer scripts, that's
kinda of a problem. This is where tmpfiles.d plus Credentials
(https://systemd.io/CREDENTIALS/ see examples toward the end
especially) can come in and help, even with non-trivial files, such as
users, passwords and ssh keys.
Perhaps those complex binaries should be created by oneshot services
that run at boot with a ConditionPathExists=!/var/some/complex/binary
other than maintainer scripts? That way if /var is blown away, you
still get a working system on next boot.

But again, happy to shelve this for now, as it's a more complex topic.
See attached file for new revision, also pushed to Salsa.
From  Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Tue, 9 May 2023 01:38:13 +0100
Subject: [PATCH] Define service directories and tmpfiles.d interfaces and
 usage

---
 policy/ch-files.rst | 49 +
 policy/ch-maintainerscripts.rst |  7 +
 policy/ch-opersys.rst   | 21 ++
 3 files changed, 77 insertions(+)

diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index b34c183..7d0837c 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -722,6 +722,55 @@ 

Bug#1051604: libime FTCBFS: fails to run built tools

[Helmut Grohne]

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

libime fails to cross build from source, because it fails running built
tools such as LibIME::pinyindict. Actually, CMake is clever here in that
it recognizes that it cannot run those things and fails with "not
found". When looking into this, I noticed that all of the affected tools
are packaged in libime-bin, so in principle a very simple solution is
adding a build dependency on that and just running the installed tools.
That is ok if all of tools that are used have architecture-independent
output. I'm really not sure whether that's right and unfortunately
libime-bin entirely lacks documentation that would assist in figuring
this out. Can you help here? Do you understand what the tools in
libime-bin do and whether their output depends on the architecture used
to run them? If their output artifacts are textual, the answer probably
is that they are architecture-independent. If their output is binary,
more inspection is needed. Does the output depend on the number of bits
a pointer has? Does the output depend on the endianess? If we determine
that libime-bin really has tools that are not architecture-independent,
please do *not* apply the attached patch. Rather explicitly mark
libime-bin as "Multi-Arch: no" instead and close this bug.

So now we assume that libime-bin only has tools that are
architecture-independent. Then it should be marked "Multi-Arch: foreign"
instead. Then my patch can be used to use the installed libime-bin and
that makes the cross build succeed. It is not clear to me whether the
result actually is working or how I could test for that.

Note that the patch adds a dependency on libime-bin:native. This is
necessary, because currently libime-bin is not Multi-Arch: foreign. Once
you add that, the :native annotation must be deleted.

I hope you can help me figure this out.

Helmut
diff --minimal -Nru libime-1.1.1/debian/changelog libime-1.1.1/debian/changelog
--- libime-1.1.1/debian/changelog   2023-08-22 19:21:32.0 +0200
+++ libime-1.1.1/debian/changelog   2023-09-10 11:42:12.0 +0200
@@ -1,3 +1,10 @@
+libime (1.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Run native tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 10 Sep 2023 11:42:12 +0200
+
 libime (1.1.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru libime-1.1.1/debian/control libime-1.1.1/debian/control
--- libime-1.1.1/debian/control 2023-08-20 02:46:15.0 +0200
+++ libime-1.1.1/debian/control 2023-09-10 11:42:12.0 +0200
@@ -13,6 +13,7 @@
  libboost-iostreams-dev (>= 1.61),
  libdouble-conversion-dev (>= 3.1.5-5~),
  libfcitx5utils-dev (>= 5.1~),
+ libime-bin:native ,
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://github.com/fcitx/libime
diff --minimal -Nru libime-1.1.1/debian/patches/cross.patch 
libime-1.1.1/debian/patches/cross.patch
--- libime-1.1.1/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ libime-1.1.1/debian/patches/cross.patch 2023-09-10 11:42:12.0 
+0200
@@ -0,0 +1,52 @@
+--- libime-1.1.1.orig/tools/CMakeLists.txt
 libime-1.1.1/tools/CMakeLists.txt
+@@ -2,17 +2,14 @@
+ target_link_libraries(libime_slm_build_binary kenlm)
+ 
+ install(TARGETS libime_slm_build_binary DESTINATION ${CMAKE_INSTALL_BINDIR})
+-add_executable(LibIME::slm_build_binary ALIAS libime_slm_build_binary)
+ 
+ add_executable(libime_prediction libime_prediction.cpp)
+ target_link_libraries(libime_prediction LibIME::Core)
+ install(TARGETS libime_prediction DESTINATION ${CMAKE_INSTALL_BINDIR})
+-add_executable(LibIME::prediction ALIAS libime_prediction)
+ 
+ add_executable(libime_pinyindict libime_pinyindict.cpp)
+ target_link_libraries(libime_pinyindict LibIME::Pinyin)
+ install(TARGETS libime_pinyindict DESTINATION ${CMAKE_INSTALL_BINDIR})
+-add_executable(LibIME::pinyindict ALIAS libime_pinyindict)
+ 
+ add_executable(libime_history libime_history.cpp)
+ target_link_libraries(libime_history LibIME::Core)
+@@ -22,7 +19,6 @@
+ add_executable(libime_tabledict libime_tabledict.cpp)
+ target_link_libraries(libime_tabledict LibIME::Table)
+ install(TARGETS libime_tabledict DESTINATION ${CMAKE_INSTALL_BINDIR})
+-add_executable(LibIME::tabledict ALIAS libime_tabledict)
+ 
+ add_executable(libime_migrate_fcitx4_table libime_migrate_fcitx4_table.cpp)
+ target_link_libraries(libime_migrate_fcitx4_table LibIME::Table 
Boost::iostreams Boost::filesystem)
+@@ -33,3 +29,23 @@
+ target_link_libraries(libime_migrate_fcitx4_pinyin LibIME::Pinyin 
Boost::iostreams Boost::filesystem)
+ install(TARGETS libime_migrate_fcitx4_pinyin DESTINATION 
${CMAKE_INSTALL_BINDIR})
+ add_executable(LibIME::migrate_fcitx4_pinyin ALIAS 
libime_migrate_fcitx4_pinyin)
++
++if(CMAKE_CROSSCOMPILING)
++find_program(native_slm_build_binary NAMES libime_slm_build_binary REQUIRED)
++add_executable(LibIME::slm_build_binary IMPORTED 

Bug#1051173: libgwenhywfar FTCBFS: fails to run mklistdoc

[Helmut Grohne]

Hi Micha,

On Sat, Sep 09, 2023 at 11:10:08AM +0200, Micha Lenk wrote:
> I've also commited the suggested changes to the Debian package. This allows
> us to see how the cross build is doing in the Salsa CI builds.

Thank you.

> Unfortunately the package seems to still fail to cross build from source:
> https://salsa.debian.org/aqbanking-team/pkg-libgwenhywfar/-/jobs/4677663
> 
> Would you mind to take a more elaborate look and suggest anything that could
> help fixing the cross build?
> Or is this an issue of the Salsa CI pipeline that is okay to ignore for now?

Sure. The failure is checking for the existence of /proc/self/maps. When
you use AC_CHECK_FILE, it is to be understood as a check of the host
machine, but we're on the build machine, so the check cannot determine
the correct result. Sometimes, people use it to discover headers. That's
wrong and they should use test -e instead. In this case, the check is
totally right. A cross builder needs to pass the correct result into the
build. We don't currently have a good mechanism for doing so. In my
local builds, I export ac_cv_file__proc_self_maps=yes when building for
linux and then it works. If you want cross builds to just work, you may
consider adding the following to debian/rules:

ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
ifeq ($(DEB_HOST_ARCH_OS),linux)
export ac_cv_file__proc_self_maps=yes
endif
endif

In principle, I think such code should not be part of packages, but
that's what we do in a number of packages already. Some check results
are also part of cross-config, but that's not in a good shape nor
maintained.

Helmut

Bug#1051602: encfs FTCBFS: a try run check fails

[Helmut Grohne]

Source: encfs
Version: 1.9.5-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

encfs fails to cross build from source, because a try run check fails.
Looking closer this check isn't part of encfs itself part of a vendored
dependency. Looking even closer, the relevant dependency is used for
unit testing. Since we cannot run tests during cross builds, we might as
well skip building tests. Indeed, doing so fixes the cross build. I'm
attaching a patch for your convenience.

I observe that encfs does not run tests during build at all. Still I
consider building the tests a form of testing and thus have not disabled
that.

Helmut
diff --minimal -Nru encfs-1.9.5/debian/changelog encfs-1.9.5/debian/changelog
--- encfs-1.9.5/debian/changelog2023-01-21 18:06:03.0 +0100
+++ encfs-1.9.5/debian/changelog2023-09-09 13:25:59.0 +0200
@@ -1,3 +1,10 @@
+encfs (1.9.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip building tests when DEB_BUILD_OPTIONS=nocheck (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 09 Sep 2023 13:25:59 +0200
+
 encfs (1.9.5-2) unstable; urgency=medium
 
   * Update debconf template translation
diff --minimal -Nru encfs-1.9.5/debian/rules encfs-1.9.5/debian/rules
--- encfs-1.9.5/debian/rules2023-01-21 18:06:03.0 +0100
+++ encfs-1.9.5/debian/rules2023-09-09 13:25:57.0 +0200
@@ -14,7 +14,12 @@
 
 override_dh_auto_configure:
# keep cmake's default rpath handling with rewritting on installation 
but target a custom folder
-   dh_auto_configure -- -DUSE_INTERNAL_TINYXML=off -DBUILD_SHARED_LIBS=on 
-DINSTALL_LIBENCFS=on -DLIB_INSTALL_DIR=lib/encfs
+   dh_auto_configure -- \
+   -DUSE_INTERNAL_TINYXML=off \
+   -DBUILD_SHARED_LIBS=on \
+   -DINSTALL_LIBENCFS=on \
+   -DLIB_INSTALL_DIR=lib/encfs \
+   -DBUILD_UNIT_TESTS=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),off,on)
 
 ifneq ($(DOENCFSTESTS),FORCE)
 # needs the fuse kernel module -> ignore

Bug#1051603: 19 packages from graphviz have an undeclared file conflict

[Helmut Grohne]

Package: 
libgvplugin-gtk-dev,libgvplugin-neato-layout-dev,libgvplugin-neato-layout,libgvplugin-webp-dev,libgvplugin-webp,libgvplugin-gd,libxdot-dev,libgvplugin-gdk,libgvplugin-xlib,liblab-gamut-dev,libgvplugin-pango-dev,libgvplugin-rsvg-dev,libgvplugin-pango,libgvplugin-rsvg,libgvplugin-gtk,libgvpr-dev,libgvplugin-xlib-dev,libgvplugin-gd-dev,libgvplugin-gdk-dev
Version: 8.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libgraphviz-dev libgvc6 libgvc6-plugins-gtk

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gd.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gd-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gdk.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gdk-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gtk.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gtk-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_neato_layout.so
is contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-neato-layout-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_pango.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-pango-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_rsvg.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-rsvg-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_webp.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-webp-dev as present in experimental

The file /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_xlib.so is
contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-xlib-dev as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/libgvpr.so
 * /usr/lib/x86_64-linux-gnu/pkgconfig/libgvpr.pc
are contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libgvpr-dev as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/pkgconfig/liblab_gamut.pc
 * /usr/lib/x86_64-linux-gnu/liblab_gamut.so
are contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * liblab-gamut-dev as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/pkgconfig/libxdot.pc
 * /usr/lib/x86_64-linux-gnu/libxdot.so
are contained in the packages
 * libgraphviz-dev as present in bookworm|bullseye|trixie|unstable
 * libxdot-dev as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gd.so.6.0.0
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gd.so.6
are contained in the packages
 * libgvc6 as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gd as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_neato_layout.so.6.0.0
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_neato_layout.so.6
are contained in the packages
 * libgvc6 as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-neato-layout as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_pango.so.6
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_pango.so.6.0.0
are contained in the packages
 * libgvc6 as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-pango as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_webp.so.6
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_webp.so.6.0.0
are contained in the packages
 * libgvc6 as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-webp as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_xlib.so.6
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_xlib.so.6.0.0
are contained in the packages
 * libgvc6 as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-xlib as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gdk.so.6
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gdk.so.6.0.0
are contained in the packages
 * libgvc6-plugins-gtk as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gdk as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gtk.so.6
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_gtk.so.6.0.0
are contained in the packages
 * libgvc6-plugins-gtk as present in bookworm|bullseye|trixie|unstable
 * libgvplugin-gtk as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/graphviz/libgvplugin_rsvg.so.6
 * 

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Salvatore Bonaccorso]

Hi,

On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > On Sat, Sep 09, 2023 at 10:23:32PM +0200, Salvatore Bonaccorso wrote:
> > > Source: mutt
> > > Version: 2.2.9-1
> > > Severity: grave
> > > Tags: security upstream
> > > Justification: user security hole
> > > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > > 
> > > 
> > > Hi,
> > > 
> > > The following vulnerabilities were published for mutt.
> > > 
> > > CVE-2023-4874[0]:
> > > | Null pointer dereference when viewing a specially crafted email in
> > > | Mutt >1.5.2 <2.2.12
> > > 
> > > 
> > > CVE-2023-4875[1]:
> > > | Null pointer dereference when composing from a specially crafted
> > > | draft message in Mutt >1.5.2 <2.2.12
> > > 
> > > Make sure to include all three commits referenced from [2], the last
> > > one is technically not part of the two CVEs, but another crash found
> > > by upstream.
> > > 
> > > 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-4874
> > > https://www.cve.org/CVERecord?id=CVE-2023-4874
> > > [1] https://security-tracker.debian.org/tracker/CVE-2023-4875
> > > https://www.cve.org/CVERecord?id=CVE-2023-4875
> > > [2] 
> > > http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/56.html
> > > 
> > > Please adjust the affected versions in the BTS as needed.
> > 
> > Thanks for raising this, I'm uploading the new packages with the fixes 
> > today.
> 
> FWIW, I have done the bookworm-security upload already to
> security-master, and still working on the bullseye-security one (with
> plan to release the DSA tonight ideally).

Here are the debdiffs for those.

Regards,
Salvatore
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2022-12-07 22:39:58.0 +0100
+++ mutt-2.0.5/debian/changelog 2023-09-10 13:53:23.0 +0200
@@ -1,3 +1,14 @@
+mutt (2.0.5-4.1+deb11u3) bullseye-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix rfc2047 base64 decoding to abort on illegal characters.
+(CVE-2023-4874, CVE-2023-4875) (Closes: #1051563)
+  * Check for NULL userhdrs. (CVE-2023-4875) (Closes: #1051563)
+  * Fix write_one_header() illegal header check. (CVE-2023-4874)
+(Closes: #1051563)
+
+ -- Salvatore Bonaccorso   Sun, 10 Sep 2023 13:53:23 +0200
+
 mutt (2.0.5-4.1+deb11u2) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2022-12-07 22:39:58.0 +0100
+++ mutt-2.0.5/debian/patches/series2023-09-10 13:53:23.0 +0200
@@ -18,3 +18,6 @@
 upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
 upstream/Fix-public-key-block-listing-for-old-versions-of-gpg.patch
 upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
+upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
+upstream/Check-for-NULL-userhdrs.patch
+upstream/Fix-write_one_header-illegal-header-check.patch
diff -Nru mutt-2.0.5/debian/patches/upstream/Check-for-NULL-userhdrs.patch 
mutt-2.0.5/debian/patches/upstream/Check-for-NULL-userhdrs.patch
--- mutt-2.0.5/debian/patches/upstream/Check-for-NULL-userhdrs.patch
1970-01-01 01:00:00.0 +0100
+++ mutt-2.0.5/debian/patches/upstream/Check-for-NULL-userhdrs.patch
2023-09-10 13:53:23.0 +0200
@@ -0,0 +1,50 @@
+From: Kevin McCarthy 
+Date: Mon, 4 Sep 2023 12:50:07 +0800
+Subject: Check for NULL userhdrs.
+Origin: 
https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4875
+
+When composing an email, miscellaneous extra headers are stored in a
+userhdrs list.  Mutt first checks to ensure each header contains at
+least a colon character, passes the entire userhdr field (name, colon,
+and body) to the rfc2047 decoder, and safe_strdup()'s the result on
+the userhdrs list.  An empty result would from the decode would result
+in a NULL headers being added to list.
+
+The previous commit removed the possibility of the decoded header
+field being empty, but it's prudent to add a check to the strchr
+calls, in case there is another unexpected bug resulting in one.
+
+Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
+crashes, giving a working example draft message, and providing the
+stack traces for the two NULL derefences.
+---
+ sendlib.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index c2283972f1d3..763bff4117f2 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -2418,7 +2418,7 @@ int 

Bug#1051606: RM: sysprof [i386] -- RoM; ANAIS; The GUI binary package is no longer built

[Jeremy Bícha]

Package: ftp.debian.org

Please remove the sysprof binary package from i386 because it is
intentonally no longer built there. The rest of the binaries built by
the sysprof source package are built on i386.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Salvatore Bonaccorso]

Hi Antonio,

On Sun, Sep 10, 2023 at 03:57:58PM +0200, Antonio Radici wrote:
> On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> > Hi Antonio,
> > 
> > FWIW, I have done the bookworm-security upload already to
> > security-master, and still working on the bullseye-security one (with
> > plan to release the DSA tonight ideally).
> 
> Ack, thanks for the update, I assume this was a particularly serious issue 
> that
> had to be handled immediately!

In retrospect, I'm not completely sure, but better to be on the safe
side in this case. The NULL pointer dereference flaw reported by
Chenyuan Mi is one when composing from a specially crafted draft
message, so rather on the harmless side, but the second is when
viewing a message with specially crafted headers, leading to a crash.
OTOH it is isolated to such an email, when viewing a message with
specially crafted headers, see the commit
https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0
in particular.

I agree that maybe I should have waited for you for comments, which I
try to remember to keep in mind for any future occurence.

Regards,
Salvatore

Bug#1049412: logcheck: Does not respect removal of /etc/logcheck/header.txt in bullseye

[Richard Lewis]

On Tue, 15 Aug 2023 19:54:26 +0200 Santiago Vila  wrote:

> In preinst, do something like this:
>
> if upgrading-from-previous-version-whatever-is-coded
>if [ ! -f /etc/logcheck/header.txt ]; then
>  touch /etc/logcheck.header.was.removed.txt
>fi
> fi
>
> Then in postinst, do something like this:
>
> if [ -f /etc/logcheck.header.was.removed.txt ]
>rm -f /etc/logcheck/header.txt
>rm -f /etc/logcheck.header.was.removed.txt
> fi
>
> Completely untested, just an idea.

https://salsa.debian.org/debian/logcheck/-/merge_requests/20 does this

Bug#1051627: units: The temperature conversion between Fahrenheit and Celcius is wrong

[Mark Grieveson]

Package: units
Version: 2.22-2
Severity: normal
X-Debbugs-Cc: markgrieve...@yahoo.ca

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I was trying to convert a temperature from degrees Celcius ("degC") to degrees 
Fahrenheit ("degF")

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

I typed "0 degC" as the unit I had, and I typed "degF" as the unit I wanted.

   * What was the outcome of this action?

You have: 0 degC
You want: degF
* 0
/ inf

   * What outcome did you expect instead?

Zero degrees Celcius equals 32 degrees Fahrenheit.  So, I expected the 
following:

You have: 0 degC
You want: degF
* 32


*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 units depends on:
ii  libc6 2.36-9+deb12u1
ii  libreadline8  8.2-1.3

Versions of packages units recommends:
ii  python3   3.11.2-1+b1
ii  python3-requests  2.28.1+dfsg-1

units suggests no packages.

-- no debconf information

Bug#1051544: ding: looking up words is very slow

[Christian Weiske]

I got a response from Markus Kohm:
The problem is known, but he does not intent to fix it because he does
not have enough time.
He recommends pdfjam which can do the same task.

So I think a5toa4 should be removed.

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Christian Weiske]

I got a response from Markus Kohm:
The problem is known, but he does not intent to fix it because he does
not have enough time.
He recommends pdfjam which can do the same task.

So I think a5toa4 should be removed.

Bug#1051629: chromium: Crash with seqfault when starting

[Michael Rasmussen]

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Crash when starting:
[411709:411709:0910/203433.221232:ERROR:chrome_browser_cloud_management_controller.cc(163)]
 Cloud management controller initialization aborted as CBCM is not enabled.
[411709:411709:0910/203433.290281:ERROR:object_proxy.cc(590)] Failed to call 
method: org.freedesktop.portal.Settings.Read: object_path= 
/org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.UnknownMethod: No 
such interface “org.freedesktop.portal.Settings” on object at path 
/org/freedesktop/portal/desktop
libva error: vaGetDriverNameByIndex() failed with unknown libva error, 
driver_name = (null)
[411709:411737:0910/203433.474597:ERROR:nss_util.cc(357)] After loading Root 
Certs, loaded==false: NSS error code: -8018
[0910/203433.684242:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0910/203433.684772:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Trace/breakpoint trap


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

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

Versions of packages chromium depends on:
ii  chromium-common  116.0.5845.180-1
ii  libasound2   1.2.9-2
ii  libatk-bridge2.0-0   2.49.91-2
ii  libatk1.0-0  2.49.91-2
ii  libatomic1   13.2.0-3
ii  libatspi2.0-02.49.91-2
ii  libbrotli1   1.0.9-2+b6
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libcups2 2.4.2-5
ii  libdbus-1-3  1.14.10-1
ii  libdouble-conversion33.3.0-1
ii  libdrm2  2.4.115-1
ii  libevent-2.1-7   2.1.12-stable-8
ii  libexpat12.5.0-2
ii  libflac121.4.3+ds-2
ii  libfontconfig1   2.14.2-5
ii  libfreetype6 2.13.2+dfsg-1
ii  libgbm1  23.1.7-1
ii  libgcc-s113.2.0-3
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjsoncpp25 1.9.5-6
ii  liblcms2-2   2.14-2
ii  libminizip1  1:1.2.13.dfsg-3
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libopenh264-72.3.1+dfsg-3
ii  libopenjp2-7 2.5.0-2
ii  libopus0 1.4-1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libpng16-16  1.6.40-1
ii  libpulse016.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  libwebpdemux21.2.4-0.2
ii  libwebpmux3  1.2.4-0.2
ii  libwoff1 1.0.2-2
ii  libx11-6 2:1.8.6-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxkbcommon01.5.0-1
ii  libxml2  2.9.14+dfsg-1.3
ii  libxnvctrl0  525.125.06-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxslt1.1   

Bug#1051611:

[Pascal Hambourg]

On 10/09/2023 at 16:59, G M wrote:

Install boot loader Grub - error.
Partitions: SCSI 20GB, Default partition layout for BIOS systems.


Failure to mount efivarfs in the target system. Looks like a duplicate 
of .

Bug#1051637: ITP: python-bitmath -- handle file sizes with different prefix notations

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-bitmath
  Version : 1.3.3.1
  Upstream Contact: Tim Bielawa 
* URL : https://github.com/tbielawa/bitmath
* License : Expat
  Programming Lang: Python
  Description : handle file sizes with different prefix notations

 bitmath simplifies many facets of interacting with file sizes in various units.
 Originally focusing on file size unit conversion, functionality now includes:
  * Converting between SI and NIST prefix units (kB to GiB)
  * Converting between units of the same type (SI to SI, or NIST to NIST)
  * Automatic human-readable prefix selection (like in hurry.filesize)
  * Basic arithmetic operations (subtracting 42KiB from 50GiB)
  * Rich comparison operations (1024 Bytes == 1KiB)
  * bitwise operations (<<, >>, &, |, ^)
  * Reading a device's storage capacity (Linux/OS X support only)
  * argparse integration as a custom type
  * click integration as a custom parameter type
  * progressbar integration as a better file transfer speed widget
  * String parsing
  * Sorting
 .
 In addition to the conversion and math operations, bitmath provides human
 readable representations of values which are suitable for use in interactive
 shells as well as larger scripts and applications. The format produced for
 these representations is customizable via the functionality included in stdlibs
 string.format.

I intend to maintain this package as part of DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmT+GqMbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqHmIH/iK1ORX0zi4vefRUgYLL
Xlr8MOW83uJzOOTUOF2jfz6Qs/mIYxekeRHR8tAAY4yG37JTRcqgJHtF9GN+XdSx
mrpyRgP8TK0Z9mdDoVd9n0eICK3DLTAePR5zOF/o9CBaEjHkO11851+wU76TNBDU
PXF0853o4z5AcDTlpF5glssHuKLgMlq5jpPXdKJPl1lKo8/ztgs8adC1cBsaUomD
NBCSTGAxerccfHydI0N/V12lmGjR5uHfeTR4gkbHhNx8TEXmwtfNNYvo4jNiPTq0
dzcOn7AY3DhPhgCKkH0UzP0aHncSBwwrMyfNkXHhAC74/Nx25jXXG8BhYNxit9zU
rak=
=30pw
-END PGP SIGNATURE-

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Sebastian Andrzej Siewior]

On 2023-09-10 15:57:13 [+0200], Antonio Radici wrote:
Hi Antonio,

> On Sun, Sep 10, 2023 at 01:47:30PM +0200, Salvatore Bonaccorso wrote:
> > Hi Antonio,
> > 
> > On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote:
> > > On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > > > Thanks for raising this, I'm uploading the new packages with the fixes 
> > > > today.
> > > 
> > > apparently someone else did a NMU with the new version and incorrectly 
> > > closed
> > > the bug.
> > 
> > You mean the NMU by Sebastian?
> 
> Yes

The new version addressed the CVEs so closing the bug isn't incorrect?

> > 
> > > I reopened the bug because stable needs to be addressed (which I will do 
> > > today
> > > as I just wrote) and then it's probably worth investigating how to 
> > > integrate
> > > those NMU into the git repo
> > 
> > Actually you do not need to reopen. A bug can be closed with mutliple
> > versions, that is 2.2.12-0.1 closes it, but as well so does then the
> > 2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one.
> > 
> > I think that was not the case several years ago, but nowdays BTS can
> > handle that, and will reflect it nicely as well in the version graph.
> > 
> > Or were you meaning something different?
> 
> Ah ok good, then I will add the extra versions if they are not there already

Right, here is an example for the bug closed in stable, and
experimental.

https://bugs.debian.org/1034720

Sebastian

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

[Timo Röhling]

* Russ Allbery  [2023-09-10 09:16]:

In order to structure the discussion and prod people into thinking about
the implications, I will make the following straw man proposal.  This is
what I would do if the decision was entirely up to me:



Licenses will be included in common-licenses if they meet all of the
following criteria:



* The license is DFSG-free.
* Exactly the same license wording is used by all works covered by it.
* The license applies to at least 100 source packages in Debian.
* The license text is longer than 25 lines.


In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.


For me, this outcome would already be an improvement over the current
situation and alleviate my biggest pain point (CC licenses).
Still, I'd like to be significantly more relaxed.

I propose the following three criteria must be satisfied for
inclusion in /usr/share/common-licenses:

 * The license is DFSG-free.
 * Exactly the same license wording is used by all works covered by it.
 * The license is in the SPDX list of common licenses 
(https://spdx.org/licenses/)
   OR
   The license applies to at least 100 source packages in Debian.


I am not committed to the 100 source packages threshold, it is
mostly intended as fallback for a hypothetical future license which
is super popular but for some reason does not make it to the SPDX
list in a timely manner.

One very intentional side effect of my proposal is a nudge towards
using SPDX License Identifiers in d/copyright files.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Christian Weiske]

Hello Hilmar,


> Seems to be a long standing issue [1]. Are you willing to contact the 
> upstream author of the pfarrei package? I don't really have the time
> to care about upstream issues.

I contacted Markus Kohm, which is the maintainer according to
https://www.tug.org/texlive//Contents/live/texmf-dist/tex/latex/pfarrei/a5toa4.tex

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

Bug#1037878: ultracopier: diff for NMU version 2.2.6.0-1.1

[Marcos Talau]

Control: tags 1037878 + patch
Control: tags 1037878 + pending


Dear maintainer,

I've prepared an NMU for ultracopier (versioned as 2.2.6.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ultracopier-2.2.6.0/debian/changelog ultracopier-2.2.6.0/debian/changelog
--- ultracopier-2.2.6.0/debian/changelog	2022-06-27 03:16:15.0 +0530
+++ ultracopier-2.2.6.0/debian/changelog	2023-09-10 13:25:35.0 +0530
@@ -1,3 +1,11 @@
+ultracopier (2.2.6.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/01-fix_ftbfs_gcc-13.patch: New. Fix FTBFS with gcc-13.
+Thanks to alpha_one_x86 (Closes: #1037878).
+
+ -- Marcos Talau   Sun, 10 Sep 2023 13:25:35 +0530
+
 ultracopier (2.2.6.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #1013057).
diff -Nru ultracopier-2.2.6.0/debian/patches/01-fix_ftbfs_gcc-13.patch ultracopier-2.2.6.0/debian/patches/01-fix_ftbfs_gcc-13.patch
--- ultracopier-2.2.6.0/debian/patches/01-fix_ftbfs_gcc-13.patch	1970-01-01 05:30:00.0 +0530
+++ ultracopier-2.2.6.0/debian/patches/01-fix_ftbfs_gcc-13.patch	2023-09-10 13:25:35.0 +0530
@@ -0,0 +1,26 @@
+Description: Fix FTBFS with gcc-13
+Author: alpha_one_x86 
+Bug-Debian: https://bugs.debian.org/1037878
+Last-Update: 2023-09-10
+
+--- ultracopier-2.2.6.0.orig/cpp11addition.h
 ultracopier-2.2.6.0/cpp11addition.h
+@@ -7,6 +7,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #if ! defined(Q_LIKELY)
+ #if defined(__GNUC__)
+--- ultracopier-2.2.6.0.orig/lib/qt-tar-xz/QTarDecode.h
 ultracopier-2.2.6.0/lib/qt-tar-xz/QTarDecode.h
+@@ -8,7 +8,7 @@
+ 
+ #include 
+ #include 
+-#include 
++#include 
+ 
+ /// \brief read the raw tar data, and organize it into data structure
+ class QTarDecode
diff -Nru ultracopier-2.2.6.0/debian/patches/series ultracopier-2.2.6.0/debian/patches/series
--- ultracopier-2.2.6.0/debian/patches/series	1970-01-01 05:30:00.0 +0530
+++ ultracopier-2.2.6.0/debian/patches/series	2023-09-10 13:25:35.0 +0530
@@ -0,0 +1 @@
+01-fix_ftbfs_gcc-13.patch

Bug#1051590: general: Received error from D-Bus search

[WR]

Package: general
Severity: normal
X-Debbugs-Cc: kru...@gmail.com

Dear Maintainer,

Received error from D-Bus search provider org.gnome.Terminal.desktop:
Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Obiekt nie
istnieje w ścieżce „/org/gnome/Terminal/SearchProvider”

Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ecere-sdk

ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or
bookworm. Please remove this unmaintained package from the archive.

Cheers
-- 
Sebastian Ramacher

Bug#1051597: eom: Hardcodes dependency on removed transitional package libgl1-mesa-glx

[Adrian Bunk]

Package: eom
Version: 1.26.0-2
Severity: serious
Tags: trixie sid

eom hardcodes a dependency on the removed
transitional package libgl1-mesa-glx.

Bug#1051598: view3dscene: Hardcodes dependency on removed transitional packages

[Adrian Bunk]

Package: view3dscene
Version: 4.2.0-1
Severity: serious
Tags: trixie sid

Package: view3dscene
Architecture: any
Depends:
...
 libgl1-mesa-swx11 | libgl1-mesa-glx | libgl1-nvidia-glx,



This should be changed to depend on libgl1 instead.

Bug#1029126: Wishing for Emacs 29 in Debian

[Pásztor János]

Dear Maintenars,

Now that emacs 29.1 reached Debian testing (huge thanks for that!), I 
have attempted a simple backport to bookworm.
To my delight, with a minimal set of changes, one can successfully build 
and use emacs 29.1 on bookworm.


I hope that the initial patch what I have attached could help you create 
a proper backport in the main Debian archive.


Regards,
János PásztorFrom 29ac2f4a88846d0ba251df960fc3255870dd32d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1sztor=20J=C3=A1nos?= 
Date: Sun, 10 Sep 2023 10:27:33 +0200
Subject: [PATCH] Initial attempt of a simple backport

---
 debian/changelog | 6 ++
 debian/control   | 4 ++--
 debian/rules | 2 +-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 0aa4aa439d5..1fb9a568d6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+emacs (1:29.1+1-5~bpo12+1) bookworm-backports; urgency=medium
+
+  * Rebuild for bookworm-backports.
+
+ -- Pásztor János   Sun, 10 Sep 2023 10:21:03 +0200
+
 emacs (1:29.1+1-5) unstable; urgency=medium
 
   * Don't try to build with native compilation on riscv64 (Closes: #1050653).
diff --git a/debian/control b/debian/control
index 2d2a96a2471..5a06bfdc0c4 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  bsd-mailx | mailx,
  ca-certificates,
  dbus-x11,
- gcc-13,
+ gcc-12,
  debhelper-compat (= 13),
  dpkg-dev (>> 1.10.0),
  git,
@@ -19,7 +19,7 @@ Build-Depends:
  libasound2-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
  libcairo-dev,
  libdbus-1-dev,
- libgccjit-13-dev,
+ libgccjit-12-dev,
  libgif-dev,
  libgmp-dev,
  libgnutls28-dev,
diff --git a/debian/rules b/debian/rules
index f7cf5e5820e..e75abf74338 100755
--- a/debian/rules
+++ b/debian/rules
@@ -315,7 +315,7 @@ confflags_lucid += --without-gsettings
 define cfg_tree
   cd $(1) && \
 CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" \
-CC=gcc-13 \
+CC=gcc-12 \
 REL_ALLOC=no \
   $(CURDIR)/debian/build-src/configure $(confflags) $(2)
 endef
-- 
2.39.2

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

[Simon McVittie]

In general I support this direction.

On Sun, 25 Jun 2023 at 16:55:44 +0100, Luca Boccassi wrote:
> Packages shipping ``tmpfiles.d`` snippets should
> +depend on the appropriate virtual packages in the following order:
> +``default-systemd-tmpfiles | systemd-tmpfiles``.

I think it's worth saying explicitly that if the package relies on
functionality added in systemd version n, where n is newer than some
reasonable cutoff, it should depend on
default-systemd-tmpfiles (>= n) | systemd-tmpfiles (>= n)
instead.

If a package is targeting testing/unstable, then it can drop the version
constraint in the very common case where its tmpfiles.d snippet is processed
correctly by stable's systemd-tmpfiles. Similarly if it's targeting stable,
it can drop the version constraint if oldstable's systemd would have been
enough.

Perhaps this?

Packages shipping ``tmpfiles.d`` snippets should
depend on the appropriate virtual packages in the following order:
``default-systemd-tmpfiles (>= v) | systemd-tmpfiles (>= v)``,
where *v* is a version of systemd that provides all ``tmpfiles.d``
features that are required. The version constraint may be
omitted if it is satisfied by all implementations of the
``systemd-tmpfiles`` virtual package supported in the previous stable
release.

(If debhelper generates the dependency, in practice it's probably enough
for it to generate the unversioned dependency, and in the rare case
where a tmpfiles.d snippet needs new features, maintainers can add
the versioned dependency themselves.)

smcv

Bug#1051437: RM: gnome-metronome -- RoQA; RC-buggy; replaced by completely new rust app

[Jeremy Bícha]

Control: tags -1 -moreinfo

We do intend to package the new Rust version of gnome-metronome. This
has been blocked because it took us a while to get the Rust GTK
packaging up to date and more importantly, package rust-libadwaita in
a way that ftpmasters approved of.

rust-libadwaita-sys was recently accepted into Debian so we should be
able to get gnome-metronome updated later this year.

It feels to me like NEW processing is a bit slow these days so I would
prefer to avoid the wait. Therefore, I suggest we close this bug and
reconsider next year if gnome-metronome has still not made it to
Testing.

Thank you,
Jeremy Bícha

Bug#967324: eboard: depends on deprecated GTK 2

[Francesco Poli]

On Mon, 14 Aug 2023 13:22:13 +0200 Bastian Germann 
wrote:

> There are many alternatives for eboard in Debian. Maybe
> it is time to remove this package.

Fine, could you please name those many alternatives for eboard in
Debian?

After a quick search, I found

  xboard 

and maybe

  tagua 
  scid 

Any other?

Which ones may be used to play chess with package 'stockfish'?
Possibly through 'polyglot'?

Please let me know.
Thanks for your time and patience!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpf0s57v_MGD.pgp
Description: PGP signature

Bug#1051617: mailman3: Receiving email every minute with Django warnings

[Tony]

Package: mailman3
Version: 3.3.8-2~deb12u1
Severity: important

Dear Maintainer,

On a new installation I receive an email every minute with the following 
message.

System check identified some issues:

WARNINGS:
django_mailman3.MailDomain: (models.W042) Auto-created primary key used when 
not defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
django_mailman3.Profile: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Attachment: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Email: (models.W042) Auto-created primary key used when not defining 
a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Favorite: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.LastView: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.MailingList: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Profile: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining a 
primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tagging: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Thread: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Vote: (models.W042) Auto-created primary key used when not defining 
a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
HyperKittyConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.
postorius.EmailTemplate: (models.W042) Auto-created primary key used when not 
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
PostoriusConfig.default_auto_field attribute to point to a subclass of 
AutoField, e.g. 'django.db.models.BigAutoField'.


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

Bug#1051618: mailman3: Receive messages every minute saying retry and timeout miconfigured.

[Tony]

Package: mailman3
Version: 3.3.8-2~deb12u1
Severity: normal

Dear Maintainer,

A new installation of Mailman 3.  Every minute I receive an email message saying

/usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and 
timeout are misconfigured. Set retry larger than timeout, 
failure to do so will cause the tasks to be retriggered before 
completion. 

Adding the following to /etc/mailman3/mailman-web.py seems to have fixed the 
problem.

Q_CLUSTER = {'orm': 'default',
 'retry': 360,
 'save_limit': 100,
 'timeout': 300,
 'workers': 2}


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

Versions of packages mailman3 depends on:
ii  cron 3.0pl1-162
ii  dbconfig-mysql   2.0.24
ii  debconf [debconf-2.0]1.5.82
ii  init-system-helpers  1.65.2
ii  logrotate3.21.0-1
ii  python3  3.11.2-1+b1
ii  python3-aiosmtpd 1.4.3-1.1
ii  python3-alembic  1.8.1-2
ii  python3-authheaders  0.15.2-1
ii  python3-authres  1.2.0-3
ii  python3-click8.1.3-2
ii  python3-dateutil 2.8.2-2
ii  python3-dnspython2.3.0-1
ii  python3-falcon   3.1.1-1+b1
ii  python3-flufl.bounce 4.0-3
ii  python3-flufl.i18n   3.0.1-3
ii  python3-flufl.lock   5.0.1-4
ii  python3-gunicorn 20.1.0-6
ii  python3-importlib-resources  5.1.2-2
ii  python3-lazr.config  2.2.3-3
ii  python3-passlib  1.7.4-3
ii  python3-psycopg2 2.9.5-1+b1
ii  python3-public   2.3-4
ii  python3-requests 2.28.1+dfsg-1
ii  python3-sqlalchemy   1.4.46+ds1-1
ii  python3-zope.component   5.1.0-1
ii  python3-zope.configuration   4.4.1-1
ii  python3-zope.event   4.4-3
ii  python3-zope.interface   5.5.2-1+b1
ii  ucf  3.0043+nmu1

Versions of packages mailman3 recommends:
ii  exim4-daemon-custom [mail-transport-agent]  4.96-15+deb12u1

Versions of packages mailman3 suggests:
pn  anacron
ii  lynx [www-browser] 2.9.0dev.12-1
pn  mailman3-doc   
ii  mariadb-server [virtual-mysql-server]  1:10.11.3-1

-- debconf information:
  mailman3/pgsql/manualconf:
  mailman3/remote/port:
  mailman3/dbconfig-upgrade: true
  mailman3/passwords-do-not-match:
  mailman3/dbconfig-remove: true
  mailman3/mysql/method: Unix socket
  mailman3/remote/host: localhost
  mailman3/pgsql/changeconf: false
  mailman3/internal/reconfiguring: false
  mailman3/remote/newhost:
  mailman3/missing-db-package-error: abort
* mailman3/config_hyperkitty: true
  mailman3/purge: false
  mailman3/install-error: abort
* mailman3/dbconfig-install: true
  mailman3/upgrade-backup: true
  mailman3/pgsql/admin-user: postgres
  mailman3/remove-error: abort
  mailman3/pgsql/authmethod-admin: ident
  mailman3/db/app-user: mailman3@localhost
  mailman3/pgsql/no-empty-passwords:
  mailman3/upgrade-error: abort
  mailman3/db/basepath: /var/lib/mailman3/data
* mailman3/dbconfig-reinstall: false
  mailman3/db/dbname: mailman.db
  mailman3/pgsql/method: TCP/IP
  mailman3/init_service_failed:
  mailman3/internal/skip-preseed: false
  mailman3/mysql/admin-user:
* mailman3/database-type: sqlite3
  mailman3/pgsql/authmethod-user: password
  mailman3/mysql/authplugin: default

Bug#1051619: cron: please add SyslogFacility=cron to the systemd .service

[Alexandre Detiste]

Package: cron
Version: please add SyslogFacility=cron to the systemd .service
Severity: minor

The title say it all.

Please also write up a _usefull_ changelog and
not "implemented Alexandre's request".

Even myself I forgot about what it was about two weeks later.

See my pending MR on Salsa.

Greetings,



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-175
ii  init-system-helpers  1.65.2
ii  libc62.37-7
ii  libpam-runtime   1.5.2-7
ii  libpam0g 1.5.2-7
ii  libselinux1  3.5-1
ii  sensible-utils   0.0.20

Versions of packages cron recommends:
ii  nullmailer [mail-transport-agent]  1:2.2+10~g7ed88a0-1

Versions of packages cron suggests:
pn  checksecurity   
ii  logrotate   3.21.0-1
ii  systemd-cron [anacron]  2.1.1-1

Bug#1051411: fcoe-utils: Cyclic systemd unit dependencies

[Valentin Vidic]

On Thu, Sep 07, 2023 at 07:55:56PM -0700, tony mancill wrote:
> Thank you for the bug report.  My initial instinct is to use the same
> unit file and service dependencies as upstream.  Looking at the history
> of Debian's patch [2] of the unit file, and specifically this commit
> [3], it appears that the change was made to resolve an issue.
> 
> The patch to the systemd unit file predates my involvement with this
> package, so Valentin may be able to provide more context.  Perhaps
> there was a bug in fcoe-utils that necessitated the change at that time,
> but we can now revert to the unit file patch?
> 
> Valentin, do you have any insight on this?  Without a link to the
> original bug, I'm unsure what regression reverting to the upstream unit
> file dependencies might cause.

Hi, as the comment on commit 1519b5cd suggests, I think there was some
race condition with getting FCoE working reliably on boot. It is
possible this is not required and can be reverted, but I don't have
access to the hardware anymore to test it.

Another option would be to move both services to start before the
network, if the testing shows that this is still required.

-- 
Valentin

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

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Hideki Yamane (2023-09-10 11:00:07)

>>  Hmm, how about providing license-common package and that depends on
>>  "license-common-list", and ISO image provides both, then? It would be
>>  no regressions.

I do wonder why we've never done this.  Does anyone know?  common-licenses
is in an essential package so it doesn't require a dependency and is
always present, and we've leaned on that in the past in justifying not
including those licenses in the binary packages themselves, but I'm not
sure why a package dependency wouldn't be legally equivalent.  We allow
symlinking the /usr/share/doc directory in some cases where there is a
dependency, so we don't strictly require every binary package have a
copyright file.

>>  I expect license-common-list data as below
>> 
>>  license-short-name: URL
>>  GPL-2: file:///usr/share/common-licenses/GPL-2
>>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

> Ah, so what you propose is to use file URIs.

> I guess Russ' response above was a concern over using http(s) URIs
> towards a non-local resource.

Yes, I think the https URL is an essential part of the first proposal,
since it avoids needing to ship a copy of all of the licenses.  But I'm
dubious that would pass legal muster.

The alternative proposal as I understand it would be to haave a
license-common package that includes full copies of all the licenses with
some more relaxed threshold requirement and have packages that use one of
those licenses depend on that package.  (This would obviously require a
maintainer be found for the license-common package.)

> License: Apache-2.0
> Reference: /usr/share/common-licenses/Apache-2.0

This is separate from this particular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.

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

Bug#1050676: enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.

[GCS]

Hi,

On Sun, Sep 10, 2023 at 9:21 PM Andreas Metzler  wrote:
> I tried to do a test build of enblend against graphviz 8.1.0 from
> experimental. I had no luck, since dot seems to be built without support
> for png output:
 It is/was due to another issue which is just fixed. But it is still a
work in progress, not fully ready for user consumption.
enblend-enfuse will still not build. Please give me some time to clear
all graphviz issues.

Regards,
Laszlo/GCS

Bug#1050512: gnome-shell: Crash when viewing video with mpv

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 31 Aug 2023 at 13:45:04 +0200, Marc Glisse wrote:
> It looks like my stack trace is useless because I forgot to set
> MUTTER_SYNC=1 :-(
>
> It seems likely that this is the same bug as
> https://gitlab.gnome.org/GNOME/mutter/-/issues/2857 (sadly not fixed yet).

Would you be able to reproduce this with MUTTER_SYNC=1 in the environment
(setting it in ~/.config/environment.d/mutter-sync.conf should apparently
work) to confirm that it's the same crash as mutter#2857 upstream?

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6778#note_1782883
seems like the characteristic backtrace: a BadMatch in response to
DPMSForceLevel().

You say this happens when playing a video with mpv: perhaps this could
be because mpv disables power saving / screen blanking while it's playing
the video?

If you install the x11-xserver-utils package and run "xset -dpms", does
that trigger the same crash?

There is a merge request upstream which *might* fix this. If you are able
to rebuild the mutter source package with patches applied, please try
applying the attached file "bug1050512-without-xsync.patch" and see whether
you can reproduce the crash. If that works, please report back. If not,
please revert that change, apply "bug1050512-with-xsync.patch", rebuild
and try again.

If you're not able to rebuild the mutter source package, I'll try to
prepare packages that you can try, but there's a heatwave here at the
moment, so I'm trying not to heat my house more by compiling lots of
packages right now!

Thanks,
smcv
From: =?UTF-8?q?Jonas=20=C3=85dahl?= 
Date: Mon, 7 Aug 2023 22:42:18 +0200
Subject: monitor-manager/xrandr: Trap DPMS changes

Apparently DPMSForceLevel() can fail to force a valid level sometimes.

Bug: https://gitlab.gnome.org/GNOME/mutter/-/issues/2857
Bug: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6883
Forwarded: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3160
Bug-Debian: https://bugs.debian.org/1050512
---
 src/backends/x11/meta-monitor-manager-xrandr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/backends/x11/meta-monitor-manager-xrandr.c b/src/backends/x11/meta-monitor-manager-xrandr.c
index f288c7af239..1a23709c8a2 100644
--- a/src/backends/x11/meta-monitor-manager-xrandr.c
+++ b/src/backends/x11/meta-monitor-manager-xrandr.c
@@ -180,8 +180,10 @@ meta_monitor_manager_xrandr_set_power_save_mode (MetaMonitorManager *manager,
 return;
   }
 
+  meta_clutter_x11_trap_x_errors ();
   DPMSForceLevel (manager_xrandr->xdisplay, state);
   DPMSSetTimeouts (manager_xrandr->xdisplay, 0, 0, 0);
+  meta_clutter_x11_untrap_x_errors ();
 }
 
 static xcb_randr_rotation_t
-- 
GitLab

>From 7d911855b480ce19941f27df3d2d8c270ceb6ba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20=C3=85dahl?= 
Date: Mon, 7 Aug 2023 22:42:18 +0200
Subject: [PATCH] monitor-manager/xrandr: Trap DPMS changes

Apparently DPMSForceLevel() can fail to force a valid level sometimes.

Bug: https://gitlab.gnome.org/GNOME/mutter/-/issues/2857
Bug: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6883
Origin: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3160
[smcv: call XSync() before untrap, as suggested by Sebastian Keller]
Bug-Debian: https://bugs.debian.org/1050512
---
 src/backends/x11/meta-monitor-manager-xrandr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/backends/x11/meta-monitor-manager-xrandr.c b/src/backends/x11/meta-monitor-manager-xrandr.c
index beb9fb80d2..0785dad36f 100644
--- a/src/backends/x11/meta-monitor-manager-xrandr.c
+++ b/src/backends/x11/meta-monitor-manager-xrandr.c
@@ -180,8 +180,11 @@ meta_monitor_manager_xrandr_set_power_save_mode (MetaMonitorManager *manager,
 return;
   }
 
+  meta_clutter_x11_trap_x_errors ();
   DPMSForceLevel (manager_xrandr->xdisplay, state);
   DPMSSetTimeouts (manager_xrandr->xdisplay, 0, 0, 0);
+  XSync (manager_xrandr->xdisplay, False);
+  meta_clutter_x11_untrap_x_errors ();
 }
 
 static xcb_randr_rotation_t
-- 
2.40.1

Bug#1039073: wrong output from /usr/lib/xymon/client/ext/kern

[Steve K Brown [DEB]]

Package: hobbit-plugins
Version: 20230301
Severity: normal

Dear maintainer,

I'd like to submit another report concerning this bug and confirm the 
'kern' plugin mis-reports the version string of the 'newest installed 
kernel' on disk, resulting in a Yellow warning in the Xymon dasjboard.


As the previous reported, I note this behaviour on a Debian 12 (stable) 
Arm64 platform.


I can confirm that manually testing the current vmlinuz disk image does 
result in some extra cruft. I believe the characters delimited below 
between >> << need to be ignored.


Linux version 6.1.50-current-rockchip64 >>(armbian@next) 
(aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld 
(GNU Binutils for Ubuntu) 2.38)<< #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 
2023


Additionally, there are two matches within the vmlinuz file - the 
*second* match is to be preferred as the first match which is the one 
used in the plugin is missing the number following the hash (3 in this 
example) in '#3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023'


If helpful, I'm happy to test any patches that may be created as 
otherwise the test is not useful since it permanently creates a Yellow 
warning.


Kind regards,

Steve

Bug#1039724: gpgme: building underbookworm fails with no matches in python3-gpg.install

[Bastian Germann]

Am 10.09.23 um 16:35 schrieb Andreas Metzler:

Was there something off-BTS?


No.


The on-BTS discussion ended with finding the cause in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039724#61


Having a clean chroot (no python3-setuptools installed) lets the build pass, so 
this certainly not FTBFS.
You can untag wontfix if you think that anybody should do something about it.

Bug#1050512: gnome-shell: Crash when viewing video with mpv

[Marc Glisse]

On Sun, 10 Sep 2023, Simon McVittie wrote:


Would you be able to reproduce this with MUTTER_SYNC=1 in the environment
(setting it in ~/.config/environment.d/mutter-sync.conf should apparently
work) to confirm that it's the same crash as mutter#2857 upstream?


I was hoping to wait until the other bug was fixed, since producing the 
trace is a bit of work.



You say this happens when playing a video with mpv: perhaps this could
be because mpv disables power saving / screen blanking while it's playing
the video?


I have no idea. It also happens (but less quickly) when watching videos 
full screen with firefox.



If you install the x11-xserver-utils package and run "xset -dpms", does
that trigger the same crash?


No, it doesn't seem to have any effect.


There is a merge request upstream which *might* fix this. If you are able
to rebuild the mutter source package with patches applied, please try
applying the attached file "bug1050512-without-xsync.patch" and see whether
you can reproduce the crash. If that works, please report back. If not,
please revert that change, apply "bug1050512-with-xsync.patch", rebuild
and try again.


The first patch does not work (still crashing). The second one does seem 
to help, that's great! Playing a few videos did not trigger any crash :-)


If the problem reappears (with a lower frequency), I'll write again.


If you're not able to rebuild the mutter source package,


I had to use DEB_BUILD_OPTIONS=nocheck since several tests were failing, 
including some with very long timeouts.



there's a heatwave here at the moment,


Same here...

--
Marc Glisse

Bug#1051588: ITP: rust-pkcs8 -- pure Rust implementation of PKCS#8

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-pkcs8
  Version : 0.10.2
  Upstream Contact: RustCrypto Developers
* URL : https://github.com/rustcrypto/formats
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : pure Rust implementation of PKCS#8

 The pkcs8 crate is a pure Rust implementation
 of Public-Key Cryptography Standards (PKCS) #8:
 Private-Key Information Syntax Specification (RFC 5208).
 .
 PKCS#8 is a format for cryptographic private keys,
 often containing pairs of private and public keys.

This package will be maintained in the collaborative Debian section of
salsa, at .
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmT9apgACgkQLHwxRsGg
ASF3EhAApqSs0osaDj0TKQHPOsojxNNsEfYy9JeKhlkg1oJCF12v607EMlZc2o0x
VQNh7cQTJUIASLoh965ntMOkfpclAPmqGqW0/D0V+ECDsCN7iaMnggllgxXnG/Yi
6nZumKICsQQu6wJME2T3a3gOaOoRIW591P+x26EFO4fABiDLz29ARnc24zNQknEy
XL/xeN7A+MemMKub2pzYp8tqssGB8L/ARw31zqP5tjKyPAeEMFbVr59HfWqJrdU5
PcWiAGrYEC+MBfeO16a3tV6bot0Yomh6NetvbiYiOC5nEtq9tTIaOudON+0zIbom
FcvPAKW2H6C1xCVg9T87iwsFjntbUn+mnVsXyhDUZYa/6bKO16mswuD0ZEDBN++Z
w/l/DoQtrbP7WgYHeJONYJJADwZy334/m5MqukryjPxr9mYuW5/5M70cK5naWLuV
7M2HYi3lbefHvd3zbxh7UeqYXUq0yARnh8USyC9g4cR57d9rnNKwJbMixlTLrzfj
tNZMYQI3U+hSn8rGXEWAjPk3n9QOAMPhRVotP/lFLX5u5UU+1yGrIebBD6G7Wf27
vnX0t0el0ME1kBnPOdtvKD1f5qHH7Om0++0y9Vu6o2MbSJRnTRlJ4cBtT8+JCZ9Y
rLeawJcuVdrle2lYFDMUixrh9N4o50Q+id0Qo0i3Qxecmb/GNO8=
=KMXB
-END PGP SIGNATURE-

Bug#1051591: ITP: node-vega-tooltip -- Tooltip for node-vega and node-vega-lite

[Yadd]

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

* Package name: node-vega-tooltip
  Version : 0.33.0
  Upstream Contact: https://github.com/vega/vega-tooltip/issues
* URL : https://github.com/vega/vega-tooltip
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Tooltip for node-vega and node-vega-lite

node-vega-tooltip is a tooltip plugin for Vega and Vega-Lite visualizations.
This plugin implements a custom tooltip handler for Vega that uses custom
HTML tooltips instead of the HTML title attribute.

This is a dependency of node-jupyterlab. It will be maintained under JS
Team umbrella.

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Timo Sigurdsson]

Package: linux
Version: 6.1.52-1
Severity: grave

Dear Maintainers,

linux-image-6.1.0-12-amd64 causes a serious regression in nftables. After 
upgrading one of my machines, nftables fails to start - leaving the system 
without an active firewall.

Doing
`nft -cf /etc/nftables.conf'
throws many "Operation not supported" errors on rulesets that have been in 
place for months wihtout issues.

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


Downgrading to linux-image-6.1.0-11-amd64 resolves the issue.

Notes: I'm running a local rebuild of linux-image-amd64 with a few additional 
symbols enabled. But since these symbols are totally unrelated to the netfilter 
subsystem and there are no changes to the source itself, I'm certain, this 
affects the original Debian build as well. Whether it only affects certain 
architectures or rulesets, I can't say, though.

I'm cc'ing debian-secur...@debian.org because the update came via the 
stable-security channel.


Thanks and regards,

Timo

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

[Hideki Yamane]

On Sat, 09 Sep 2023 20:35:27 -0700
Russ Allbery  wrote:
> Licenses will be included in common-licenses if they meet all of the
> following criteria:

 How about just pointing SPDX licenses URL for whole license text and
 lists DFSG-free licenses from that? (but yes, we should adjust short
 name of licenses for DEP-5 and SPDX for it).


-- 
Hideki Yamane 

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Jörg-Volker Peetz]

Package: emacs
Version: 1:29.1+1-5
Severity: wishlist

Dear Rob Browning,

on my system each newly started emacs process does native-compilation of
all used modules, even the ones already compiled by previous processes.
Is this to be expected?
As I see it, the cached native-compiled modules should be re-used.
Do I have to configure something for that?

Thanks for your work on the debian emacs packages and regards,
Jörg.


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

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

Versions of packages emacs depends on:
ii  emacs-lucid  1:29.1+1-5

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1051437: RM: gnome-metronome -- RoQA; RC-buggy; replaced by completely new rust app

[Matthias Geiger]

On 10.09.23 14:56, Jeremy Bícha wrote:

Control: tags -1 -moreinfo

We do intend to package the new Rust version of gnome-metronome. This
has been blocked because it took us a while to get the Rust GTK
packaging up to date and more importantly, package rust-libadwaita in
a way that ftpmasters approved of.

rust-libadwaita-sys was recently accepted into Debian so we should be
able to get gnome-metronome updated later this year.

It feels to me like NEW processing is a bit slow these days so I would
prefer to avoid the wait. Therefore, I suggest we close this bug and
reconsider next year if gnome-metronome has still not made it to
Testing.

Thank you,
Jeremy Bícha


The only blocker for the rust version is the ongoing gtk-rs transition 
and one new gstreamer rust library.


gnome-metronome can be easily updated then, so RM'ing it now would just 
create extra work imho.


best,

--
Matthias Geiger (werdahias)
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:47:30PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote:
> > On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > > Thanks for raising this, I'm uploading the new packages with the fixes 
> > > today.
> > 
> > apparently someone else did a NMU with the new version and incorrectly 
> > closed
> > the bug.
> 
> You mean the NMU by Sebastian?

Yes

> 
> > I reopened the bug because stable needs to be addressed (which I will do 
> > today
> > as I just wrote) and then it's probably worth investigating how to integrate
> > those NMU into the git repo
> 
> Actually you do not need to reopen. A bug can be closed with mutliple
> versions, that is 2.2.12-0.1 closes it, but as well so does then the
> 2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one.
> 
> I think that was not the case several years ago, but nowdays BTS can
> handle that, and will reflect it nicely as well in the version graph.
> 
> Or were you meaning something different?

Ah ok good, then I will add the extra versions if they are not there already

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> FWIW, I have done the bookworm-security upload already to
> security-master, and still working on the bullseye-security one (with
> plan to release the DSA tonight ideally).

Ack, thanks for the update, I assume this was a particularly serious issue that
had to be handled immediately!

Bug#1051584: /usr/lib/llvm-15/bin/llvm-config: multiarch issues, with llvm-config-15

[Sylvestre Ledru]

Hello,

Le 10/09/2023 à 05:48, Witold Baryluk a écrit :

Package: llvm-15
Version: 1:15.0.7-8
Severity: normal
File: /usr/lib/llvm-15/bin/llvm-config
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

I am trying to cross compile Mesa for armhf, on arm64 box.

I installed llvm-15, libllvm15:arm64 and libllvm15:armhf

So I do have libLLVM.so now for armhf, but I am unable to convince the
llvm-config-15 to output proper paths with --ldflags.


llvm-config doesn't work very well. I would not rely on it in general.

Sorry
Sylvestre

Bug#1050676: enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.

[Andreas Metzler]

Hello,

I tried to do a test build of enblend against graphviz 8.1.0 from
experimental. I had no luck, since dot seems to be built without support
for png output:

/usr/bin/m4 --fatal-warnings --prefix-builtins --synclines 
--define='dot_output_type=png' ../../doc/uml-dot.m4 
../../doc/external-mask-workflow.dot | \
/usr/bin/dot  -Tpng -Gbgcolor=transparent -Gresolution=600 | \
/usr/bin/convert png:- -transparent white -resize $(( ((96 * 1000) 
/ 600) / 10 ))% external-mask-workflow.png
Format: "png" not recognized. Use one of: canon cmap cmapx cmapx_np dot 
dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps 
ps2 svg svgz tk xdot xdot1.2 xdot1.4 xdot_json
convert: improper image header 
`/dev/shm/magick-u_9y0p39jcrUpQwvjHcDxiLBtxK8jlEu' @ 
error/png.c/ReadPNGImage/4107.
[...]

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#1050731: gnome-shell segfault in libmutter-clutter-12.so with nvidia-graphics-drivers set to 144Hz refresh

[Simon McVittie]

Control: retitle -1 gnome-shell segfault in libmutter-clutter-12.so with 
nvidia-graphics-drivers set to 144Hz refresh
Control: severity -1 important
Control: tags -1 + moreinfo
Control: affects -1 + src:gnome-shell src:nvidia-graphics-drivers

On Tue, 29 Aug 2023 at 22:14:50 +0200, gozdek wrote:
> I found workaround, changing the refresh in nvidia-settings from 144Hz to 
> 60Hz 
> solves the problem with libmutter segfault. Nvidia drivers: 535.104.05

A workaround exists, so this doesn't make GNOME Shell completely unusable;
downgrading the bug severity to important.

> Gnome-shell: Alt-F2, type 'r'

> or open Firefox/Chrome browser and play any video for example from youtube

Those two might actually be two separate root causes, or they might be
two different ways to trigger the same root cause; it's not yet clear from
the information available.

Alt+F2, 'r' sometimes triggers bugs in shutdown/cleanup code paths
that would normally only result in the Shell crashing when it is already
trying to exit (which is a bug, but relatively harmless). This seems likely
to be the same thing as #1050502, which was also reported by a user of the
Nvidia proprietary graphics driver.

Playing videos in a web browser probably means there is a crash involving
hardware video acceleration (VA-API or VDPAU). This could be the same thing
as #1050512, which was *also* reported by a user of the Nvidia proprietary
graphics driver.

> I found similar problem:
> https://gitlab.gnome.org/GNOME/mutter/-/issues/2977201

That doesn't seem to be a valid issue URL, do you mean
 or something else?

https://gitlab.gnome.org/GNOME/mutter/-/issues/2977 seems similar to your
first reproducer involving Alt+F2, 'r'.

> gnome-shell[24802]: segfault at 28 ip 7fed6c6f5f14 sp
> 7ffc869e41a0 error 4 in
> libmutter-clutter-12.so.0.0.0[7fed6c689000+8d000] likely on CPU 2 (core
> 2, socket 0)

There is not enough information here to identify a specific crash
or find a solution. Please could you get a backtrace? Please see:
.

For gnome-shell, usually the easiest way to get a backtrace is:

* Install the systemd-coredump package
* Reboot (I'm not sure whether this is strictly necessary but it can't hurt)
* Do whatever you need to do to trigger the crash
* In a shell: DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl gdb
* Enable automatic download of debug symbols if prompted
* At the (gdb) prompt: set pagination off
* Still at the (gdb) prompt: bt

In your case, you've reported two different ways to trigger this crash
(one with Alt+F2, 'r' similar to #1050502, and one with videos similar
to #1050512) so it would be useful if you could get a separate backtrace
for each one, and send them to the bug address indicating which is which.

Also, please look for any messages from gnome-shell in the system log
(systemd journal) at the time of the crash, by using the journalctl
tool or reading the file /var/log/syslog. For example you might see
something similar to this:

2023-09-10T16:09:04.136417+01:00 tautology gnome-shell[2831]: 
clutter_actor_contains: assertion 'CLUTTER_IS_ACTOR (self)' failed

or this:

May  7 18:02:51 darter gnome-shell[2213]: Attempting to run a JS callback 
during garbage collection. This is most likely caused by destroying a Clutter 
actor or GTK widget with ::destroy signal connected, or using the destroy(), 
dispose(), or remove() vfuncs. Because it would crash the application, it has 
been blocked.

Please copy anything from around the time of the crash.

Thanks,
smcv

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

[Russ Allbery]

Russ Allbery  writes:

> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:

> Licenses will be included in common-licenses if they meet all of the
> following criteria:

> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.

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

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

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 18:16:07)
> Russ Allbery  writes:
> 
> > In order to structure the discussion and prod people into thinking about
> > the implications, I will make the following straw man proposal.  This is
> > what I would do if the decision was entirely up to me:
> 
> > Licenses will be included in common-licenses if they meet all of the
> > following criteria:
> 
> > * The license is DFSG-free.
> > * Exactly the same license wording is used by all works covered by it.
> > * The license applies to at least 100 source packages in Debian.
> > * The license text is longer than 25 lines.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.
> 
> My guess is that with the threshold set at 100, we will probably add
> around eight new licenses with the 25 line threshold (AGPL-2,
> Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
> OFL-1.1, and I'm not sure about some of those because the CC licenses have
> variants that would each have to reach the threshold independently; my
> current ad hoc script does not distinguish between the variants), and
> maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
> the BSD licenses).  This would essentially be continuing current practice
> except with more transparent and consistent criteria.  It would mean not
> including a lot of long legal license texts that people have complained
> about having to duplicate, such as the CDDL, CeCILL licenses, probably the
> EPL, the Unicode license, etc.
> 
> If that's what people want, that's what we'll do; as I said, that's what I
> would do if the choice were left entirely up to me.  But I want to make
> sure I give the folks who want a much more relaxed standard a chance to
> speak up.

Good point.

Another way of reading the responses is that there was some interest in
including even more licenses.

I would also prefer inclusion of more licenses, simply had the
impression that a) we could do that step by step, and b) my habit of
writing copyright files (and other teksts) using [semantic linebreaks]
made me forget that Expat license is arguably only 3 lines long (whereas
in my style of writing it is 24-25 lines long).

If "include all SPDX licenses" is for some reason (space in minimal
systems?) problematic, then let me propose a threshold of 1000
characters - as that just about covers Expat ;-)


 - Jonas


[semantic linebreaks]: https://sembr.org/

-- 
 * 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#1050547: GNOME crashes with white screen after boot up

[Simon McVittie]

On Sat, 09 Sep 2023 at 12:40:53 +0800, Hor Jiun Shyong wrote:
> coredumpctl_gdb.txt.gz

The relevant part is:

#0  0x7f9e956ced54 in meta_display_get_x11_display () from 
/lib/x86_64-linux-gnu/libmutter-12.so.0
#1  0x7f9e956f9a3b in ?? () from /lib/x86_64-linux-gnu/libmutter-12.so.0
#2  0x7f9e95e95f8f in g_initable_new_valist () from 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#3  0x7f9e95e96069 in g_initable_new () from 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7f9e956f9dda in ?? () from /lib/x86_64-linux-gnu/libmutter-12.so.0
#5  0x7f9e956fd5ce in ?? () from /lib/x86_64-linux-gnu/libmutter-12.so.0
#6  0x7f9e956fd62d in ?? () from /lib/x86_64-linux-gnu/libmutter-12.so.0
#7  0x7f9e9568b04e in meta_cursor_tracker_get_sprite () from 
/lib/x86_64-linux-gnu/libmutter-12.so.0
#8  0x7f9e94d4cf7a in ?? () from /lib/x86_64-linux-gnu/libffi.so.8

but this is of limited usefulness since you don't have debug symbols for
mutter available.

The easiest way to get the debug symbols is to use:

DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl gdb

and type "bt" at the (gdb) prompt when the symbols have finished
downloading.

Or you could enable the debug symbols apt repository (see
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols)
and install the libmutter-12-0-dbgsym package. We don't need any other
packages for this particular crash.

> core.gnome-shell.117.db5045b3be454eabaf40ab7634cdd15f.1720.169425800700.zst.gz

In general we can't get a useful backtrace from the actual compressed
core dump: that's something that the bug reporter needs to do. I tried to
get a useful backtrace from this with debug symbols, but it doesn't match
the result you sent and I'm not sure whether it really makes sense.

Sharing these core dumps is also a privacy risk because they can contain
private information, although in this case the crash was from the gdm
login screen before you had a chance to enter any passwords, so it's
probably harmless.

smcv

Bug#1051630: transition: qtwebengine-abi-5-15-15

[Dmitry Shachnev]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: qtwebengine-opensource-...@packages.debian.org
Control: affects -1 + src:qtwebengine-opensource-src

Dear Release team,

Qt WebEngine has a new patch release in 5.15 LTS branch, and as usual
we change the ABI virtual package name, which requires a binNMU of two
reverse dependencies: angelfish and qtwebview-opensource-src.

The new version is prepared in experimental and built successfully.
We no longer have mipsel architecture, so the problems from the previous
transition should not repeat.

Ben file:

title = "qtwebengine-opensource-src";
is_affected = .depends ~ "qtwebengine-abi-5-15-14" | .depends ~ 
"qtwebengine-abi-5-15-15";
is_good = .depends ~ "qtwebengine-abi-5-15-15";
is_bad = .depends ~ "qtwebengine-abi-5-15-14";

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Jeremy Stanley]

On 2023-09-09 20:35:27 -0700 (-0700), Russ Allbery wrote:
[...]
> Finally, as promised, here is the count of source packages in
> unstable that use the set of licenses that I taught my script to
> look for.  This is likely not accurate; the script uses a bunch of
> heuristics and guesswork.
[...]

I'm surprised, for example, by the absence of the ISC license given
that not only ISC's software but much of that originating from the
OpenBSD ecosystem uses it. My personal software projects also use
the ISC license. Are you aggregating the "License:" field in
copyright files too, or is it really simply a hard-coded list of
matching patterns?

Regardless, this is great work, thanks for kicking off the
reevaluation!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Bill Allombert (2023-09-10 18:29:36)
> On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > Jonas Smedegaard  writes:
> > > Quoting Hideki Yamane (2023-09-10 11:00:07)
> > >>  Hmm, how about providing license-common package and that depends on
> > >>  "license-common-list", and ISO image provides both, then? It would be
> > >>  no regressions.
> > 
> > I do wonder why we've never done this.  Does anyone know?  common-licenses
> > is in an essential package so it doesn't require a dependency and is
> > always present, and we've leaned on that in the past in justifying not
> > including those licenses in the binary packages themselves, but I'm not
> > sure why a package dependency wouldn't be legally equivalent.  We allow
> > symlinking the /usr/share/doc directory in some cases where there is a
> > dependency, so we don't strictly require every binary package have a
> > copyright file.
> 
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage
> the copying themselves.

I very much like this idea. The main reason maintainers want more licenses in
/usr/share/common-licenses/ is so that they do not anymore have humongous
d/copyright files with all license texts copypasted over and over again. If
long texts could be reduced to a reference that get expanded by a machine it
would make debian/copyright look much nicer and would make it easier to
maintain while at the same time shipping the full license text in the binary
package.

Does anybody know why such an approach would be a bad idea?

I have zero legal training so the only potential problem with this approach
that I was able to come up with is, that then the source package itself would
not anymore contain the license text and thus we would be shipping code covered
by a license that states that the code may only be distributed with the license
text alongside it without that text. So while auto-generating this would
probably create compliant binary packages, it would leave the source package
without the license text. Is that a problem?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1051640: pgrouting: uploader email address maybe invalid (Michael Fladischer)

[Ben Tris]

Source: pgrouting
Version: 3.4.2-1
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, fl...@debian.org, m...@qa.debian.org

Dear Maintainer,

The email under uploader Michael Fladischer is now
 this is not found in qa.
Probably it should be . (active maintainer/uploader)


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/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#1051069: fixed by cleaning .cache/common-lisp/

[Gijs Hillenius]

It looks like I managed to resolve this by cleaning out

.cache/common-lisp/

which forces the rebuilding of

.cache/common-lisp/2.3.7.debian-linux-x64/

when I restarted Emacs, and M-x slime

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

[Simon McVittie]

On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> Luca, am I right that service directories are specific to, well, services?
> If so, what would you think of moving them to Policy 9.3 alongside the
> other discussion of systemd units?  They feel out of place here, since
> packages that do not use services cannot use this functionality

I'm not Luca, but I think you're correct here.

> Luca Boccassi  writes:
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, should not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +`_
> > +interface.  Files and directories under ephemeral filesystems such as
> > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets.
> 
> I understand the empty directory part, but I don't believe "files that are
> located under /var" is correct unless you specifically mean *empty* files
> (and even then, I'm not clear on precisely when this would be needed).
> For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
> maintainer script, and I can see no possible way that action could (or
> should) be handled by the tmpfiles.d mechanism.

In general tmpfiles.d handles files that exist only as metadata: symbolic
links (for which the target is the only interesting fact), empty files
(for which the existence and ownership/permissions are the only interesting
facts), directories (ditto) and so on.

It can also handle files that have static initial contents that do not
vary between systems, but can change in a system-specific way later,
with initial contents either hard-coded in the tmpfiles.d snippet (for
short text strings) or copied from somewhere below /usr (canonically
/usr/share/factory).

Files generated by non-trivial imperative code, like machine-specific
initial contents (/var/lib/dbus/machine-id) or some sort of compiler
(/var/lib/gnubg/gnubg_ts0.bd, as far as I can tell), are out of scope for
tmpfiles.d, so I think you're right to be concerned that Luca's wording
as written is asking gnubg to do something that is unimplementable.
ch-maintainerscripts.rst has the same issue.

Perhaps "files with trivial contents that are located under /var" would be
a good wording that is not overly specific about implementation details,
covers the 90% case, and leaves room for exceptions by declaring packages
like dbus and gnubg to be non-trivial?

If /var/lib/gnubg/gnubg_ts0.bd is deterministically compiled from
files shipped in the .deb as a time/space trade-off, is only written
during package management operations, and is otherwise read-only, then
perhaps it should live in /usr, but that's orthogonal to wanting to use
tmpfiles.d where feasible. (Prior art for similar situations includes
Python bytecode, glibc locales, GLib gschemas.compiled and giomodule.cache,
and so on.)

smcv

Bug#935104: Hostname fields store "\n" when copy+pasted

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.8~git20230203.10abe45+dfsg-1+deb12u1

On  Mo 19 Aug 2019 15:59:46 CEST, Mike Gabriel wrote:


Package: gosa
Severity: important
Version: 2.7.4+reloaded3-9
User: debian-...@lists.debian.org
Usertag: debian-edu

A customer of mine copy+pasted host names into GOsa (as GOsa  
systems). If by accident one pastes 2 lines from a hostname list  
into the hostname field in GOsa, GOsa stores the line break ("\n")  
in the hostname's CN field (and thus the DN).


This issue cannot be reproduced since GOsa² 2.8 anymore. So, closing.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp2BVpTOsks3.pgp
Description: Digitale PGP-Signatur

Bug#1051437: RM: gnome-metronome -- RoQA; RC-buggy; replaced by completely new rust app

[Jeremy Bícha]

On Sun, Sep 10, 2023 at 9:07 AM Matthias Geiger  wrote:
> The only blocker for the rust version is the ongoing gtk-rs transition
> and one new gstreamer rust library.

Yes, here is the updated packaging:
https://salsa.debian.org/a-wai/gnome-metronome/-/merge_requests

Thank you,
Jeremy Bícha

Bug#998283: Mark as pensing

[Lisandro Damián Nicanor Pérez Meyer]

tag 998283 pending
thanks

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1051616: FTBFS: error: ‘uint32_t’ does not name a type

[Bo YU]

Source: rawtherapee
Version: 5.9-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)


Dear Maintainer,

rawtherapee has build issue on riscv64 with gcc-13:

```
In file included from /<>/rtengine/rawimage.h:26,
 from /<>/rtengine/filmnegativeproc.cc:22:
/<>/rtengine/dcraw.h:187:13: error: ‘uint32_t’ does not name a type
  187 | uint32_t MediaSize;
  | ^~~~
/<>/rtengine/dcraw.h:24:1: note: ‘uint32_t’ is defined in header 
‘’; did you forget to ‘#include ’?
   23 | #include 
  +++ |+#include 
   24 | 
/<>/rtengine/dcraw.h:189:13: error: ‘uint32_t’ does not name a type
  189 | uint32_t MediaType; /* 1 -> /C/RAW, 2-> JPEG */
  | ^~~~
/<>/rtengine/dcraw.h:189:13: note: ‘uint32_t’ is defined in header 
‘’; did you forget to ‘#include ’?
/<>/rtengine/dcraw.h:579:30: error: ‘uint32_t’ has not been 
declared
  579 | bool crxDecodePlane(void *p, uint32_t planeNumber);
  |  ^~~~
[ 16%] Building CXX object rtengine/CMakeFiles/rtengine.dir/flatcurves.cc.o

```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=rawtherapee=riscv64=5.9-1=1694185774=0

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1051606: RM: sysprof [i386] -- RoM; ANAIS; The GUI binary package is no longer built

[jeremy . bicha]

The removals page suggests removing too much. I think this string would work:

dak rm -p -d 1051606 -R -C package -m "RoM; ANAIS; The GUI binary package is no 
longer built" -b -a i386 sysprof

Thank you,
Jeremy Bícha

Bug#1051638: freerdp2: CVE-2023-39350 CVE-2023-39351 CVE-2023-39352 CVE-2023-39353 CVE-2023-39354 CVE-2023-39355 CVE-2023-39356 CVE-2023-40181 CVE-2023-40186 CVE-2023-40188 CVE-2023-40567 CVE-2023-405

[Salvatore Bonaccorso]

Source: freerdp2
Version: 2.10.0+dfsg1-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.10.0+dfsg1-1

Hi,

The following vulnerabilities were published for freerdp2.

CVE-2023-39350[0]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. This issue affects Clients
| only. Integer underflow leading to DOS (e.g. abort due to
| `WINPR_ASSERT` with default compilation flags). When an insufficient
| blockLen is provided, and proper length validation is not performed,
| an Integer Underflow occurs, leading to a Denial of Service (DOS)
| vulnerability. This issue has been addressed in versions 2.11.0 and
| 3.0.0-beta3. Users are advised to upgrade. There are no known
| workarounds for this vulnerability.


CVE-2023-39351[1]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Affected versions of
| FreeRDP are subject to a Null Pointer Dereference leading a crash in
| the RemoteFX (rfx) handling.  Inside the
| `rfx_process_message_tileset` function, the program allocates tiles
| using `rfx_allocate_tiles` for the number of numTiles. If the
| initialization process of tiles is not completed for various
| reasons, tiles will have a NULL pointer. Which may be accessed in
| further processing and would cause a program crash. This issue has
| been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised
| to upgrade. There are no known workarounds for this vulnerability.


CVE-2023-39352[2]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Affected versions are
| subject to an invalid offset validation leading to Out Of Bound
| Write. This can be triggered when the values `rect->left` and
| `rect->top` are exactly equal to `surface->width` and
| `surface->height`. eg. `rect->left` == `surface->width` &&
| `rect->top` == `surface->height`. In practice this should cause a
| crash. This issue has been addressed in versions 2.11.0 and
| 3.0.0-beta3. Users are advised to upgrade. There are no known
| workarounds for this vulnerability.


CVE-2023-39353[3]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Affected versions are
| subject to a missing offset validation leading to Out Of Bound Read.
| In the `libfreerdp/codec/rfx.c` file there is no offset validation
| in `tile->quantIdxY`, `tile->quantIdxCb`, and `tile->quantIdxCr`. As
| a result crafted input can lead to an out of bounds read access
| which in turn will cause a crash. This issue has been addressed in
| versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There
| are no known workarounds for this vulnerability.


CVE-2023-39354[4]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Affected versions are
| subject to an Out-Of-Bounds Read in the `nsc_rle_decompress_data`
| function. The Out-Of-Bounds Read occurs because it processes
| `context->Planes` without  checking if it contains data of
| sufficient length. Should an attacker be able to leverage this
| vulnerability they may be able to cause a crash. This issue has been
| addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to
| upgrade. There are no known workarounds for this vulnerability.


CVE-2023-39355[5]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Versions of FreeRDP on the
| 3.x release branch before beta3 are subject to a Use-After-Free in
| processing `RDPGFX_CMDID_RESETGRAPHICS` packets. If
| `context->maxPlaneSize` is 0, `context->planesBuffer` will be freed.
| However, without updating `context->planesBuffer`, this leads to a
| Use-After-Free exploit vector. In most environments this should only
| result in a crash. This issue has been addressed in version
| 3.0.0-beta3 and users of the beta 3.x releases are advised to
| upgrade. There are no known workarounds for this vulnerability.


CVE-2023-39356[6]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. In affected versions a
| missing offset validation may lead to an Out Of Bound Read in the
| function `gdi_multi_opaque_rect`. In particular there is no code to
| validate if the value `multi_opaque_rect->numRectangles` is less
| than 45. Looping through `multi_opaque_rect->`numRectangles without
| proper boundary checks can lead to Out-of-Bounds Read errors which
| will likely lead to a crash. This issue has been addressed in
| versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There
| are no known workarounds for this vulnerability.


CVE-2023-40181[7]:
| FreeRDP is a free implementation of the Remote Desktop Protocol
| (RDP), released under the Apache license. Affected versions are
| subject to an 

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Carsten Schoenert]

Hello Alejandro,

Am 09.09.23 um 22:46 schrieb Alejandro Colomar:

Hi,

Since some recent version, every time I delete a mail, the list scrolls
up a few messages, and I need to manually scroll down again, every time.


did tried to follow these steps?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

I can't reproduce this issues.

--
Regards
Carsten

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

[Hideki Yamane]

On Sat, 09 Sep 2023 22:41:48 -0700
Russ Allbery  wrote:
> >  How about just pointing SPDX licenses URL for whole license text and
> >  lists DFSG-free licenses from that? (but yes, we should adjust short
> >  name of licenses for DEP-5 and SPDX for it).
> 
> Can we do this legally?  If we can, it certainly has substantial merits,
> but I'm not sure that this satisfies the requirement in a lot of licenses
> to distribute a copy of the license along with the work.  Some licenses
> may allow that to be provided as a URL, but I don't think they all do
> (which makes sense since people may receive Debian on physical media and
> not have Internet access).

 Hmm, how about providing license-common package and that depends on
 "license-common-list", and ISO image provides both, then? It would be
 no regressions.


 I expect license-common-list data as below

 license-short-name: URL
 GPL-2: file:///usr/share/common-licenses/GPL-2
 Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

-- 
Hideki Yamane 

Bug#1051595: RFS: geeqie/1:2.1-1 -- image viewer using GTK+

[Andreas Rönnquist]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "geeqie":

 * Package name : geeqie
   Version  : 1:2.1-1
 * URL  : http://geeqie.org/
 * License  : GPL-2+, GFDL-1.2+
 * Vcs  : https://salsa.debian.org/debian/geeqie
   Section  : graphics

The source builds the following binary packages:

  geeqie - image viewer using GTK+
  geeqie-common - data files for Geeqie

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/geeqie/

Alternatively, you can download the package with 'dget' using this command:

  dget -x https://mentors.debian.net/debian/pool/main/g/geeqie/geeqie_2.1-1.dsc

Changes since the last upload:

 geeqie (1:2.1-1) unstable; urgency=medium
 .
   * Update debian/watch
   * New upstream version 2.1
   * Refresh patches
   * Remove patch Fix-1023-Unresponsive-UI-when-Show-Marks-is-enabled.patch
   * No need to install AUTHORS file
   * Install SVG icon too
   * d/changelog: remove trailing whitespace
   * Update Debian copyright to 2023
   * Remove unused include-binaries
   * Upgrade to Standards Version 4.6.2 (No changes required)
   * Add patch to fix lintian warning privacy-breach-generic
   * Add lintian override for false positive spelling error
 (ment/meant)

Regards,
-- 
  Andreas Rönnquist

Bug#1021601: vlc: VAAPI hardware acceleration no more available

[Viktor Horvath]

With a fresh config, my VLC in bookworm would play the file with a bit
less than 1 frame per second... console output:

$ VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[55d9bd39e550] main libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[55d9bd43f4b0] main playlist: playlist is empty
[7fbcd4004d30] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
[7fbcd4004d30] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
[7fbcf000e340] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for 
hardware decoding

The system here is a Intel Pentium Silver J5005 with built-in "UHD
Graphics 605" (Gemini Lake).

My workarounds: one of

* explicitly configure VLC for XVideo output - no GPU acceleration but
at least an acceptable picture;  (this would have been what I expected
VLC to do out-of-the-box)

* use "mpv --hwdec=vaapi"

* use the Flatpak VLC version ("org.videolan.VLC") - though that pulls
in more than 1 GB of platform data, if you didn't use flatpak before.

Best regards,
Viktor.


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

Bug#1051601: ITP: node-geojson -- Node.js library to convert geo data into GeoJSON

[Yadd]

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

* Package name: node-geojson
  Version : 0.5.0
  Upstream Contact: Casey Cesari
  
* URL : https://github.com/caseycesari/geojson.js
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to convert geo data into GeoJSON

node-geojson is a dependency of node-vega-lite and a TS dependency of
node-d3. It will be maintained under JS Team umbrella.

Bug#1051471: btrfsd: cron job for calling btrfsd

[Matthew Vernon]

Hi,

Just a note on the libsystemd dependency.

On 10/09/2023 10:21, Martin Steigerwald wrote:


Sure, that should actually be extremely low-maintenance, there isn't
any hard dependency the daemon has on systemd - with one exception: It
uses libsystemd to write to the journal if that's available, and I
would like to keep that feature. It will however already fall back to
syslog in case sd-journal isn't available, and libsystemd is inert on
systems without systemd.


On Debian systems, libelogind0 Provides: libsystemd0, so a libsystemd0 
dependency (which, as you say, util-linux has) isn't a problem.


Regards,

Matthew

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

[Paul Menzel]

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 suggest you have a look at your `systemd-analyze critical-chain`
to see your actual critical chain.


Thank you. I am well aware of these tools – including systemd-bootchart.


Kind regards,

Paul

Bug#1051625: RM: rust-sha3-0.9 -- RoM; obsolete duplicate of rust-sha3

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: rust-sha-3-...@packages.debian.org
Affects: src:rust-sha3-0.9

Please remove rust-sha3-0.9

It has no remaining users and there is rust-sha3 instead.

On behalf of the Debian Rust Team,
Jeremy Bicha

Bug#1051624: RM: rust-sha2-0.9 -- RoM; obsolete duplicate of rust-sha2

[Jeremy Bícha]

Package: ftp.debian.org
X-Debbugs-Cc: rust-sha-2-...@packages.debian.org
Affects: src:rust-sha2-0.9
Control: block -1 by 1051620

Please remove rust-sha2-0.9

It has no remaining users and there is rust-sha2 instead.

On behalf of the Debian Rust Team,
Jeremy Bicha

Bug#1050502: gnome-shell crashes when restarting it with ALT+F2 and "r"

[Simon McVittie]

Control: retitle -1 gnome-shell crash when restarting with ALT+F2, "r" on 
nvidia-graphics-drivers
Control: affects -1 + src:mutter src:nvidia-graphics-drivers
Control: tags -1 + moreinfo

On Fri, 25 Aug 2023 at 13:34:17 +0200, Markus Steinko wrote:
> Restarting the gnome-shell with ALT+F2 and then typing r - made the system
> crash.

I see you're using an Nvidia GPU with nvidia-graphics-drivers:

> ii libglx-nvidia0 [libglx-vendor] 525.125.06-2
> ii nvidia-egl-icd [libegl-vendor] 525.125.06-2

which makes this bug report look similar to of one of the two scenarios
in #1050731.

Are you using a high-refresh-rate (144Hz) monitor? The reporter of
#1050731 said that they were able to work around the crash by setting
a 60Hz refresh rate. If the same workaround works for you, that would
be a useful data point; or if it *doesn't* work for you, then that's
also a useful data point.

On Fri, 25 Aug 2023 at 13:52:06 +0200, Markus Steinko wrote:
> Here's also an coredumpctl debug output:
> 
> user@hostname:/var/lib/systemd/coredump$ sudo coredumpctl debug

Please could you re-trace this, either with libmutter-12-0-dbgsym installed
or with DEBUGINFOD_URLS="https://debuginfod.debian.net; in the environment?
(sudo env DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl debug)
That will give us more information on precisely how it is crashing, which
is very useful when determining whether two crashes are really the same
thing, and also makes it much more likely that a solution can be found.

Also, please look for any messages from gnome-shell in the system log
(systemd journal) at the time of the crash, by using the journalctl
tool or reading the file /var/log/syslog. For example you might see
something similar to this:

2023-09-10T16:09:04.136417+01:00 tautology gnome-shell[2831]: 
clutter_actor_contains: assertion 'CLUTTER_IS_ACTOR (self)' failed

or this:

May  7 18:02:51 darter gnome-shell[2213]: Attempting to run a JS callback 
during garbage collection. This is most likely caused by destroying a Clutter 
actor or GTK widget with ::destroy signal connected, or using the destroy(), 
dispose(), or remove() vfuncs. Because it would crash the application, it has 
been blocked.

Please copy anything from around the time of the crash.

Thanks,
smcv

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

[Bill Allombert]

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > Quoting Hideki Yamane (2023-09-10 11:00:07)
> 
> >>  Hmm, how about providing license-common package and that depends on
> >>  "license-common-list", and ISO image provides both, then? It would be
> >>  no regressions.
> 
> I do wonder why we've never done this.  Does anyone know?  common-licenses
> is in an essential package so it doesn't require a dependency and is
> always present, and we've leaned on that in the past in justifying not
> including those licenses in the binary packages themselves, but I'm not
> sure why a package dependency wouldn't be legally equivalent.  We allow
> symlinking the /usr/share/doc directory in some cases where there is a
> dependency, so we don't strictly require every binary package have a
> copyright file.

Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the 
copying
themselves.

Cheers,
Bill

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Russ Allbery]

Guillem Jover  writes:

> Seems I missed another file:

>   * .changes:
> policy → «upload control file» / «Debian changes file»
> dpkg   → «upload control file» / «.changes control file» /
>  «Debian .changes file» / «Debian changes file»

[...]

> For changes I think something like the following might be a more clear
> option (and has the minor bonus of aligning perfectly on the first
> words! :), with it mentioning explicitly this is about changes being
> uploaded, and that it is a control file (but I'm not sure I'm entirely
> convinced about it):

> * .changes:   «Debian upload changes control files»

[...]

> I've also found instances of «record» and «section» referring to fields
> or stanzas.

[...]

> I also recalled another term that has always seemed very confusing in
> context: «control information files» or «control information area». For
> example in a sentence such as “the control file is a control information
> file in the control information area in a .deb archive”. :) This also
> seems confusing when some of the files in the .deb control member are
> not really “control files” with a deb822(5) format.

> My thinking has been going into calling these as the «metadata files»,
> and being located in either the  «metadata part of the .deb archive» or
> explicitly the «control member of the .deb archive», in contrast to the
> filesystem part. In dpkg I'd be eventually switching to meta/metadata
> and fsys/filesystem, from control or info and data. I've added a patch
> with the proposed change, but again nothing set in stone, and I'm again
> open to discussing pros/cons of this.

> Attached the proposals for discussion/review, and I might again have
> perhaps missed instances or similar.

All of these changes seem straightforward and uncontroversial to me, and
there are huge advantages to using consistent terminology between Policy
and dpkg.  I have applied all of them for the next Policy release.  Thank
you!

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

Bug#967324: eboard: depends on deprecated GTK 2

[Bastian Germann]

Am 10.09.23 um 15:44 schrieb Francesco Poli:

After a quick search, I found

   xboard 

and maybe

   tagua 
   scid 

Any other?


Certainly pychess, which should be the most popular one.


Which ones may be used to play chess with package 'stockfish'?
Possibly through 'polyglot'?


Right. I think pychess can work as UCI client as well.

Bug#1051635: firmware-linux: missing firmware on AMD

[Xavier Bestel]

Package: firmware-linux
Version: 20210315-3
Severity: normal

Dear Maintainer,

On my 6.1.0 kernel, I have this message:
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: enabling device ( -
> 0002)
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: no command queues
available
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: sev enabled
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: psp enabled
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: firmware: failed to
load amd/amd_sev_fam17h_model31h.sbin (-2)
[dim. 10 sept. 17:37:23 2023] firmware_class: See
https://wiki.debian.org/Firmware for information about missing firmware
[dim. 10 sept. 17:37:23 2023] ccp :43:00.1: firmware: failed to
load amd/amd_sev_fam17h_model31h.sbin (-2)

Apparently I'm missing a firmware for my machine. Would it be possible
to have it in stable ?

Regards,

Xavier

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

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

Versions of packages firmware-linux depends on:
ii  firmware-linux-free 20200122-1
ii  firmware-linux-nonfree  20210315-3

Versions of packages firmware-linux recommends:
ii  amd64-microcode  3.20230719.1~deb10u1
ii  intel-microcode  3.20230808.1~deb10u1

firmware-linux suggests no packages.

-- no debconf information

Bug#1049863: Partial Solution

[Илия]

After applying patch "xthread_fix.patch" and siebenmann's patch posted here:
https://github.com/fvwmorg/fvwm3/issues/818#issuecomment-1401144381

The issue seems to go away, when using fvwm 2.7.0 source code, icons
are displayed as it should, after restart, application fullscreen
change, etc.
But, maybe, there is a reason to wait for a more official solution, as
a main FVWM developer is aware about this issue in all FVWM 2/3
versions when using new GNU/Linux distributions.