Bug#1036279: XSS in RSS syntax

[Salvatore Bonaccorso]

Control: retitle -1 dokuwiki: CVE-2023-34408: XSS in RSS syntax

Hi,

On Thu, May 18, 2023 at 03:19:05PM +0200, Moritz Muehlenhoff wrote:
> Source: dokuwiki
> Version: 0.0.20220731.a-1
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> No CVE yet:
> https://huntr.dev/bounties/c6119106-1a5c-464c-94dd-ee7c5d0bece0/
> https://github.com/dokuwiki/dokuwiki/pull/3967
> https://www.github.com/splitbrain/dokuwiki/commit/53df38b0e4465894a67a5890f74a6f5f82e827de

CVE-2023-34408 has been assigned for this issue.

Regards,
Salvatore

Bug#1037079: unblock: configobj/5.0.8-2

[Salvatore Bonaccorso]

Hi,

On Sun, Jun 04, 2023 at 09:50:23PM +0200, Sebastian Ramacher wrote:
> retitle 1037079 bookworm-pu: configobj/5.0.8-2
> tags 1037079 bookworm moreinfo
> user release.debian@packages.debian.org
> usertags 1037079 + pu - unblock
> thanks
> 
> Hi Stefano
> 
> On 2023-06-03 16:28:41 -0400, Stefano Rivera wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: config...@packages.debian.org
> > Control: affects -1 + src:configobj
> > 
> > Please unblock package configobj
> 
> We have entered the quiet periold of bookworm [1]. Please consider
> fixing this issue via bookworm-pu. As this update fixes a security
> issue, please also check with the Security Team in case this update is
> worth of a DSA.

As it does not warrant a DSA, the first bookworm point release is fine
for it.

Regards,
Salvatore

Bug#1037111: ITP: pipewire-module-xrdp -- xRDP module for the PipeWire sound server

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-utopia-maintain...@lists.alioth.debian.org

* Package name: pipewire-module-xrdp
  Version : git HEAD
  Upstream Contact: https://github.com/matt335672/pipewire-module-xrdp/issues
* URL : https://github.com/matt335672/pipewire-module-xrdp
* License : MIT
  Programming Lang: C
  Description : xRDP module for the PipeWire sound server

This module allows xrdp to generate sound on a pipewire-based system.

A known user of xrdp is the MS Hyper-V virtual machines, when running in
so-called "Enhanced Session Mode" or ESM for short. ESM means that user
access their VM over xRDP. In this mode, if the Linux guest uses
Pipewire, then we need an additional xRDP module for the sound.

Discussions show that there's interest from PipeWire upstream to include
such a module [1]. So hopefully, the package pipewire-module-xrdp that
I'm proposing here is only temporary.

I plan to maintain this package with the Utopia team (which already
maintains pipewire), and I'd be happy to get a round of review from
them.

[1]: 
https://github.com/neutrinolabs/xrdp/discussions/2023#discussioncomment-4829470

Bug#1037110: ITP: libgraphviz2-perl -- Perl interface to the GraphViz graphing tool

[Andrew Ruthven]

Package: wnpp
Owner: Andrew Ruthven 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgraphviz2-perl
  Version : 2.67
  Upstream Author : Ron Savage 
* URL : https://metacpan.org/release/GraphViz2
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl interface to the GraphViz graphing tool

This module provides an interface to layout and image generation of
directed and undirected graphs in a variety of formats (PostScript,
PNG, etc.) using the "dot", "neato", "twopi", "circo" and "fdp"
programs from the GraphViz project (http://www.graphviz.org/ or
http://www.research.att.com/sw/tools/graphviz/).

This is a complete rewrite of the module in libgraphviz-perl which
extends support to all the latest features of Graphviz. It is not
backwards compatible with libgraphviz-perl. In addition, the
GraphViz Perl module is deprecated[0], GraphViz2 is the replacement.
GraphViz2 is a dependency of Request Tracker v5.0.4.

The package will be maintained under the umbrella of the Debian Perl Group.

[0] https://metacpan.org/pod/GraphViz

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |



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

Bug#1037109: ITP: libtest-snapshot-perl -- test against data stored in automatically-named file

[Andrew Ruthven]

Package: wnpp
Owner: Andrew Ruthven 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name    : libtest-snapshot-perl 
  Version : 0.06 
  Upstream Author : Ed J  
* URL : https://metacpan.org/release/Test-Snapshot 
* License : GPL-1+ or Artistic 
  Programming Lang: Perl 
  Description : test against data stored in automatically-named file

Not connected with Test::Snapshots, which is based on a similar  
concept but for running executables.

Implements a function to automate the storing and updating of expected 
test outputs. This is based on the idea known in frontend development 
circles as "snapshot testing", hence the module name.

The package will be maintained under the umbrella of the Debian Perl 
Group.

This module is required for building the GraphViz2 Perl module which
I'm about to file an ITP about.

[Apologies for the previous email, first time I've submitted an ITP
for a number of years!]

 -- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |


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

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

Hey Paul,
On Sun, Jun 4, 2023 at 10:36 PM Paul Gevers  wrote:
> On 04-06-2023 21:28, Martin-Éric Racine wrote:
> > As previously stated, the Geode LX (but not older Geodes) does fulfill
> > the baseline requirement for i686. NOPL, PAE and others were marked by
> > Intel as optional features. If what the new Debian baseline really
> > means is something that can run the -686-pae kernel, the release notes
> > should explicitly say so.
>
> I believe you are more aware of the problems with the Geode than I, as
> it were your bugs that lead to the update in the release notes. If I
> understand correctly the kernel still runs fine, but a bunch of
> important binaries use NOPL and hence fail on the Geode. We could add a
> check for NOPL, like I mentioned in the MR.

I pasted the result of 'uname -a' and 'cat /proc/cpuinfo' on the Salsa
merge request. It should give someone a good idea of what the LX (but
not earlier Geodes) supports.

> > On a related issue, something in dpkg or apt should check the CPU
> > features and refuse to perform an upgrade/dist-upgrade on an host
> > whose CPU doesn't meet the new baseline requirements.
>
> Please file a bug with the respective packages. Mentioning it in a bug
> against the release notes isn't going to achieve that feature.

Oh, totally. I'm just not sure of which one typically handles this.
Last time the baseline was raised from 586 to 686 (before that from
486 to 586), something in the upgrade process performed the CPU check
and loudly aborted the proceedings. Something similar was done when
the baseline was raised on SPARC ages ago; upgrade aborted early if
the host hardware didn't meet the new baseline.

Martin-Éric

Bug#1036740: [Pkg-netatalk-devel] Bug#1036740: closed by Markus Koschany (Re: Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault with valid metadata)

[Daniel Markstedt]

On Sat, Jun 3, 2023 at 11:07 PM Jonas Smedegaard  wrote:
>
> Quoting Salvatore Bonaccorso (2023-06-04 07:39:12)
> > Hi Daniel,
> >
> > On Sat, Jun 03, 2023 at 02:56:00PM -0700, Daniel Markstedt wrote:
> > > > -- Forwarded message --
> > > > From: Markus Koschany 
> > > > To: Daniel Markstedt , 1036740-d...@bugs.debian.org
> > > > Cc: debian-...@lists.debian.org
> > > > Bcc:
> > > > Date: Thu, 01 Jun 2023 19:54:55 +0200
> > > > Subject: Re: Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault 
> > > > with valid metadata
> > > > Version:  3.1.12~ds-3+deb10u2
> > > >
> > > > Thanks for your report and the detailed replies. I could reproduce the 
> > > > problem
> > > > and identify a wrongly applied commit in libatalk/adouble/ad_open.c. 
> > > > After
> > > > applying a new patch to fix it, the AppleDouble v2 format seems to work 
> > > > as
> > > > intended again. I'm going to close this bug report now.
> > > >
> > > > Best,
> > > >
> > > > Markus
> > > >
> > >
> > > Thank you Markus for narrowing down the problem and fixing it!
> > > I can confirm that appledouble=v2 works in my environment now too.
> > >
> > > So this covers the outstanding CVEs for oldstable now;
> > > are you already preparing to port the same patchset to stable as well?
> > >
> > > I can file another bug report if it helps.
> >
> > No other reports needed, since all were reported. For the bookworm
> > release they would be fixed, for the current stable (bullseye) we
> > explicitly asked the maintainer trough
> > https://bugs.debian.org/1025011#15 . So we are waiting for the
> > netatalk maintainers to propose an update here for bullseye-security.
>
> @Salvatore: In addition to being upstream developer, Daniel has also
> joined the Debian packaging team.
>

Salvatore, I left a comment over at that bug. It should be easy to
accomplish if I can learn how to contribute patches to security
releases.

> @Daniel: Debian issue tracker - debbugs - can be confusing from an
> upstream POV, due to it being distro-centric: Some issues are not about
> upstream code but "meta" about distro organization - e.g. bug#1025011
> which is not about netatalk but about *attention* for netatalk and
> therefore open despite netatalk itself has no bugs. Also, issues tied to
> upstream projects is tracked across multiple Debian releases, so can be
> both fixed and unfixed depending on release scope.
>
> What is double confusing here is that no bugreport exists in Debian for
> tracking CVE-2022-23123 - bug#1036740 filed by you is about collateral
> damage in fixing that CVE for oldstable, and bug#1025011 is about
> meta-discussion only indirectly involving that same CVE.
>
> All in all: Yes, please file a bugreport about CVE-2022-23123 - and then
> tag it as closed with package release 3.1.15~ds-1, which makes that
> bugreport "fixed" for the scope of Debian testing and unstable, but
> unfixed for the scope of Debian stabel.
>
>
> Hope that helps.
>
>  - Jonas
>

Jonas, definitely a helpful summary, thanks!

However, I assume you mean CVE-2022-45188 for bookworm regarding
filing a bug to resolve an already resolved CVE?
This one was fixed with 3.1.15 but due to a typo in the commit message
was left as unresolved, if I'm not mistaken.

As far as I can tell, CVE-2022-23123 is already properly flagged as
resolved both for bookworm and sid.

Please let me know if there's something I overlooked here!

Best,
Daniel

Bug#1036899: logiops: logid does not work for MX Master 3

[Chow Loong Jin]

On Sun, May 28, 2023 at 11:01:16PM +0200, Hendrik Tews wrote:
> Package: logiops
> Version: 0.3.1-1
> Severity: important
> X-Debbugs-Cc: none, Hendrik Tews 
> 
> Dear Maintainer,
> 
> after upgrading to logiops version 0.3.1-1 the logid daemon does not
> seem to do anything any more. For my configuration the symptom is that
> the thumb button is no longer mapped to button 2. The problem seems to
> be also present in the current upstream version (v0.3.2), see upstream
> issue 387 (https://github.com/PixlOne/logiops/issues/387).
> 
> For now I downgraded to 0.2.3-1+b1, which is still working fine.

Hey Hendrik,

Could you check if 0.3.1-1 (in unstable) or 0.3.2-1 (in experimental) is
working for you?

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1025011: [Pkg-netatalk-devel] Bug#1025011: fixed in netatalk 3.1.15~ds-1

[Daniel Markstedt]

On Wed, May 24, 2023 at 7:18 AM Moritz Mühlenhoff  wrote:
> [...]
> It's nice that there's renewed interest, but this involves also taking
> care of netatalk in stable, there's a range of issues (full list at
> https://security-tracker.debian.org/tracker/source-package/netatalk)
> which need to be backported to bullseye-security.
>
> I'm reopening the bug, it can be closed with the respective upload
> to bullseye-security.
>
> Cheers,
> Moritz
>

Since both buster and bullseye use the same base version of netatalk
(3.1.12) the work required here should be straight-forward: Simply
bring over the CVE patchset that were applied to buster-security.

A snippet from `apt source netatalk` on buster:
[...]
dpkg-source: info: applying CVE-2022-45188.patch
dpkg-source: info: applying CVE-2022-43634.patch
dpkg-source: info: applying CVE-2022-23125.patch
dpkg-source: info: applying CVE-2022-23121.patch
dpkg-source: info: applying CVE-2021-31439.patch
dpkg-source: info: applying CVE-2022-23123_part1.patch
dpkg-source: info: applying CVE-2022-23123_part2.patch
dpkg-source: info: applying CVE-2022-23123_part3.patch
dpkg-source: info: applying CVE-2022-23123_part4.patch
dpkg-source: info: applying CVE-2022-23123_part5.patch
dpkg-source: info: applying CVE-2022-23121_regression.patch

The only real difference between buster and bullseye netatalk 3.1.12
is that the latter have a few extra backported crashfixes etc. I had a
quick look and concluded that they shouldn't interfere with the CVE
patches.

I'd be happy to try to achieve the "upload to bullseye-security" if
you all can give me some pointers. This is all new to me.

Best regards,
Daniel

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 30 May 2023 at 17:12, Leonardo Held  wrote:
>
> Package: qt6-base-dev
> Followup-For: Bug #1035985
>
> Dear Maintainer,
>
> please consider bumping the severity level of #1035985, as it makes
> Debian unable to use qt on the many embedded platforms, and the next
> stable will be affected by this for a long time. Is it possible to
> include the `QT_FEATURE_opengles2` flag before the release? I'm
> willingly to send a patch if needed.

I am afraid it was discovered too late in the release process. My plan
is to test it as soon as Bookworm is released and hopefully get a
stable pu update. But I can't promise anything.

Bumping the severity for a feature not discovered in time is a non-go.

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

[Luca Boccassi]

On Sun, 4 Jun 2023 at 14:56, Simon McVittie  wrote:
>
> (Newly cc'd elogind maintainers: Please see #945269 for context)
>
> On Sun, 04 Jun 2023 at 12:15:41 +0100, Luca Boccassi wrote:
> > On Sun, 4 Jun 2023 at 12:02, Sean Whitton  wrote:
> > > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
> > > > For now I've kept only a mention of the 'systemd-tmpfiles' virtual
> > > > package. As maintainers we would really prefer if the 'main'
> > > > implementation is pulled in whenever possible. When a minimal
> > > > installation is desired (ie, a minbase), it is possible to manually
> > > > specify the -standalone variant.
> > > >
> > > > This was a controversial point last year, see:
> > > >
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441
> > >
> > > Hmm.  I don't have personal experience with this sort of thing, but
> > > based on some of the examples in that bug, it seems like doing this
> > > could cause apt to change people's systems around in ways they strongly
> > > disprefer.  What you propose seems like it could cause unpleasant
> > > surprises.
> >
> > Only due to bugs in said other packages, or if the wrong commands are
> > passed to apt/aptitude/etc.
>
> I think one way or another, if anyone is going to set a package-level
> dependency on systemd-tmpfiles, the first (preferred) dependency needs to
> be on either a concrete provider (systemd or systemd-tmpfiles-standalone
> in this case), or a default-systemd-tmpfiles virtual package
> that only has one provider per architecture (which is the way
> {default-,}dbus-{system,session}-bus are handled). Otherwise, you
> can get a non-deterministic choice of default implementation, which
> seems strictly worse than either depending on systemd or depending on
> systemd-tmpfiles-standalone - if you're unlucky, it can have all the
> disadvantages of either one of those.
>
> So I think the only realistic options for packages that hard-require
> this functionality (not all do) are:
>
> 1. Depends: systemd | systemd-tmpfiles
> 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
> 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles
>
> (where the third one is equivalent to one of the first two, depending on
> how default-systemd-tmpfiles was implemented), possibly with some more
> less-preferred options between the first "|" and the virtual-package
> fallback.
>
> I also think that Policy shouldn't be recommending this interface without
> also being able to give guidance on what an appropriate dependency would
> look like, because if some packages choose (1.) and some choose (2.),
> again we'll get a non-deterministic result, depending on which packages
> you happen to install first and what their maintainers think; and I don't
> want individual services' maintainers to be required to constantly argue
> whether (1.) or (2.) is better.
>
> In #1017441 the debhelper maintainers declined to generate such a
> dependency, but even if they had wanted to generate it centrally, we'd
> have the same distro-integration considerations about saying what the
> right dependency would look like.
>
> Before describing pros and cons of those options in different scenarios,
> I want to reiterate that installing the systemd package (which contains
> the default/recommended implementation of the systemd-tmpfiles interface)
> does not imply using systemd as an init system, and everywhere in this
> message that I have said "systemd", I specifically mean the systemd
> package and not systemd-as-pid-1.
>
> >From the point of view of init systems, I think the interesting scenarios
> are:
>
> A. systemd package installed (typically via systemd-sysv)
> B. non-systemd init system (typically sysvinit) and no systemd package
> C. no init system at all (typically in Docker or a chroot)
>
> For (A.), there is no ambiguity: systemd is installed and provides the
> tmpfiles interface, and everything is fine. Any dependency sequence ((1.),
> (2.) or (3.) above) should give us the result we want. The only problem
> scenario I can think of for (A.) with (2.) is:
>
> - a package (let's say foo-service) has chosen (2.) and so depends on
>   systemd-tmpfiles-standalone | systemd-tmpfiles
> - we install a base system with neither foo-service nor systemd
>   - this must be a minbase debootstrap or similar, because a default
> debootstrap already includes systemd-sysv
> - we install foo-service first, without systemd
>   - systemd-tmpfiles-standalone is pulled in
> - afterwards, we install systemd (via the init metapackage and
>   systemd-sysv, or directly)
>   - desired result: systemd-tmpfiles-standalone is removed and replaced by
> systemd
>   - actual result: apt's heuristic might have difficulty realising that
> it needs to do that
>
> I would have expected that anyone wanting an environment with an init
> system is more likely to include it in the bootstrap or in the first
> batch of post-bootstrap additions than to install it later, but maybe
> that's 

Bug#1037108: evolution-data-server: gnome-keyring should not be a dependency

[Sebastian Crane]

Package: evolution-data-server
Version: 3.38.3-1+deb11u2
Severity: minor
X-Debbugs-Cc: none, Sebastian Crane 

Currently, gnome-keyring is listed as a run-time dependency.
gnome-keyring is only one implementation of the freedesktop.org Secret
Service API, and so other secrets management software (such as
KeePassXC) could be used instead.

The gnome-keyring package installs files into the system configuration
that cause it to be started automatically on login. As systemd units are
not used, disabling gnome-keyring entirely can be challenging.

I therefore suggest removing the dependency on gnome-keyring.

Best wishes,

Sebastian

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert 
wrote:
> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> > If you prefer, I can reword the general rule to be stricter, ie:
> > "packages must not use diversions where native mechanisms are
> > available" or so. Would this be better?
> 
> "native mechanisms" seems to vague.

Well, I originally had written precisely what I meant, but was told on
this thread to "add normative language for only the general case"
instead, so I've done that. That's always going to sound vague. I
cannot do both at the same time.

As you can see from the latest revision, right now the rule is general
but it's immediately followed by a very concrete and documented
example. Open to precise suggestions on how to improve it.

-- 
Kind regards,
Luca Boccassi


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

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Otto Kekäläinen]

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

For reference:

* The upgrade scenario this MR fixed:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/15cbf6e691827608636e6ff7f0a50432f50d0c4f
* Release notes mention:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187
* Upload to experimental pending in NEW queue:
https://ftp-master.debian.org/new/mariadb_1:10.11.3-2~exp1.html
* Release team consultation:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037107

Bug#1037107: pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1

[Otto Kekäläinen]

Package: release.debian.org
Severity: serious
Tags. bookworm
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 src:mariadb

This pre-unblock request is to get a decision from the Bookworm
release team if you prefer to have this Bug#1035949 fix:

a) in Bookworm in a stable update
b) not at all

(option c to have it in Bookworm I assume is too late)


## The new Debian revision reason: Bug#1035949

In Bug#1035949 it was discovered that in certain upgrade scenarios
where a system has default-mysql-server indirectly installed (e.g. as
a dependency of a consumer, such as zoph) running `apt-get install
default-mysql-server` would trigger a sequence in apt which uninstalls
mariadb-client-10.5 before mariadb-server-10.5 is stopped, causing
dpkg to error as the MariaDB init file in mariadb-server-10.5 depends
on mariadb-admin from mariadb-client-10.5.

Running apt full-upgrade or apt dist-upgrade is not affected. Details
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035949, marked
'serious'.

The issue was not visible in normal piuparts or in any of the custom
Salsa-CI jobs testing upgrades in src:mariadb. Credits goes to Andreas
Beckman for discovering the issue by meticulously testing various
Bookworm upgrade scenarios semi-manually with piuparts!


## Fix: introduce transitional mariadb-server-10.5

Andreas also figured out the fix for this as none of the other
attempted fixes were successful. The fix is to introduce a
transitional mariadb-server-10.5 package:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47

Work on this particular issue has only been done around Bullseye to
Bookworm upgrades. The same issue might also need a transitional
mariadb-server-10.3 if we want to support flawless Buster to Bookworm
upgrades.


## Testing and quality assurance

Once Bug#1035949 was reported, a Salsa-CI job was added specifically
for this type of upgrade scenarios:
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/15cbf6e691827608636e6ff7f0a50432f50d0c4f

The fix has been validated to work both by this Salsa-CI scenario and
by Andrea's piuparts runs. To expedite the distribution of the fix it
has already been uploaded to experimental. Full debdiff attached, and
visual comparison with full commit metadata at
https://salsa.debian.org/mariadb-team/mariadb-server/-/compare/00c0a8fc...93c08bcc.

Since it introduces a new package (albeit that it already existed in
Debian previously) the upload needs to also pass the NEW queue:
https://ftp-master.debian.org/new/mariadb_1:10.11.3-2~exp1.html


## Risk quantification and analysis

This is not a regression from any recent uploads of MariaDB 10.11, but
has existed since the introduction of 10.11 into Debian on January
16th, 2023. This is the first time this specific issue was reported by
people doing or testing upgrades from mariadb-10.5 (or mariadb-10.6,
which was in testing/unstable before 10.11).

This may have existed upstream since MariaDB 10.7 from 2022
(https://jira.mariadb.org/browse/MDEV-286409), but never got proper
attention by me as I was busy maintaining the package in Debian, and
10.7/8/9/10 were never in Debian.

While Bug#1035949 has participation only from one reporter it is
reasonable to expect that there are and will be more users affected.

There are no known drawbacks of having a transitional
mariadb-server-10.5 in Bookworm.


## Mitigation

For the time being as a mitigation was filed to mention this as a
potential issue in the Bookworm release notes:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187
(Bug#1037103).


mariadb-1%10.11.3-2_exp1.debdiff.xz
Description: application/xz

Bug#1037106: asciidoctor: Some tips to improve the formatting quality of man pages

[Bjarni Ingi Gislason]

Package: asciidoctor
Version: 2.0.18-2
Severity: minor

Dear Maintainer,

here are some observations about created man pages with asciidoctor. 



Do not use '.sp' right after paragraphing macros like "SH".



Begin each sentence on a new line, applies to both the source file and
the man page, see man-pages(7).



Don't use '\c' after a normal line, it's use is to join the output of
_two_ macros without an intervening space.

### 

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

Kernel: Linux 6.1.27-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages asciidoctor depends on:
ii  ruby  1:3.1
ii  ruby-asciidoctor  2.0.18-2

asciidoctor recommends no packages.

asciidoctor suggests no packages.

-- no debconf information

Bug#1037105: dkms unable to compile r8168-dkms to backported kernel

[epp]

Package: r8168-dkms
Version: 8.048.03-3


I installed SpiralLinux, which installs the current Debian stable at the time 
the image was released, in this case, bullseye and it also enables Backports by 
default. During the upgrade process after the initial installation, dkms 
reported it was having issues with the r8168-dkms package, presumably 
compiling/adding (?) it to the kernel, which is a backported kernel.


The kernel version is 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux

My network card has the Realtek r8169 chip on it, so this package was 
unnecessary. Once I purged the package and rebooted, network connectivity was 
restored. 


Although I do not require this package, I felt that it should be reported to 
Debian as a bug, in hopes that a fix is found for those who require the package.


Below is information that was displayed during the time dkms was having the 
issue, plus the log file from the stated filename.




dkms: running auto installation service for kernel 6.1.0-0.deb11.7-amd64:
Kernel preparation unnecessary for this kernel.  Skipping...


Building module:
cleaning build area...
make -j2 KERNELRELEASE=6.1.0-0.deb11.7-amd64 -C 
/lib/modules/6.1.0-0.deb11.7-amd64/build 
M=/var/lib/dkms/r8168/8.050.03/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-0.deb11.7-amd64 
(x86_64)
Consult /var/lib/dkms/r8168/8.050.03/build/make.log for more information.




DKMS make.log for r8168-8.050.03 for kernel 6.1.0-0.deb11.7-amd64 (x86_64)
Sun 04 Jun 2023 02:50:39 PM EDT
make: Entering directory '/usr/src/linux-headers-6.1.0-0.deb11.7-amd64'
  CC [M]  /var/lib/dkms/r8168/8.050.03/build/r8168_n.o
  CC [M]  /var/lib/dkms/r8168/8.050.03/build/r8168_asf.o
In file included from /var/lib/dkms/r8168/8.050.03/build/r8168_n.c:87:
/var/lib/dkms/r8168/8.050.03/build/r8168_n.c: In function ‘rtl8168_init_one’:
/var/lib/dkms/r8168/8.050.03/build/r8168.h:564:57: error: too many arguments to 
function ‘netif_napi_add’
  564 | #define RTL_NAPI_CONFIG(ndev, priv, function, weight)   
netif_napi_add(ndev, >napi, function, weight)
  | ^~
/var/lib/dkms/r8168/8.050.03/build/r8168_n.c:26866:9: note: in expansion of 
macro ‘RTL_NAPI_CONFIG’
26866 | RTL_NAPI_CONFIG(dev, tp, rtl8168_poll, R8168_NAPI_WEIGHT);
  | ^~~
In file included from /var/lib/dkms/r8168/8.050.03/build/r8168_n.c:46:
/usr/src/linux-headers-6.1.0-0.deb11.7-common/include/linux/netdevice.h:2569:1: 
note: declared here
 2569 | netif_napi_add(struct net_device *dev, struct napi_struct *napi,
  | ^~
/var/lib/dkms/r8168/8.050.03/build/r8168_n.c:26907:25: error: implicit 
declaration of function ‘netif_set_gso_max_size’; did you mean 
‘netif_set_tso_max_size’? [-Werror=implicit-function-declaration]
26907 | netif_set_gso_max_size(dev, LSO_32K);
  | ^~
  | netif_set_tso_max_size
cc1: some warnings being treated as errors
make[1]: *** 
[/usr/src/linux-headers-6.1.0-0.deb11.7-common/scripts/Makefile.build:255: 
/var/lib/dkms/r8168/8.050.03/build/r8168_n.o] Error 1

Bug#1037104: sasl2-bin in conflict with SASL library for subversion?

[DGhost]

package: sasl2-bin
version: 2.1.27

When installing subversion on Debian Bullseye, the svnserve is running fine; 

svnserve --version
svnserve, version 1.14.1 (r1886195)
   compiled Apr  5 2022, 23:23:59 on x86_64-pc-linux-gnu

Copyright (C) 2021 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_x : Module for working with an experimental (FSX) repository.
* fs_base : Module for working with a Berkeley DB repository.

Cyrus SASL authentication is available.

But as soon I installed sasl2-bin I get: 

svnserve --version
svnserve: E200029: Couldn't perform atomic initialization
svnserve: E170001: Could not initialize the SASL library
svnserve: E170001: error when parsing configuration file

Even after uninstall sasl2-bin, the error stays the same (using apt-get purge 
also).

Could there be a conflict between libsasl2-2 and sasl2-bin?

Regards.

Alex

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[inasprecali]

Hi,

I tried installing chromium-l10n again on a freshly updated
Bullseye machine (with the bullseye-security and bullseye-updates
repositories enabled, of course) and this time the operation
succeeded with no conflicts.

Unless there are new reports about this problem persisting, I
think this bug can be closed.

Best regards.

Bug#1037102: stack trace

[Tim McConnell]

Stack trace of thread 621419:
#0 
0x5608483faf53 n/a (distort + 0x5f53)
#1 
0x5608483fc62b n/a (distort + 0x762b)
#2 
0x5608483fa0cc n/a (distort + 0x50cc)
#3 
0x7f5197b2118a __libc_start_call_main (libc.so.6 + 0x2718a)
#4 
0x7f5197b21245 __libc_start_main_impl (libc.so.6 + 0x27245)
#5 
0x5608483fa9c1 n/a (distort + 0x59c1)
ELF object binary
architecture: AMD x86-64

Bug#1037103: release-notes: MariaDB 10.11, versionless package names, potential upgrade issue

[Otto Kekäläinen]

Package: release-notes
Severity: normal
Tags: patch

Hi!

Please consider including
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187
in release notes for Bookworm. Details in submission.

Bug#1037101: ITP: mobilitydb -- geospatial trajectory data management & analysis platform

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: "Bradford D. Boyle" 
X-Debbugs-Cc: debian-de...@lists.debian.org, bradford.d.bo...@gmail.com

* Package name: mobilitydb
  Version : 1.1
  Upstream Contact: Esteban Zimanyi 
* URL : https://github.com/MobilityDB/MobilityDB
* License : PostgreSQL
  Programming Lang: C
  Description : geospatial trajectory data management & analysis platform

MobilityDB is a database management system for moving object geospatial
trajectories, such as GPS traces. It adds support for temporal and
spatio-temporal objects to the PostgreSQL database and its spatial
extension PostGIS.

This will be team-maintained within the PostgreSQL team.

Bug#1037079: unblock: configobj/5.0.8-2

[Sebastian Ramacher]

retitle 1037079 bookworm-pu: configobj/5.0.8-2
tags 1037079 bookworm moreinfo
user release.debian@packages.debian.org
usertags 1037079 + pu - unblock
thanks

Hi Stefano

On 2023-06-03 16:28:41 -0400, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: config...@packages.debian.org
> Control: affects -1 + src:configobj
> 
> Please unblock package configobj

We have entered the quiet periold of bookworm [1]. Please consider
fixing this issue via bookworm-pu. As this update fixes a security
issue, please also check with the Security Team in case this update is
worth of a DSA.

Cheers

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg0.html
-- 
Sebastian Ramacher

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Paul Gevers]

Hi Martin-Éric,

On 04-06-2023 21:28, Martin-Éric Racine wrote:

As previously stated, the Geode LX (but not older Geodes) does fulfill
the baseline requirement for i686. NOPL, PAE and others were marked by
Intel as optional features. If what the new Debian baseline really
means is something that can run the -686-pae kernel, the release notes
should explicitly say so.


I believe you are more aware of the problems with the Geode than I, as 
it were your bugs that lead to the update in the release notes. If I 
understand correctly the kernel still runs fine, but a bunch of 
important binaries use NOPL and hence fail on the Geode. We could add a 
check for NOPL, like I mentioned in the MR.



On a related issue, something in dpkg or apt should check the CPU
features and refuse to perform an upgrade/dist-upgrade on an host
whose CPU doesn't meet the new baseline requirements.


Please file a bug with the respective packages. Mentioning it in a bug 
against the release notes isn't going to achieve that feature.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

On Mon, 29 May 2023 06:52:22 +0200 Paul Gevers  wrote:
> On 28-05-2023 17:32, Paul Gevers wrote:
> > On 11-05-2023 20:20, Paul Gevers wrote:
> >> Please review my proposal here:
> >>
> >> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
> >
> > The release notes now document that the baseline has been bumped.
>
> I ment this message to close the bug, but I failed to adjust the mail To
> header.

As commented both on Salsa and in response to your previous e-mail, I
still don't think that the release notes adequately describe the
updated baseline for i386.

As previously stated, the Geode LX (but not older Geodes) does fulfill
the baseline requirement for i686. NOPL, PAE and others were marked by
Intel as optional features. If what the new Debian baseline really
means is something that can run the -686-pae kernel, the release notes
should explicitly say so.

On a related issue, something in dpkg or apt should check the CPU
features and refuse to perform an upgrade/dist-upgrade on an host
whose CPU doesn't meet the new baseline requirements.

Martin-Éric

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello again,
Uploaded again to mentors.
Turns out bullseye-backports lintian (2.115.1~bpo11+1) only checks for 4.6.1 
Standards, therefore a more serious error (depends-on-obsolete-package 
lsb-base) was reported by sid lintian.
Upon inspecting the situation (lsb-base is now a transitional empty package 
only here for debootstrap purposes mainly) and reading 
https://lists.debian.org/debian-devel/2023/01/msg00160.html I removed the 
package dependency entirely. This should be entirely safe. I also added 
Upstream-Contact into debian/copyright and stripped some trailing whitelines. 
Package should be lintian O.K. now.
Nicholas, my salsa account is verified now, waiting for push permission if that 
is ok. Is there anything else I should do now about that ?

Best,
Alexandru

--- Original Message ---
On Saturday, June 3rd, 2023 at 12:59 PM, Alexandru Mihail 
 wrote:


> Hi,
> Thanks everyone for the input !
> Indeed the forking service type is the correct one for this package as 
> daemon() is called as part of the initialization sequence. (if daemon() is 
> not available, plain fork() is called anyway)
> I've adjusted debian/rules, taking into consideration Lorenzo's advice, 
> thanks Lorenzo !
> 
> > Thanks! Do you know if you'd prefer to fork and file pull
> > requests/merge requests, or wait for the permissions to push directly to
> > be granted?
> 
> I'd prefer waiting for push permission, for sure; if that is not possible in 
> the near future, I can also fork and file requests.
> 
> Have a great weekend!
> Alexandru
> 
> --- Original Message ---
> On Saturday, June 3rd, 2023 at 1:58 AM, Nicholas D Steeves nstee...@gmail.com 
> wrote:
> 
> 
> 
> > Alexandru Mihail alexandru_mih...@protonmail.ch writes:
> > 
> > > As for the old bugs, at least #491078 and #1018900 are stil present, I
> > > shall test a user submitted patch for the first one.
> > 
> > Thank you for taking the time to verify and document this. While not
> > required, it would also be nice if #491078 was noted in the appropriate
> > patch[es]. Bug-Debian is an optional field:
> > https://dep-team.pages.debian.net/deps/dep3/
> > 
> > > I'll also create a salsa account soon.
> > 
> > Thanks! Do you know if you'd prefer to fork and file pull
> > requests/merge requests, or wait for the permissions to push directly to
> > be granted?
> > 
> > > I hope this mail finds you well !
> > 
> > Thanks, you as well!
> > Nicholas

Bug#1037100: cpp-httplib: CVE-2023-26130

[Salvatore Bonaccorso]

Source: cpp-httplib
Version: 0.11.4+ds-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cpp-httplib.

CVE-2023-26130[0]:
| Versions of the package yhirose/cpp-httplib before 0.12.4 are
| vulnerable to CRLF Injection when untrusted user input is used to set
| the content-type header in the HTTP .Patch, .Post, .Put and .Delete
| requests. This can lead to logical errors and other misbehaviors.
| **Note:** This issue is present due to an incomplete fix for
| [CVE-2020-11709](https://security.snyk.io/vuln/SNYK-UNMANAGED-
| YHIROSECPPHTTPLIB-2366507).

The related CVE-2020-11709 was fixed before the initial upload to
Debian.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-26130
https://www.cve.org/CVERecord?id=CVE-2023-26130
[1] https://security.snyk.io/vuln/SNYK-UNMANAGED-YHIROSECPPHTTPLIB-5591194
[2] 
https://github.com/yhirose/cpp-httplib/commit/5b397d455d25a391ba346863830c1949627b4d08

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033341: org-mode: CVE-2023-28617

[David Bremner]

Salvatore Bonaccorso  writes:

>
> Looking at https://security-tracker.debian.org/tracker/CVE-2023-28617
> I think we should be fine for bookworm already, correct?

Yes, I think what is there makes sense, given the constraints of
expressing a weird situation.

d

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[Salvatore Bonaccorso]

Hi Moritz,

On Sun, Jun 04, 2023 at 08:40:19PM +0200, Salvatore Bonaccorso wrote:
> Hi Moritz,
> 
> On Sun, Jun 04, 2023 at 07:22:47PM +0200, Moritz Muehlenhoff wrote:
> > On Sun, Jun 04, 2023 at 12:06:01PM -0400, Andres Salomon wrote:
> > > Hi Security Team,
> > > 
> > > Looking at 
> > > https://security.debian.org/debian-security/pool/main/c/chromium/
> > > , I see that chromium-l10n built for bookworm (deb12u1) but not for 
> > > bullseye
> > > (deb11u1). I'm guessing that the arch:all build was interrupted or is 
> > > still
> > > in a needs-build state or something, but since it's the security infra I
> > > can't see it. Can you please do a giveback or whatever is needed to get it
> > > building, or if something is reproducably broken with the build please 
> > > send
> > > me the build log?
> > 
> > I sent a giveback, let's see what comes out of it.
> 
> Incidently it was asked about it already this afternoon, and did gave
> back as well earlier today. But the build failed again. If your
> give-back fails as well then we need to fetch the build logs to
> understand the failures.

Actually according to Adam, my give-back from earlier this afternoon
ist still running, and your give back did put the state again in
needs-build state.

But this means we will see the results likely earlier depending on
what happends on the earlier triggered build.

Hopefully the build will suggeeds and it was just a temporary hickup.

Regards,
Salvatore

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[Salvatore Bonaccorso]

Hi Moritz,

On Sun, Jun 04, 2023 at 07:22:47PM +0200, Moritz Muehlenhoff wrote:
> On Sun, Jun 04, 2023 at 12:06:01PM -0400, Andres Salomon wrote:
> > Hi Security Team,
> > 
> > Looking at https://security.debian.org/debian-security/pool/main/c/chromium/
> > , I see that chromium-l10n built for bookworm (deb12u1) but not for bullseye
> > (deb11u1). I'm guessing that the arch:all build was interrupted or is still
> > in a needs-build state or something, but since it's the security infra I
> > can't see it. Can you please do a giveback or whatever is needed to get it
> > building, or if something is reproducably broken with the build please send
> > me the build log?
> 
> I sent a giveback, let's see what comes out of it.

Incidently it was asked about it already this afternoon, and did gave
back as well earlier today. But the build failed again. If your
give-back fails as well then we need to fetch the build logs to
understand the failures.

Regards,
Salvatore

Bug#1037099: RFS: lighttpd/1.4.71-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.71-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.71-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036020
for lighttpd 1.4.70, this currently targets experimental, though I
would like to get this into testing and into Bookworm in due time.
Please advise.

Thank you.  Glenn

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Bill Allombert]

On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> If you prefer, I can reword the general rule to be stricter, ie:
> "packages must not use diversions where native mechanisms are
> available" or so. Would this be better?

"native mechanisms" seems to vague.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Samuel Thibault]

Hello,

Cyril Brulebois, le jeu. 01 juin 2023 21:12:18 +0200, a ecrit:
> Do we have other ttys than just tty1 that people might want to switch
> to, and that might benefit from a similar adjustment?

This script is actually not used for the other consoles, so it has never
had any effect on them on any arch anyway.

Samuel

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Samuel Thibault]

Emanuele Rocca, le jeu. 01 juin 2023 15:11:53 +0200, a ecrit:
> On 2023-05-31 05:46, Samuel Thibault wrote:
> > I'd rather see a patch like
> > 
> > if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
> > # Busybox's init uses a global TERM across all consoles.
> > # If the serial console is the default such as on arm64, that
> > # will force vt102 on the Linux VT. Fix this back so we get
> > # colors, utf-8, etc.
> > TERM=linux
> > fi
> > 
> > (to be tested etc.)
> 
> The following patch works. I've built a netboot image with patched rootskel,
> see attached screenshots for before and after the cure.

Thanks for testing!

I have uploaded it
(with fixed indent)

Samuel

> diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux 
> /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux
> --- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 
> 01:05:16.0 +0100
> +++ 
> /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux 
>   2023-06-01 15:05:32.514361854 +0200
> @@ -1,5 +1,13 @@
>  export LANG=C
> 
> +if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
> +   # Busybox's init uses a global TERM across all consoles.
> +# If the serial console is the default such as on arm64, that
> +# will force vt102 on the Linux VT. Fix this back so we get
> +   # colors, utf-8, etc.
> +   TERM=linux
> +fi
> +
>  if [ "$TERM" = linux ] ; then
> if [ "$TERM_TYPE" = virtual ]; then
> echo -ne "\033[9;0]" # Turn off console blanking.

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[Moritz Muehlenhoff]

On Sun, Jun 04, 2023 at 12:06:01PM -0400, Andres Salomon wrote:
> Hi Security Team,
> 
> Looking at https://security.debian.org/debian-security/pool/main/c/chromium/
> , I see that chromium-l10n built for bookworm (deb12u1) but not for bullseye
> (deb11u1). I'm guessing that the arch:all build was interrupted or is still
> in a needs-build state or something, but since it's the security infra I
> can't see it. Can you please do a giveback or whatever is needed to get it
> building, or if something is reproducably broken with the build please send
> me the build log?

I sent a giveback, let's see what comes out of it.

Cheers,
Moritz

Bug#1037098: RFS: serious-engine/0~git20230515+dfsg-1 [ITP]

[Sébastien Noel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "serious-engine":

 * Package name : serious-engine
   Version  : 0~git20230515+dfsg-1
   Upstream contact : https://github.com/ptitSeb/Serious-Engine/issues
 * URL : https://www.croteam.com/serious-sam-source-code-released/
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/twolife/serious-engine
   Section  : contrib/games

The source builds the following binary packages:

  serious-sam-tfe - Serious Sam - The First Encounter
  serious-sam-tse - Serious Sam - The Second Encounter

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

  https://mentors.debian.net/package/serious-engine/

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

  dget -x
https://mentors.debian.net/debian/pool/contrib/s/serious-engine/serious-engine_0~git20230515+dfsg-1.dsc

Changes for the initial release:

 serious-engine (0~git20230515+dfsg-1) unstable; urgency=low
 .
   * Initial release. Closes: #1034630


This package alone isn't of any use; it only contains the game engine,
an engine that has no Free data and therefore is in contrib.
You will need a copy of the original game for this package to be
useful.
Please use/build the git version of game-data-packager
https://salsa.debian.org/games-team/game-data-packager 
to build a .deb of proprietary data (gog or steam) to unleash the full
potential of this code.

Best Regards,
Sébastien

Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated

[Guilhem Moulin]

Control: tag -1 moreinfo unreproducible

Hi,

On Sun, 04 Jun 2023 at 10:41:56 +0200, Georg Gast wrote:
> But dropbear did not start as it was complaining about the missing dss host
> key.
> […]
> If i delete /etc/dropbear/initramfs/dropbear_dss_host_key and generate a new
> one
> dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key
> in the resuce shell dropbear starts.

Which version of the dropbear-bin package is that?  2022.83-1 doesn't
support DSS, see the NEWS-file.

> Versions of packages dropbear-initramfs depends on:
> ii  busybox-static [busybox]  1:1.35.0-4+b3
> pn  dropbear-bin  
> ii  initramfs-tools   0.142
> ii  udev  252.6-1

dropbear-initramfs=2022.83-1 has ‘Depends: dropbear-bin (>= 2022.83-1)’,
so it can skip over DSS key generation when dependencies are fulfilled.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[Andres Salomon]

Hi Security Team,

Looking at 
https://security.debian.org/debian-security/pool/main/c/chromium/ , I 
see that chromium-l10n built for bookworm (deb12u1) but not for 
bullseye (deb11u1). I'm guessing that the arch:all build was 
interrupted or is still in a needs-build state or something, but since 
it's the security infra I can't see it. Can you please do a giveback or 
whatever is needed to get it building, or if something is reproducably 
broken with the build please send me the build log?


Thanks,
Andres

On Sun, Jun 4 2023 at 10:25:26 AM +00:00:00, Attila Hammer 
 wrote:

Package: chromium-l10n
Severity: important

Dear Maintainer,

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


   * What led up to the situation?
sudo apt install chromium chromium-l10n command results me following 
error

message:
"Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies: chromium-l10n : 
Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 
114.0.5735.90-2~deb11u1 is to be installed

E: Unable to correct problems, you have held broken packages."


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Simple ran sudo apt install chromium chromium-l10n command.

   * What was the outcome of this action?
Previous Chromium and Chromium related language packages are right 
installed.


   * What outcome did you expect instead?

The quoted error message since yesterday.
I am not using pinned repositoryes, holded packages,
simple used standard Bullseye related repositories.


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


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium-l10n depends on:
pn  chromium  

chromium-l10n recommends no packages.

chromium-l10n suggests no packages.

Bug#1036268: gnome-shell: Session crashes, thrown out to login screen, after the session has been idle & screen switched off

[Amr Ibrahim]

Am Samstag, dem 27.05.2023 um 21:32 +0100 schrieb Simon McVittie:
> What is logged in the systemd journal when this crash occurs?

Today another crash. Attached is gnome-logs-important.txt

> A backtrace from the crash would be very useful information for this or any
> other crash. Please see :
> usually the easiest way is to use the systemd-coredump package, as described
> in 

Attached are coredumpctl info and debug.

16:25:59 systemd: Failed to start app-gnome-gnome\x2dkeyring\x2dssh-13893.scope 
- Application launched by gnome-session-binary.
16:02:24 systemd-coredum: Process 2121 (gnome-shell) of user 1000 dumped core.

Module libnss_resolve.so.2 from deb systemd-252.6-1.amd64
Module libudev.so.1 from deb systemd-252.6-1.amd64
Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Stack trace of thread 2121:
#0  0x7fbb351e8963 n/a (libwayland-server.so.0 + 0xd963)
#1  0x7fbb351e3bda n/a (libwayland-server.so.0 + 0x8bda)
#2  0x7fbb351e689a wl_event_loop_dispatch (libwayland-server.so.0 + 0xb89a)
#3  0x7fbb3574d937 n/a (libmutter-11.so.0 + 0x14d937)
#4  0x7fbb3653e7a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
#5  0x7fbb3653ea38 n/a (libglib-2.0.so.0 + 0x54a38)
#6  0x7fbb3653ecef g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#7  0x7fbb356d6eb5 meta_context_run_main_loop (libmutter-11.so.0 + 0xd6eb5)
#8  0x55995c54e924 n/a (gnome-shell + 0x2924)
#9  0x7fbb3544618a n/a (libc.so.6 + 0x2718a)
#10 0x7fbb35446245 __libc_start_main (libc.so.6 + 0x27245)
#11 0x55995c54ebc1 n/a (gnome-shell + 0x2bc1)

Stack trace of thread 2125:
#0  0x7fbb3551afff __poll (libc.so.6 + 0xfbfff)
#1  0x7fbb3653e9ae n/a (libglib-2.0.so.0 + 0x549ae)
#2  0x7fbb3653eacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#3  0x7fbb3653eb11 n/a (libglib-2.0.so.0 + 0x54b11)
#4  0x7fbb36568cfd n/a (libglib-2.0.so.0 + 0x7ecfd)
#5  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#6  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 2137:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbb1e50c059 n/a (iris_dri.so + 0x10c059)
#3  0x7fbb1e4be17b n/a (iris_dri.so + 0xbe17b)
#4  0x7fbb1e50bf97 n/a (iris_dri.so + 0x10bf97)
#5  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#6  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 2138:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbb1e50c059 n/a (iris_dri.so + 0x10c059)
#3  0x7fbb1e4be17b n/a (iris_dri.so + 0xbe17b)
#4  0x7fbb1e50bf97 n/a (iris_dri.so + 0x10bf97)
#5  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#6  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 2140:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbb1e50c059 n/a (iris_dri.so + 0x10c059)
#3  0x7fbb1e4be17b n/a (iris_dri.so + 0xbe17b)
#4  0x7fbb1e50bf97 n/a (iris_dri.so + 0x10bf97)
#5  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#6  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 2142:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbb1e50c059 n/a (iris_dri.so + 0x10c059)
#3  0x7fbb1e4be17b n/a (iris_dri.so + 0xbe17b)
#4  0x7fbb1e50bf97 n/a (iris_dri.so + 0x10bf97)
#5  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#6  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 2205:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbb332692a7 
_ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE 
(libmozjs-102.so.0 + 0xa692a7)
#3  0x7fbb3326943d 
_ZN7mozilla6detail21ConditionVariableImpl8wait_forERNS0_9MutexImplERKNS_16BaseTimeDurationINS_27TimeDurationValueCalculatorEEE
 (libmozjs-102.so.0 + 0xa6943d)
#4  0x7fbb32a7d645 n/a (libmozjs-102.so.0 + 0x27d645)
#5  0x7fbb32a7d6f1 n/a (libmozjs-102.so.0 + 0x27d6f1)
#6  0x7fbb32a7c9f7 n/a (libmozjs-102.so.0 + 0x27c9f7)
#7  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#8  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 10468:
#0  0x7fbb354a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7fbb354a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7fbae14fc99f n/a (librsvg-2.so.2 + 0xfc99f)
#3  0x7fbae14fc3be n/a (librsvg-2.so.2 + 0xfc3be)
#4  0x7fbae16c2c92 n/a (librsvg-2.so.2 + 0x2c2c92)
#5  0x7fbae16c83f1 n/a (librsvg-2.so.2 + 0x2c83f1)
#6  0x7fbae16bebed n/a (librsvg-2.so.2 + 0x2bebed)
#7  0x7fbae1a31153 n/a (librsvg-2.so.2 + 0x631153)
#8  0x7fbb354a7fd4 n/a (libc.so.6 + 0x88fd4)
#9  0x7fbb355285bc n/a (libc.so.6 + 0x1095bc)

Stack trace of thread 10465:
#0  

Bug#1037096: Acknowledgement (firmware-iwlwifi: Intel AC 8265 Wifi card missing with iwlwifi-8265-36.ucode: Failed to start INIT ucode: -110)

[Leon Weber]

For others affected, installing firmware-iwlwifi from bullseye is a
possible workaround for this issue.

This can be achieved e.g. by pinning:

Add an entry to /etc/apt/sources.list such as

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037096
deb http://deb.debian.org/debian bullseye non-free
deb http://security.debian.org/debian-security/ bullseye-security non-free 
non-free-firmware

Add a pin for firmware-iwlwifi to /etc/apt/preferences:

Package: *
Pin: release n=bullseye
Pin-Priority: -1

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037096
Package: firmware-iwlwifi
Pin: release n=bullseye
Pin-Priority: 1000

Run apt update, apt dist-upgrade and reboot. Make sure to remove this
pin once this issue is resolved to receive updates for this package in
the future.

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Bob Friesenhahn]

My own testing is under Ubuntu 20.04 using GCC 10.

Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.


As a further data point, I compiled the test program under Illumos 
(Solaris derivative) and it was able to run tens of thousands of loops 
without any memory leak or other anomaly.


In this case GCC 7.5.0 was used.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#1037097: shotwell: problem with sendto and thunderbird : there is no attachment file since the dropping of nautilus sendto in version 0.3.15 (it works with other mailers)

[Romain Kobylanski]

Package: shotwell
Version: 0.30.17-1+b1
Severity: normal
X-Debbugs-Cc: romain.kobylan...@free.fr

Dear Maintainer,

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


* What led up to the situation?
* What exactly did you do (or not do) that was effective (or ineffective)?

I tried to send a photo with the "sendto" menu item. The thuderbird send 
window opens but there is no document attached.With another mailer like 
evolution or emacs mail it works correctly


I reverted to version 0.30.14-2 where shotwell uses nautilus sednto to 
send the photo by email
The problem started with version 0.30.15 of shotwell ( since the 
dropping of nautilus sendto)


I use the mate desktop with debain testing

* What was the outcome of this action?
* What outcome did you expect instead?

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


-- Package-specific info:

-- System Information:
Debian Release: 12.0
APT prefers testing
APT policy: (850, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shotwell depends on:

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#1037096: firmware-iwlwifi: Intel AC 8265 Wifi card missing with iwlwifi-8265-36.ucode: Failed to start INIT ucode: -110

[Leon Weber]

Package: firmware-iwlwifi
Version: 20230210-5
Severity: important

After an upgrade from bullseye to bookworm today, during which
firmware-iwlwifi was upgraded from 20210315-3 to 20230210-5, the wifi
interface is missing.

I believe this is the same issue that was previously reported as
#1001927.

Output of dmesg | grep iwlwifi:

[   18.530231] iwlwifi :03:00.0: enabling device ( -> 0002)
[   18.547930] iwlwifi :03:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   18.548294] iwlwifi :03:00.0: loaded firmware version 36.ca7b901d.0 
8265-36.ucode op_mode iwlmvm
[   18.937295] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   19.992546] iwlwifi :03:00.0: SecBoot CPU1 Status: 0x3040001, CPU2 
Status: 0x0
[   19.992705] iwlwifi :03:00.0: WFPM_ARC1_PD_NOTIFICATION: 0xf
[   19.992774] iwlwifi :03:00.0: HPM_SECONDARY_DEVICE_STATE: 0x742
[   19.992844] iwlwifi :03:00.0: WFPM_MAC_OTP_CFG7_ADDR: 0x0
[   19.992913] iwlwifi :03:00.0: WFPM_MAC_OTP_CFG7_DATA: 0x0
[   19.992918] iwlwifi :03:00.0: Collecting data: trigger 15 fired.
[   20.240083] iwlwifi :03:00.0: Not valid error log pointer 0x for 
Init uCode
[   20.240224] iwlwifi :03:00.0: IML/ROM dump:
[   20.240226] iwlwifi :03:00.0: 0x | IML/ROM error/state
[   20.240288] iwlwifi :03:00.0: 0x03040001 | IML/ROM data1
[   20.240298] iwlwifi :03:00.0: Fseq Registers:
[   20.240353] iwlwifi :03:00.0: 0xF554E51D | FSEQ_ERROR_CODE
[   20.240408] iwlwifi :03:00.0: 0xE80E3CB0 | FSEQ_TOP_INIT_VERSION
[   20.240463] iwlwifi :03:00.0: 0x21039CC2 | FSEQ_CNVIO_INIT_VERSION
[   20.240518] iwlwifi :03:00.0: 0xA10B | FSEQ_OTP_VERSION
[   20.240573] iwlwifi :03:00.0: 0xDC7353E2 | FSEQ_TOP_CONTENT_VERSION
[   20.240628] iwlwifi :03:00.0: 0xEBDD85A3 | FSEQ_ALIVE_TOKEN
[   20.240684] iwlwifi :03:00.0: 0x6884A0A0 | FSEQ_CNVI_ID
[   20.240739] iwlwifi :03:00.0: 0xBDD4A936 | FSEQ_CNVR_ID
[   20.240794] iwlwifi :03:00.0: 0x0010 | CNVI_AUX_MISC_CHIP
[   20.240852] iwlwifi :03:00.0: 0x0BADCAFE | CNVR_AUX_MISC_CHIP
[   20.240910] iwlwifi :03:00.0: 0x0BADCAFE | 
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[   20.240968] iwlwifi :03:00.0: 0x0BADCAFE | 
CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[   20.241022] iwlwifi :03:00.0: Failed to start INIT ucode: -110
[   20.241060] iwlwifi :03:00.0: Collecting data: trigger 16 fired.
[   22.247065] iwlwifi :03:00.0: Failed to run INIT ucode: -110
[   22.263081] iwlwifi :03:00.0: retry init count 0
[   22.263199] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   23.320314] iwlwifi :03:00.0: SecBoot CPU1 Status: 0x3040001, CPU2 
Status: 0x0
[   23.320498] iwlwifi :03:00.0: WFPM_ARC1_PD_NOTIFICATION: 0xf
[   23.320662] iwlwifi :03:00.0: HPM_SECONDARY_DEVICE_STATE: 0x742
[   23.320819] iwlwifi :03:00.0: WFPM_MAC_OTP_CFG7_ADDR: 0x0
[   23.320981] iwlwifi :03:00.0: WFPM_MAC_OTP_CFG7_DATA: 0x0
[   23.321001] iwlwifi :03:00.0: Collecting data: trigger 15 fired.
[   23.568419] iwlwifi :03:00.0: Not valid error log pointer 0x for 
Init uCode
[   23.568560] iwlwifi :03:00.0: IML/ROM dump:
[   23.568567] iwlwifi :03:00.0: 0x | IML/ROM error/state
[   23.568715] iwlwifi :03:00.0: 0x03040001 | IML/ROM data1
[   23.568780] iwlwifi :03:00.0: Fseq Registers:
[   23.568912] iwlwifi :03:00.0: 0xF554E51D | FSEQ_ERROR_CODE
[   23.569042] iwlwifi :03:00.0: 0xE80E3CB0 | FSEQ_TOP_INIT_VERSION
[   23.569191] iwlwifi :03:00.0: 0x21039CC2 | FSEQ_CNVIO_INIT_VERSION
[   23.569325] iwlwifi :03:00.0: 0xA10B | FSEQ_OTP_VERSION
[   23.569470] iwlwifi :03:00.0: 0xDC7353E2 | FSEQ_TOP_CONTENT_VERSION
[   23.569609] iwlwifi :03:00.0: 0xEBDD85A3 | FSEQ_ALIVE_TOKEN
[   23.569741] iwlwifi :03:00.0: 0x6884A0A0 | FSEQ_CNVI_ID
[   23.569872] iwlwifi :03:00.0: 0xBDD4A936 | FSEQ_CNVR_ID
[   23.570003] iwlwifi :03:00.0: 0x0010 | CNVI_AUX_MISC_CHIP
[   23.570138] iwlwifi :03:00.0: 0x0BADCAFE | CNVR_AUX_MISC_CHIP
[   23.570273] iwlwifi :03:00.0: 0x0BADCAFE | 
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[   23.570408] iwlwifi :03:00.0: 0x0BADCAFE | 
CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[   23.570557] iwlwifi :03:00.0: Failed to start INIT ucode: -110
[   23.570605] iwlwifi :03:00.0: Collecting data: trigger 16 fired.
[   25.100517] iwlwifi :03:00.0: Failed to run INIT ucode: -110
[   25.113863] iwlwifi :03:00.0: retry init count 1
[   25.113996] iwlwifi :03:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   26.168433] iwlwifi :03:00.0: SecBoot CPU1 Status: 0x3040001, CPU2 
Status: 0x0
[   26.168717] iwlwifi :03:00.0: WFPM_ARC1_PD_NOTIFICATION: 0xf
[   26.168877] iwlwifi :03:00.0: HPM_SECONDARY_DEVICE_STATE: 0x742
[   26.169044] iwlwifi :03:00.0: WFPM_MAC_OTP_CFG7_ADDR: 0x0
[   26.169208] iwlwifi :03:00.0: 

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

[Simon McVittie]

(Newly cc'd elogind maintainers: Please see #945269 for context)

On Sun, 04 Jun 2023 at 12:15:41 +0100, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 at 12:02, Sean Whitton  wrote:
> > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
> > > For now I've kept only a mention of the 'systemd-tmpfiles' virtual
> > > package. As maintainers we would really prefer if the 'main'
> > > implementation is pulled in whenever possible. When a minimal
> > > installation is desired (ie, a minbase), it is possible to manually
> > > specify the -standalone variant.
> > >
> > > This was a controversial point last year, see:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441
> >
> > Hmm.  I don't have personal experience with this sort of thing, but
> > based on some of the examples in that bug, it seems like doing this
> > could cause apt to change people's systems around in ways they strongly
> > disprefer.  What you propose seems like it could cause unpleasant
> > surprises.
> 
> Only due to bugs in said other packages, or if the wrong commands are
> passed to apt/aptitude/etc.

I think one way or another, if anyone is going to set a package-level
dependency on systemd-tmpfiles, the first (preferred) dependency needs to
be on either a concrete provider (systemd or systemd-tmpfiles-standalone
in this case), or a default-systemd-tmpfiles virtual package
that only has one provider per architecture (which is the way
{default-,}dbus-{system,session}-bus are handled). Otherwise, you
can get a non-deterministic choice of default implementation, which
seems strictly worse than either depending on systemd or depending on
systemd-tmpfiles-standalone - if you're unlucky, it can have all the
disadvantages of either one of those.

So I think the only realistic options for packages that hard-require
this functionality (not all do) are:

1. Depends: systemd | systemd-tmpfiles
2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
3. Depends: default-systemd-tmpfiles | systemd-tmpfiles

(where the third one is equivalent to one of the first two, depending on
how default-systemd-tmpfiles was implemented), possibly with some more
less-preferred options between the first "|" and the virtual-package
fallback.

I also think that Policy shouldn't be recommending this interface without
also being able to give guidance on what an appropriate dependency would
look like, because if some packages choose (1.) and some choose (2.),
again we'll get a non-deterministic result, depending on which packages
you happen to install first and what their maintainers think; and I don't
want individual services' maintainers to be required to constantly argue
whether (1.) or (2.) is better.

In #1017441 the debhelper maintainers declined to generate such a
dependency, but even if they had wanted to generate it centrally, we'd
have the same distro-integration considerations about saying what the
right dependency would look like.

Before describing pros and cons of those options in different scenarios,
I want to reiterate that installing the systemd package (which contains
the default/recommended implementation of the systemd-tmpfiles interface)
does not imply using systemd as an init system, and everywhere in this
message that I have said "systemd", I specifically mean the systemd
package and not systemd-as-pid-1.

>From the point of view of init systems, I think the interesting scenarios
are:

A. systemd package installed (typically via systemd-sysv)
B. non-systemd init system (typically sysvinit) and no systemd package
C. no init system at all (typically in Docker or a chroot)

For (A.), there is no ambiguity: systemd is installed and provides the
tmpfiles interface, and everything is fine. Any dependency sequence ((1.),
(2.) or (3.) above) should give us the result we want. The only problem
scenario I can think of for (A.) with (2.) is:

- a package (let's say foo-service) has chosen (2.) and so depends on
  systemd-tmpfiles-standalone | systemd-tmpfiles
- we install a base system with neither foo-service nor systemd
  - this must be a minbase debootstrap or similar, because a default
debootstrap already includes systemd-sysv
- we install foo-service first, without systemd
  - systemd-tmpfiles-standalone is pulled in
- afterwards, we install systemd (via the init metapackage and
  systemd-sysv, or directly)
  - desired result: systemd-tmpfiles-standalone is removed and replaced by
systemd
  - actual result: apt's heuristic might have difficulty realising that
it needs to do that

I would have expected that anyone wanting an environment with an init
system is more likely to include it in the bootstrap or in the first
batch of post-bootstrap additions than to install it later, but maybe
that's wrong? Or are there other problem scenarios here?

I'll come back to (B.), non-default init, in a moment.

No init system at all, (C.), can only happen when starting with a
minbase debootstrap or equivalent (because a default 

Bug#1037075: diffoscope: Get's killed trying to diff 2 large images (> 5GB)

[Holger Levsen]

On Sat, Jun 03, 2023 at 02:08:12PM +0200, Evangelos Ribeiro Tzaras wrote:
> [1]21386 killed diffoscope --debug 
> l5-phosh-{1,2}/mobian-librem5-phosh-20230603.img

fwiw, I can reproduce this bug on bullseye and unstable, with and without
--no-default-limits.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

»Sieh, dass du Mensch bleibst. Mensch sein ist von allem die Hauptsache.
Und das heißt fest und klar und heiter sein, ja heiter, trotz alledem.«
(Rosa Luxemburg)


signature.asc
Description: PGP signature

Bug#1035669: gir1.2-harfbuzz-0.0: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

[James Addison]

Package: gir1.2-harfbuzz-0.0
Followup-For: Bug #1035669
X-Debbugs-Cc: abou.almonta...@sfr.fr
Control: tags -1 patch

Dear Maintainer and Abou,

The attached patch allows me to serialize GIR XML from the HarfBuzz-0.0.typelib
file contained in the resulting gir1.2-harfbuzz-0.0 package.

For more extensive details, please read the patch description; in short, it
removes a C typecast that appears to mislead the gobject build process into
treating the 'HB_LANGUAGE_INVALID' constant (value: zero) as an interface,
instead of a basic (and serializable) integer type.

Please be somewhat skeptical of the patch; I don't know whether it is the
best place for a fix, and it would benefit from awareness and discussion
upstream.  I think it helps identify the approximate area in which the problem
occurs, and my hope is that that is helpful at least.

Regards,
James
Description: Remove typecast from HB_LANGUAGE_INVALID definition
Author: James Addison 

The GObject Introspection tooling identifies the HB_LANGUAGE_INVALID
constant #define'd in hb-common.h as an interface[1] type, due to the
use of a C typecast to a struct type.

Subsequently, attempts to serialize the binary typelib database that
contains the type entry for HB_LANGUAGE_INVALID into an XML format
will fail during serialization[2].

In practice, the value is a constant used for direct comparison
purposes (as is evident in test cases that use '==' comparisons
between NULL and HB_LANGUAGE_INVALID).  Removing the typecast
and annotating it explicitly as a constant[3] value should make that
clearer and enable serialization to XML.

(the annotation is not strictly necessary, but makes it clearer that
the change is intentional and part of the API for the library)

[1] - 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/gitypes.h#L410

[2] - 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/girwriter.c#L784

[3] - https://gi.readthedocs.io/en/latest/annotations/giannotations.html

---
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669
Last-Update: 2023-06-04

--- harfbuzz-6.0.0+dfsg.orig/src/hb-common.h
+++ harfbuzz-6.0.0+dfsg/src/hb-common.h
@@ -315,13 +315,13 @@ HB_EXTERN const char *
 hb_language_to_string (hb_language_t language);
 
 /**
- * HB_LANGUAGE_INVALID:
+ * HB_LANGUAGE_INVALID: (value 0)
  *
  * An unset #hb_language_t.
  *
  * Since: 0.6.0
  */
-#define HB_LANGUAGE_INVALID ((hb_language_t) 0)
+#define HB_LANGUAGE_INVALID 0
 
 HB_EXTERN hb_language_t
 hb_language_get_default (void);

Bug#1035669: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

[James Addison]

Hi Abou,

Please find some slightly re-ordered responses below, and with the
gtk-gnome list and bug on cc because others are likely to know more
than me about this.

On Sat, 3 Jun 2023 at 22:40, Abou Al Montacir  wrote:
...
> However, when starting the conversion, g-ir-generate crashes with an error on 
> HarfBuzz-0.0.
> I've raised a ticket 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669 to that package, 
> but I'm not sure it is an issue in HarfBuzz itself, and maybe it is in 
> g-ir-generate itself.

I'd begun looking into the problem - it seems that the g-ir-generate
tool determines that the HB_LANGUAGE_INVALID constant (zero) is a GTK
'interface'[1] type instead of a basic type (such as int, utf8, ...).
That causes the XML gir serialization failure here[2], because the
interface type isn't supported.

> Few weeks ago, I started adding support for Gtk3 in FPC and Lazarus as part 
> of the effort to close bugs related to the deprecation of Gtk2.
> My goal was to be able to build binding units (pascal modules) from .typelib 
> files shipped by Debian.
> In order to be able to do that, I use a tool called gir2pas that I'm 
> maintaining.
> I've added support for on the fly converting .typelib files using 
> g-ir-generate.

While developing a patch I'd found it difficult to figure out what the
effect of my changes were on the output .typelib binary file.  In
fact, I filed 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/341
as a feature request for diffoscope.  Would any of the code from
gir2pas be helpful to mention there?

> The reason I'm write to debian-devel is to know if we want to enforce the 
> fact that typelib files shall be able to regenerate gir files for Bookworm.
> If this is the case, shall I raise severity to be release critical?

What's the impact of the inability to generate the XML gir files for
gir1.2-harfbuzz on other packages?

Thanks,
James

[1] - 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/gitypes.h#L410

[2] - 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/girwriter.c#L784

Bug#1037095: eyed3: --no-prompt is not recognized

[Björn Wiberg]

Package: eyed3
Version: 0.8.10-4
Severity: normal

Hello,

Just a heads-up that the --no-prompt option mentioned in the eyeD3 (1) man page 
appears not to be supported:

bwiberg@glimmer:/tmp/bw$ eyeD3 --no-prompt --preserve-file-times 
--remove-all-comments --remove-all-images --remove-all-lyrics --remove-v1 *.mp3
eyed3.plugins:WARNING: Plugin '('lastfm.py', 
'/usr/lib/python3/dist-packages/eyed3/plugins')' requires packages that are not 
installed: No module named 'pylast'
usage: eyeD3 [-h] [--version] [-l LEVEL[:LOGGER]] [--profile] [--pdb] 
[--exclude PATTERN] [--fs-encoding ENCODING] [-L] [-P NAME] [-C FILE] 
[--backup] [-Q] [--no-color] [--no-config] [-a STRING] [-A STRING] [-b STRING] 
[-t STRING]
 [-n NUM] [-N NUM] [--track-offset N] [--composer STRING] [-d NUM] 
[-D NUM] [-G GENRE] [--non-std-genres] [-Y YEAR] [-c STRING] [--rename PATTERN] 
[-1] [-2] [--to-v1.1] [--to-v2.3] [--to-v2.4] [--release-date DATE]
 [--orig-release-date DATE] [--recording-date DATE] 
[--encoding-date DATE] [--tagging-date DATE] [--publisher STRING] [--play-count 
<+>N] [--bpm N] [--unique-file-id OWNER_ID:ID] [--add-comment 
COMMENT[:DESCRIPTION[:LANG]]]
 [--remove-comment DESCRIPTION[:LANG]] [--remove-all-comments] 
[--add-lyrics LYRICS_FILE[:DESCRIPTION[:LANG]]] [--remove-lyrics 
DESCRIPTION[:LANG]] [--remove-all-lyrics] [--text-frame FID:TEXT] 
[--user-text-frame DESC:TEXT]
 [--url-frame FID:URL] [--user-url-frame DESCRIPTION:URL] 
[--add-image IMG_PATH:TYPE[:DESCRIPTION]] [--remove-image DESCRIPTION] 
[--remove-all-images] [--write-images DIR]
 [--add-object OBJ_PATH:MIME-TYPE[:DESCRIPTION[:FILENAME]]] 
[--remove-object DESCRIPTION] [--write-objects DIR] [--remove-all-objects] 
[--add-popularity EMAIL:RATING[:PLAY_COUNT]] [--remove-popularity EMAIL] 
[--remove-v1]
 [--remove-v2] [--remove-all] [--remove-frame FID] [--max-padding 
NUM_BYTES] [--no-max-padding] [--encoding latin1|utf8|utf16|utf16-be] 
[--force-update] [-v] [--preserve-file-times]
 [PATH ...]
eyeD3: error: unrecognized arguments: --no-prompt

Best regards
Björn

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

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

Versions of packages eyed3 depends on:
ii  python33.9.2-3
ii  python3-eyed3  0.8.10-4
ii  python3-pkg-resources  52.0.0-4

eyed3 recommends no packages.

eyed3 suggests no packages.

-- no debconf information

Bug#932957: Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi Stuart,

Stuart Prescott  wrote (Sat, 3 Jun 2023 14:45:46 +1000):
> > - The list of archs is hardcoded in the Makefile for now.
> 
> The following might provide you with some useful way of not hard-coding 
> such information:
> 
>   curl -s 'https://api.ftp-master.debian.org/suite/bookworm'
> 
> (pipe that into « jq -r '.architectures[]' » to get just the archs as 
> plain text)

I managed to get a list of all relevant architectures via
curl -s 'https://api.ftp-master.debian.org/suite/testing' | jq -r 
'.architectures[]' | grep -v all | grep -v source

> You might want to make that a 'maintainer-run' step rather than is run 
> occasionally as part of preparing a release, rather than as a build time 
> step. That is, the maintainer runs that from a machine with internet 
> access to find the list of archs that should be used; this is then 
> cached in the repo until it is next refreshed. There is precedent for 
> this 'maintainer-run' step in various "make dist' mechanisms (from the 
> autotools world) and how the dh-python packages prepares a cache of 
> known python modules in the archive for later module→package translation.

I created a prepare-release.sh script, which can be used to prepare the
release-notes for the next stable.
That script creates an archlist file, which holds the relevant archs for
the current testing.

Thanks for helping me with that!


> There has been talk for a while about how we might avoid baking in 
> internal metadata in packages and there might be more inspiration on how 
> to do this in other parts of the project:
> 
>   https://wiki.debian.org/SuitesAndReposExtension
> 
> (there are already a couple of entries there for the release notes)

Shouldn't the above solution be added to that wiki page?
(I don't see it there, right?)


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1037094: gzip: Build for linux should not depend on mingw64

[Henry N.]

Package: gzip
Version: 1.12-1
Severity: minor
Tags: ftbfs
Usertags: rebootstrap

Dear Maintainer,

there exist dependency to mingw-w64 build system,
and in label binary-indep is called i686-w64-mingw32-strip.

This is not nice for cross building, where not need any w64 binaries,
and typically the whole build system for i686-w64-mingw32 is never need.

Why was put the build for "gzip.exe" in binary-indep packages for a Linux 
system?

Please remove the dependency mingw-w64 and do not build "gzip.exe".

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect

Versions of packages gzip depends on:
ii  dpkg   1.21.21
ii  libc6  2.36-8

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  590-1.2

-- no debconf information

Bug#1037093: libarchive: CVE-2023-30571

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.6.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1876
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libarchive.

CVE-2023-30571[0]:
| Libarchive through 3.6.2 can cause directories to have world-writable
| permissions. The umask() call inside archive_write_disk_posix.c
| changes the umask of the whole process for a very short period of
| time; a race condition with another thread can lead to a permanent
| umask 0 setting. Such a race condition could lead to implicit
| directory creation with permissions 0777 (without the sticky bit),
| which means that any low-privileged local user can delete and rename
| files inside those directories.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-30571
https://www.cve.org/CVERecord?id=CVE-2023-30571
[1] https://github.com/libarchive/libarchive/issues/1876

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037091: podman run fails because of missing ~/.config/docker/config.json

[Felix Stupp]

For others having the same issue, just creating an empty file with "touch 
~/.config/docker/config.json" does fix the issue.
Podman does not seem to require any configuration in there (at least in my 
case).

However, as someone might assume that Podman wants any content there,
they still might be virtually hindered to use podman, so I think severity 
important is still correct.
But feel free to reduce that if you think otherwise.

Bug#1037092: erofs-utils: CVE-2023-33551 CVE-2023-33552

[Salvatore Bonaccorso]

Source: erofs-utils
Version: 1.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for erofs-utils.

CVE-2023-33551[0]:
| Heap Buffer Overflow in the erofsfsck_dirent_iter function in
| fsck/main.c in erofs-utils v1.6 allows remote attackers to execute
| arbitrary code via a crafted erofs filesystem image.


CVE-2023-33552[1]:
| Heap Buffer Overflow in the erofs_read_one_data function at data.c in
| erofs-utils v1.6 allows remote attackers to execute arbitrary code via
| a crafted erofs filesystem image.

The proposed fixes are yet only commited in upstream repository but in
the experimental branch. So they might be subject of changes yet.

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-33551
https://www.cve.org/CVERecord?id=CVE-2023-33551
[1] https://security-tracker.debian.org/tracker/CVE-2023-33552
https://www.cve.org/CVERecord?id=CVE-2023-33552

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Bob Friesenhahn]

On Sun, 4 Jun 2023, László Böszörményi wrote:


Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:

I am definitely able to confirm that memory consumption builds due to
invoking GetImageDepth() via a POSIX thread.  The rate that it builds
is image sensitive since some images cause GetImageDepth() to perform
more OpenMP loops.

Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?


Using PNG is not important.  The nature of the input image is 
important.  Prepare a test image like


  gm convert infile.png -depth 4 testfile.pnm

and then use testfile.pnm as input.

The PNM reader is now also also threaded (in very recent versions). 
PNG should work as well to reproduce the bug.



My own testing is under Ubuntu 20.04 using GCC 10.

Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.


That of course is the question.  It seems like some small bit of state 
is being added to (presumably) many thread stacks, I see the number of 
'anon' mappings increasing, and the "heap" similarly grows and, but is 
released before the program exits.


It is possible that doing some OpenMP thing prior to using POSIX 
threads (so OpenMP teams are already created) might change the 
outcome.  I have not tried that yet.


I have attached a version of threadarena.c which loops 1024 times and 
then quits.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt/*
 * gcc -o threadarena threadarena.c \
 *`GraphicsMagick-config --cppflags --ldflags --libs`
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void* readimage(void* arg)
{
  ImageInfo *imageInfo;
  ExceptionInfo exception;
  const char* filename = (const char*) arg;
  /* ImageCharacteristics chars; */
  unsigned long depth;

  imageInfo=CloneImageInfo(0);
  GetExceptionInfo();

  (void) strncpy(imageInfo->filename, arg, MaxTextExtent-1 );

  Image *image = ReadImage(imageInfo, );
  if (image == (Image *) NULL)
{
  CatchException();
  perror("ReadImage");
}

  depth=GetImageDepth(image,);
  if (exception.severity != UndefinedException)
CatchException();
  else
fprintf(stdout,"Depth: %lu\n", depth);

  DestroyImage(image);
  DestroyImageInfo(imageInfo);
  DestroyExceptionInfo(  );
  return NULL;
}

int main ( int argc, char **argv )
{
  unsigned int count = 1024;
  const char* file = argv[1];
  if ( file == NULL )
{
  fprintf(stderr,"usage: %s \n", argv[0]);
  return 1;
}

  InitializeMagick(NULL);

  while (count)
{
  pid_t myp = getpid();
  char s[PATH_MAX];
#if 1
  /* this code path has a thread arena leak */
  pthread_t thread_id;
  pthread_create(_id, NULL, readimage, argv[1]);

  /* pthread_detach(thread_id); also shows the problem */
  pthread_join(thread_id, NULL);
#else
  /* this code path doesn't have a thread arena leak */
  readimage(argv[1]);
#endif

  sleep(1);

  fprintf(stderr,"%u : %lld\n", count, (long long)time(0));
  snprintf(s,sizeof(s),
   "ps -o vsz -o rss -o user -o command -p %lld", (long long)myp);
  system(s);
  snprintf(s,sizeof(s),
   "pmap -x %lld | grep anon | wc -l", (long long)myp);
  system(s);
  count--;
}

  DestroyMagick();

  return 0;
}

Bug#1037091: podman run fails because of missing ~/.config/docker/config.json

[Felix Stupp]

Package: podman
Version: 4.3.1+ds1-8+b1
Severity: important


Dear maintainer,

the current version of podman does not allow me to run any container due
to the following error message:
Error: stat /home/$USER/.config/docker/config.json: no such file or directory

I can trigger this issue with a simple: podman run debian
However, what container I try to run seems not to matter.

The current version in experimental (4.4.0+ds1-1) is also not working on
my machine.

I cannot say which version introduced this issue as I do not use podman
very often. To the best of my knowledge, the last time I used it, it
worked fine and I do not know of any changes I introduced (beside
updates) which could explain this issue.

However, it still seems at least weird to me, that podman requires (not
just reads optionally) a config file which is in Docker's config dir.

I can append further debugging information if requested.

Thanks
Felix Stupp


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'testing-security'), (500, 
'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350, 
'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages podman depends on:
ii  conmon   2.1.6+ds1-1
ii  crun 1.8.1-1+b1
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-9
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  libsubid41:4.13+dfsg1-1+b1
ii  runc 1.1.5+ds1-1+b1

Versions of packages podman recommends:
ii  buildah1.28.2+ds1-3+b1
ii  dbus-user-session  1.14.6-1
ii  fuse-overlayfs 1.10-1
ii  slirp4netns1.2.0-1
ii  tini   0.19.0-1
ii  uidmap 1:4.13+dfsg1-1+b1

Versions of packages podman suggests:
ii  containers-storage  1.43.0+ds1-8
ii  docker-compose  1.29.2-3
ii  iptables1.8.9-2

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

-- no debconf information

Bug#1037090: imagemagick: CVE-2021-3610

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.6
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: fixed -1 8:6.9.12.20+dfsg1-1

Hi,

The following vulnerability was published for imagemagick.

CVE-2021-3610[0]:
| A heap-based buffer overflow vulnerability was found in ImageMagick in
| versions prior to 7.0.11-14 in ReadTIFFImage() in coders/tiff.c. This
| issue is due to an incorrect setting of the pixel array size, which
| can lead to a crash and segmentation fault.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3610
https://www.cve.org/CVERecord?id=CVE-2021-3610

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037089: seatd: improve d/control homepage and add upstream/metadata

[Patrice Duroux]

Package: seatd
Version: 0.7.0-6
Severity: wishlist

Dear Maintainer,

Could it be https://sr.ht/~kennylevinsen/seatd/
instead of https://git.sr.ht/~kennylevinsen/seatd
?
It would also be more consistent to the greetd and wlsunset packages.
See https://salsa.debian.org/debian/greetd/-/blob/master/debian/control
for instance.

And so the upstream source URL could be part of the upstream/metadata file.
See
https://salsa.debian.org/debian/greetd/-/blob/master/debian/upstream/metadata
for instance.

Regards,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 seatd depends on:
ii  debconf1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages seatd recommends:
ii  libseat1  0.7.0-6

seatd suggests no packages.

-- no debconf information

Bug#1037075: diffoscope: Get's killed trying to diff 2 large images (> 5GB)

[Holger Levsen]

hi,

thanks Evangelos, for filing this bug and providing the images exposing it to
https://fortysixandtwo.eu/upload/mobian-librem5-phosh-20230603-{1,2}.img now.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I miss the old days were billionaires’ vanity projects were to build 1000 public
libraries or giant music venues.


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Sun, 4 Jun 2023 at 12:25, Luca Boccassi  wrote:
>
> On Sun, 4 Jun 2023 at 11:54, Sean Whitton  wrote:
> >
> > Hello Luca,
> >
> > On Mon 08 May 2023 at 08:07PM +01, Luca Boccassi wrote:
> >
> > > The specific difference, for which I think an explicit call out is
> > > needed, is because these config files are shipped by some packages but
> > > are not used _by_ them, they are consumed by systemd (or udev, or
> > > kmod, etc). Specifically, if package A ships a.service, and package B
> > > overrides it, even if the maintainers of A and B agree, that's still
> > > not good enough for me, as they are really affecting systemd, which is
> > > the consumer and the provider of the interface they are using, and
> > > ultimately the first port of call for bug reports. This is especially
> > > true for udev.
> > >
> > > So in my latest revision of the patch, the general rule is as
> > > requested by Russ and as you mention it, but there is an explicit,
> > > stricter rule to cover this case, which is important to me. Policy
> > > calls out core component software in many places, such as dpkg, and
> > > systemd is already mentioned in other parts of the policy, so it did
> > > not seem too far-fetched to me.
> >
> > I'm afraid I'm not convinced.  I'd second a patch where systemd is used
> > as an example of the rule, as I suggested.
>
> The existing policy is too weak for this case, ie: it's a "should". It
> needs to be a "must" for these specific cases. Also the existing
> policy only covers diverting from other packages, not from 'self' -
> that needs to be forbidden too. There was one such example,
> iptables-persistent, and it has been fixed in Bookworm, so to be clear
> this is a zero-net-effect policy change, ie, no packages will suddenly
> become rc-buggy, as the two existing instances have already been
> fixed.
>
> If you prefer, I can reword the general rule to be stricter, ie:
> "packages must not use diversions where native mechanisms are
> available" or so. Would this be better?
>
> > Thank you for the additional commit regarding kmod.  It is good to have
> > been made aware of issue, but let's discuss it in a separate bug after
> > making this change -- the considerations might be quite different.
> >
> > On Tue 09 May 2023 at 12:31AM +01, Luca Boccassi wrote:
> >
> > > On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery  wrote:
> > >
> > >> Oh, thank you!  I had completely forgotten that we said something
> > >> about this under maintainer scripts.
> > >>
> > >> That doesn't entirely cover this case (because systemd and udev may
> > >> not be "that package" in this sense), but it covers much of the
> > >> general case.
> > >
> > > Would you like me to reword/move the new snippet?
> >
> > Yes, thank you.  I will review the new version.
>
> Any specific suggestions? IE, where it should be, etc.

In the interest of speeding things up a bit, I've done some rewording
as suggested - moved to the exiting chapter, and use the systemd files
only as an example:

https://salsa.debian.org/bluca/policy/-/commit/5058bd2f8c742c3d8695e2c98ee3a597d431ffd7

Off-topic - any reasons MRs are disabled on the policy repo? It would
be much nicer and quicker to use the Gitlab review process I think,
like we do for other packages.

Kind regards,
Luca Boccassi

Bug#1033341: org-mode: CVE-2023-28617

[Salvatore Bonaccorso]

Hi David,

On Sun, Jun 04, 2023 at 08:34:18AM -0300, David Bremner wrote:
> Nicholas D Steeves  writes:
> 
> > fixed 1033341 org/mode/9.5.2+dfsh-5
> > fixed 1033341 org-mode/9.6.6+dfsg-1~exp1
> > thanks
> 
> Are you sure about that? It depends on emacs 28.2, which afaik has the
> vulnerable org-mode embedded. I guess it's a question of interpretation,
> but the vulnerability is still there after installing the package.

For src:emacs the respective bug is in #1033342.

But this is why I as well mentioned that for org-mode this tecnically
would need a per suite "unimportant" tracking in the security-tracker
(as the source still affected up to < 9.6.6+dfsg-1~exp1, but not the
resulting binary packages).

Looking at https://security-tracker.debian.org/tracker/CVE-2023-28617
I think we should be fine for bookworm already, correct?

(For bullseye the issue is no-dsa and could be fixed with respective
updates in a point release).

Regards,
Salvatore

Bug#1037088: libzstd build fails with profile "nodoc"

[Henry N.]

Source: libzstd
Version: 1.5.4+dfsg2-3
Severity: normal
Tags: ftbfs patch
Usertags: rebootstrap

Dear Maintainer,

build from source with profile "nodoc" fails.
Follow these steps:

# apt source libzstd
# apt build-dep libzstd
# cd libzstd-1.5.4+dfsg2
# dpkg-buildpackage -B -Pnodoc,nocheck -uc -us
...
make[1]: Entering directory '/tmp/libzstd/libzstd-1.5.4+dfsg2'
cp /tmp/libzstd/libzstd-1.5.4+dfsg2/debian/zstd/usr/share/man/man1/zstd.1 
/tmp/libzstd/libzstd-1.5.4+dfsg2/debian/zstd/usr/share/man/man1/zstdmt.1
cp: cannot stat 
'/tmp/libzstd/libzstd-1.5.4+dfsg2/debian/zstd/usr/share/man/man1/zstd.1':
No such file or directory
make[1]: *** [debian/rules:66: execute_after_dh_installman] Error 1
make[1]: Leaving directory '/tmp/libzstd/libzstd-1.5.4+dfsg2'
make: *** [debian/rules:34: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect
# Fix to build with profile "nodoc"
--- libzstd-1.5.4+dfsg2/debian/rules
+++ libzstd-1.5.4+dfsg2/debian/rules
@@ -62,10 +62,12 @@
 override_dh_makeshlibs:
dh_makeshlibs -plibzstd1 -V'libzstd1 (>= 1.5.2)' 
--add-udeb=libzstd1-udeb
 
+ifeq (,$(filter nodoc,$(DEB_BUILD_PROFILES)))
 execute_after_dh_installman:
cp $(mandir)/zstd.1 $(mandir)/zstdmt.1
$(HELP2MAN) --name='parallelized Zstandard compression, a la pigz' 
contrib/pzstd/pzstd \
| perl -pe 's/(\(de\)compression\s\(default:)(\d+)(\))/$$1 All$$3/g' 
>$(mandir)/pzstd.1
+endif
 
 build:
dh $@

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Andreas Beckmann]

On 04/06/2023 07.03, Otto Kekäläinen wrote:

What do you Andreas suggest we do now?


I'd suggest uploading it to experimental immediately (for NEW 
processing) and filing a pre-approval bug and let the release team 
decide what to do. This fix will probably be delayed to the first point 
release.

Should there be something about this issue in the release notes?


Andreas

Bug#1034387: update youtube-dl control file to reflect transitional package

[Andreas Tille]

Control: tags -1 pending

Am Sat, Jun 03, 2023 at 12:54:33PM -0400 schrieb Jesse Rhodes:
> The debian/control fields for youtube-dl still have a lot of leftover
> information from when it was a binary package, which should be cleaned
> up to reflect what the package actually does at present. Specifically,
> it does not need to Recommend any other packages past the dependency
> on yt-dlp, and it also does not need ~1200 lines of a list of websites
> supported by a tool which is no longer packaged.
> 
> For convenience, I have attached an updated control file, which
> includes the above request as well.

Applied in Git.

Thanks a lot for the fix
Andreas.

-- 
http://fam-tille.de

Bug#1033341: org-mode: CVE-2023-28617

[David Bremner]

Nicholas D Steeves  writes:

> fixed 1033341 org/mode/9.5.2+dfsh-5
> fixed 1033341 org-mode/9.6.6+dfsg-1~exp1
> thanks

Are you sure about that? It depends on emacs 28.2, which afaik has the
vulnerable org-mode embedded. I guess it's a question of interpretation,
but the vulnerability is still there after installing the package.

d


signature.asc
Description: PGP signature

Bug#1037087: chromium-l10n: The following packages have unmet dependencies: chromium-l10n : Depends: chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be installed

[Attila Hammer]

Package: chromium-l10n
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
sudo apt install chromium chromium-l10n command results me following error
message:
"Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies: chromium-l10n : Depends: 
chromium (< 112.0.5615.138-1~deb11u1.1~) but 114.0.5735.90-2~deb11u1 is to be 
installed
E: Unable to correct problems, you have held broken packages."


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Simple ran sudo apt install chromium chromium-l10n command.

   * What was the outcome of this action?
Previous Chromium and Chromium related language packages are right installed.

   * What outcome did you expect instead?

The quoted error message since yesterday.
I am not using pinned repositoryes, holded packages,
simple used standard Bullseye related repositories.


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


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium-l10n depends on:
pn  chromium  

chromium-l10n recommends no packages.

chromium-l10n suggests no packages.

Bug#975495: gping

[Tom Forbes]

Thank you, there is no rush! Please let me know if there is anything I can do 
to make this easier on my side.

On Sun, 4 Jun 2023, at 10:26 AM, matthias.geiger1...@tutanota.de wrote:
> Hi Tom,
> 
> I have prepared the packaging so far. I didn't have time yet to upload it 
> because I was busy with other debian work. I have some time next week so I 
> can update it to the latest version and then upload.
> 
> regards,
> 
> ---
> Matthias Geiger (werdahias)
> 
> *Attachments:*
>  • signature.asc

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Sun, 4 Jun 2023 at 11:54, Sean Whitton  wrote:
>
> Hello Luca,
>
> On Mon 08 May 2023 at 08:07PM +01, Luca Boccassi wrote:
>
> > The specific difference, for which I think an explicit call out is
> > needed, is because these config files are shipped by some packages but
> > are not used _by_ them, they are consumed by systemd (or udev, or
> > kmod, etc). Specifically, if package A ships a.service, and package B
> > overrides it, even if the maintainers of A and B agree, that's still
> > not good enough for me, as they are really affecting systemd, which is
> > the consumer and the provider of the interface they are using, and
> > ultimately the first port of call for bug reports. This is especially
> > true for udev.
> >
> > So in my latest revision of the patch, the general rule is as
> > requested by Russ and as you mention it, but there is an explicit,
> > stricter rule to cover this case, which is important to me. Policy
> > calls out core component software in many places, such as dpkg, and
> > systemd is already mentioned in other parts of the policy, so it did
> > not seem too far-fetched to me.
>
> I'm afraid I'm not convinced.  I'd second a patch where systemd is used
> as an example of the rule, as I suggested.

The existing policy is too weak for this case, ie: it's a "should". It
needs to be a "must" for these specific cases. Also the existing
policy only covers diverting from other packages, not from 'self' -
that needs to be forbidden too. There was one such example,
iptables-persistent, and it has been fixed in Bookworm, so to be clear
this is a zero-net-effect policy change, ie, no packages will suddenly
become rc-buggy, as the two existing instances have already been
fixed.

If you prefer, I can reword the general rule to be stricter, ie:
"packages must not use diversions where native mechanisms are
available" or so. Would this be better?

> Thank you for the additional commit regarding kmod.  It is good to have
> been made aware of issue, but let's discuss it in a separate bug after
> making this change -- the considerations might be quite different.
>
> On Tue 09 May 2023 at 12:31AM +01, Luca Boccassi wrote:
>
> > On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery  wrote:
> >
> >> Oh, thank you!  I had completely forgotten that we said something
> >> about this under maintainer scripts.
> >>
> >> That doesn't entirely cover this case (because systemd and udev may
> >> not be "that package" in this sense), but it covers much of the
> >> general case.
> >
> > Would you like me to reword/move the new snippet?
>
> Yes, thank you.  I will review the new version.

Any specific suggestions? IE, where it should be, etc.

Kind regards,
Luca Boccassi

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

[Luca Boccassi]

On Sun, 4 Jun 2023 at 12:02, Sean Whitton  wrote:
>
> Hello,
>
> On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
>
> > I've done an initial attempt to define the wording, although I'm sure
> > it will need quite a few changes. Attached as a patch, and also
> > available on Salsa:
> >
> > https://salsa.debian.org/bluca/policy/-/commits/tmpfiles
> >
> > Happy to move/reword/change/enhance as required.
>
> Thanks.
>
> > For now I've kept only a mention of the 'systemd-tmpfiles' virtual
> > package. As maintainers we would really prefer if the 'main'
> > implementation is pulled in whenever possible. When a minimal
> > installation is desired (ie, a minbase), it is possible to manually
> > specify the -standalone variant.
> >
> > This was a controversial point last year, see:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441
>
> Hmm.  I don't have personal experience with this sort of thing, but
> based on some of the examples in that bug, it seems like doing this
> could cause apt to change people's systems around in ways they strongly
> disprefer.  What you propose seems like it could cause unpleasant
> surprises.

Only due to bugs in said other packages, or if the wrong commands are
passed to apt/aptitude/etc.

> > We could even decide that no dependency is added at all by dh, and
> > instead the build tool needs to decide if it's building an image where
> > tmpfiles snippets need to be ran, and if so pull in the preferred
> > alternative.
>
> This is a highly inspecific response, but: aren't things expressed by
> dependencies generally less work for everyone than more special cases to
> be handled by each build tool?

Well, sure, but at some point it's either one or the other: set up the
dependencies so that the default case (which in debian is systemd)
works out of the box and the right thing happens magically, and people
who want to use non-default init systems (which are supported for the
purpose of "experimenting and exploring alternatives") will need to
fix their packages and provide the right instructions to apt, or no
dependency is set at all and bootstrapping/image building/etc tools
need to adapt and manually pull the right tools at the right time.

I'm in favour of the first one, to be clear, but I am open to the
second one for policy if that's what you prefer, and say nothing, in
the interest of moving forward with the change, and at least codify
how things should look like, leaving the low-level arrangements out of
it.

Kind regards,
Luca Boccassi

Bug#826425: deborphan: reports package as unused whereas it's used

[Martin-Éric Racine]

On Sun, 26 May 2019 13:11:51 + nodiscc  wrote:
> Confirming this bug on Debian Stretch, deborphan 1.7.28.8-0.3+b1
>
> $ deborphan --guess-all |grep cffi
> python3-cffi-backend:amd64
> python-cffi-backend:amd64
>
> $ aptitude why python3-cffi-backend:amd64
> i   python3-cryptography Depends  python3-cffi-backend-api-min (<= 9729)
> i A python3-cffi-backend Provides python3-cffi-backend-api-min
>
> $ aptitude why python-cffi-backend:amd64
> i   ansible Depends  python-cryptography
> i A python-cryptography Depends  python-cffi-backend-api-min (<= 9729)
> i A python-cffi-backend Provides python-cffi-backend-api-min

This bug is still present in Bookworm, which is frozen and about to be released.

Martin-Éric

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

[Sean Whitton]

Hello,

On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:

> I've done an initial attempt to define the wording, although I'm sure
> it will need quite a few changes. Attached as a patch, and also
> available on Salsa:
>
> https://salsa.debian.org/bluca/policy/-/commits/tmpfiles
>
> Happy to move/reword/change/enhance as required.

Thanks.

> For now I've kept only a mention of the 'systemd-tmpfiles' virtual
> package. As maintainers we would really prefer if the 'main'
> implementation is pulled in whenever possible. When a minimal
> installation is desired (ie, a minbase), it is possible to manually
> specify the -standalone variant.
>
> This was a controversial point last year, see:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441

Hmm.  I don't have personal experience with this sort of thing, but
based on some of the examples in that bug, it seems like doing this
could cause apt to change people's systems around in ways they strongly
disprefer.  What you propose seems like it could cause unpleasant
surprises.

> We could even decide that no dependency is added at all by dh, and
> instead the build tool needs to decide if it's building an image where
> tmpfiles snippets need to be ran, and if so pull in the preferred
> alternative.

This is a highly inspecific response, but: aren't things expressed by
dependencies generally less work for everyone than more special cases to
be handled by each build tool?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello Luca,

On Mon 08 May 2023 at 08:07PM +01, Luca Boccassi wrote:

> The specific difference, for which I think an explicit call out is
> needed, is because these config files are shipped by some packages but
> are not used _by_ them, they are consumed by systemd (or udev, or
> kmod, etc). Specifically, if package A ships a.service, and package B
> overrides it, even if the maintainers of A and B agree, that's still
> not good enough for me, as they are really affecting systemd, which is
> the consumer and the provider of the interface they are using, and
> ultimately the first port of call for bug reports. This is especially
> true for udev.
>
> So in my latest revision of the patch, the general rule is as
> requested by Russ and as you mention it, but there is an explicit,
> stricter rule to cover this case, which is important to me. Policy
> calls out core component software in many places, such as dpkg, and
> systemd is already mentioned in other parts of the policy, so it did
> not seem too far-fetched to me.

I'm afraid I'm not convinced.  I'd second a patch where systemd is used
as an example of the rule, as I suggested.

Thank you for the additional commit regarding kmod.  It is good to have
been made aware of issue, but let's discuss it in a separate bug after
making this change -- the considerations might be quite different.

On Tue 09 May 2023 at 12:31AM +01, Luca Boccassi wrote:

> On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery  wrote:
>
>> Oh, thank you!  I had completely forgotten that we said something
>> about this under maintainer scripts.
>>
>> That doesn't entirely cover this case (because systemd and udev may
>> not be "that package" in this sense), but it covers much of the
>> general case.
>
> Would you like me to reword/move the new snippet?

Yes, thank you.  I will review the new version.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Mon 08 May 2023 at 12:52PM -07, Russ Allbery wrote:

> Sean Whitton  writes:
>> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:
>
>>> In other words, dpkg-divert is primarily for local administrators,
>>> non-Policy-compliant local packages that are doing unusual things, and
>>> the occasional rare problem that requires special coordination between
>>> packages, not something that Debian packages should be doing to other
>>> packages without explicit coordination.
>
>>> The rule about systemd and udev files doesn't entirely fall out of that
>>> statement,
>
>> Hmm, could you explain why?
>
> It didn't fall out of the above statement because the systemd unit file
> may not be shipped with the systemd package, but by some other random
> package, so you could have an explicit coordination with the package that
> provides the unit file but still be doing something that the systemd
> maintainers don't want to support.
>
> I think it does fall out of the somewhat squishier statement that you
> shouldn't use diversions when there's some other available mechanism to
> accomplish the same goal.

Thanks, I see.  I agree that we should have the latter statement.

>> I don't mean to dismiss the significant impact on the systemd
>> maintainers that's being claimed, but specifically calling out udev and
>> systemd configuration files seems strangely specific, for Policy, to me.
>
> I think they're a special case of the general rule that if there's some
> mechanism other than diversions to do what you want, you should use it
> instead, but it's such a common special case that we should call it out
> explicitly, particularly since a lot of people right now don't seem to
> know about masking or drop-ins.  So in other words, I think I basically
> agree with this, but I think it's worth spending some words on systemd and
> udev, more as a communication strategy than anything else.

Okay cool, I'm glad you're happy with my "For example ..." thing.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[GCS]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> is image sensitive since some images cause GetImageDepth() to perform
> more OpenMP loops.
 Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?

> My own testing is under Ubuntu 20.04 using GCC 10.
 Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.

Regards,
Laszlo/GCS

Bug#955523: polari: Join button is grayed out. No rooms shown.

[cacatoès]

Package: polari
Version: 43.0-1
Followup-For: Bug #955523
X-Debbugs-Cc: cacat...@tuxfamily.org

Dear Maintainers,

I'm giving polari a try, so on a fresh install, I was unable to connect to any
server.

When selecting a server, the rotating wheel icon shows it tries to connect,
then in abandons, leaving a lock icon about server requiring a password (which
should not be the case).

So actually the software is not usable.

Have a good day,


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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 polari depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-secret-1  0.20.5-3
ii  gir1.2-soup-2.4  2.74.3-1
ii  gir1.2-telepathyglib-0.120.24.2-0.1
ii  gir1.2-telepathylogger-0.2   0.8.2-4
ii  gjs  1.74.2-1
ii  libc62.36-9
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libglib2.0-0 2.74.6-2
ii  libglib2.0-bin   2.74.6-2
ii  libtelepathy-glib0   0.24.2-0.1
ii  telepathy-idle   0.2.2-1
ii  telepathy-logger 0.8.2-4
ii  telepathy-mission-control-5  1:5.16.5-2

polari recommends no packages.

polari suggests no packages.

-- no debconf information

Bug#975495: gping

[matthias . geiger1024]

Hi Tom,

I have prepared the packaging so far. I didn't have time yet to upload it 
because I was busy with other debian work. I have some time next week so I can 
update it to the latest version and then upload. 

regards,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1035535: Debian 11 -> 12: manual "apt install" needed to update some packages (vkd3d, appindicator, wx)

[Paul Gevers]

reassign

Hi,

First of all, thanks for reporting issues you experience and sorry it 
took a while to reply.


On 05-05-2023 04:27, kolafl...@kolahilft.de wrote:

But "apt dist-upgrade" didn't upgrade some packages.


Did you follow the upgrade procedure as outlined in the release notes, 
or is $(apt dist-upgrade) all you ran? It has happened before that apt 
can't figure out an upgrade path in one go, but when ran twice it does 
(the bullseye release notes had something on a particular known problem 
IIRC).


So I had to do it 
manually. Should it be that way?


Ideally not, no.


   apt install \
     vkd3d-compiler/bookworm \
     libvkd3d-dev/bookworm \
     libvkd3d-dev:i386/bookworm \
     libappindicator1/bookworm

By this the vkd3d packages where upgraded to bookworm and 
libappindicator1 was replaced with libayatana-appindicator1 and 
libayatana-indicator7.


Hmm.


I also had wx3.0-headers installed.
And I had to install the new +version manually.

   apt install wx3.2-headers


Maybe related:
My "apt dist-upgrade" from Debian 11 to 12 ended with an error.
See here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#32


Was this before or after the issue you pointed out above? I assume apt 
already told you before this error it wouldn't upgrade everything, 
right? Did you retry running $(apt dist-upgrade) again after this error?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Hi,

On Fri, 2 Jun 2023, at 20:42, Gioele Barabucci wrote:
> On 02/06/23 20:25, Andrej Shadura wrote:
>>> This (current?) limitation should be mentioned in the short and long
>>> descriptions.
>> 
>> It does in fact work with anything, as long as has a PKCS #11 provider.

> The README on GitHub says:

>  > Momentálne podporujeme na Slovensku bežne používané karty
>  > a ich ovládače:
>  >
>  > * občiansky preukaz (eID klient)
>  > * I.CA SecureStore
>  > * MONET+ ProID+Q
>  > * Gemalto IDPrime 940
>  >
>  > Doplniť ďalšie je pomerne ľahké pokiaľ používajú PKCS#11.

> I read this as "Support for other kinds of eIDs is _possible and easy_ 
> as long as they support PKCS#11, but _not automatic_". Am I reading this 
> wrong?

Well, I suspect they want to be on the safe side, but OTOH I have not verified 
it. Given that some of the Autogram’s dependencies are still not in Debian, I 
reckon this can either be solved upstream by the time the package is ready, or 
I can add a disclaimer to the package description.

-- 
Cheers,
  Andrej

Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated

[Georg Gast]

Package: dropbear-initramfs
Version: 2022.83-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
One of my systems did not start and landed in rescue shell. I wanted to install
dropbear-initramfs and enable ssh access for rescue target. I installed it and
configured it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Updated initramfs and created symlinks
/etc/dropbear/dropbear_ecdsa_host_key ->
/etc/dropbear/initramfs/dropbear_ecdsa_host_key
/etc/dropbear/dropbear_ed25519_host_key ->
/etc/dropbear/initramfs/dropbear_ed25519_host_key
/etc/dropbear/dropbear_rsa_host_key ->
/etc/dropbear/initramfs/dropbear_rsa_host_key

DROPBEAR_OPTIONS="-FEsjk"

But dropbear did not start as it was complaining about the missing dss host
key. I generated a new dss key and added the symlink

dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key
/etc/dropbear/dropbear_dss_host_key ->
/etc/dropbear/initramfs/dropbear_dss_host_key

Updated initramfs, reboot into rescue

   * What was the outcome of this action?
dropbear did NOT start.

If i delete /etc/dropbear/initramfs/dropbear_dss_host_key and generate a new
one
dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key
in the resuce shell dropbear starts.


Info:
-

georg@nas-dsm:~$ uname -a
Linux nas-dsm 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)
x86_64 GNU/Linux
georg@nas-dsm:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
georg@nas-dsm:~$ apt-cache policy dropbear-initramfs
dropbear-initramfs:
  Installiert:   2022.83-1
  Installationskandidat: 2022.83-1
  Versionstabelle:
 *** 2022.83-1 500
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
georg@nas-dsm:~$ tree /etc/dropbear/
/etc/dropbear/
├── dropbear_dss_host_key -> initramfs/dropbear_dss_host_key
├── dropbear_ecdsa_host_key -> initramfs/dropbear_ecdsa_host_key
├── dropbear_ed25519_host_key -> initramfs/dropbear_ed25519_host_key
├── dropbear_rsa_host_key -> initramfs/dropbear_rsa_host_key
└── initramfs
├── authorized_keys
├── dropbear.conf
├── dropbear_dss_host_key
├── dropbear_ecdsa_host_key
├── dropbear_ed25519_host_key
└── dropbear_rsa_host_key

2 directories, 10 files





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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
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 dropbear-initramfs depends on:
ii  busybox-static [busybox]  1:1.35.0-4+b3
pn  dropbear-bin  
ii  initramfs-tools   0.142
ii  udev  252.6-1

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.6.1-4~deb12u1

dropbear-initramfs suggests no packages.

Bug#1037085: RFP: strawberry-graphql -- GraphQL library for Python that leverages type annotations

[Carsten Schoenert]

Package: wnpp
Severity: wishlist

* Package name: strawberry-graphql
  Version : 0.180.5
  Upstream Contact: Patrick Arminio 
* URL : https://github.com/strawberry-graphql/strawberry
* License : Expat
  Programming Lang: Python
  Description : GraphQL library for Python that leverages type annotations

Strawberry is a new GraphQL library for Python 3, inspired by
dataclasses. One of its goals is to provide a great developer experience
for both GraphQL beginners and advanced users.

Strawberry is a code-first GraphQL server library that uses Python type
annotations to define GraphQL types. This allows you to focus more on how
you can integrate one ore more DBs into your workflow and less on the
idiosyncrasies of GraphQL itself.

This library is a upcomming build and package dependency for NetBox (see
ITP https://bugs.debian.org/1017079).

Bug#824521: Bug#1034771: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[Vagrant Cascadian]

Control: block 1034771 by 824521

On 2023-04-24, Daniel Leidert wrote:
> 2023-04-24 03:07:41 ERROR build/debian-cd: missing metadata file 
> ./tmp/mirror/dists/bullseye/main/dep11/Components-amd64.yml.gz at 
> ./tmp/debian-cd/tools/generate_firmware_patterns line 172.
> 2023-04-24 03:07:41 ERROR build/debian-cd: generate_firmware_patterns failed: 
> 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257.

This is because reprepro does not generate or support these
dep11/Components-*.ym.gz files...

   https://bugs.debian.org/824521

It might be possible to work around in similar to how debian-installer
images are download in simple_cdd/tools/mirror_download.py

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1036740: [Pkg-netatalk-devel] Bug#1036740: closed by Markus Koschany (Re: Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault with valid metadata)

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2023-06-04 07:39:12)
> Hi Daniel,
> 
> On Sat, Jun 03, 2023 at 02:56:00PM -0700, Daniel Markstedt wrote:
> > > -- Forwarded message --
> > > From: Markus Koschany 
> > > To: Daniel Markstedt , 1036740-d...@bugs.debian.org
> > > Cc: debian-...@lists.debian.org
> > > Bcc:
> > > Date: Thu, 01 Jun 2023 19:54:55 +0200
> > > Subject: Re: Bug#1036740: Fix for CVE-2022-23123 causes afpd segfault 
> > > with valid metadata
> > > Version:  3.1.12~ds-3+deb10u2
> > >
> > > Thanks for your report and the detailed replies. I could reproduce the 
> > > problem
> > > and identify a wrongly applied commit in libatalk/adouble/ad_open.c. After
> > > applying a new patch to fix it, the AppleDouble v2 format seems to work as
> > > intended again. I'm going to close this bug report now.
> > >
> > > Best,
> > >
> > > Markus
> > >
> > 
> > Thank you Markus for narrowing down the problem and fixing it!
> > I can confirm that appledouble=v2 works in my environment now too.
> > 
> > So this covers the outstanding CVEs for oldstable now;
> > are you already preparing to port the same patchset to stable as well?
> > 
> > I can file another bug report if it helps.
> 
> No other reports needed, since all were reported. For the bookworm
> release they would be fixed, for the current stable (bullseye) we
> explicitly asked the maintainer trough
> https://bugs.debian.org/1025011#15 . So we are waiting for the
> netatalk maintainers to propose an update here for bullseye-security.

@Salvatore: In addition to being upstream developer, Daniel has also
joined the Debian packaging team.

@Daniel: Debian issue tracker - debbugs - can be confusing from an
upstream POV, due to it being distro-centric: Some issues are not about
upstream code but "meta" about distro organization - e.g. bug#1025011
which is not about netatalk but about *attention* for netatalk and
therefore open despite netatalk itself has no bugs. Also, issues tied to
upstream projects is tracked across multiple Debian releases, so can be
both fixed and unfixed depending on release scope.

What is double confusing here is that no bugreport exists in Debian for
tracking CVE-2022-23123 - bug#1036740 filed by you is about collateral
damage in fixing that CVE for oldstable, and bug#1025011 is about
meta-discussion only indirectly involving that same CVE.

All in all: Yes, please file a bugreport about CVE-2022-23123 - and then
tag it as closed with package release 3.1.15~ds-1, which makes that
bugreport "fixed" for the scope of Debian testing and unstable, but
unfixed for the scope of Debian stabel.


Hope that helps.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Jay]

Package: release-notes
X-Debbugs-Cc: jlsan...@protonmail.com
Severity: important

Starting non-GNOME wayland sessions through GDM leads to a user's PATH
being set to
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
instead of /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
(from /etc/profile).

Example: Starting sway or plasma-workspace-wayland through gdm and
trying to launch
lutris or gnome-chess only to find out that they won't start even
though they are
installed. It can take some time for a user to find out that the PATH
environment
variable is different.

This is a regression in bookworm and can surprise users upgrading from bullseye.

Possible workarounds are: Using a different display manager such as
sddm or starting
the wayland session through tty.

I first discovered this bug after installing lutris a few months
ago[0] and filed
a few bug reports[1][2]. As bookworm is about to be released, I thought it may
be worthwhile to document this unexpected behavior in its release notes.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942131
2: https://gitlab.gnome.org/GNOME/gdm/-/issues/846