Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Olly Betts]

On Wed, Jun 07, 2023 at 09:27:13PM +0100, Olly Betts wrote:
> I think it'd be good to check with upstream if the "experimental" marker
> is out-dated, or still accurate, and if it's still accurate what the
> downsides of this are.  I've opened a ticket:
> 
> https://github.com/wxWidgets/wxWidgets/issues/23619

Upstream confirms it's not experimental any more and will update
the docs.  They did note that not only does it not work under Wayland,
but also that it may not be possible to make it work there.

Cheers,
Olly

Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine

[Didier 'OdyX' Raboud]

Le mercredi, 7 juin 2023, 10.10:50 h CEST Bastien ROUCARIES a écrit :
> Le mer. 7 juin 2023 à 08:00, Didier 'OdyX' Raboud  a
> 
> écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Didier 'OdyX' Raboud 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> > 
> >   Package name: typesense
> >   Version : 0.24.1
> >   Upstream Contact: TypeSense team 
> >   URL : https://typesense.org
> >   License : GPL-3
> >   Programming Lang: C++
> > 
> > Typo-tolerant search engine optimized for instant search-as-you-type
> > experiences and developer productivity. Push data to it and then allow
> > users to search through this data via a search UI in a site or app.
> > 
> > I plan to package this under https://salsa.debian.org/debian/typesense.
> > If there's a matching packaging team, more than happy to move there!
> 
> It is useful for dyslexic people. Maybe accessibilty related team ?

It's more of a web-oriented / mobile search engine than an accessiblity 
facilitator.

That said, I've sadly noted that it build-depends on several more un-packaged 
software, namely Apache brpc (which typesense forks), braft (same), lru-cache 
(https://github.com/goldsborough/lru-cache/, never released), libfor (https://
github.com/cruppstahl/libfor, never released, little-endian only).

That'll be (much) more work than I expected, and I'll ponder on how to move 
forward here.

Best,
OdyX

Bug#1001750: RFA: fwlogwatch -- Taking over maintenance of this project

[Leandro Cunha]

Hi,

If you open RFA or ITA for this package and not wnpp, your request or
intention to adopt will not appear in searches. Still interested? I'm
thinking of doing some QA work for the package that should come out
after bookworm is released.

[1] 
https://wnpp.debian.net/?type%5B%5D=ITA%5B%5D=ITP%5B%5D=O%5B%5D=RFA%5B%5D=RFH%5B%5D=RFP=fwlogwatch=%5B%5D=yes%5B%5D=no%5B%5D=dust%5B%5D=type%5B%5D=description%5B%5D=installs%5B%5D=owner=installs%2Fdesc

-- 
Cheers,
Leandro Cunha

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

[Otto Kekäläinen]

Hi!

Note that upstream released 10.11.4 today. Import preparation in
progress at 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50.
I plan to upload this to experimental tomorrow and eventually into
bookworm-pu if the release team approves.

- Otto

Bug#1030320: tango: New version 9.4.1 available

[Santiago Ruano Rincón]

Control: tags -1 + fixed-in-experimental

On Thu, 02 Feb 2023 21:29:12 +0100 Thomas Braun  
wrote:
> Package: tango
> Severity: normal
> 
> We would really like to have 9.4.1 [0] in upcoming debian bookworm
> instead of the old 9.3.x.
> 
> I've already tested if our tests pass on debian testing on amd64, yes
> they do [1].
> 
> The changes compared to 9.3.x are listed at [2]. Packaging wise the
> biggest change is that we now only support cmake.
> 
> As you are using the TangoSourceDistribution we have some info posted
> at [3] wrt to the cmake options.
> 
> Thanks,
> Thomas
> 
> [0]: https://gitlab.com/tango-controls/cppTango/-/releases/9.4.1
> [1]: https://gitlab.com/tango-controls/cppTango/-/merge_requests/1044
> [2]:
> https://gitlab.com/tango-controls/cppTango/-/blob/main/RELEASE_NOTES.md
> [3]:
> https://gitlab.com/tango-controls/TangoSourceDistribution/-/tree/main/assets#installation

9.4.2-rc2 is now available in experimental.

Cheers,

 -- S


signature.asc
Description: PGP signature

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

[Luca Boccassi]

On Wed, 7 Jun 2023 at 11:46, Luca Boccassi  wrote:
>
> On Wed, 7 Jun 2023 at 11:29, Simon McVittie  wrote:
> >
> > On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> > > Luca Boccassi  writes:
> > > > +Packages might need additional files or directories to implement their
> > > > +functionality. Directories that are located under ``/var/`` or
> > > > +``/etc/``, and files that are located under ``/var/``, must not be
> > > > +created manually via maintainer scripts, but instead be declaratively
> > > > +defined via the `tmpfiles.d
> > > > +`_
> > > > +interface.
> > >
> > > This is an oddly specific list of directories and not at all the
> > > directories that I would have expected to be handled by tmpfiles.d.
> >
> > Sorry, in my previous reading of this bug I had been concentrating on
> > the mechanics of how to make tmpfiles.d(5) something that maintainers can
> > rely on if it's convenient/helpful, and I'd missed that Luca is asking
> > for its use to be mandatory in some cases.
> >
> > I would personally be inclined to concentrate on making tmpfiles.d(5)
> > something that we can rely on and encourage the use of where appropriate,
> > even on non-systemd systems, so that (upstream and downstream) maintainers
> > can move towards it of their own accord because it's more convenient
> > than other options, and put aside the question of making it generally a
> > "should" or "must" for the moment.
> >
> > I believe (please correct me if I'm wrong) that Luca's intention here
> > is that this is drawing a line between:
> >
> > - the static files of the OS: /usr and the /usr-like top-level directories
> >   (the ones that get merged by the /usr merge), which should be statically
> >   shipped in packages and managed by dpkg (or on "immutable" systems
> >   that use image-based/tree-based upgrades, maybe by ostree or casync
> >   or similar, from an tree originally constructed from dpkg packages)
> >
> > - this specific system's persistent state: /var and parts of /etc
> >
> > with the intention of eventually enabling functionality like being
> > able to do a "factory reset" to the equivalent of a freshly installed
> > system by deleting (most of) /etc and /var, rebooting, and letting the
> > OS re-create them from a template below /usr; or doing the equivalent
> > for individual packages by deleting only their part of /etc and /var.
> >
> > /etc is somewhere between static files and state, because traditionally
> > it has been a mixture of files that the sysadmin or installer must provide
> > (like /etc/passwd); configuration files that are shipped by a package and
> > can be edited by the sysadmin (like /etc/systemd/logind.conf); and
> > integration glue that links up one package with another, can in principle
> > be edited by the sysadmin, but in practice is rarely edited
> > (like /etc/profile.d/flatpak.sh).
> >
> > Various upstream projects including systemd have been trying to reduce
> > the extent to which /etc and /var are included in the data.tar.* of a .deb
> > or other packaging systems' equivalents, by moving the integration glue
> > to a /usr-like directory (/lib/udev/rules.d, /usr/share/dbus-1/system.d),
> > reserving the corresponding /etc directory for sysadmin configuration
> > (/etc/udev/rules.d, /etc/dbus-1/system.d), and providing a way for the
> > sysadmin to "mask" any integration files they want the system to ignore.
> >
> > If we disregard conffiles and configuration files in /etc for the
> > moment, there are basically three ways for a package to get a file onto
> > the running system:
> >
> > - ship it in the data.tar.* of a .deb
> > - create it from a maintainer script and also during boot
> > - maybe via tmpfiles.d(5)
> > - or maybe open-coded
> > - have the package create it at runtime, on-demand
> > - this clearly doesn't work if the package's code runs unprivileged
> >   and relies on root having created a directory for it already
> >
> > For /usr and the /usr-like directories, shipping files in the .deb is by
> > far the most common, although a few packages need to create files here
> > via maintainer scripts or triggers (for example
> > /usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache which is a summary
> > of files created by multiple packages, and is updated whenever those
> > packages are added, removed or changed).
> >
> > For /run, /tmp and /var/tmp, I think there's consensus that shipping files
> > in those directories in the .deb is a bug, because at the next reboot,
> > the file will be deleted, leaving the files that dpkg thinks it's managing
> > out of sync with the files that actually exist. At the moment, these are
> > variously created by maintainer scripts, systemd units/init scripts, or the
> > daemons themselves, with some duplication, and no good way to get an
> > overview of which packages "own" which locations: dpkg doesn't know anything
> > about them, and 

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Chris Lamb]

No, please go ahead and do both: my availability is spotty for the next 18 
hours. :) 

(on mobile) 


Utkarsh Gupta wrote:

> Hi Chris,
>
> On Wed, Jun 7, 2023 at 9:01 PM Chris Lamb  wrote:
>> I see your 2.5.5-3+deb10u6 update on the debian/buster branch which
>> fixes the broken +deb10u5 upload, but I don't see it in the archive
>> yet.
>>
>> Although you mentioned you were going to wait a bit more, I'm just
>> 100%-checking you aren't waiting on anything from me to upload that?
>
> Oh yeah, I wanted to sneak in some fixes and enable the tests and fix
> the failing ones with the last upload. So I'll take care of the upload
> and the announcement unless you prefer doing that since you did the
> original upload?
>
>
>

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1037217: coreutils: od: -S considers printable, not graphic, characters

[наб]

Package: coreutils
Version: 8.32-4+b1
Version: 9.1-1
Severity: normal

Dear Maintainer,

isgraph(3):
   isgraph()
  checks for any printable character except space.
od(1):
   -S BYTES, --strings[=BYTES]
  output strings of at least BYTES graphic chars; 3 is implied when 
BYTES is not specified
$ printf 'a b\0' | od -S3
000 a b

?

наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 7 Jun 2023 at 20:17, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Wed, 7 Jun 2023 at 14:15, Leonardo Held  wrote:
> >
> >
> > Hello again Lisandro,
> >
> > On 06.06.23 11:40 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > And at that point is where I'll personally say "no". I do not have
> > > enough free time to handle this, and that is in fact the reason I am
> > > maintaining Qt 6 mostly as team member (I am not listed in Uploaders
> > > on purpose).
> > That's completely understandable.
> > > This is specially true if your company uses Debian as a base for the
> > > containers shipped in your products (Leonardo: hint, hint).
> > I'll work a bit on this this week on our private Debian feed and then
> > start helping your team out, hopefully.
>
> Wonderful! I'll be delighted to help as I can!

Extra tip: you can take a look at the Qt 5 gles/* branches in salsa.
You don't need to rebuild **everything**, just the pieces required for
QtGui.

https://salsa.debian.org/qt-kde-team/qt/qtbase/-/tree/gles/master?ref_type=heads

Also feel free to email me.

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 7 Jun 2023 at 14:15, Leonardo Held  wrote:
>
>
> Hello again Lisandro,
>
> On 06.06.23 11:40 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > And at that point is where I'll personally say "no". I do not have
> > enough free time to handle this, and that is in fact the reason I am
> > maintaining Qt 6 mostly as team member (I am not listed in Uploaders
> > on purpose).
> That's completely understandable.
> > This is specially true if your company uses Debian as a base for the
> > containers shipped in your products (Leonardo: hint, hint).
> I'll work a bit on this this week on our private Debian feed and then
> start helping your team out, hopefully.

Wonderful! I'll be delighted to help as I can!

> Should I keep in touch with your or Patrick Franz (listed as the
> uploader)? Do you guys have an IRC I can jump in to?

Yes, jump in #debian-qt-kde on OFTC. I currently have my bouncer down,
but I hope to have it back soon.


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

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

[Bill Allombert]

On Tue, Jun 06, 2023 at 11:34:17PM +0100, Luca Boccassi wrote:
> On Wed, 7 Jun 2023 00:01:42 +0200 Bill Allombert 
> > This is beside the point. Your problematic statement was
> > "The whole project is moving toward git and Salsa ".
> > This is not conducive of productive interaction.
> 
> It was not problematic at all, unless you are deliberately trying to
> see problems where there are none. It was an hyperbole: a huge number
> of packages and teams are using effectively Salsa workflows for
> collaboration today. Are you denying this?

This is not important. What matters is that this statement could be read as
excluding from the project or belittling developers that are not moving toward
Salsa.  This is inappropriate. Even assuming it was not your intent, such
statements creates friction in the project by making people uncomfortable
without any benefit, and so should be avoided.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1036821: NTP does not keep accurate time on bookworm

[Richard Laager]

I've made a suggestion upstream of how we could do better here by making 
this either a fatal error or at least a warning. If it was a fatal error 
with a good error message, you would have figured it out immediately. 
Let's see what people think of that.


--
Richard

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

[Holger Levsen]

On Wed, Jun 07, 2023 at 08:19:08AM -0700, Russ Allbery wrote:
> I would like to add more documentation like this around systemd-related
> things to Policy because systemd is complicated and has a lot of options,
> so people who aren't deeply familiar with it will easily miss best
> practices in its reams of very good but overwhelming documentation, and
> Debian should be opinionated about steering people towards best practices
> for our primary init system, just as we were very opinionated about how to
> write init scripts for sysvinit.
[...]
> I definitely agree that Policy should have a whole section devoted to
> systemd and its configuration files, but I don't want to try to boil the
> ocean in one bug.  But yes, we should be working towards that, IMO.

yes! (to everything in said email.) thank you.


-- 
cheers,
Holger

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

Only change is constant.


signature.asc
Description: PGP signature

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Utkarsh Gupta]

Hi Bernhard, Kees,

On Wed, Jun 7, 2023 at 6:58 PM Schmidt, Bernhard
 wrote:
> > I've prepared a fix for the regression and uploaded the binaries at:
> > https://people.debian.org/~utkarsh/lts/ruby2.5/
> >
> > Can you please give these a try and see if that fixes the regression
> > you're seeing?
>
> Looking good!

Many thanks for testing, too!

I've actually managed to prepare a final update that I'm ready to
upload - this has quite some fixes plus 2 new CVE fixes. Would you
please test the new resulting binaries and make sure they look sane
enough? :)

The binaries can be found at
https://people.debian.org/~utkarsh/lts/ruby2.5/. Many thanks!


- u

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Utkarsh Gupta]

Hi Chris,

On Wed, Jun 7, 2023 at 9:01 PM Chris Lamb  wrote:
> I see your 2.5.5-3+deb10u6 update on the debian/buster branch which
> fixes the broken +deb10u5 upload, but I don't see it in the archive
> yet.
>
> Although you mentioned you were going to wait a bit more, I'm just
> 100%-checking you aren't waiting on anything from me to upload that?

Oh yeah, I wanted to sneak in some fixes and enable the tests and fix
the failing ones with the last upload. So I'll take care of the upload
and the announcement unless you prefer doing that since you did the
original upload?


- u

Bug#1037185: bpftrace: Fix FTBFS on armhf

[Vincent Bernat]

On 2023-06-07 12:07, Danilo Egea Gondolfo wrote:


* What led up to the situation?

The build is failing on armhf because cmake is not detecting the 
architecture correctly as we cross compile on arm64.


Also, after fixing the cmake part, the build will fail in src/triggers.h 
due to the attribute used when it build on arm 32-bit. It might be a bug 
on gcc but I'm not sure (clang++ doesn't throw the same error).


Shouldn't all this be fixed upstream?

Bug#1037216: mkdocstrings-python-handlers: please make the build reproducible

[Chris Lamb]

Source: mkdocstrings-python-handlers
Version: 0.8.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
mkdocstrings-python-handlers was causing other packages to nod build
reproducibly. Here is python-mkdocs:


 -  writable
property
 +  writable


This is because the "griffe" Python module populates a Python set()
object with strings such as "property" and "writable", which the
labels.html template (in this package) then naïvely iterates over.

A patch is attached that simply sorts these when rendering using
Jinja's "|sort" filter.

  [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git 
a/src/mkdocstrings_handlers/python/templates/material/_base/labels.html 
b/src/mkdocstrings_handlers/python/templates/material/_base/labels.html
index 4f2f72d..0c84067 100644
--- a/src/mkdocstrings_handlers/python/templates/material/_base/labels.html
+++ b/src/mkdocstrings_handlers/python/templates/material/_base/labels.html
@@ -1,7 +1,7 @@
 {% if labels %}
   {{ log.debug("Rendering labels") }}
   
-{% for label in labels %}
+{% for label in labels|sort %}
   {{ label 
}}
 {% endfor %}
   

Bug#1037215: [ifupdown] not possible to force -ddd option on wpasupplicant (debug option)

[Jean-Marc LACROIX]

Source: ifupdown
Version:
Severity: n0.8.36 ormal

Dear Debian team,

I   am   using  ifupdown   package on   Debian   11.7   with  one wifi
interface(if-sta0)   in STA mode  with   sysvinit (no systemd).  As  a
result,  of course,  i  am also   using supplicant daemon  supplied by
wpasupplicant Debian package.

In order  to search complex issue  when usging multiple  AP targets, i
would to use debug feature as defined in wpasupplicant documentation.


~$ zgrep debug   /usr/share/doc/wpasupplicant/README.modes.gz

In order to debug connection, association and authentication problems,
increase the verbosity level of wpa_supplicant to log debug output by
adding the wpa-debug-level option to /etc/network/interfaces like in
wpa-debug-level 3

My   current   configuration  for   this   interface  (if-sta0)  (file
/etc/network/interfaces) is ...

.
# interface 2.1/17 (if-sta0) (physical):02:00.0 Network controller: 
Intel Corporation Wireless 7265 (rev 59), WLAN interface on motherboard 
in STA mode

allow-autoif-sta0
iface if-sta0  inet dhcp
  wpa-group   CCMP TKIP
  wpa-pairwiseCCMP TKIP
  wpa-proto   WPA RSN
  wpa-key-mgmtWPA-PSK
  wpa-auth-algOPEN
  wpa-debug-level 3# either 1,2 or 3
  wpa-driver  wext,nl80211
  wpa-iface   if-sta0
  wpa-ap-scan 1
  wpa-scan-ssid   1
  wpa-logfile /var/log/wpa_supplicant.log
  wpa-psk "test-debian"
  wpa-ssid"hn-tplink-re450-275-2.4Ghz"
  wpa-ctrl_interface /var/run/wpa_supplicant
  wpa-conf/etc/wpa_supplicant/wpa_supplicant.if-sta0.conf
.

After following command 

sudo ifdown if-sta0;sleep 1;sudo ifup -v if-sta0

The  interface shut  down,  then wpasupplicant  is correctly launched,
then  association is done,  and final  dhcp is  also  done, so that no
error occurs, perfect (!)

Debian ifup/ifdown launch daemon with following parameters...

ansible@hn-asusgl752-400:~$ ps auxww |grep supplic
ansible  15775  0.0  0.0   5500   892 pts/1S+   14:25   0:00 tail -f 
/var/log/wpa_supplicant.log
root 20123  0.1  0.0  11776  3524 ?Ss   22:23   0:00 
/sbin/wpa_supplicant -B -P /run/wpa_supplicant.if-sta0.pid -i if-sta0 -D 
wext,nl80211 -f /var/log/wpa_supplicant.log -c 
/etc/wpa_supplicant/wpa_supplicant.if-sta0.conf
ansible  20326  0.0  0.0   6228  1048 pts/18   S+   22:23   0:00 grep 
supplic



As you can see, it seems that option "-ddd" is  not computed by Debian
infrastructure   when reading  "wpa-debug-level   3"  into
/etc/network/interfaces,  it is therefore  not  possible to  debug this
daemon.

Thanks to give me one method to force debug daemon mode.

Please give me a method to force debug daemon mode. Please note that I
tried the following line in the  interface definition, but without any
hit ?

 pre-up /usr/sbin/wpa_supplicant -B -D nl80211,wext -i if-sta0 -c 
/etc/wpa_supplicant/wpa_supplicant.if-sta0.conf -f 
/var/log/wpa_supplicant/wpa_supplicant.log -t -dd


Best regards
--
  -- Jean-Marc LACROIX  (06 82 29 98 66) --
-- mailto : jeanmarc.lacr...@free.fr   --

Bug#1037214: bullseye-pu: package appstream-glib/0.7.18-1+deb11u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bullseye moreinfo
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: appstream-g...@packages.debian.org
Control: affects -1 + src:appstream-glib

[ Reason ]
Recent server-side changes on flathub.org mean that it started publishing
Appstream metadata that appstream-glib doesn't understand ( and 
markup), and appstream-glib is intolerant of non-recognised markup in
this context, causing `flatpak search` to regress in bullseye. (#1037206)

[ Impact ]
If not fixed, `flatpak search` will show an error message for Flathub
users and not offer any search results, unless the user upgrades to
the version from bullseye-backports (which is unaffected by appstream-glib
bugs because it has switched to using libappstream, a different codebase).

[ Tests ]
I confirmed that this fixes the reproducer from #1037206.

bullseye's gnome-software, which uses appstream-glib, is still able
to display search results from both Debian (I searched for amoebax)
and Flathub (I searched for steamlink and organicmaps). The package
description for organicmaps, which includes  and therefore triggered
this bug, is not displayed correctly in gnome-software (text inside 
doesn't appear), but that isn't a regression: the same behaviour is seen
without this change.

The patches also add a regression test, which is run at build-time
and passes.

[ Risks ]
These are straightforward backports from the newer upstream release in
bookworm, and have also been proposed for an Ubuntu 22.04 stable update.
The original change introduced a test failure, for which the subsequent
upstream fix is also included.

I've marked this as moreinfo because it should ideally be reviewed by the
package's maintainer (not me).

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are part of solving #1037206.

Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Olly Betts]

Control: reassign -1 source:wxwidgets3.2

On Wed, Jun 07, 2023 at 09:49:19AM -0400, Scott Talbert wrote:
> I think it would be okay to enable xtest support even though it doesn't work
> under Wayland.

I think it'd be good to check with upstream if the "experimental" marker
is out-dated, or still accurate, and if it's still accurate what the
downsides of this are.  I've opened a ticket:

https://github.com/wxWidgets/wxWidgets/issues/23619

> However, this type of change doesn't seem appropriate for a
> stable release (it's possible it might even cause an ABI change), so we'd
> have to make it unstable after bookworm is released (this weekend?!). Thus,
> the bug should be reassigned to wxwidgets3.2.

Oh, I missed that this was reported in wxwidgets3.0 - thanks for
spotting.

I agree this should be reassigned - wxwidgets3.0 is gone from bookworm
and newer and I really can't see the release team agreeing to enabling a
new optional feature in a stable or oldstable update (and one of their
criteria is severity important or higher).

So we can only target addressing this for trixie at this point, so we can
take the time to check with upstream.  If it requires an ABI bump we'd
need to do a transition so that's a key question.

Cheers,
Olly

Bug#1037213: awstats: prompting due to modified conffiles which were not modified by the user: /etc/logrotate.d/httpd-prerotate/awstats

[Andreas Beckmann]

Package: awstats
Version: 7.8-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up awstats (7.8-3) ...
  
  Configuration file '/etc/logrotate.d/httpd-prerotate/awstats'
   ==> Deleted (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** awstats (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
awstats (--configure):
   end of file on stdin at conffile prompt

This was observed on the upgrade path
  buster -> bullseye -> bookworm
It does not show up on either buster -> bullseye or bullseye ->
bookworm.


There is something fancy happening here: a directory containing a
conffile is to be replaced by a conffile.



cheers,

Andreas


awstats_7.8-3.log.gz
Description: application/gzip

Bug#1037206: appstream-glib: diff for NMU version 0.7.18-1+deb11u1

[Simon McVittie]

Control: tags 1037206 + patch
Control: tags 1037206 + pending

Here is a proposed fix. I'll open a bullseye-pu bug next.

Corresponding git branch:
https://salsa.debian.org/smcv/appstream-glib/-/tree/debian/bullseye-proposed?ref_type=heads

Diff viewable at:
https://salsa.debian.org/smcv/appstream-glib/-/merge_requests/1
(not a MR against https://salsa.debian.org/pkgutopia-team/appstream-glib
because there isn't a bullseye branch there at the moment).

smcv
diffstat for appstream-glib-0.7.18 appstream-glib-0.7.18

 debian/.gitignore |1 
 debian/changelog  |   10 
 debian/patches/Improve-handling-of-em-and-code-tags.patch |  220 ++
 debian/patches/Properly-initialize-AsNodeToXmlHelper.patch|   34 +
 debian/patches/Support-em-code-tags.patch |  118 +
 debian/patches/series |4 
 debian/patches/trivial-Turn-is_-em-code-_text-fields-into-bitfields.patch |   26 +
 libappstream-glib/as-node.c   |  120 -
 libappstream-glib/as-self-test.c  |   51 ++
 9 files changed, 552 insertions(+), 32 deletions(-)

diff -Nru appstream-glib-0.7.18/debian/changelog appstream-glib-0.7.18/debian/changelog
--- appstream-glib-0.7.18/debian/changelog	2020-12-21 23:14:10.0 +
+++ appstream-glib-0.7.18/debian/changelog	2023-06-07 19:25:59.0 +0100
@@ -1,3 +1,13 @@
+appstream-glib (0.7.18-1+deb11u1) bullseye; urgency=medium
+
+  * Add patches from upstream to cope with  and  in metadata.
+Older versions of appstream-glib mis-parse upstream metadata that
+contains  and , causing flatpak 1.12.x or older to fail
+to load the metadata now published by Flathub. The symptom is that
+`flatpak search` fails. (Closes: #1037206, LP: #2023215)
+
+ -- Simon McVittie   Wed, 07 Jun 2023 19:25:59 +0100
+
 appstream-glib (0.7.18-1) unstable; urgency=medium
 
   [ Matthias Klumpp ]
diff -Nru appstream-glib-0.7.18/debian/.gitignore appstream-glib-0.7.18/debian/.gitignore
--- appstream-glib-0.7.18/debian/.gitignore	1970-01-01 01:00:00.0 +0100
+++ appstream-glib-0.7.18/debian/.gitignore	2023-06-07 19:25:59.0 +0100
@@ -0,0 +1 @@
+*~
diff -Nru appstream-glib-0.7.18/debian/patches/Improve-handling-of-em-and-code-tags.patch appstream-glib-0.7.18/debian/patches/Improve-handling-of-em-and-code-tags.patch
--- appstream-glib-0.7.18/debian/patches/Improve-handling-of-em-and-code-tags.patch	1970-01-01 01:00:00.0 +0100
+++ appstream-glib-0.7.18/debian/patches/Improve-handling-of-em-and-code-tags.patch	2023-06-07 19:25:59.0 +0100
@@ -0,0 +1,220 @@
+From: "Jan Alexander Steffens (heftig)" 
+Date: Fri, 15 Jul 2022 21:18:47 +0200
+Subject: Improve handling of  and  tags
+
+This is still not great code but at least somewhat an improvement. Tests
+were expanded to showcase the new behavior.
+
+I think, ideally, we would append opening/closing tags to the ancestor
+`p` or `li` node's cdata as soon as we encounter the start/end of an
+`em` or `code` element. This would then also handle empty elements
+correctly.
+
+Origin: https://github.com/hughsie/appstream-glib/pull/446
+Applied-upstream: 0.8.1, commit:674490bd54ff206f213ca4547db7fdb591a0fb3d
+Bug-Debian: https://bugs.debian.org/1037206
+---
+ libappstream-glib/as-node.c  | 108 +++
+ libappstream-glib/as-self-test.c |  39 +-
+ 2 files changed, 101 insertions(+), 46 deletions(-)
+
+diff --git a/libappstream-glib/as-node.c b/libappstream-glib/as-node.c
+index 5e19337..655b947 100644
+--- a/libappstream-glib/as-node.c
 b/libappstream-glib/as-node.c
+@@ -674,6 +674,7 @@ as_node_end_element_cb (GMarkupParseContext *context,
+ 			GError **error)
+ {
+ 	AsNodeToXmlHelper *helper = (AsNodeToXmlHelper *) user_data;
++	AsNodeData *data = helper->current->data;
+ 
+ 	/* do not create a child node for em and code tags */
+ 	if (g_strcmp0 (element_name, "em") == 0) {
+@@ -684,6 +685,42 @@ as_node_end_element_cb (GMarkupParseContext *context,
+ 		helper->is_code_text = 0;
+ 		return;
+ 	}
++
++	if (data->cdata != NULL) {
++		/* split up into lines and add each with spaces stripped */
++		if ((helper->flags & AS_NODE_FROM_XML_FLAG_LITERAL_TEXT) == 0) {
++			AsRefString *cdata = data->cdata;
++			data->cdata = as_node_reflow_text (cdata, strlen (cdata));
++			as_ref_string_unref (cdata);
++		}
++
++		/* intern commonly duplicated tag values and save a bit of memory */
++		if (data->is_tag_valid) {
++			AsNode *root = g_node_get_root (helper->current);
++			switch (data->tag) {
++			case AS_TAG_CATEGORY:
++			case AS_TAG_COMPULSORY_FOR_DESKTOP:
++			case AS_TAG_CONTENT_ATTRIBUTE:
++			case AS_TAG_DEVELOPER_NAME:
++			case AS_TAG_EXTENDS:
++			case AS_TAG_ICON:
++			case 

Bug#1037203: aide release notes to work around #1037171

[Marc Haber]

On Wed, Jun 07, 2023 at 08:01:23PM +0100, Justin B Rye wrote:
> Marc Haber wrote:
> > I am really sorry for this. #1037171 is an embarrassing one, sadly too
> > late for the release, but I'll try to do a fix via spu.
> 
> I gather from the version data that when the bug submitter says buster
> that's a typo for bookworm?

Yes. It is.

> > Suggested wording for something along chapter 5.4:
> 
> It'll also need a section title and a summary of what the bug actually
> is, which isn't completely clear to me.  Does the bug mean that
> bullseye systems where aide was already working will break on
> dist-upgrade to bookworm, or is it only a bug for systems where aide
> is installed subsequently?

Sadly, aide will be broken after upgrades. bookworm's aide is the first
version that doesn't run as root and thus needs the account.

>I'm guessing:
> 
>
>  Bug in aide user creation
>  
>The version of aide in the
>initial 12.0 release of bookworm has a bug
>(https://bugs.debian.org/1037171;>#1037171) in
>its package scripts which results in the _aide
>user not being created, preventing aideinit
>from creating a new database.
>  

Yes. It prevents the package from working at all on systemd systems at
least.

> > Before upgrading your aide packages, create
> 
> So this needs to be done before the dist-upgrade?

It is the cleanest way, yes. Or the local admin can reinstall aide after
creating the account.

> > /usr/lib/sysusers.d/aide-common.conf with the following contents:
> 
> Isn't this the sort of thing that's usually overridable via files with
> names like /etc/sysusers.d/aide-common.conf?  I'll assume for now that
> this needs to live in /usr/lib (because we *want* it trampled when the
> point release version installs its own copy).

Yes. That's the idea.

> > #Type   NameID  GECOS   
> > Home directoryShell↲
> > u   _aide   -   "Advanced Intrusion Detection Environment"  
> > /var/lib/aide /usr/sbin/nologin↲
> 
> (I'm assuming "↲" just means "newline"...)

Yes, sorry, that's a cut and paste error.

>  
> > and call systemd-sysusers to work around Bug #1037171.
> 
> (...and that this is a plain root-privileged invocation of bullseye
> "systemd-sysusers".  So:)
> 
>  
>The bug can be avoided by creating the user before the dist-upgrade.
>Create a file /usr/lib/sysusers.d/aide-common.conf
>containing:
>
> #Type  Name   ID  GECOS   Home directory 
> Shell
> u  _aide  -   "Advanced Intrusion Detection Environment"  /var/lib/aide  
> /usr/sbin/nologin
>
>and then run systemd-sysusers.
>  
>

Yes, that's it.

Thanks for helping.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1037200: please consider backporting valijson to Bullseye

[Pierre Gruet]

Control: block -1 by 1037212


Hello,

Le 07/06/2023 à 20:34, Dima Kogan a écrit :

Hi. I'll gladly accept help on this. If you can do this yourself, that
would be great!

Thanks


Thanks for your quick answer; fine then, I will do so :)

I could build it in a Bullseye chroot by having also picojson 
backported, I will ask its maintainer as well, and proceed afterwards.


Best wishes,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037212: Please consider backporting picojson to Bullseye

[Pierre Gruet]

Source: picojson
Severity: wishlist

Dear Maintainer,

I would be interested in having picojson backported to Bullseye, for myself but
also for people working with me.

If you want, I would be pleased to do it for you (I am a DD).

Best,

-- 
Pierre

Bug#1033398: linux-image-amd64: reproducible kernel freeze on 5.19+

[Salvatore Bonaccorso]

Hi Florian,

On Mon, Jun 05, 2023 at 08:49:25PM +0200, Florian Lehner wrote:
> Hi all,
> 
> the fix was merged upstream with 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/maccess.c?id=d319f344561de23e810515d109c7278919bff7b0

And so landed in 6.4-rc1.

Great thanks! Would you mind proposing the change as well for
inclusion in the relevant stable versions? Make sure to CC the
relevant maintainers in the request for stable?

Regards,
Salvatore

Bug#1037211: coreutils: od: XSI [+]offset.[b] documented but not recognised

[наб]

Package: coreutils
Version: 8.32-4+b1
Version: 9.1-1
Severity: normal

Dear Maintainer,

Quoth od(1):
SYNOPSIS
   od [OPTION]... [FILE]...
   od [-abcdfilosx]... [FILE] [[+]OFFSET[.][b]]
   od --traditional [OPTION]... [FILE] [[+]OFFSET[.][b] [+][LABEL][.][b]]
DESCRIPTION
   If first and second call formats both apply, the second format is 
assumed if the last operand begins with +  or
   (if  there  are  2 operands) a digit.  An OFFSET operand means -j 
OFFSET.  LABEL is the pseudo-address at first
   byte printed, incremented when dump is progressing.  For OFFSET and 
LABEL, a 0x or 0X prefix indicates hexadec‐
   imal; suffixes may be . for octal and b for multiply by 512.

Quoth Issue 8 Draft 3, XSI, od:
108088  SYNOPSIS
108089  od [-v] [-A address_base] [-j skip] [-N count] [-t type_string]...
108090 [file...]
108091  XSI od [-bcdosx] [file] [[+]offset[.][b]]
108156  OPERANDS
108157   The following operands shall be supported:
108158   fileA pathname of a file to be read. If no file 
operands are specified, the standard input
108159   shall be used.
108160   If there are no more than two operands, none of 
the −A, −j, −N, −t, or −v options is
108161   specified, and either of the following is true: 
the first character of the last operand
108162   is a  ('+'), or there are two operands 
and the first character of the last
108163  XSI  operand is numeric; »the last operand shall be 
interpreted as an offset operand on
108164   XSI-conformant systems.« Under these conditions, 
the results are unspecified on
108165   systems that are not XSI-conformant systems.
108166  XSI »[+]offset[.][b] The offset operand specifies the offset in the 
file where dumping is to commence.
108167   This operand is normally interpreted as octal 
bytes. If '.' is appended, the offset
108168   shall be interpreted in decimal. If 'b' is 
appended, the offset shall be interpreted
108169   in units of 512 bytes.«

These are in agreement:
  od f 1000
  od f 1b
  od f 1.b
  od f 512.
should be equivalent. And yet:
  $ od /tmp/ur 1000
  0001000 00 077600 00 177600 00 077600 00 177600
  *
  0001640 00 077600 00 177600
  0001650
  $ od /tmp/ur 1b
  0001000 00 077600 00 177600 00 077600 00 177600
  *
  0001640 00 077600 00 177600
  0001650
  $ od /tmp/ur 1.b
  000 123453 136512 137101 003650 123571 151453 036037 127475
  020 046712 137125 051752 120146 043401 007016 163454 170646
  040 102342 124607 160463 102374 175711 150532 070241 011205
  060 030473 047651 047726 153534 155411 155052 024737 115614
  100 020043 073133 071157 072545 064564 071554 024135 027457
  120 073564 072151 062564 027162 067543 027555 060556 064542
  140 060552 075143 062554 062567 064554 071457 060564 072564
  160 027563 032061 030460 031465 033070 033470 031467 034063
  200 00 037600 00 137600 00 040440 00 140440
  220 00 041310 00 141310 00 042172 00 142172
  240 04 043034 04 143034 05 043703 05 143703
  260 022000 044564 022000 144564 113200 045430 113200 145430
  300 136040 046276 136040 146276 065450 047156 065450 147156
  320 001371 050025 001371 150025 041667 050672 041667 150672
  340 152245 051550 152245 151550 102347 052421 102347 152421
  360 163041 053265 163041 153265 057651 054143 057651 154143
  400 015712 055016 015712 155016 121274 055661 121274 155661
  420 005553 056536 005553 156536 143443 057412 143443 157412
  440 074354 060255 074354 160255 153447 061130 153447 161130
  460 103170 062007 103170 162007 064026 062651 064026 162651
  500 141034 063523 141034 163523 054522 064404 054522 164404
  520 067646 065245 067646 165245 145620 066116 145620 166116
  540 037472 067001 037472 167001 107410 067641 107410 167641
  560 171312 070511 171312 170511 067574 071374 067574 171374
  600 142656 072235 142656 172235 033432 073105 033432 173105
  620 102340 073766 102340 173766 011414 074632 011414 174632
  640 113717 075500 113717 175500 136703 076360 136703 176360
  660 073232 077226 073232 177226 00 077600 00 177600
  700 00 077600 00 177600 00 077600 00 177600
  *
  od: 1.b: No such file or directory
  0001640 00 077600 00 177600
  0001650
  $ od /tmp/ur 512.
  000 123453 136512 137101 003650 123571 151453 036037 127475
  020 046712 137125 051752 120146 043401 007016 163454 170646
  040 102342 124607 160463 102374 175711 150532 070241 011205
  060 030473 047651 047726 153534 155411 155052 024737 115614
  100 020043 073133 071157 072545 064564 071554 024135 027457
  120 073564 072151 062564 027162 067543 027555 060556 064542
  

Bug#1035089: Release Notes: Unknown reference "newreleasename"

[Paul Gevers]

Hi,

On 07-06-2023 13:40, Martin Bagge / brother wrote:
Noticed that  was added in the upgrading section of the 
release notes (looks to be introduced via #1035089) and I can parse that 
(or can I?) but make validate does not pass clean with it.


Thanks, I thought I fixed that...

Yes I did, in commit c4a6eda (but it seems it sneaked in in el).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 06, 2023 at 11:00:14PM -0400, Nicholas D Steeves wrote:
> +org-mode (9.4.0+dfsg-1+deb11u1) bullseye-security; urgency=medium
> +
> +  * Fix Org Mode command injection vulnerability CVE-2023-28617 by 
> backporting
> +0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch like src:emacs
> +did (Closes: #1033341).  Thanks to Rob Browning's work in that package,
> +fixing org-mode was trivially easy!
> +
> + -- Nicholas D Steeves   Sun, 04 Jun 2023 13:26:52 -0400

Small remark, for the bullseye pu update please target at 'bullseye'
not 'bullseye-security'.

Regards,
Salvatore

Bug#1037203: aide release notes to work around #1037171

[Justin B Rye]

Marc Haber wrote:
> I am really sorry for this. #1037171 is an embarrassing one, sadly too
> late for the release, but I'll try to do a fix via spu.

I gather from the version data that when the bug submitter says buster
that's a typo for bookworm?

> Suggested wording for something along chapter 5.4:

It'll also need a section title and a summary of what the bug actually
is, which isn't completely clear to me.  Does the bug mean that
bullseye systems where aide was already working will break on
dist-upgrade to bookworm, or is it only a bug for systems where aide
is installed subsequently?  I'm guessing:

   
 Bug in aide user creation
 
   The version of aide in the
   initial 12.0 release of bookworm has a bug
   (https://bugs.debian.org/1037171;>#1037171) in
   its package scripts which results in the _aide
   user not being created, preventing aideinit
   from creating a new database.
 

> Before upgrading your aide packages, create

So this needs to be done before the dist-upgrade?

> /usr/lib/sysusers.d/aide-common.conf with the following contents:

Isn't this the sort of thing that's usually overridable via files with
names like /etc/sysusers.d/aide-common.conf?  I'll assume for now that
this needs to live in /usr/lib (because we *want* it trampled when the
point release version installs its own copy).

> #Type   NameID  GECOS   Home 
> directoryShell↲
> u   _aide   -   "Advanced Intrusion Detection Environment"  
> /var/lib/aide /usr/sbin/nologin↲

(I'm assuming "↲" just means "newline"...)
 
> and call systemd-sysusers to work around Bug #1037171.

(...and that this is a plain root-privileged invocation of bullseye
"systemd-sysusers".  So:)

 
   The bug can be avoided by creating the user before the dist-upgrade.
   Create a file /usr/lib/sysusers.d/aide-common.conf
   containing:
   
#Type  Name   ID  GECOS   Home directory 
Shell
u  _aide  -   "Advanced Intrusion Detection Environment"  /var/lib/aide  
/usr/sbin/nologin
   
   and then run systemd-sysusers.
 
   
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1037209: qt6-base: CVE-2023-34410

[Salvatore Bonaccorso]

Source: qt6-base
Version: 6.4.2+dfsg-10
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:qtbase-opensource-src 5.15.8+dfsg-11
Control: retitle -2 qtbase-opensource-src: CVE-2023-34410

Hi,

The following vulnerability was published for Qt.

CVE-2023-34410[0]:
| An issue was discovered in Qt before 5.15.15, 6.x before 6.2.9, and
| 6.3.x through 6.5.x before 6.5.2. Certificate validation for TLS
| does not always consider whether the root of a chain is a configured
| CA certificate.


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-34410
https://www.cve.org/CVERecord?id=CVE-2023-34410

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#1037208: renderdoc: CVE-2023-33863 CVE-2023-33864 CVE-2023-33865

[Salvatore Bonaccorso]

Source: renderdoc
Version: 1.24+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for renderdoc.

CVE-2023-33863[0]:
| integer overflow to heap-based buffer overflow


CVE-2023-33864[1]:
| integer underflow to heap-based buffer overflow


CVE-2023-33865[2]:
| symlink vulnerability in /tmp/RenderDoc


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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037207: matrix-synapse: CVE-2023-32682 CVE-2023-32683

[Salvatore Bonaccorso]

Source: matrix-synapse
Version: 1.78.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for matrix-synapse.

CVE-2023-32682[0]:
| Synapse is a Matrix protocol homeserver written in Python with the
| Twisted framework. In affected versions it may be possible for a
| deactivated user to login when using uncommon configurations. This
| only applies if any of the following are true: 1. JSON Web Tokens
| are enabled for login via the `jwt_config.enabled` configuration
| setting. 2. The local password database is enabled via the
| `password_config.enabled` and `password_config.localdb_enabled`
| configuration settings *and* a user's password is updated via an
| admin API after a user is deactivated. Note that the local password
| database is enabled by default, but it is uncommon to set a user's
| password after they've been deactivated. Installations that are
| configured to only allow login via Single Sign-On (SSO) via CAS,
| SAML or OpenID Connect (OIDC); or via an external password provider
| (e.g. LDAP) are not affected. If not using JSON Web Tokens, ensure
| that deactivated users do not have a password set. This issue has
| been addressed in version 1.85.0. Users are advised to upgrade.


CVE-2023-32683[1]:
| Synapse is a Matrix protocol homeserver written in Python with the
| Twisted framework. A discovered oEmbed or image URL can bypass the
| `url_preview_url_blacklist` setting potentially allowing server side
| request forgery or bypassing network policies. Impact is limited to
| IP addresses allowed by the `url_preview_ip_range_blacklist` setting
| (by default this only allows public IPs) and by the limited
| information returned to the client: 1. For discovered oEmbed URLs,
| any non-JSON response or a JSON response which includes non-oEmbed
| information is discarded. 2. For discovered image URLs, any non-
| image response is discarded. Systems which have URL preview disabled
| (via the `url_preview_enabled` setting) or have not configured a
| `url_preview_url_blacklist` are not affected. This issue has been
| addressed in version 1.85.0. Users are advised to upgrade. User
| unable to upgrade may also disable URL previews.


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

Regards,
Salvatore

Bug#1037200: please consider backporting valijson to Bullseye

[Dima Kogan]

Hi. I'll gladly accept help on this. If you can do this yourself, that
would be great!

Thanks

Bug#1037206: libappstream-glib8/bullseye: flatpak fails to load current Flathub metadata

[Simon McVittie]

Package: libappstream-glib8
Version: 0.7.18-1
Severity: important
Tags: fixed-upstream bullseye
Control: forwarded -1 https://github.com/flatpak/flatpak/issues/5434
Control: affects -1 + flatpak
Control: fixed -1 0.8.1-1

To reproduce:

$ podman run --rm -it debian:bullseye-slim
# apt update
# apt install flatpak reportbug
# flatpak remote-add --if-not-exists flathub 
https://flathub.org/repo/flathub.flatpakrepo
# flatpak search steamlink

Expected result: something similar to the output on unstable:

```
Name   Description Application ID   Version   Branch Remotes
Steam… Stream games from another … …esoftware.SteamLink 1.2.0.241 stable flathub
```

(for more readable results use a wider terminal, but this truncated
version is OK)

Actual result:

```
root@c8b13fe6aeca:/# flatpak search steamlink
F: Failed to parse 
/var/lib/flatpak/appstream/flathub/x86_64/active/appstream.xml.gz file: Error 
on line 1960 char 29:  already set '
  Organic Maps is a free Android & iOS offline maps app for travelers,
  tourists, hikers, and cyclists.
  It uses crowd-sourced OpenStreetMap data and is developed with love by
  ' and tried to replace with ' ('
No matches found
```

This is not actually a flatpak bug, it's been diagnosed as happening
because older versions of appstream-glib mis-parse upstream metadata
that contains  and .

Targeted fixes for the same upstream release have been proposed in
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/2023215
and I'm now looking at an equivalent update for bullseye.

Workaround: the version of flatpak in bullseye-backports and bookworm has
switched from appstream-glib to libappstream, which does not have this
problem, even in bullseye. I've confirmed that the bullseye-backports
version ("apt install flatpak/bullseye-backports") works fine with
these steps.

smcv

-- 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 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libappstream-glib8 depends on:
ii  libarchive13 3.4.3-2+deb11u1
ii  libc62.31-13+deb11u6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libsoup2.4-1 2.72.0-2
ii  libstemmer0d 2.1.0-1
ii  libuuid1 2.36.1-8+deb11u1
ii  libyaml-0-2  0.2.2-1

libappstream-glib8 recommends no packages.

libappstream-glib8 suggests no packages.

-- no debconf information

Bug#1037205: multipath-tools: please make the build reproducible

[Chris Lamb]

Source: multipath-tools
Version: 0.9.4-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
multipath-tools could not be built reproducibly.

In a previous reproducibility bug (#1030727), I thought that it was
the parallel nature of the build that was making it unreproducible,
and adding this flag made it reproducible for me at the time. However,
despite the --max-parallel flag working back then, I am now seeing
that the package is unreproducible.

As a reminder, what is happening is that in the "first" build the
documentation is being regenerated, but in the "second" build, the
documentation is left entirely alone, resulting in the docs in the
orig tarball being shipped instead. These have slightly different
contents, hence the unreproducibility of the package.

Anyway, it seems like we can force the docs' regeneration in all
possible cases by simply deleting the top-level source of the
documentation in the debian/rules "clean" target, and then relying on
the dependency resolution to recreate it again.

A patch to this end is attached, which also removes the --max-parallel
calls.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2023-06-07 10:55:29.627967515 -0700
--- b/debian/rules  2023-06-07 11:03:56.834719140 -0700
@@ -16,6 +16,8 @@
rm -rf debian/$$treename ;\
done
rm -rf debian/tmp-multipath-udeb
+   # Force recreation of docs re. reproducibility
+   rm -fv libdmmp/docs/man/dmmp_strerror.3
 
 execute_before_dh_auto_configure:
# no out of tree build support, prepare two source trees
@@ -27,13 +29,10 @@
 override_dh_auto_configure:
 
 override_dh_auto_build:
-   # parallel build is disabled to avoid race condition in man page build, 
which will end in
-   # unreproducible contents (either regenerated man pages or shipped man 
pages will be
-   # selected, depending on the race). #1030727
-   dh_auto_build --sourcedirectory=debian/build-deb --max-parallel=1 -- \
+   dh_auto_build --sourcedirectory=debian/build-deb -- \
SCSI_DH_MODULES_PRELOAD="scsi_dh_alua scsi_dh_emc scsi_dh_rdac"
# multipath-udeb: build separately; don't reference dynamic libgcc at 
runtime (#779579); disable systemd
-   dh_auto_build --sourcedirectory=debian/build-udeb --max-parallel=1 -- \
+   dh_auto_build --sourcedirectory=debian/build-udeb -- \
SYSTEMD= EXTRACFLAGS="-static-libgcc"
 
 override_dh_auto_test:

Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Greg Kroah-Hartman]

On Fri, May 26, 2023 at 05:36:02PM +0200, Ben Hutchings wrote:
> On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > > From: Sean Christopherson 
> > > > > 
> > > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > > 
> > > > > For commands with small input/output buffers, use the local stack to
> > > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just 
> > > > > work.
> > > > [...]
> > > > 
> > > > Julien Cristau reported a regression in ccp - the
> > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > > this was introduced by the above commit, which depends on:
> > > > 
> > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > > Author: Sean Christopherson 
> > > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > > >  
> > > > crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > > 
> > > > Ben.
> > > > 
> > > 
> > > Thanks for letting me know, now queued up.
> > 
> > Nope, now dropped, it breaks the build :(
> 
> I've now looked further and found that we need both:
> 
> d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
> 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command 
> structs
> 
> (Not yet tested; I'll ask Julien if he can do that.)

Looks sane to me, both now queued up, thanks.

greg k-h

Bug#1037204: the place of #DEBHELPER# matters

[Marc Haber]

Package: debhelper
Version: 13.11.4
Severity: minor

Hi,

traditionally, I have placed my #DEBHELPER# marker last in my maintainer
scripts. I think that many package maintainers do it that way.

This doesnt work if systemd-sysusers and dh_installsysusers is used
since the account will be created only in the #DEBHELPER# code, so
maintainer script code using the account needs to be after the
#DEBHELPER# marker. This is a somewhat surprising change if adduser was
used previously.

I am not even sure whether there does debhelper code exist that needs
to be "late" in the process.

Please elaborate a bit about correct / preferred placement of
#DEBHELPER# in maintainer scripts in debhelper(7) to keep other people
from falling in that trap.

Greetings
Marc

Bug#1037203: aide release notes to work around #1037171

[Marc Haber]

Package: release-notes
Severity: normal

I am really sorry for this. #1037171 is an embarrassing one, sadly too
late for the release, but I'll try to do a fix via spu.

Greetings
Marc

Suggested wording for something along chapter 5.4:

Before upgrading your aide packages, create
/usr/lib/sysusers.d/aide-common.conf with the following contents:

#Type   NameID  GECOS   Home 
directoryShell↲
u   _aide   -   "Advanced Intrusion Detection Environment"  
/var/lib/aide /usr/sbin/nologin↲

and call systemd-sysusers to work around Bug #1037171.

Bug#1037171: aide: fresh aide package install fails to add the requried _aide user to system

[Marc Haber]

Control: tags -1 confirmed
Control: found -1 0.18.1-1
thanks

This confirmation also applies to the severity of the issue :-(  that
slipped itself in in March 2023 with 0.18.1-1. dh_installsysusers is not
called by the normal dh sequence in dh compat level 13 which leads to
the user not being created at package installation.

Patch to source package:
diff -Nru aide-0.18.3/debian/aide-common.postinst 
aide-0.18.3/debian/aide-common.postinst
--- aide-0.18.3/debian/aide-common.postinst 2023-04-20 23:50:04.0 
+0200
+++ aide-0.18.3/debian/aide-common.postinst 2023-05-18 10:25:22.0 
+0200
@@ -45,18 +45,6 @@
 # added updating to 0.18-1
 rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
 
-if dpkg --compare-versions "$2" lt 0.17.5-1; then
-# we're updating from a version earlier than 0.17.5, chown logs
-# and databases
-chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log 
/var/log/aide/aide.log.* || true
-chmod --quiet 2755 /var/log/aide || true
-chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new 
|| true
-fi
-if dpkg --compare-versions "$2" lt 0.18-3; then
-# we're updating from a version earlier than 0.18-3, chown aideinit logs
-chown --quiet _aide:adm /var/log/aide/aideinit.log 
/var/log/aide/aideinit.errors|| true
-fi
-
 rm -f /var/lib/aide/aide.conf.autogenerated
 if dpkg --compare-versions "$2" le "0.16-1"; then
 # we're updating from a version earlier than 0.16-1, rename DHCP conffiles
@@ -96,6 +84,20 @@
 
 #DEBHELPER#
 
+# this needs to be after debhelper, otherwise the account doesn't
+# yet exist.
+if dpkg --compare-versions "$2" lt 0.17.5-1; then
+# we're updating from a version earlier than 0.17.5, chown logs
+# and databases
+chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log 
/var/log/aide/aide.log.* || true
+chmod --quiet 2755 /var/log/aide || true
+chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new 
|| true
+fi
+if dpkg --compare-versions "$2" lt 0.18-3; then
+# we're updating from a version earlier than 0.18-3, chown aideinit logs
+chown --quiet _aide:adm /var/log/aide/aideinit.log 
/var/log/aide/aideinit.errors|| true
+fi
+
 exit 0
 
 # vim:sw=4:sts=4:et:
diff -Nru aide-0.18.3/debian/rules aide-0.18.3/debian/rules
--- aide-0.18.3/debian/rules2023-04-20 23:50:04.0 +0200
+++ aide-0.18.3/debian/rules2023-05-18 10:25:22.0 +0200
@@ -33,6 +33,10 @@
 override_dh_auto_configure:
dh_auto_configure -- $(strip ${COMMON_CONFIGURE_ARGS}) $(strip 
${EXTRA_CONFIGURE_ARGS})
 
+# make this execute_after_dh_auto_install after bookworm
 override_dh_auto_install:
dh_auto_install
dh_installsystemd --name=dailyaidecheck
+   # this is needed until dh compat 14
+   dh_installsysusers
+

A run-time fix would be to call
adduser --system --home /var/lib/aide --shell /usr/sbin/nologin _aide
before package installation.

or to drop the following file
#Type   NameID  GECOS   Home 
directoryShell
u   _aide   -   "Advanced Intrusion Detection Environment"  
/var/lib/aide /usr/sbin/nologin
in /usr/lib/sysusers.d/aide-common.conf and execute systemd-sysusers.

A fixed package will be brought on the way by means of stable proposed
updates and a bookworm point release.

Greetings
Marc

Bug#1037202: libunity9: Multi-Arch: same, but not co-installable

[Ben Harris]

Package: libunity9
Version: 7.1.4+19.04.20190319-6+b1
Severity: normal

Dear Maintainer,

While cross-grading an i386 system to amd64, I tried to co-install both 
i386 and amd64 versions of libunity9.  This should be possible as they are 
both marked "Multi-Arch: same".  However, dpkg complains:


wraith:~/crossgrade# dpkg -i libunity9_7.1.4+19.04.20190319-6+b1_i386.deb
(Reading database ... 431882 files and directories currently installed.)
Preparing to unpack libunity9_7.1.4+19.04.20190319-6+b1_i386.deb ...
Unpacking libunity9:i386 (7.1.4+19.04.20190319-6+b1) over 
(7.1.4+19.04.20190319-6+b1) ...
Setting up libunity9:i386 (7.1.4+19.04.20190319-6+b1) ...
Processing triggers for libc-bin (2.36-9) ...
Processing triggers for libglib2.0-0:amd64 (2.74.6-2) ...
Processing triggers for libglib2.0-0:i386 (2.74.6-2) ...
wraith:~/crossgrade# dpkg -i libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb
(Reading database ... 431882 files and directories currently installed.)
Preparing to unpack libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb ...
Unpacking libunity9:amd64 (7.1.4+19.04.20190319-6+b1) ...
dpkg: error processing archive libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb 
(--install):
 trying to overwrite shared '/usr/bin/unity-scope-loader', which is different 
from other instances of package libunity9:amd64
Processing triggers for libc-bin (2.36-9) ...
Errors were encountered while processing:
 libunity9_7.1.4+19.04.20190319-6+b1_amd64.deb

/usr/bin/unity-scope-loader is indeed an i386 executable in the i386 
package and an amd64 executable in the amd64 package.


I think either unity-scopes-loader should be removed from the libunity9 
package or libunity9 should be marked as "Multi-Arch: no".


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

--
Ben Harris, University of Cambridge Information Services.

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

[Beauregard,Christophe (ECCC)]

Reported to the GCC maintainers: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110156

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

[Leonardo Held]

Hello again Lisandro,

On 06.06.23 11:40 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
And at that point is where I'll personally say "no". I do not have 
enough free time to handle this, and that is in fact the reason I am 
maintaining Qt 6 mostly as team member (I am not listed in Uploaders 
on purpose).

That's completely understandable.
This is specially true if your company uses Debian as a base for the 
containers shipped in your products (Leonardo: hint, hint).
I'll work a bit on this this week on our private Debian feed and then 
start helping your team out, hopefully.
Should I keep in touch with your or Patrick Franz (listed as the 
uploader)? Do you guys have an IRC I can jump in to?

Regards,

Bug#815539: typecatcher: Still the same in Bookworm

[Keith Edmunds]

Package: typecatcher
Version: 0.3-1.2
Followup-For: Bug #815539

The package in Bookworm has exactly the same problem. Disappointing that this 
bug remains seven years after being reported.

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

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

Versions of packages typecatcher depends on:
ii  gir1.2-glib-2.0 1.74.0-3
ii  gir1.2-gtk-3.0  3.24.37-2
ii  gir1.2-webkit2-4.0  2.40.1-1
ii  python3 3.11.2-1+b1
ii  python3-gi  3.42.2-3+b1

Versions of packages typecatcher recommends:
ii  yelp  42.2-1

typecatcher suggests no packages.

-- no debconf information

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Jérôme Charaoui]

On Wed, 7 Jun 2023 18:47:02 +0530 Utkarsh Gupta 
 wrote:> I've prepared a fix for the 
regression and uploaded the binaries at:

https://people.debian.org/~utkarsh/lts/ruby2.5/

Can you please give these a try and see if that fixes the regression
you're seeing?


These packages also fix the Puppet regression reported here, on our 
buster systems.


Thanks,

-- Jérôme

Bug#1036858: bookworm-pu: package gnome-shell/43.6-1~deb12u1

[Simon McVittie]

Control: retitle -1 bookworm-pu: package gnome-shell/43.6-1~deb12u1

On Sun, 28 May 2023 at 00:29:58 +0100, Simon McVittie wrote:
> The gnome-shell 43.5 release from GNOME upstream seems like something
> we should have in a bookworm update.

So does 43.6.

> This requires mutter 43.5, for which see #1036856.

Still true.

[ Reason ]
New upstream stable release

[ Impact ]
If not accepted, our default desktop will have several known bugs.

[ Tests ]
Manual testing: I'm running this version on my main laptop.
I'll upload to unstable when bookworm has been released.

[ Risks ]
There's the potential for regressions of similar magnitude to what we're
fixing. GNOME is our default desktop, so any regressions will be highly
visible.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in bookworm
  [ ] the issue is verified as fixed in unstable
  - intentionally not done during the full freeze

[ Changes ]
js/misc/ibusManager.js:
- Fix input method popup getting stuck on screen during engine changes
  (gnome-shell#6717)

js/misc/objectManager.js:
- Receive notifications of removed objects from D-Bus ObjectManager
  instances correctly (gnome-shell!2730).
  This is utility code used in multiple places, I don't know what
  user-visible impact this has.

js/ui/appDisplay.js:
- Fix an assertion failure during shutdown (gnome-shell#6512)

js/ui/components/autorunManager.js:
- Fix a regression in 43~beta involving detection of hotplugged media
  with autorunnable content (gnome-shell!2745)

js/ui/components/polkitAgent.js:
- When cancelling the polkit agent prompt while using
  gnome-remote-desktop, don't break subsequent polkit prompts
  (gnome-shell!2761)

js/ui/dash.js:
- Avoid destroying labels twice, most commonly when using
  gnome-shell-extension-dash-to-dock (gnome-shell!2739)

js/ui/dnd.js:
- Fix "TypeError: this._dragActor is null" warnings related to
  drag-and-drop (gnome-shell!2770)

js/ui/messageTray.js:
- Fix queued notifications getting into a state where they can no
  longer be removed (gnome-shell!2736)

js/ui/modalDialog.js:
- After 60 second timeout in logout/reboot/poweroff confirmation
  dialog, do the requested action instead of leaving the Shell in a
  broken state (gnome-shell#6506)

js/ui/panelMenu.js:
- Avoid keyboard navigation focus getting stuck on top bar buttons with
  no associated menu (gnome-shell!2734; does not solve #1032319 but is
  helpful when working around it)

js/ui/screenshot.js (first hunk), d/control.in:
- Fix a regression in which the cursor would not be included in
  screenshots since mutter 43.1 (gnome-shell!2710).
  This needs mutter 43.5; strictly speaking it isn't a required
  dependency, but if mutter is too old then the regression won't
  be fixed, so to simplify things I made it a dependency.

js/ui/screenshot.js (second and third hunks):
- Fix a cursor appearing at 0,0 in screenshots that should not
  include it (gnome-shell!2702)

js/ui/search.js:
- Make search results fill unused space as intended (gnome-shell#5924)

js/ui/status/location.js:
- Fix an assertion failure if Geoclue isn't D-Bus-activatable
  (gnome-shell!2689)

js/ui/windowPreview.js:
- Fix assertion failures after a window preview is destroyed
  (gnome-shell#5512, gnome-shell#6065)

js/ui/workspacesView.js:
- Update visibility of workspaces in workspace switcher when required
  (gnome-shell#6519)

src/shell-app-system.c:
- Improve matching of app StartupWMClass to a .desktop file, giving
  priority to apps that were not hidden by OnlyShowIn under the current
  desktop environment, in particular preferring gnome-system-monitor's
  non-KDE-specific .desktop file while running GNOME (gnome-shell!2721)

src/shell-window-preview-layout.c:
- Fix a crash when a window preview is destroyed (gnome-shell#6570)

[ Other info ]
I have not uploaded to unstable due to the full freeze, and I can't
upload to experimental because GNOME 44 is already there.

The attached diff is between patched trees, excluding the patches
themselves to avoid duplicating the changes, and is lightly filtered to
ignore translations (very verbose) and upstream CI stuff (not used or
relevant in Debian). I normally upload using dgit, so if I'm the uploader,
the uploaded .dsc will be checked for an exact match to what's in git.

Thanks,
smcv
git diff patch-queue/43.4.. | filterdiff -p1 -x'debian/patches/*.patch' -x.gitlab-ci.yml -x'.gitlab-ci/*' -x'po/*.po'

diff --git a/NEWS b/NEWS
index d20f27985..87adbee86 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,34 @@
+43.6
+
+* Fix stuck authentication dialog in remote sessions [Joan; !2761]
+* Fix IM popup getting stuck on engine changes [Daniel; !2774]
+* Fixed crash [Carlos; !2756]
+* Misc. bug fixes and cleanups 

Bug#1037056: bookworm-pu: package libreswan/4.10-2+deb12u1

[Adam D. Barratt]

On Fri, 2023-06-02 at 18:54 -0400, Daniel Kahn Gillmor wrote:
> Uploading libreswan 4.19-1+deb12u1 should address #1035542 (aka
> CVE-2023-30570), which addresses a potential DoS against libreswan
> instances that use a certain IKEv1 configuration.
> 
> Discussion with Salvatore Bonaccorso over in #1035542 concluded that
> using point releases for this should be sufficient.
> 

fwiw, because you already uploaded this, it hit testing-proposed-
updates, where it got autobuilt without any review from the Release
Team (as the approval boundary there is tpu -> testing, rather than
stable-new -> pu).

Hopefully that shouldn't make any practical difference, I'm just
mentioning it in case it was unexpected. (It will also need a bit of
handholding to get our tooling to recognise it properly once the
release has happened, but it's not the only package in that situation.)

Regards,

Adam

Bug#1036856: bookworm-pu: package mutter/43.6-1~deb12u1

[Simon McVittie]

Control: retitle -1 bookworm-pu: package mutter/43.6-1~deb12u1

On Sun, 28 May 2023 at 00:15:26 +0100, Simon McVittie wrote:
> The mutter 43.5 release from GNOME upstream seems like something we should
> have in a bookworm update.

So does the 43.6 release.

[ Reason ]
New upstream stable release

[ Impact ]
If not accepted, our default desktop will have several known bugs including
a crash during suspend/resume under some circumstances, and selectively
recording/screencasting a window that is not visible on a display not being
reliable. Additionally, this update is a prerequisite for a bug fix in
gnome-shell which I would also like to get fixed in bookworm (separate
bookworm-pu request, #1036858).

[ Tests ]
Manual testing: I'm running this version on my main laptop, and I'll
upload to unstable as soon as bookworm has been released.

Automated testing: mutter's test-suite still passes at build-time and in
autopkgtest.

[ Risks ]
There's the potential for regressions of similar magnitude to what we're
fixing. GNOME is our default desktop, so any regressions will be highly
visible.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in bookworm
  [ ] the issue is verified as fixed in unstable
  - intentionally not done yet, due to full freeze

[ Changes ]
src/backends/meta-screen-cast-window-stream.c,
src/backends/meta-screen-cast-window.c,
src/compositor/meta-surface-actor-wayland.c,
src/compositor/meta-window-actor.c: make sure that if a window is being
recorded or screencasted, it gets updated at the refresh rate of at least
some arbitrary display, even if it's not actually visible on any display
(for example because it's obscured by a window in front).

src/backends/native/meta-kms-impl-device-dummy.c:
don't crash on trying to blank the screen when run "headless" by
gnome-remote-desktop

src/wayland/meta-wayland-actor-surface.c: consider updating windows even if
they're fully obscured, to make sure that single-window
recording/screencasting works as intended, at the cost of not optimizing
away as many non-user-visible window updates.

src/compositor/meta-compositor-view.c: simple change to fix a resource leak
by calling the parent class's destructor correctly

src/wayland/meta-wayland-outputs.c: backported patch from version 44
(not part of 43.x upstream) to avoid a known source of crashes during
suspend/resume, which might resolve Debian bug reports #1010478 and/or
#1036268

src/core/window-private.h, src/meta/window.h, debian/libmutter-11-0.symbols:
export a symbol needed by GNOME Shell 43.5 for a screenshot bug fix there,
already present in 44.1 in experimental

[ Other info ]
I have not uploaded to unstable due to the full freeze, and I can't
upload to experimental because GNOME 44 is already there.
git diff patch-queue/43.4.. | filterdiff -p1 -x'debian/patches/*.patch' -x'po/*.po'

diff --git a/NEWS b/NEWS
index 65e5d1cf89..410519419e 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,24 @@
+43.6
+
+* Fix popup issues [Jonas; !2940]
+* Plugged leak [Jonas; !2991]
+* Fixed crash [Jonas; !3037]
+
+Contributors:
+  Jonas Ådahl
+
+43.5
+
+* Fix recording windows on non-active workspaces [Robert; !2789]
+* Fixed crashes [Colin, Sebastian, Jonas; !2917, !2955, !2969]
+* Misc. bug fixes and cleanups [Ivan; !2928]
+
+Contributors:
+  Jonas Ådahl, Sebastian Keller, Colin Kinloch, Robert Mader, Ivan Molodetskikh
+
+Translators:
+  Nart Tlisha [ab]
+
 43.4
 
 * Do not overwrite previously set offsets on attach [Matthias; !2843]
diff --git a/debian/changelog b/debian/changelog
index d7daed1235..5ec723d601 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,24 @@
+mutter (43.6-1) UNRELEASED; urgency=medium
+
+  * New upstream stable release 43.5
+- Always update surfaces belonging to a window that is being recorded
+  or included in a screencast, even if the window is not visible
+  on a local display (mutter#2538, mutter!2789)
+- Export previously-private meta_window_has_pointer(), needed by
+  screenshot UI fixes in gnome-shell 43.5 (mutter!2928)
+  + d/libmutter-11-0.symbols: Update to add that symbol
+- All other changes were already present in 43.4-2
+  * New upstream stable release 43.6
+- Fix a resource leak when a compositor view is destroyed (mutter!2991)
+- Fix a crash when headless gdm greeter via gnome-remote-desktop
+  attempts to blank the screen (mutter#2841)
+  * d/patches: Drop patches that were applied upstream
+  * d/p/wayland-outputs-Fix-potential-crash-when-output-has-no-mo.patch:
+Backport patch from 44~beta to fix a crash during suspend/resume on
+some systems (mutter#2570, Closes: #1036268)
+
+ -- Simon McVittie   Tue, 06 Jun 2023 18:33:18 +0100
+
 mutter (43.4-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/libmutter-11-0.symbols b/debian/libmutter-11-0.symbols
index 1128f2ab36..f3b181d85b 100644

Bug#1034744: Please consider making emacs support optional

[Agustin Martin]

Control: reassign -1 emacsen-common,dictionaries-common

El mar, 25 abr 2023 a las 9:29, Agustin Martin () escribió:
>
> El dom, 23 abr 2023 a las 7:45, Josh Triplett
> () escribió:
> >
> > Package: dictionaries-common
> > Version: 1.29.5
> > Severity: wishlist
> > X-Debbugs-Cc: j...@joshtriplett.org
> >
> > As far as I can tell, the support provided by dictionaries-common makes
> > emacs better if installed, but isn't needed if an emacs isn't installed.
> > The maintainer scripts correctly check to see if the necessary binaries
> > are installed before invoking them. Would it be possible to change the
> > emacsen-common Depends to a Recommends?
>
> Hi, Josh,
>
> This is mandated by emacsen-common policy, point 5C
>
> /usr/share/doc/emacsen-common/debian-emacs-policy.gz

Reassigning this bug report to both emacsen-common and
dictionaries-common, as dictionaries-common just follows
emacsen-common policy.

Bug#1037201: ITP: cwltest -- Common Workflow Language testing framework

[Michael R. Crusoe]

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

Subject: ITP: cwltest -- Common Workflow Language testing framework
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: cwltest
  Version : 2.3.20230607140609
  Upstream Author : CWL, a project of Software Freedom Conservancy
* URL : https://www.commonwl.org
* License : Apache-2.0
  Programming Lang: Python
  Description : Common Workflow Language testing framework


Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/cwltest

Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?

[Cyril Brulebois]

Control: tag -1 patch pending

Cyril Brulebois  (2023-05-27):
> For the record, those archives end up being published in locations like
> the following, and I definitely expected those to match the firmware
> packages getting shipped into the images, not be some kind of snapshot of
> what's in unstable at the time the release is built!
> 
> https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/
> 
> We should definitely clarify the situation, and get to the bottom of that
> double firmware build.
> 
> From the log lines quoted above, if both bookworm and sid builds end up
> shipping files in the same destination directory, the last build wins and
> overrides the first one entirely?

I'm considering the following change for the upcoming (pseudo) RC 5 release:
  https://salsa.debian.org/images-team/setup/-/commit/9a77631

This means nothing changes for weekly builds, which are detected as being
built with DEBVERSION set to “testing” (please note that I didn't
investigate what happens to firmware directories in this case).

Meanwhile, actual releases get that sid job skipped (since the release
specific config file, e.g. CONF.sh.bookworm_di_rc4, sets DEBVERSION to
“bookworm-DI-rc4” instead of sticking to the default “testing” value).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#990336: This still affects the current bullseye package

[Athanasius]

On Wed, Jun 07, 2023 at 03:32:00PM +0200, Olivier Berger wrote:
> Hi
> 
> Le Thu, Jul 28, 2022 at 12:59:18PM +0100, Athanasius a écrit :
> >   I've just noticed this myself.  Our smtp.log is from 2020-08-08
> > onwards, so almost 2 years worth of logging.  It's 28 MiB in size, so
> > not disasterously big.
> > 
> >   I've added specific rotation of the other logfiles manually for now.
> > 
> 
> Would you mind sharing the snippet that you used for the logrotate config ?
> 
> It seems that maybe the smtp.log file might need special treatment, if I 
> refer to the discussion at https://gitlab.com/mailman/mailman/-/issues/931 
> (following 
> https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/RRFWGZY56OHAXPRCIQD5RLU3SLW5W2LH/
>  )

---
/var/log/mailman3/bounce.log /var/log/mailman3/debug.log 
/var/log/mailman3/plugins.log /var/log/mailman3/smtp.log 
/var/log/mailman3/mailman.log {
daily
rotate 5
compress
delaycompress
missingok
notifempty
create 640 list list
postrotate
if /etc/init.d/mailman3 status >/dev/null; then \
/usr/bin/mailman-wrapper reopen >/dev/null; \
fi;
endscript
}
---

Which has currently resulted in:
---
root@river:/var/log/mailman3;
16:31:17 0$ ls -lart
total 352
-rw-r-  1 list list  0 Aug  8  2020 plugins.log
-rw-r-  1 list list  0 Aug  8  2020 debug.log
-rw-r-  1 list list184 May 16 16:41 bounce.log.5.gz
-rw-r-  1 list list877 May 18 05:02 bounce.log.4.gz
-rw-r-  1 list list278 May 19 22:07 bounce.log.3.gz
-rw-r-  1 list list133 May 20 09:23 bounce.log.2.gz
-rw-r-  1 list list356 May 23 20:48 bounce.log.1
-rw-r-  1 list list  0 May 24 06:25 bounce.log
-rw-r-  1 list list   1238 Jun  3 05:30 smtp.log.5.gz
-rw-r-  1 list list  18977 Jun  3 06:25 mailman.log.5.gz
-rw-r-  1 list list997 Jun  4 04:30 smtp.log.4.gz
-rw-r-  1 list list  18824 Jun  4 06:25 mailman.log.4.gz
drwxr-xr-x 36 root root  16384 Jun  5 02:33 ../
-rw-r-  1 list list   1019 Jun  5 06:25 smtp.log.3.gz
-rw-r-  1 list list  18743 Jun  5 06:25 mailman.log.3.gz
-rw-r-  1 list list781 Jun  6 06:25 smtp.log.2.gz
-rw-r-  1 list list  18652 Jun  6 06:25 mailman.log.2.gz
-rw-r-  1 list list   4336 Jun  7 06:00 smtp.log.1
-rw-r-  1 list list 196373 Jun  7 06:25 mailman.log.1
drwxr-xr-x  2 list list   4096 Jun  7 06:25 ./
-rw-r-  1 list list   2009 Jun  7 15:12 smtp.log
-rw-r-  1 list list   7738 Jun  7 16:00 mailman.log
---

The current last line in smtp.log.1 is timestamped `Jun 07 06:00:10 2023`,
so it doesn't *look* like the upstream bug/fix you linked to affects this
setup.

  But thanks for the heads up.  That fix being from only 4 days ago no
doubt means it won't be in bookworm's packages, at least not at
promotion to stable this weekend.  Hopefully it will be backported in
ASAP.

-- 
- Athanasius (he/him) = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME


signature.asc
Description: PGP signature

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

[Bill Allombert]

On Wed, Jun 07, 2023 at 08:19:08AM -0700, Russ Allbery wrote:
> > In general, policy proscription are only useful when the description of
> > a better mechanism is provided.  But there is no place for that in this
> > section.
> 
> I'm not sure I understand this statement, since describing a better
> mechanism is exactly the point of that language about systemd.  We link
> directly to those better mechanisms (masking, drop-ins, and, for
> alternatives, aliases).

What I meant was that this section in not the right place for systemd or other
software configuration detail, because nobody will look for systemd
configuration detail in the dpkg-divert section.

> I definitely agree that Policy should have a whole section devoted to
> systemd and its configuration files, but I don't want to try to boil the
> ocean in one bug.  But yes, we should be working towards that, IMO.

Yes that what I wanted to say.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Chris Lamb]

Utkarsh,

> I had missed your comment in the bug but super, many thanks for
> testing this out! I'll wait a bit more before I roll this out.

I see your 2.5.5-3+deb10u6 update on the debian/buster branch which
fixes the broken +deb10u5 upload, but I don't see it in the archive
yet.

Although you mentioned you were going to wait a bit more, I'm just
100%-checking you aren't waiting on anything from me to upload that?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1037190: dhcpcd: version is lower than in wheezy

[Martin-Éric Racine]

On Wed, Jun 7, 2023 at 3:58 PM Martin-Éric Racine
 wrote:
>
> On Wed, Jun 7, 2023 at 3:09 PM Andreas Beckmann  wrote:
> >
> > Package: dhcpcd
> > Version: 9.4.1-22
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > wheezy had a dhcpcd binary package built from src:dhcpcd at version
> > 1:3.2.3-11+deb7u1 while bookworm has one built from src:dhcpcd5 at
> > version 9.4.1-22 which is lower, violating the archive property of
> > monotonically increasing version numbers.
>
> You are talking about a version that is even older than what's in
> oldstable.  Sorry, but that really doesn't qualify as
> Severity:serious.
>
> This being said, this is something that is easily fixed by
> re-introducing the epoch. Whether this is really worth the trouble
> given how the discrepancy dates back to something even older than
> oldstable is an entirely different issue.

+dhcpcd (1:3.2.3-11+deb7u1) oldstable-security; urgency=high
+
+  * Fix CVE-2012-6698, CVE-2012-6699, CVE-2012-6700,
+out-of-bound reads/writes and use-after-free issues with specially
+crafted DHCP messages.
+This is a forward port of the patch applied to squeeze-lts since
+wheezy uses the same upstream version. (LP: #1517226)
+
+ -- Guido Günther   Sun, 27 Mar 2016 15:47:43 +0200
+
+dhcpcd (1:3.2.3-11) unstable; urgency=high
+
+* Security fix, remote stack overflow: CVE-2012-2152. (closes: #671265)
+
+ -- Simon Kelley   Thu, 3 May 2012 14:03:12 +

These are the very last uploads I could find that used this epoch. I
really don't think that we're gonna go there.

Martin-Éric

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

[Russ Allbery]

Bill Allombert  writes:
> On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:

>> I prefer that too, but in this case, it feels like must is appropriate
>> for at least systemd configuration files.  And also, just intuitively,
>> I feel like must is correct when people are using diversions rather
>> than a native mechanism.  Diversions add weird edge cases and we really
>> shouldn't be using them lightly.

>> The wording I proposed and that Luca has now adopted therefore uses
>> must with a caveat.  Does that sound okay to you?

> I do not think appropriate for the policy to list systemd or any other
> packages specifically in this section.

My rationale for listing systemd specifically is:

1. This is a common case where one package wants to change the behavior of
   another and I expect it to become increasingly common as people make
   more use of systemd security features. For example, I would expect
   cases where the default systemd configuration for a service disallows
   access to large swaths of the file system, and then installing a plugin
   for that package grants additional access to specific paths used by
   that plugin.

2. We understand what people are trying to do in this case and can offer
   very specific guidance, whereas we can't in general for arbitrary
   packages. This makes Policy more useful for packagers; instead of
   seeing a general rule that they can't use diversions but being left on
   their own to figure out how to solve their problem, Policy can
   explicitly say "here are the mechanisms to use for this case, they can
   do everything you would want to do with diversions."

I would like to add more documentation like this around systemd-related
things to Policy because systemd is complicated and has a lot of options,
so people who aren't deeply familiar with it will easily miss best
practices in its reams of very good but overwhelming documentation, and
Debian should be opinionated about steering people towards best practices
for our primary init system, just as we were very opinionated about how to
write init scripts for sysvinit.

> If a package set up a diversion that breaks another, then it is buggy,
> whatever policy say. If the diversion does not cause any breakage, there
> is no purpose for policy to declare it a RC bug.

I don't really agree with this, and I thought we had reached some
agreement in the other branch of this thread that this isn't quite
complete and it's okay to ban diversions if there's a better mechanism
available.

I think that if diversions and some other mechanism work equally well
technically, we should forbid using diversions and require using the other
mechanism.  This is in part based on the long threads that came out of the
/usr-merge discussions, which made clear that diversions are a very
complicated feature with a lot of edge cases, and it's possible to get
into trouble with them because they're manipulating the packaging system
at a very low level.  If there's some alternative that's less invasive, I
do feel like using diversions is a fairly serious bug because it adds to
the instability of the system.

In isolation, you could talk me into it being an important bug rather than
an RC bug, but that feels like a lot of nuance here and must feels cleaner
and more straightforward.

That being said, I'd rather back down to should than remove the
systemd-specific details, since I think the latter are quite valuable.

> In general, policy proscription are only useful when the description of
> a better mechanism is provided.  But there is no place for that in this
> section.

I'm not sure I understand this statement, since describing a better
mechanism is exactly the point of that language about systemd.  We link
directly to those better mechanisms (masking, drop-ins, and, for
alternatives, aliases).

I definitely agree that Policy should have a whole section devoted to
systemd and its configuration files, but I don't want to try to boil the
ocean in one bug.  But yes, we should be working towards that, IMO.

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

Bug#1037200: please consider backporting valijson to Bullseye

[Pierre Gruet]

Source: valijson
Severity: wishlist

Dear Maintainer,

I would be interested in having a backport of valijson in Bullseye, not only
for me but also for other users I know.

I would happily do it myself if you wish (I am a DD).

Best wishes,

-- 
Pierre

Bug#1037172: unixodbc-common,odbcinst: missing Breaks+Replaces: odbcinst1debian1

[Hugh McMaster]

Hi Andreas,

This is an unexpected bug report.

On Wed, 7 Jun 2023 at 09:39, Andreas Beckmann wrote:

> Package: unixodbc-common,odbcinst
> Version: 2.3.11-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + libsqliteodbc
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'lenny' to 'squeeze' to 'wheezy' to 'jessie' to 'stretch' to 'buster' to
> 'bullseye' to 'bookworm'.
> It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy',
> 'jessie', 'stretch', 'buster', and 'bullseye' successfully,
> but then the upgrade to 'bookworm' failed.
>


Can I ask why you’re testing from Lenny?

And what piuparts command line are you using?


In case the package was not part of an intermediate stable release,
> the version from the preceding stable release was kept installed.
>
> From the attached log (scroll to the bottom...):
>
> ...
>   Selecting previously unselected package unixodbc-common.
>   Preparing to unpack .../22-unixodbc-common_2.3.11-2_all.deb ...
>   Unpacking unixodbc-common (2.3.11-2) ...
>   dpkg: error processing archive
> /tmp/apt-dpkg-install-JsWDst/22-unixodbc-common_2.3.11-2_all.deb (--unpack):
>trying to overwrite '/etc/odbc.ini', which is also in package
> odbcinst1debian1 2.2.11-16
> ...
>   Selecting previously unselected package odbcinst.
>   Preparing to unpack .../25-odbcinst_2.3.11-2_amd64.deb ...
>   Unpacking odbcinst (2.3.11-2) ...
>   dpkg: error processing archive
> /tmp/apt-dpkg-install-JsWDst/25-odbcinst_2.3.11-2_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/odbcinst', which is also in package
> odbcinst1debian1 2.2.11-16
> ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-JsWDst/22-unixodbc-common_2.3.11-2_all.deb
>/tmp/apt-dpkg-install-JsWDst/25-odbcinst_2.3.11-2_amd64.deb
>
> The mentioned Breaks+Replaces may have been there in the past,
> but on some upgrade paths originating in lenny the obsolete packages may
> have survived without being affected by B+R so far.
>
> (In the concrete case, libsqliteodbc/lenny had a dependency on
> odbcinst1debian1, libsqliteodbc/bookworm has a dependency on odbcinst
> while in all releases inbetween there was no pdenedency on an *odbc*
> package at all.)



Wow. odbcinst1debian1 hasn’t existed for years.

We’re only a few days from the release of Bookworm, so this will need to be
fixed in the first point release.

In saying that, the number of users impacted by this upgrade path must be
very small.

Hugh

Bug#1037060: run-with-aspell.1: Fix some formatting issues in the man page

[Agustin Martin]

Control: forwarded -1 https://github.com/GNUAspell/aspell/issues/636
Control: tags -1 + pending forwarded-upstream

El sáb, 3 jun 2023 a las 4:09, Bjarni Ingi Gislason
() escribió:
>
> Package: aspell
> Version: 0.60.8-4+b1
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> here are some fixes.

Thanks, forwarsed upstream and tagged as pending

Regards,

-- 
Agustin

Bug#1037059: aspell.1: fix some formatting issues in the man page

[Agustin Martin]

Control: forwarded -1 https://github.com/GNUAspell/aspell/issues/636
Control: tags -1 + pending forwarded-upstream

El sáb, 3 jun 2023 a las 3:45, Bjarni Ingi Gislason
() escribió:
>
> Package: aspell
> Version: 0.60.8-4+b1
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> here are some fixes.

Thanks, forwarded upstream and tagged as pending.

-- 
Agustin

Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive

[James Addison]

Package: lintian
Followup-For: Bug #1029555
X-Debbugs-Cc: rol...@debian.org

Dear Maintainer,

Please find attached a potential fix for this lintian check bug.

Thanks,
James
>From 9fe45fdcbbc2fef8771cb049822307c5bbbafd15 Mon Sep 17 00:00:00 2001
From: James Addison 
Date: Wed, 7 Jun 2023 15:11:20 +0100
Subject: [PATCH] license-problem-font-adobe-copyrighted-fragment-no-credit:
 previously-checked code is now open source, so check for other,
 non-open-source code from the same publication

---
 lib/Lintian/Check/Fonts/Postscript/Type1.pm | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/lib/Lintian/Check/Fonts/Postscript/Type1.pm 
b/lib/Lintian/Check/Fonts/Postscript/Type1.pm
index 87cbef7c6..de5de8992 100644
--- a/lib/Lintian/Check/Fonts/Postscript/Type1.pm
+++ b/lib/Lintian/Check/Fonts/Postscript/Type1.pm
@@ -90,7 +90,25 @@ sub visit_installed_files {
 # copyright adobe a few line before the only
 # place where the startlock is documented is
 # in the black book copyrighted fragment
-if ($line =~ m/startlock\s*get\s*exec/) {
+#
+# 2023-06-05: this check has been adjusted because
+# Adobe's type hint code[1] (including Flex[2]) became
+# open source[3] with an Apache-2.0 license[4] as
+# committed on 2014-09-19, making that check a false
+# positive[7].
+#
+# We continue to check for copyrighted code that is not
+# available under an open source license from the origin
+# publication,  "Adobe Type 1 Font Format"[5][6].
+#
+# [1] - 
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_hintothers.h
+# [2] - 
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.h
+# [3] - 
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1375813.html
+# [4] - 
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/LICENSE.txt
+# [5] - 
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf
+# [6] - https://lccn.loc.gov/90042516
+# [7] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029555
+if ($line =~ m/UniqueID\s*6859/) {
 
 $self->pointed_hint(
 'license-problem-font-adobe-copyrighted-fragment-no-credit',
-- 
2.39.2

Bug#1037199: evince: Cannot open links in browser due to Apparmor profile

[Ralf Jung]

Package: evince
Version: 43.1-2+b1
Severity: normal

Dear Maintainer,

clicking a link to open things in my browser works in basically all 
applications, except evince. It took me a long whole to realize that this is 
due to apparmor:

Jun 07 15:53:03 r-ethtop audit[1165140]: AVC apparmor="DENIED" operation="exec" 
profile="/usr/bin/evince" name="/home/r/bin/firefox" pid=1165140 
comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000
Jun 07 15:53:03 r-ethtop kernel: audit: type=1400 audit(1686145983.857:133): 
apparmor="DENIED" operation="exec" profile="/usr/bin/evince" 
name="/home/r/bin/firefox" pid=1165140 comm="gio-launch-desk" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000

Looks like this would happen to anyone who set their default browser to 
something they installed themselves as a user rather than using a system 
package.
That's quite surprising and most people will probably never figure out why 
things are broken.

I am still trying to figure out how to work around this, Apparmor seems super 
complicated and I don't have the time to learn it just to fix clicking links in 
a PDF... I'll probably end up just disabling it as that seems like the only 
thing that's reasonably easy to do. :/

Kind regards,
Ralf


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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  evince-common43.1-2
ii  gsettings-desktop-schemas43.0-1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libevdocument3-4 43.1-2+b1
ii  libevview3-3 43.1-2+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgnome-desktop-3-2043.2-2
ii  libgtk-3-0   3.24.37-2
ii  libhandy-1-0 1.8.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libsecret-1-00.20.5-3
ii  shared-mime-info 2.2-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.6-1

Versions of packages evince suggests:
ii  gvfs 1.50.3-1
pn  nautilus-sendto  
ii  poppler-data 0.4.12-1
pn  unrar

-- no debconf information

Bug#1037198: locales: please parallelise locale-gen

[наб]

Package: locales
Version: 2.36-9
Severity: wishlist
Tags: patch

Dear Maintainer,

Posting as a bug per comment from Andrej; originally posted 2022-05-06 as
  https://salsa.debian.org/glibc-team/glibc/-/merge_requests/7

Patch based on current Salsa HEAD attached, incl. analysis.

Best,
наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 locales depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc-bin   2.36-9
ii  libc-l10n  2.36-9

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: en_GB.UTF-8 UTF-8
* locales/default_environment_locale: en_GB.UTF-8
From b6af0ad83f5517fd1987f9c7ac0493565bc0976d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Fri, 6 May 2022 01:22:10 +0200
Subject: [PATCH] Parallelise locale-gen if possible
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mutt-PGP: OS

Assuming a very generous 200M free/localedef (because I saw a max RSS
of 147M w/time(1)), this will attempt to keep all jobs saturated,
and usually succeed. There's little starvation, since the vast majority
of time is spent in gzip(1) ‒ 1:14 user vs 27:55 sys

At 2.2ish seconds per locale, even on a low-end system of today with
4 CPUs (and 800 free MB), we can generate up to 4 locales at once
for 6.6s' speed-up. Assuming no super-pathological cases, this globally
scales in roughly ceil(locales/ncpus)*2.2s chunks, which is a massive
win

The only user-visible change is that, with nproc>1, the output is
  en_GB.UTF-8...
  
instead of
  en_GB.UTF-8... 

MemFree: in /proc/meminfo is available on all supported Debian kernels,
and, indeed, exactly what procps free(1) uses
---
 debian/local/usr_sbin/locale-gen | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/debian/local/usr_sbin/locale-gen b/debian/local/usr_sbin/locale-gen
index 7fa3d772..f1632f4e 100755
--- a/debian/local/usr_sbin/locale-gen
+++ b/debian/local/usr_sbin/locale-gen
@@ -23,6 +23,18 @@ is_entry_ok() {
 	fi
 }
 
+nproc="$(nproc 2>/dev/null)" || nproc=1
+if [ "$nproc" -gt 1 ]; then
+	mem_free=0
+	while read -r k v _; do
+		[ "$k" = "MemFree:" ] && mem_free="$v" && break || :
+	done < /proc/meminfo || :
+	mem_free=$(( mem_free / 1024 / 200 ))
+	[ "$mem_free" -lt 1 ] && mem_free=1 || :
+	[ "$mem_free" -lt "$nproc" ] && nproc="$mem_free" || :
+	jobs=0; pids=
+fi 2>/dev/null
+
 echo "Generating locales (this might take a while)..."
 while read -r locale charset; do
 	if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue; fi
@@ -35,6 +47,7 @@ while read -r locale charset; do
 	locale_at="${locale#*@}"
 	[ "$locale_at" = "$locale" ] && locale_at= || locale_at="@$locale_at"
 	printf "  %s.%s%s..." "$locale_base" "$charset" "$locale_at"
+	[ "$nproc" -gt 1 ] && echo || :
 
 	if [ -e "$USER_LOCALES/$locale" ]; then
 		input="$USER_LOCALES/$locale"
@@ -46,7 +59,20 @@ while read -r locale charset; do
 			input="$USER_LOCALES/$input"
 		fi
 	fi
-	localedef -i "$input" -c -f "$charset" -A /usr/share/locale/locale.alias "$locale" || :
-	echo " done"
+	localedef -i "$input" -c -f "$charset" -A /usr/share/locale/locale.alias "$locale" &
+	if [ "$nproc" -gt 1 ]; then
+		pids="$pids$! "
+		jobs=$(( jobs + 1 ))
+
+		if [ "$jobs" -ge "$nproc" ]; then
+			wait "${pids%% *}" || :
+			jobs=$(( jobs - 1 ))
+			pids="${pids#* }"
+		fi
+	else
+		wait
+		echo " done"
+	fi
 done < "$LOCALEGEN"
+wait
 echo "Generation complete."
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1037164: libwxgtk3.0-gtk3-0v5: wxwidgets not built with XTest support (libxtst6)

[Scott Talbert]

On Tue, 6 Jun 2023, Maxim Cournoyer wrote:


I researched the problem and found that the feature I wanted was implemented
using XTest, which is detected at wxWidgets' build time [1].  Looking at the 
Debian
package dependencies, I found it did *not* depend on the libxtst6 package.


I think it would be okay to enable xtest support even though it doesn't 
work under Wayland.  However, this type of change doesn't seem appropriate 
for a stable release (it's possible it might even cause an ABI change), so 
we'd have to make it unstable after bookworm is released (this weekend?!). 
Thus, the bug should be reassigned to wxwidgets3.2.


Scott

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Schmidt, Bernhard]

Am Mittwoch, dem 07.06.2023 um 18:47 +0530 schrieb Utkarsh Gupta:

Hi,

> > Yep, I'm taking a look to prep something for 2.5.
> 
> I've prepared a fix for the regression and uploaded the binaries at:
> https://people.debian.org/~utkarsh/lts/ruby2.5/
> 
> Can you please give these a try and see if that fixes the regression
> you're seeing?

Looking good!

# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional
resources using 'eval_generate': Failed to open TCP connection to :8140
(Connection refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not
retrieve file metadata for puppet:///pluginfacts: Failed to open TCP
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional
resources using 'eval_generate': Failed to open TCP connection to :8140
(Connection refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not
retrieve file metadata for puppet:///plugins: Failed to open TCP
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Info: Retrieving locales
[..]


# dpkg -i libruby2.5_2.5.5-3+deb10u6_amd64.deb
(Reading database ... 69723 files and directories currently installed.)
Preparing to unpack libruby2.5_2.5.5-3+deb10u6_amd64.deb ...
Unpacking libruby2.5:amd64 (2.5.5-3+deb10u6) over (2.5.5-3+deb10u5) ...
Setting up libruby2.5:amd64 (2.5.5-3+deb10u6) ...
Processing triggers for libc-bin (2.28-10+deb10u2) ...

# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for xxx.lrz.de
Info: Applying configuration version 'master-3a083818c9e2'
Notice: Applied catalog in 3.86 seconds

Bernhard

Bug#990336: This still affects the current bullseye package

[Olivier Berger]

Hi

Le Thu, Jul 28, 2022 at 12:59:18PM +0100, Athanasius a écrit :
>   I've just noticed this myself.  Our smtp.log is from 2020-08-08
> onwards, so almost 2 years worth of logging.  It's 28 MiB in size, so
> not disasterously big.
> 
>   I've added specific rotation of the other logfiles manually for now.
> 

Would you mind sharing the snippet that you used for the logrotate config ?

It seems that maybe the smtp.log file might need special treatment, if I refer 
to the discussion at https://gitlab.com/mailman/mailman/-/issues/931 (following 
https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/RRFWGZY56OHAXPRCIQD5RLU3SLW5W2LH/
 )

Hope this helps,

Best regards,
-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#1037197: snapd: applications installed via snap don't appear in the desktop launcher like on derivatives

[jordan]

Package: snapd
Version: 2.49-1+deb11u2
Severity: important
X-Debbugs-Cc: jordanlives...@gmail.com

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)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** 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/6 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  gnupg2.2.27-2+deb11u2
ii  libapparmor1 2.13.6-10
ii  libc62.31-13+deb11u6
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libudev1 247.3-7+deb11u2
ii  openssh-client   1:8.4p1-5+deb11u1
ii  squashfs-tools   1:4.4-2+deb11u2
ii  systemd  247.3-7+deb11u2
ii  udev 247.3-7+deb11u2

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2+deb11u2

Versions of packages snapd suggests:
ii  zenity  3.32.0-6

-- no debconf information

Bug#1037196: bullseye-pu: package dbus/1.12.28-0+deb11u1

[Cyril Brulebois]

Simon McVittie  (2023-06-07):
> Technically dbus has udebs, although as noted in the similar bookworm
> update request, they aren't directly useful for anything.

I only glanced at the discussion that happened a few hours/days ago on
IRC, but that seemed compelling. No objections from the d-i side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Utkarsh Gupta]

Hi Kees,

On Wed, Jun 7, 2023 at 6:53 PM Kees Meijs | Nefos  wrote:
> I know you were asking Bernhard, but I downloaded and installed as well.
> Our Puppet agent seems to be happy again.

I had missed your comment in the bug but super, many thanks for
testing this out! I'll wait a bit more before I roll this out.

There's also CVE-2021-33621 and CVE-2022-28739 open for ruby2.5 in
buster, I'll try to include the fixes in this update, too.


- u

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Kees Meijs | Nefos]

Hi Utkarsh,

Many thanks from our end.

I know you were asking Bernhard, but I downloaded and installed as well. 
Our Puppet agent seems to be happy again.


Cheers,
Kees

On 07-06-2023 15:17, Utkarsh Gupta wrote:

I've prepared a fix for the regression and uploaded the binaries at:
https://people.debian.org/~utkarsh/lts/ruby2.5/

Can you please give these a try and see if that fixes the regression
you're seeing?

Bug#1037196: bullseye-pu: package dbus/1.12.28-0+deb11u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:dbus

[ Reason ]
Fix a local denial of service for which the security team does not intend
to do a DSA (dbus#457, #1037151; CVE assignment pending).

[ Impact ]
While a sysadmin is using `dbus-monitor --system` or similar tools,
an unprivileged local user can cause denial of service by crashing the
`dbus-daemon --system`.

The new upstream release also fixes some smaller bugs:
- fix a denial of service that wasn't relevant for the way Debian compiles
  dbus (it was only a problem when assertions are enabled)
- an autopkgtest regression on Ubuntu kernels
- wrong upstream bug reporting URLs
- a documentation typo

[ Tests ]
Build-time tests and autopkgtests pass. There is new test coverage for the
denial of service, which was able to reproduce the bug. I also smoke-tested
this on a GNOME virtual machine; I already upgraded my real-hardware
systems to bookworm, so I can't directly test this on hardware.

[ Risks ]
It's a key package, so any regressions would be highly visible.

Technically dbus has udebs, although as noted in the similar bookworm
update request, they aren't directly useful for anything.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable
  - intentionally not done yet due to the full freeze, because dbus
has udebs

[ Changes ]
bus/connection.c: fix the denial of service, #1037151
dbus/dbus-connection{.c,-internal.h}: enablers for #1037151
dbus/dbus-string.c: fix a local denial of service if assertions are
enabled in the dbus-daemon, which in Debian they are not
doc/dbus-api-design.duck: fix a typo in some sample code, not functionally
significant
configure.ac, dbus/dbus-sysdeps-unix.c: update bug reporting URLs
AUTHORS, NEWS, configure.ac: release administrivia
test/data/dbus-installed-tests.aaprofile.in: make a test profile a little
more permissive to fix an autopkgtest regression on Ubuntu kernels
test/data/valid-config-files, test/monitor.c: reproducer for the denial
of service bug

smcv
debdiff *.dsc | filterdiff -p1 -xaminclude_static.am -xMakefile.in -x'*/Makefile.in' -xconfigure

diffstat for dbus-1.12.24 dbus-1.12.28

 AUTHORS |4 +
 Makefile.in |2 
 NEWS|   54 +++
 aminclude_static.am |2 
 build-aux/ltmain.sh |4 -
 bus/Makefile.in |2 
 bus/connection.c|   15 
 configure   |   36 +-
 configure.ac|6 -
 dbus/Makefile.in|2 
 dbus/dbus-connection-internal.h |2 
 dbus/dbus-connection.c  |   11 ++-
 dbus/dbus-string.c  |2 
 dbus/dbus-sysdeps-unix.c|2 
 debian/changelog|   13 +++
 doc/dbus-api-design.duck|4 -
 test/Makefile.in|2 
 test/data/dbus-installed-tests.aaprofile.in |4 +
 test/data/valid-config-files/forbidding.conf.in |3 
 test/monitor.c  |   84 +---
 20 files changed, 212 insertions(+), 42 deletions(-)

diff -Nru dbus-1.12.24/AUTHORS dbus-1.12.28/AUTHORS
--- dbus-1.12.24/AUTHORS	2022-10-05 11:04:10.0 +0100
+++ dbus-1.12.28/AUTHORS	2023-06-06 14:00:50.0 +0100
@@ -40,6 +40,7 @@
 Daniel P. Berrange 
 Daniel Reed 
 Dan Williams 
+Dave Jones 
 Dave Reisner 
 David King 
 David Zeuthen 
@@ -65,6 +66,7 @@
 Havoc Pennington 
 Havoc Pennington 
 Hendrik Buschmeier 
+hongjinghao 
 hyeric 
 ilovezfs 
 Ioan-Adrian Ratiu 
@@ -113,6 +115,7 @@
 Marc Brockschmidt 
 Marc Mutz 
 Marc Mutz 
+Marco Trevisan (Treviño) 
 Marcus Brinkmann 
 Mark Brand 
 Mark McLoughlin 
@@ -215,6 +218,7 @@
 Wulf C. Krueger 
 Xan Lopez 
 Yaakov Selkowitz 
+Yen-Chin, Lee 
 Yiyang Fei 
 Zack Rusin 
 Илья А. Ткаченко 
diff -Nru dbus-1.12.24/build-aux/ltmain.sh dbus-1.12.28/build-aux/ltmain.sh
--- dbus-1.12.24/build-aux/ltmain.sh	2022-10-05 11:04:51.0 +0100
+++ dbus-1.12.28/build-aux/ltmain.sh	2023-06-06 12:05:06.0 +0100
@@ -31,7 +31,7 @@
 
 PROGRAM=libtool
 PACKAGE=libtool
-VERSION="2.4.7 Debian-2.4.7-4"
+VERSION="2.4.7 Debian-2.4.7-5"
 package_revision=2.4.7
 
 
@@ -2308,7 +2308,7 @@
compiler:   $LTCC
compiler flags: $LTCFLAGS
linker: $LD (gnu? $with_gnu_ld)
-   version:$progname 

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Utkarsh Gupta]

Hi Bernhard,

On Wed, Jun 7, 2023 at 4:16 PM Utkarsh Gupta  wrote:
> Yep, I'm taking a look to prep something for 2.5.

I've prepared a fix for the regression and uploaded the binaries at:
https://people.debian.org/~utkarsh/lts/ruby2.5/

Can you please give these a try and see if that fixes the regression
you're seeing?


- u

Bug#1037194: bookworm-pu: package dbus/1.14.8-1~deb12u1

[Cyril Brulebois]

Simon McVittie  (2023-06-07):
> Technically dbus has udebs, although as noted above they are not
> directly useful for anything.

I only glanced at the discussion that happened a few hours/days ago on
IRC, but that seemed compelling. No objections from the d-i side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1037195: dash: $(here-doc in <

[наб]

Package: dash
Version: 0.5.11+git20200708+dd9ef66-5
Version: 0.5.12-2
Severity: normal

Dear Maintainer,

bullseye bash as well as bullseye, sid, and git dash observe the following:
  $ cat -n boment
1  echo "$(head -n1 < and continues until there is a line containing only the 
delimiter and a , with no  characters in between. Then the next 
here-document starts, if there is one. The format is as follows:
and its counterpart in Issue 8 Draft 3
  80601  2.7.4 Here-Document
  80602  The redirection operators "<<" and "<<-" both allow redirection of 
subsequent lines read by
  80603  the shell to the input of a command. The redirected lines are known as 
a ``here-document’’.
  80604  The here-document shall be treated as a single word that begins after 
the next NEWLINE token 
  80605  and continues until there is a line containing only the delimiter and 
a , with no
  80606   characters in between. Then the next here-document starts, if 
there is one. For the
  80607  purposes of locating this terminating line, the end of a 
command_string operand (see sh) shall be
  80608  treated as a  character, and the end of the commands string 
in $(commands) and 
  80609  `commands` may be treated as a . If the end of input is 
reached without finding the
  80610  terminating line, the shell should, but need not, treat this as a 
redirection error. The format is as
  80611  follows:

That is, as I understand it:
  echo "$(head -n1 <

signature.asc
Description: PGP signature

Bug#1037194: bookworm-pu: package dbus/1.14.8-1~deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:dbus

[ Reason ]
Fix a local denial of service for which the security team does not intend
to do a DSA (dbus#457, #1037151; CVE assignment pending).

[ Impact ]
While a sysadmin is using `dbus-monitor --system` or similar tools,
an unprivileged local user can cause denial of service by crashing the
`dbus-daemon --system`.

The new upstream release also fixes some smaller bugs:
- minor memory leaks if malloc() returns NULL
- interop with non-Debian compilers
- a documentation typo

The packaging also makes dbus-daemon and dbus-bin correctly Multi-Arch:
foreign, like the larger dbus package already was, which is useful in
some cross-compiling scenarios (#1033056). I can revert this if you want,
but it seems like a low-risk and useful change to sneak into 12.1.

[ Tests ]
Build-time tests and autopkgtests pass. There is new test coverage for the
denial of service, which was able to reproduce the bug. I also smoke-tested
this on a GNOME virtual machine, and I'll be uploading to unstable to get
wider user testing as soon as the trixie cycle opens.

I avoided uploading to unstable right now because one of dbus' udebs
is included in the installer - although as far as I can see, it's only
an enabler for a feature that never happened (a11y in the graphical
installer), and isn't actually practically useful.

[ Risks ]
It's a key package, so any regressions would be highly visible.

Technically dbus has udebs, although as noted above they are not directly
useful for anything.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  - the debdiff is for what I'll upload to unstable, for bookworm
it'll get a new 1.14.8-1~deb12u1 changelog entry at the top
  [ ] the issue is verified as fixed in unstable
  - intentionally not done yet due to the full freeze

[ Changes ]
d/control: let dbus-bin:amd64 satisfy Depends: dbus-bin from a non-amd64
package, and the same for dbus-daemon, to help with cross-compiling
bus/connection.c: fix the denial of service, #1037151
dbus/dbus-connection{.c,-internal.h}: enablers for #1037151
dbus/dbus-internals.h: interop with non-gcc compilers
dbus/dbus-*-win.c: interop with non-gcc compilers, not compiled on Debian
dbus/dbus-message.c: fix minor memory leaks if out-of-memory
doc/dbus-api-design.duck: fix a typo in some sample code, not functionally
significant
AUTHORS, NEWS, configure.ac: release administrivia
test/data, test/monitor.c: reproducer for the denial of service bug

[ Other info ]
I'm the de facto upstream release manager for dbus, and I intend to keep
1.14.x suitable for Debian security updates and stable point releases
throughout the non-LTS lifetime of Debian 12, the same as I did for
older branches for the last few years.

After the packaging in unstable diverges from what's appropriate for
stable, I'll do the stable updates as 1.14.x-0+deb12u1, similar to how
we handled 1.12.x in buster and bullseye.

Please let me know if any of the changes are considered inappropriate.

smcv
debdiff *.dsc | filterdiff -p1 -xaminclude_static.am -xMakefile.in -x'*/Makefile.in' -xconfigure

diffstat for dbus-1.14.6 dbus-1.14.8

 AUTHORS |9 ++
 Makefile.in |2 
 NEWS|   29 
 aminclude_static.am |2 
 bus/Makefile.in |2 
 bus/connection.c|   15 
 cmake/DBus1ConfigVersion.cmake  |2 
 configure   |   26 +++
 configure.ac|4 -
 dbus/Makefile.in|2 
 dbus/dbus-connection-internal.h |2 
 dbus/dbus-connection.c  |   11 ++-
 dbus/dbus-internals.h   |2 
 dbus/dbus-message.c |   12 ++-
 dbus/dbus-spawn-win.c   |8 +-
 dbus/dbus-sysdeps-win.c |4 -
 debian/changelog|   14 
 debian/control  |2 
 doc/dbus-api-design.duck|4 -
 test/Makefile.in|2 
 test/data/valid-config-files/forbidding.conf.in |3 
 test/monitor.c  |   84 +---
 22 files changed, 197 insertions(+), 44 deletions(-)

diff -Nru dbus-1.14.6/AUTHORS dbus-1.14.8/AUTHORS
--- dbus-1.14.6/AUTHORS	2022-10-05 11:03:53.0 +0100
+++ dbus-1.14.8/AUTHORS	2023-06-06 14:00:36.0 +0100

Bug#1037190: dhcpcd: version is lower than in wheezy

[Martin-Éric Racine]

On Wed, Jun 7, 2023 at 3:09 PM Andreas Beckmann  wrote:
>
> Package: dhcpcd
> Version: 9.4.1-22
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> wheezy had a dhcpcd binary package built from src:dhcpcd at version
> 1:3.2.3-11+deb7u1 while bookworm has one built from src:dhcpcd5 at
> version 9.4.1-22 which is lower, violating the archive property of
> monotonically increasing version numbers.

You are talking about a version that is even older than what's in
oldstable.  Sorry, but that really doesn't qualify as
Severity:serious.

This being said, this is something that is easily fixed by
re-introducing the epoch. Whether this is really worth the trouble
given how the discrepancy dates back to something even older than
oldstable is an entirely different issue.

Martin-Éric

Bug#1037193: sddm-greeter crashes during first boot (black screen is shown) on openQA

[Roland Clobus]

Package: sddm
Version: 0.19.0-5
Severity: normal
X-Debbugs-Cc: p...@hands.com

Hello maintainers of sddm-greeter,

During automated testing of the d-i netinst image on openQA [1], the following
issue was found:

After the installation was completed and the virtual machine (2 GB memory, QXL
video driver) was rebooted, instead of the login screen, the screen stays
black. This only happens when booting via BIOS, when the installer was booted
with UEFI [2], everything works as expected.
On the openQA instance that I'm running locally, all works fine too.

This issue looks similar to #8087770, #839236 and #1016050

I've been able to extract and resolve a crash-dump, see attachment.
More logs can be found in the openQA page [3] (I've placed the coredump in [4])

My guess is that the issue probably depends on the hardware that is running
qemu.
If you want to have access to the machine while the bug is present, please
contact me, I can grant you access to the running VM.

Please ignore all following automated system information, this report is
generated on my own computer, not the affected VM. The information about the VM
can be found in [3].

With kind regards,
Roland Clobus

[1] https://openqa.debian.net/tests/154041
Breadcrumb (in case the link expires):
Debian (amd64) | Build20230607_0454-testing-amd64 | the red bubble in the
line of 'kde'
[2] https://openqa.debian.net/tests/154042

[3] https://openqa.debian.net/tests/154122#downloads
[4] https://openqa.debian.net/tests/154122/file/_graphical_wait_login-
var_log.tar.gz


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

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

Versions of packages sddm depends on:
ii  adduser   3.133
ii  debconf [debconf-2.0] 1.5.82
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libpam0g  1.5.2-6
ii  libqt5core5a  5.15.8+dfsg-8
ii  libqt5dbus5   5.15.8+dfsg-8
ii  libqt5gui55.15.8+dfsg-8
ii  libqt5network55.15.8+dfsg-8
ii  libqt5qml55.15.8+dfsg-3
ii  libqt5quick5  5.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  libsystemd0   252.6-1
ii  libxcb-xkb1   1.15-1
ii  libxcb1   1.15-1
ii  qml-module-qtquick2   5.15.8+dfsg-3
ii  tigervnc-standalone-server [xserver]  1.12.0+dfsg-8
ii  x11-common1:7.7+23
ii  xauth 1:1.1.2-1
ii  xserver-xephyr [xserver]  2:21.1.7-3
ii  xserver-xorg [xserver]1:7.7+23

Versions of packages sddm recommends:
ii  libpam-systemd 252.6-1
pn  sddm-theme-debian-breeze | sddm-theme  

Versions of packages sddm suggests:
pn  libpam-kwallet5   
pn  qtvirtualkeyboard-plugin  
PID 871 - core
TID 913:
#0  0x7f1a526a9ccc
#1  0x7f1a5265aef2 raise
#2  0x7f1a52645472 abort
#3  0x7f1a39c8bbeb llvm::report_fatal_error(llvm::Twine const&, bool)
#4  0x7f1a39c8ba36 llvm::report_fatal_error(char const*, bool)
#5  0x7f1a3c8f15ab 
llvm::X86Subtarget::initSubtargetFeatures(llvm::StringRef, llvm::StringRef, 
llvm::StringRef)
#6  0x7f1a3c8f184a llvm::X86Subtarget::X86Subtarget(llvm::Triple const&, 
llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::X86TargetMachine 
const&, llvm::MaybeAlign, unsigned int, unsigned int)
#7  0x7f1a3c8f2f3e llvm::X86TargetMachine::getSubtargetImpl(llvm::Function 
const&) const
#8  0x7f1a3c8f30a5 
llvm::X86TargetMachine::getTargetTransformInfo(llvm::Function const&) const
#9  0x7f1a3b90e6ad std::_Function_handler::_M_invoke(std::_Any_data const&, llvm::Function const&)
#10 0x7f1a3b2d2c0e llvm::TargetIRAnalysis::run(llvm::Function const&, 
llvm::AnalysisManager&)
#11 0x7f1a3a82f11b llvm::detail::AnalysisPassModel::Invalidator>::run(llvm::Function&, 
llvm::AnalysisManager&)
#12 0x7f1a39ed1530 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&)
#13 0x7f1a3b081f59 llvm::AssumptionAnalysis::run(llvm::Function&, 
llvm::AnalysisManager&)
#14 0x7f1a3a82da71 llvm::detail::AnalysisPassModel::Invalidator>::run(llvm::Function&, 
llvm::AnalysisManager&)
#15 0x7f1a39ed1530 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&)
#16 0x7f1a3acfc3fa llvm::SROAPass::run(llvm::Function&, 
llvm::AnalysisManager&)
#17 0x7f1a3cae2e0d 

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

[Luca Boccassi]

On Wed, 7 Jun 2023 12:23:15 +0200 Bill Allombert 
wrote:
> On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
> > Sean Whitton  writes:
> > 
> > > I think what's a bit peculiar here is using "must" for a case
where
> > > there might be package-specific exceptions.  In other cases,
Policy uses
> > > "should" for these cases.  Typically "must" rules are simple and
> > > completely determinate.
> > 
> > I prefer that too, but in this case, it feels like must is
appropriate for
> > at least systemd configuration files.  And also, just intuitively,
I feel
> > like must is correct when people are using diversions rather than a
native
> > mechanism.  Diversions add weird edge cases and we really shouldn't
be
> > using them lightly.
> > 
> > The wording I proposed and that Luca has now adopted therefore uses
must
> > with a caveat.  Does that sound okay to you?
> 
> I do not think appropriate for the policy to list systemd or any
> other packages specifically in this section.

There are already mentions of systemd and unit files in policy before
this change, in other sections. For what reason are those fine and this
is not?

> If a package set up a diversion that breaks another, then it is
buggy,
> whatever policy say. If the diversion does not cause any breakage,
there is
> no purpose for policy to declare it a RC bug.

Earlier you wrote:

> Policy is for promoting interoperability and documenting current
practices.

This is what this change is doing - promoting interoperability by
forbidding known broken and unsupported practices, and instead steering
toward known working and supported practices. It also documents what
the current practice w.r.t. overriding and aliasing is as of Bookworm.

> In general, policy proscription are only useful when the description
of a
> better mechanism is provided.  But there is no place for that in this
section.

It is explained how to use a better mechanism? With links to all the
relevant documentation et cetera. Are you saying it's not exhaustive
enough and you want more details added? I am wary of excessively
redefining and duplicating existing documentation, especially because
it will naturally evolve (in backward-compatible ways) and any such
copy would get out of date and be confusing. 

-- 
Kind regards,
Luca Boccassi


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

Bug#1037191: nfs-ganesha: nfs client: cannot be accessed, operation not allowed

[Miquel Gual Torner]

Package: nfs-ganesha
Version: 4.3-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   I'm trying to migrate my servers with nfs-kernel-server to nfs-ganesha
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 It is a new installation
   * What was the outcome of this action?
   * What outcome did you expect instead?

It is a privileged lxc container that runs on top of proxmox

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


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

Kernel: Linux 5.15.74-1-pve (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ca_ES.UTF-8), LANGUAGE=ca_ES.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nfs-ganesha depends on:
ii  dbus  1.14.6-1
ii  libacl1   2.3.1-3
ii  libblkid1 2.38.1-5+b1
ii  libc6 2.36-9
ii  libcap2   1:2.66-4
ii  libcom-err2   1.47.0-2
ii  libdbus-1-3   1.14.6-1
ii  libgssapi-krb5-2  1.20.1-2
ii  libkrb5-3 1.20.1-2
ii  libnfsidmap1  1:2.6.2-4
ii  libntirpc4.3  4.3-2
ii  liburcu8  0.13.2-1
ii  libuuid1  2.38.1-5+b1
ii  libwbclient0  2:4.17.8+dfsg-2
ii  nfs-common1:2.6.2-4
ii  rpcbind   1.2.6-6+b1

nfs-ganesha recommends no packages.

nfs-ganesha suggests no packages.

-- Configuration Files:
/etc/ganesha/ganesha.conf changed:
LOG {
COMPONENTS {
NFS4 = FULL_DEBUG;
IDMAPPER = Full_Debug;
}
}
EXPORT
{
  Export_Id = 1 ;
  Path = "/srv/PVE" ;
  Pseudo = "/srv/PVE";
  protocols = 3,4 ;
  # Error protocols = "3,4" ;
  #SecType = "sys";
  #SecType = sys, krb5;
  squash = none;
  access_type = rw;
  FSAL
  {
  name = VFS;
  }
}
-- no debconf information


##
# NFS Client #
##

root@et089601:~# mount | grep template-mount
172.20.10.107:/srv/PVE on /tmp/template-mount type nfs4 
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.20.11.39,local_lock=none,addr=172.20.10.107)
root@et089601:~# ls/tmp/template-mount/
ls: cannot access '/tmp/template-mount/': Operation not permitted

##
# NFS server #
##

12.0 root@template-server:/home/mgual# cat /var/log/ganesha/ganesha.log
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2904[main] init_logging :LOG :NULL :LOG: Setting log level for all 
components to NIV_EVENT
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2904[main] main :MAIN :EVENT :ganesha.nfsd Starting: Ganesha 
Version 4.3
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] load_rados_config :CONFIG :WARN :Missing RADOS URLs 
backend library
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] SetComponentLogLevel :LOG :NULL :LOG: Changing log 
level of COMPONENT_NFS_V4 from NIV_EVENT to NIV_FULL_DEBUG
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] SetComponentLogLevel :LOG :NULL :LOG: Changing log 
level of COMPONENT_IDMAPPER from NIV_EVENT to NIV_FULL_DEBUG
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] nfs_set_param_from_conf :NFS STARTUP :EVENT 
:Configuration file successfully parsed
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] init_fds_limit :INODE LRU :EVENT :Setting the 
system-imposed limit on FDs to 524288.
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] init_server_pkgs :NFS STARTUP :EVENT :Initializing ID 
Mapper.
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] init_server_pkgs :NFS STARTUP :EVENT :ID Mapper 
successfully initialized.
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] nfs_start_grace :STATE :EVENT :NFS Server Now IN GRACE, 
duration 90
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] nfs_start_grace :STATE :EVENT :grace reload client info 
completed from backend
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] nfs_try_lift_grace :STATE :EVENT :check grace:reclaim 
complete(0) clid count(1)
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] lower_my_caps :NFS STARTUP :EVENT :CAP_SYS_RESOURCE was 
successfully removed for proper quota management in FSAL
07/06/2023 13:37:05 : epoch 64806be1 : template-server : 
ganesha.nfsd-2905[main] lower_my_caps :NFS STARTUP :EVENT :currently set 
capabilities are: =ep 

Bug#1037192: sd: version is lower than in squeeze

[Andreas Beckmann]

Package: sd
Version: 0.7.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

squeeze had a sd binary package built from (unrelated) src:sd at
version 0.74-1 while bookworm has one built from src:rust-sd at
version 0.7.6-1 which is lower, violating the archive property of
monotonically increasing version numbers.

The highest version of src:sd ever seen in the archive seems to be
0.75-1.

Andreas

Bug#1037190: dhcpcd: version is lower than in wheezy

[Andreas Beckmann]

Package: dhcpcd
Version: 9.4.1-22
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

wheezy had a dhcpcd binary package built from src:dhcpcd at version
1:3.2.3-11+deb7u1 while bookworm has one built from src:dhcpcd5 at
version 9.4.1-22 which is lower, violating the archive property of
monotonically increasing version numbers.


Andreas

Bug#1037189: needrestart: Use of uninitialized value $processor in concatenation (.) or string at /usr/share/perl5/NeedRestart/uCode.pm line 61.

[Renato Gallo]

Use of uninitialized value $processor in concatenation (.) or string at
/usr/share/perl5/NeedRestart/uCode.pm line 61.
[ucode] # did not get available microcode version
[uCode/AMD] #0 cpuid 0x00a50f00 (/dev/cpu/0/cpuid)
[uCode/AMD] #0 cpuid 0x00a50f00 (/proc/cpuinfo)
[uCode/AMD] #0 running ucode 0x0a5c
[uCode/AMD] cpuid 0x00100f80: found processor id 0x1080
[uCode/AMD] cpuid 0x00100f81: found processor id 0x1081
[uCode/AMD] cpuid 0x00100f62: found processor id 0x1062
[uCode/AMD] cpuid 0x00100f23: found processor id 0x1022
[uCode/AMD] cpuid 0x00100f43: found processor id 0x1043
[uCode/AMD] cpuid 0x00100f91: found processor id 0x1081
[uCode/AMD] cpuid 0x00100f2a: found processor id 0x1020
[uCode/AMD] cpuid 0x00100f63: found processor id 0x1043
[uCode/AMD] cpuid 0x00100f42: found processor id 0x1041
[uCode/AMD] cpuid 0x00300f10: found processor id 0x3010
[uCode/AMD] cpuid 0x00200f31: found processor id 0x2031
[uCode/AMD] cpuid 0x00100f52: found processor id 0x1041
[uCode/AMD] cpuid 0x00100fa0: found processor id 0x10a0
[uCode/AMD] cpuid 0x00100f53: found processor id 0x1043
[uCode/AMD] cpuid 0x00100f22: found processor id 0x1022
[uCode/AMD] cpuid 0x00500f10: found processor id 0x5010
[uCode/AMD] cpuid 0x00500f20: found processor id 0x5020
[uCode/AMD] processor id 0x1022: available ucode 0x0183
[uCode/AMD] processor id 0x1020: available ucode 0x0184
[uCode/AMD] processor id 0x1062: available ucode 0x01c7
[uCode/AMD] processor id 0x1043: available ucode 0x01c8
[uCode/AMD] processor id 0x1081: available ucode 0x01d9
[uCode/AMD] processor id 0x1080: available ucode 0x01da
[uCode/AMD] processor id 0x1041: available ucode 0x01db
[uCode/AMD] processor id 0x10a0: available ucode 0x01dc
[uCode/AMD] processor id 0x2031: available ucode 0x0232
[uCode/AMD] processor id 0x3010: available ucode 0x0327
[uCode/AMD] processor id 0x5010: available ucode 0x0529
[uCode/AMD] processor id 0x5020: available ucode 0x05000119
[uCode/AMD] cpuid 0x00600f20: found processor id 0x6020
[uCode/AMD] cpuid 0x00610f01: found processor id 0x6101
[uCode/AMD] cpuid 0x00600f12: found processor id 0x6012
[uCode/AMD] processor id 0x6012: available ucode 0x0600063e
[uCode/AMD] processor id 0x6020: available ucode 0x06000852
[uCode/AMD] processor id 0x6101: available ucode 0x06001119
[uCode/AMD] cpuid 0x00700f01: found processor id 0x7001
[uCode/AMD] processor id 0x7001: available ucode 0x0700010f
[uCode/AMD] cpuid 0x00800f82: found processor id 0x8082
[uCode/AMD] cpuid 0x00800f12: found processor id 0x8012
[uCode/AMD] cpuid 0x00830f10: found processor id 0x8310
[uCode/AMD] processor id 0x8082: available ucode 0x0800820d
[uCode/AMD] processor id 0x8012: available ucode 0x0800126e
[uCode/AMD] processor id 0x8310: available ucode 0x08301072
[uCode/AMD] cpuid 0x00a00f10: found processor id 0xa010
[uCode/AMD] cpuid 0x00a00f11: found processor id 0xa011
[uCode/AMD] cpuid 0x00a00f12: found processor id 0xa012
[uCode/AMD] processor id 0xa010: available ucode 0x0a001078
[uCode/AMD] processor id 0xa011: available ucode 0x0a0011ce
[uCode/AMD] processor id 0xa012: available ucode 0x0a001231
Use of uninitialized value $processor in concatenation (.) or string at
/usr/share/perl5/NeedRestart/uCode.pm line 61.
[ucode] # did not get available microcode version
[Kernel] Linux: kernel release 6.4.0-rc5, kernel version #1 SMP
PREEMPT_DYNAMIC Mon Jun 5 09:41:58 CEST 2023
[Kernel/Linux] /boot/vmlinuz-6.4.0-rc5 => 6.4.0-rc5 (root@ghost) #1 SMP
PREEMPT_DYNAMIC Mon Jun 5 09:41:58 CEST 2023 [6.4.0-rc5]*
[Kernel/Linux] /boot/vmlinuz-6.4.0-rc4 => 6.4.0-rc4 (root@ghost) #1 SMP
PREEMPT_DYNAMIC Mon May 29 09:03:11 CEST 2023 [6.4.0-rc4]
[Kernel/Linux] /boot/vmlinuz-6.3.1 => 6.3.1 (root@ghost) #1 SMP
PREEMPT_DYNAMIC Mon May 1 06:15:59 CEST 2023 [6.3.1]
[Kernel/Linux] Expected linux version: 6.4.0-rc5

Running kernel seems to be up-to-date.

Failed to check for processor microcode upgrades.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this
host.


On Wed, 2023-06-07 at 13:32 +0200, Renato Gallo wrote:
> Package: needrestart
> Version: 3.6-4
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>    * What led up to the situation?
> enabled verbose on needrestart config because it fails to
> update my amd cpu microcode
>     launched apt-get full-upgrade
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  I've googled it
>    * What was the outcome of this action?
>  haven't found a suitable solution
>    * What outcome did you expect instead?
>  I want the error to 

Bug#1037133: Subfolders unavailable in Settings

[Lukáš Svoboda]

This may be an upstream bug in version 2.11, because I observe the same 
behavior in Ubuntu 23.04, which contains the same version of the 
owncloud-client package. Upstream version 4.0.0 does not exhibit this bug.


L.

Bug#1035089: Release Notes: Unknown reference "newreleasename"

[Martin Bagge / brother]

Hi

Noticed that  was added in the upgrading section of the 
release notes (looks to be introduced via #1035089) and I can parse that 
(or can I?) but make validate does not pass clean with it.


brother@janmayen:~/git/other/debian/release-notes (master *)$ LC_ALL=C 
make validate LINGUA=sv

xmllint --nonet --noout --postvalid --xinclude sv/release-notes.dbk
sv/upgrading.dbk:463: parser error : Entity 'newreleasename' not defined
. I och med att sv/release-notes.dbk:389: element link: validity error : Element link 
does not carry attribute linkend
sv/release-notes.dbk:389: element link: validity error : No declaration 
for attribute linked of element link
sv/release-notes.dbk:1458: element section: validity error : ID dummy 
already defined
sv/release-notes.dbk:637: element section: validity error : ID dummy 
already defined

Document sv/release-notes.dbk does not validate
make: *** [Makefile:287: validate] Error 3

I'll leave it as is in my translation, it seems to be what others are 
doing as well looking at the git log.


--
brother

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Cyril Brulebois]

Hi,

Hector Oron  (2023-06-07):
> El mié, 7 jun 2023, 13:03, Cyril Brulebois  escribió:
> 
> > Hector Oron  (2023-06-07):
> > > and Timonthy was able to test that. I could expand the change to ppc64
> > > (be) and cdrom targets and test that.
> > >
> > > Note, the ppc64el installer images are unusable with that change, at
> > > least on the Raptor systems
> >
> > I don't think you answered my question about fbdev.
> >
> 
> I defer to Timothy since I do not have a machine myself, but since Raptorcs
> is Debian partner I had assumed we - Debian - would like to ship a working
> product that works for them.

I'm happy to help. That just needs to happen *before* final preparations
have happened!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1037189: needrestart: Use of uninitialized value $processor in concatenation (.) or string at /usr/share/perl5/NeedRestart/uCode.pm line 61.

[Renato Gallo]

Package: needrestart
Version: 3.6-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
enabled verbose on needrestart config because it fails to update my amd 
cpu microcode
launched apt-get full-upgrade
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I've googled it
   * What was the outcome of this action?
 haven't found a suitable solution
   * What outcome did you expect instead?
 I want the error to disappear and my AMD Ryzen 9 5000 series microcode 
updated
*** End of the template - remove these template lines ***


-- Package-specific info:
needrestart output:
Your outdated processes:
anydesk[9035, 9184], at-spi2-registr[8898], blueman-applet[9038], 
caffeine[9141], chrome[65551, 12366, 1396352, 1466342, 306806, 65504, 1888553, 
11865, 65740, 2174719, 12339, 1911276, 253802, 2103640, 565240, 1815117, 12270, 
65949, 1732883, 2080383, 1813307, 12431, 9368, 11888, 1015838, 359719, 12354, 
1109630, 65876, 1857064, 9146, 65810, 9375, 12448, 12384, 1971982, 2205581, 
65884, 65826, 9428, 1706635, 1892074, 65620, 1815143, 2205589, 1708387, 65773, 
65762, 12410, 65511, 65838, 11862, 2022616, 1629560, 65517, 2092060, 2105595, 
797176, 65818, 1396375], dbus-daemon[8305, 8690], evolution-alarm[9020], 
evolution-sourc[8814], filezilla[9171], gedit[9033], gjs[9000, 8839, 13277], 
gnome-session-b[8712, 8556], gnome-shell[8731], goa-daemon[8396], 
gsd-color[8912], gsd-keyboard[8920], gsd-media-keys[8923], gsd-power[8926], 
gsd-print-notif[8931], gsd-printer[9051], gsd-sound[8949], gsd-wacom[8952], 
gsd-xsettings[8960], gvfsd-dnssd[11790], ibus-extension-[9008], ibus-x11[9010], 
jetbrains-toolb[9011], kalendarac[9148], kdeconnectd[9005], obexd[11918], 
parcellite[9162], pipewire[8294, 8293], pipewire-pulse[8299], thnuclnt[33964, 
33959, 33961, 33981, 33962], tilix[9024], vmware[9068], vmware-tray[11936], 
wireplumber[8298], xdg-desktop-por[9307, 12994]

checkrestart output:


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

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

Versions of packages needrestart depends on:
ii  binutils   2.40.50.20230602-1
ii  dpkg   1.21.22
ii  gettext-base   0.21-12
ii  libintl-perl   1.33-1
ii  libmodule-find-perl0.16-2
ii  libmodule-scandeps-perl1.31-2
ii  libproc-processtable-perl  0.634-1+b2
ii  libsort-naturally-perl 1.03-4
ii  libterm-readkey-perl   2.38-2+b1
ii  perl   5.36.0-7
ii  xz-utils   5.4.1-0.2

Versions of packages needrestart recommends:
ii  libimvirt-perl  0.9.6-11
ii  libpam-systemd  253-1
ii  systemd 253-1

Versions of packages needrestart suggests:
ii  iucode-tool2.3.1-3
ii  libnotify-bin  0.8.2-1

-- Configuration Files:
/etc/needrestart/needrestart.conf changed:
$nrconf{verbosity} = 2;
$nrconf{blacklist} = [
# ignore sudo (not a daemon)
qr(^/usr/bin/sudo(\.dpkg-new)?$),
# ignore DHCP clients
qr(^/sbin/(dhclient|dhcpcd5|pump|udhcpc)(\.dpkg-new)?$),
# ignore apt-get (Debian Bug#784237)
qr(^/usr/bin/apt-get(\.dpkg-new)?$),
];
$nrconf{override_rc} = {
# DBus
qr(^dbus) => 0,
# display managers
qr(^gdm) => 0,
qr(^kdm) => 0,
qr(^nodm) => 0,
qr(^sddm) => 0,
qr(^wdm) => 0,
qr(^xdm) => 0,
qr(^lightdm) => 0,
qr(^slim) => 0,
qr(^lxdm) => 0,
# networking stuff
qr(^bird) => 0,
qr(^network) => 0,
qr(^NetworkManager) => 0,
qr(^ModemManager) => 0,
qr(^wpa_supplicant) => 0,
qr(^openvpn) => 0,
qr(^quagga) => 0,
qr(^frr) => 0,
qr(^tinc) => 0,
qr(^(open|free|libre|strong)swan) => 0,
qr(^bluetooth) => 0,
# gettys
qr(^getty@.+\.service) => 0,
qr(^serial-getty@.+\.service) => 0,
# systemd --user
qr(^user@\d+\.service) => 0,
# misc
qr(^zfs-fuse) => 0,
qr(^mythtv-backend) => 0,
qr(^xendomains) => 0,
qr(^lxcfs) => 0,
qr(^libvirt) => 0,
qr(^virtlogd) => 0,
qr(^virtlockd) => 0,
qr(^docker) => 0,
# systemd stuff
# (see also Debian Bug#784238 & #784437)
qr(^emergency\.service$) => 0,
qr(^rescue\.service$) => 0,
qr(^elogind) => 0,
# do not restart oneshot services, see also #862840
qr(^apt-daily\.service$) => 0,
qr(^apt-daily-upgrade\.service$) => 0,
qr(^unattended-upgrades\.service$) => 0,
# do not restart 

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Hector Oron]

Hello

El mié, 7 jun 2023, 13:03, Cyril Brulebois  escribió:

> Hector Oron  (2023-06-07):
> > and Timonthy was able to test that. I could expand the change to ppc64
> > (be) and cdrom targets and test that.
> >
> > Note, the ppc64el installer images are unusable with that change, at
> > least on the Raptor systems
>
> I don't think you answered my question about fbdev.
>

I defer to Timothy since I do not have a machine myself, but since Raptorcs
is Debian partner I had assumed we - Debian - would like to ship a working
product that works for them.

Thanks for your support

>

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Lucas Kanashiro]

FWIW, in Ubuntu, we had a similar issue trying to fix this CVE in ruby2.7,
and in the end we reverted the fix:

https://launchpad.net/ubuntu/+source/ruby2.7/2.7.0-5ubuntu1.10

Lucas Kanashiro.

Em qua., 7 de jun. de 2023 07:47, Utkarsh Gupta 
escreveu:

> Hiya,
>
> On Wed, Jun 7, 2023 at 2:39 PM Moritz Muehlenhoff  wrote:
> > Specifically
> https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/
> > states:
> >
> > | For Ruby 2.7: Update to uri 0.10.0.1
> > | For Ruby 3.0: Update to uri 0.10.2
> > | For Ruby 3.1: Update to uri 0.11.1
> > | For Ruby 3.2: Update to uri 0.12.1
> >
> > And the 0.10 change (
> https://github.com/ruby/uri/commit/17861a53e499a2eabf7ba83d63914d0f01921d70
> )
> > is different from the 0.12 one (
> https://github.com/ruby/uri/commit/eaf89cc31619d49e67c64d0b58ea9dc38892d175
> )
> >
> > There might be other changes needed for 2.5, not sure.
>
> Yep, I'm taking a look to prep something for 2.5.
>
>
> - u
>
>

Bug#1037188: bullseye-pu: package git/2.30.2-1+deb11u3

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Jonathan Nieder 
Control: affects -1 + src:git
Control: block 987264 with -1
Control: block 984931 with -1

[ Reason ]
git-el in bullseye is uninstallable in any sensible combination with
emacs/xemacs (it only installs fine in a minimal chroot w/o
--install-recommends).
The package was dropped from sid shortly after the bullseye release,
let's to the same in bullseye.

[ Impact ]
git-el stays uninstallable (noticed by QA tools)

[ Tests ]
once the package is gone, piuparts will no longer test it (and fail)

[ Risks ]
only unused broken code that gets removed

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
remove all packaging bits for git-el, add Breaks to ensure cleanup if
the package is still (partially) installed

[ Other info ]
bullseye needs a cruft removal run to get rid of the no longer built
binary package


Andreas
diff -Nru git-2.30.2/debian/changelog git-2.30.2/debian/changelog
--- git-2.30.2/debian/changelog 2023-02-22 10:51:09.0 +0100
+++ git-2.30.2/debian/changelog 2023-06-07 11:53:11.0 +0200
@@ -1,3 +1,16 @@
+git (1:2.30.2-1+deb11u3) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport git-el removal from 1:2.32.0~rc2-1.
+
+  [ Jonathan Nieder ]
+  * remove git-el package (closes: #987264, #984931).  Since version
+1:2.18.0~rc2-1, it only contained modules that error out with a
+message pointing to other Emacs packages.  Nowadays users can
+use the README.emacs file from the git package for that instead.
+
+ -- Andreas Beckmann   Wed, 07 Jun 2023 11:53:11 +0200
+
 git (1:2.30.2-1+deb11u2) bullseye-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru git-2.30.2/debian/control git-2.30.2/debian/control
--- git-2.30.2/debian/control   2021-03-10 02:40:56.0 +0100
+++ git-2.30.2/debian/control   2023-06-07 11:52:58.0 +0200
@@ -32,13 +32,14 @@
 Pre-Depends: ${misc:Pre-Depends}
 Recommends: ca-certificates, patch, less, ssh-client
 Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
- git-doc, git-el, git-email, git-gui, gitk, gitweb,
+ git-doc, git-email, git-gui, gitk, gitweb,
  git-cvs, git-mediawiki, git-svn
 Replaces: gitweb (<< 1:1.7.4~rc1),
  git-core (<< 1:1.7.0.4-1.)
 Breaks: bash-completion (<< 1:1.90-1), gitweb (<< 1:1.7.4~rc1),
  dgit (<< 5.1~),
  git-buildpackage (<< 0.6.5),
+ git-el (<< 1:2.32.0~rc2-1~),
  cogito (<= 0.18.2+),
  openssh-client (<< 1:6.8),
  stgit (<< 0.15), stgit-contrib (<< 0.15), gitpkg (<< 0.15),
@@ -273,28 +274,6 @@
  .
  This package provides the gitk program, a tcl/tk revision tree visualizer.
 
-Package: git-el
-Architecture: all
-Multi-Arch: foreign
-Depends: ${misc:Depends}, git (>= 1:1.7.4.1-2~), emacs | emacsen
-Recommends: elpa-magit
-Replaces: git (<< 1:1.7.4.1-2~)
-Breaks: emacsen-common (<< 3.0.0~), git (<< 1:1.7.4.1-2~)
-Description: fast, scalable, distributed revision control system (emacs 
support)
- Git is popular version control system designed to handle very large
- projects with speed and efficiency; it is used for many high profile
- open source projects, most notably the Linux kernel.
- .
- Git falls in the category of distributed source code management tools.
- Every Git working directory is a full-fledged repository with full
- revision tracking capabilities, not dependent on network access or a
- central server.
- .
- This transitional package provides two modules that previously could be
- used for integration with Emacs: git.el and git-blame.el. Now the
- modules print an error message with instructions that users can use to
- migrate to Emacs's VC-mode backend for Git or Magit.
-
 Package: gitweb
 Architecture: all
 Multi-Arch: foreign
@@ -327,7 +306,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< 
${source:Upstream-Version}-.),
- git-doc, git-el, git-cvs, git-mediawiki, git-svn,
+ git-doc, git-cvs, git-mediawiki, git-svn,
  git-email, git-gui, gitk, gitweb
 Suggests: git-daemon-run | git-daemon-sysvinit
 Description: fast, scalable, distributed revision control system (all 
subpackages)
diff -Nru git-2.30.2/debian/git-el.emacsen-install 
git-2.30.2/debian/git-el.emacsen-install
--- git-2.30.2/debian/git-el.emacsen-install2021-03-10 02:40:56.0 
+0100
+++ git-2.30.2/debian/git-el.emacsen-install1970-01-01 01:00:00.0 
+0100
@@ -1,27 +0,0 @@
-#!/bin/sh
-# Based on /usr/share/doc/emacsen-common/sample-package-install-foo.gz.
-#
-# Unlike the example, we place symlinks to the elisp source alongside
-# the compiled bytecode, so the .el source is available to the various
-# Emacs help tools.  Putting .el and .elc files in the same directory

Bug#1037151: dbus: denial of service when a monitor is active and a message from the driver cannot be delivered

[Salvatore Bonaccorso]

Hi Simon,

On Tue, Jun 06, 2023 at 02:36:01PM +0100, Simon McVittie wrote:
> Package: dbus
> Version: 1.15.4-1
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> Control: found -1 1.14.6-1
> Control: found -1 1.12.24-0+deb11u1
> 
> If a privileged user with control over the dbus-daemon is using the
> org.freedesktop.DBus.Monitoring interface to monitor message bus
> traffic, then an unprivileged user with the ability to connect to the
> same dbus-daemon can cause a dbus-daemon crash under some circumstances.
> 
> When done on the well-known system bus, this is a denial-of-service
> vulnerability. Unfortunately, the upstream bug reporter already made
> this public information. I'm in the process of releasing dbus 1.15.6,
> 1.14.8 and 1.12.28 to resolve this; I've also asked MITRE for a CVE ID,
> but I have not received one yet.
> 
> Mitigation: This can only be done if a monitoring process such
> as dbus-monitor or busctl monitor is active on the same dbus-daemon
> instance, which is a privileged operation that can only be done by root
> or the Unix uid of the message bus. If no monitoring process is active,
> then the vulnerable code is not reached.
> 
> My guess is that the security team will not want to release DSAs for this
> local denial of service, and it's more appropriate to fix in bookworm
> and bullseye via their next point releases. Is that assumption correct?

Yes that sounds fine to do in point release.

Regards,
Salvatore

Bug#1037187: bullseye-pu: package libprelude/5.2.0-3+deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Control: block 996878 with -1
Control: affects -1 + src:libprelude
Control: tag 996878 patch pending

[ Reason ]
'import prelude' fails in python3 due to some missing symbol, rendering
python3-prelude useless.

[ Impact ]
'import prelude' will not work, breaking some packages depending on that

[ Tests ]
manual 'import prelude' with the fixed package in bullseye worked
added superficial autopkgtest testing the import

[ Risks ]
Low. The patch cannot make the unusable pyton module worse.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
only backported python module fixes from sid

[ Other info ]

Andreas
diff -Nru libprelude-5.2.0/debian/changelog libprelude-5.2.0/debian/changelog
--- libprelude-5.2.0/debian/changelog   2020-11-26 19:53:39.0 +0100
+++ libprelude-5.2.0/debian/changelog   2023-06-07 12:52:40.0 +0200
@@ -1,3 +1,17 @@
+libprelude (5.2.0-3+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport Python module fixes from 5.2.0-4/5.2.0-5.
+
+  [ Thomas Andrejak ]
+  * d.patches: Add new patch 025-Fix-PyIOBase_Type.patch
+- Fix PyIOBase_Type for Python 3.10 compatibility
+  * d.patches: Update 025-Fix-PyIOBase_Type.patch because swig is not
+executed (Closes: #996878)
+  * d.tests: Add test to valid that we can load prelude as a python module
+
+ -- Andreas Beckmann   Wed, 07 Jun 2023 12:52:40 +0200
+
 libprelude (5.2.0-3) unstable; urgency=medium
 
   * d.patches: Add new patch
diff -Nru libprelude-5.2.0/debian/patches/025-Fix-PyIOBase_Type.patch 
libprelude-5.2.0/debian/patches/025-Fix-PyIOBase_Type.patch
--- libprelude-5.2.0/debian/patches/025-Fix-PyIOBase_Type.patch 1970-01-01 
01:00:00.0 +0100
+++ libprelude-5.2.0/debian/patches/025-Fix-PyIOBase_Type.patch 2023-06-07 
12:52:40.0 +0200
@@ -0,0 +1,170 @@
+Description: Fix PyIOBase_Type for Python 3.10 compatibility
+Author: Thomas Andrejak 
+Last-Update: 2021-08-13
+Forwarded: yes, privately
+
+--- libprelude-5.2.0/bindings/python/libpreludecpp-python.i2020-09-09 
16:30:32.51000 +0200
 libprelude-5.2.0/bindings/python/libpreludecpp-python.i2021-08-13 
23:20:11.672221930 +0200
+@@ -163,6 +163,26 @@
+ $1 = _cb_python_log;
+ };
+ 
++%{
++static PyObject *PyIOBase_TypeObj;
++
++static int init_file_emulator(void)
++{
++PyObject *io = PyImport_ImportModule("_io");
++if (io == NULL)
++return -1;
++PyIOBase_TypeObj = PyObject_GetAttrString(io, "_IOBase");
++if (PyIOBase_TypeObj == NULL)
++return -1;
++return 0;
++}
++%}
++
++%init %{
++if (init_file_emulator() < 0) {
++return NULL;
++}
++%}
+ 
+ /* tell swig not to cast void * value */
+ %typemap(in) void *nocast_file_p %{
+@@ -172,8 +192,7 @@
+ 
+ }
+ #else
+-extern PyTypeObject PyIOBase_Type;
+-if ( ! PyObject_IsInstance((PyObject *) $input, (PyObject *) 
_Type) ) {
++if ( ! PyObject_IsInstance((PyObject *) $input, PyIOBase_TypeObj) ) {
+ SWIG_exception_fail(SWIG_RuntimeError, "Argument is not a 
file object");
+ }
+ #endif
+@@ -186,8 +205,7 @@
+ #if PY_VERSION_HEX < 0x0300
+ $1 = PyFile_Check((PyObject *) $input);
+ #else
+-extern PyTypeObject PyIOBase_Type;
+-$1 = PyObject_IsInstance((PyObject *) $input, (PyObject *) 
_Type);
++$1 = PyObject_IsInstance((PyObject *) $input, PyIOBase_TypeObj);
+ #endif
+ %}
+ 
+--- libprelude-5.2.0/bindings/python/_prelude.cxx
 libprelude-5.2.0/bindings/python/_prelude.cxx
+@@ -2761,7 +2761,7 @@ SwigPyBuiltin_FunpackSetterClosure (PyObject *obj, 
PyObject *val, void *closure)
+ 
+ SWIGINTERN void
+ SwigPyStaticVar_dealloc(PyDescrObject *descr) {
+-  PyObject_GC_UnTrack(descr);
++  PyObject_GC_UnTrack(descr);
+   Py_XDECREF(PyDescr_TYPE(descr));
+   Py_XDECREF(PyDescr_NAME(descr));
+   PyObject_GC_Del(descr);
+@@ -4176,6 +4176,20 @@ static ssize_t _cb_python_read(prelude_io_t *fd, void 
*buf, size_t size)
+ }
+ 
+ 
++static PyObject *PyIOBase_TypeObj;
++
++static int init_file_emulator(void)
++{
++PyObject *io = PyImport_ImportModule("_io");
++if (io == NULL)
++return -1;
++PyIOBase_TypeObj = PyObject_GetAttrString(io, "_IOBase");
++if (PyIOBase_TypeObj == NULL)
++return -1;
++return 0;
++}
++
++
+ void python2_return_unicode(int enabled)
+ {
+ _PYTHON2_RETURN_UNICODE = enabled;
+@@ -5291,13 +5305,19 @@ namespace swig
+   return const_reference(_seq, n);
+ }
+ 
+-bool check() const
++bool check(bool set_err = true) const
+ {
+   Py_ssize_t s = size();
+   for (Py_ssize_t i = 0; i < s; ++i) {
+   swig::SwigVar_PyObject item = PySequence_GetItem(_seq, i);
+-  if 

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Cyril Brulebois]

Hector Oron  (2023-06-07):
> and Timonthy was able to test that. I could expand the change to ppc64
> (be) and cdrom targets and test that.
> 
> Note, the ppc64el installer images are unusable with that change, at
> least on the Raptor systems

I don't think you answered my question about fbdev.

> and since the change only affects power package lists, I'd consider it
> as low impact/risk. I know we are close to a release, and it is very
> bad timing however if it can be merged, it'd be great, otherwise we'll
> have to wait until the first point release.

If you look at the work that's been going on during the last few
months on the -boot or -cd side, I think it's fair to say I have been
very accommodating, trying hard to satisfy as many reasonable requests
as possible, balancing those against possible risks. We've got some
extensive and appreciated leeway/flexibility, but at some point, I
have to draw a line.

That line was drawn a few hours ago.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Luca Boccassi]

On Wed, 7 Jun 2023 at 11:29, Simon McVittie  wrote:
>
> On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> > Luca Boccassi  writes:
> > > +Packages might need additional files or directories to implement their
> > > +functionality. Directories that are located under ``/var/`` or
> > > +``/etc/``, and files that are located under ``/var/``, must not be
> > > +created manually via maintainer scripts, but instead be declaratively
> > > +defined via the `tmpfiles.d
> > > +`_
> > > +interface.
> >
> > This is an oddly specific list of directories and not at all the
> > directories that I would have expected to be handled by tmpfiles.d.
>
> Sorry, in my previous reading of this bug I had been concentrating on
> the mechanics of how to make tmpfiles.d(5) something that maintainers can
> rely on if it's convenient/helpful, and I'd missed that Luca is asking
> for its use to be mandatory in some cases.
>
> I would personally be inclined to concentrate on making tmpfiles.d(5)
> something that we can rely on and encourage the use of where appropriate,
> even on non-systemd systems, so that (upstream and downstream) maintainers
> can move towards it of their own accord because it's more convenient
> than other options, and put aside the question of making it generally a
> "should" or "must" for the moment.
>
> I believe (please correct me if I'm wrong) that Luca's intention here
> is that this is drawing a line between:
>
> - the static files of the OS: /usr and the /usr-like top-level directories
>   (the ones that get merged by the /usr merge), which should be statically
>   shipped in packages and managed by dpkg (or on "immutable" systems
>   that use image-based/tree-based upgrades, maybe by ostree or casync
>   or similar, from an tree originally constructed from dpkg packages)
>
> - this specific system's persistent state: /var and parts of /etc
>
> with the intention of eventually enabling functionality like being
> able to do a "factory reset" to the equivalent of a freshly installed
> system by deleting (most of) /etc and /var, rebooting, and letting the
> OS re-create them from a template below /usr; or doing the equivalent
> for individual packages by deleting only their part of /etc and /var.
>
> /etc is somewhere between static files and state, because traditionally
> it has been a mixture of files that the sysadmin or installer must provide
> (like /etc/passwd); configuration files that are shipped by a package and
> can be edited by the sysadmin (like /etc/systemd/logind.conf); and
> integration glue that links up one package with another, can in principle
> be edited by the sysadmin, but in practice is rarely edited
> (like /etc/profile.d/flatpak.sh).
>
> Various upstream projects including systemd have been trying to reduce
> the extent to which /etc and /var are included in the data.tar.* of a .deb
> or other packaging systems' equivalents, by moving the integration glue
> to a /usr-like directory (/lib/udev/rules.d, /usr/share/dbus-1/system.d),
> reserving the corresponding /etc directory for sysadmin configuration
> (/etc/udev/rules.d, /etc/dbus-1/system.d), and providing a way for the
> sysadmin to "mask" any integration files they want the system to ignore.
>
> If we disregard conffiles and configuration files in /etc for the
> moment, there are basically three ways for a package to get a file onto
> the running system:
>
> - ship it in the data.tar.* of a .deb
> - create it from a maintainer script and also during boot
> - maybe via tmpfiles.d(5)
> - or maybe open-coded
> - have the package create it at runtime, on-demand
> - this clearly doesn't work if the package's code runs unprivileged
>   and relies on root having created a directory for it already
>
> For /usr and the /usr-like directories, shipping files in the .deb is by
> far the most common, although a few packages need to create files here
> via maintainer scripts or triggers (for example
> /usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache which is a summary
> of files created by multiple packages, and is updated whenever those
> packages are added, removed or changed).
>
> For /run, /tmp and /var/tmp, I think there's consensus that shipping files
> in those directories in the .deb is a bug, because at the next reboot,
> the file will be deleted, leaving the files that dpkg thinks it's managing
> out of sync with the files that actually exist. At the moment, these are
> variously created by maintainer scripts, systemd units/init scripts, or the
> daemons themselves, with some duplication, and no good way to get an
> overview of which packages "own" which locations: dpkg doesn't know anything
> about them, and systemd knows about some but not all of them.
>
> tmpfiles.d seems like a good way to keep track of who "owns" those
> transient files and directories. I think a Policy "must" is probably too
> strong here, but a "should" might be 

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Utkarsh Gupta]

Hiya,

On Wed, Jun 7, 2023 at 2:39 PM Moritz Muehlenhoff  wrote:
> Specifically 
> https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/
> states:
>
> | For Ruby 2.7: Update to uri 0.10.0.1
> | For Ruby 3.0: Update to uri 0.10.2
> | For Ruby 3.1: Update to uri 0.11.1
> | For Ruby 3.2: Update to uri 0.12.1
>
> And the 0.10 change 
> (https://github.com/ruby/uri/commit/17861a53e499a2eabf7ba83d63914d0f01921d70)
> is different from the 0.12 one 
> (https://github.com/ruby/uri/commit/eaf89cc31619d49e67c64d0b58ea9dc38892d175)
>
> There might be other changes needed for 2.5, not sure.

Yep, I'm taking a look to prep something for 2.5.


- u

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

[Luca Boccassi]

On Wed, 7 Jun 2023 at 04:40, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index b34c183..30ce013 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -722,6 +722,43 @@ The name of the files and directories installed by 
> > binary packages
> >  outside the system PATH must be encoded in UTF-8 and should be
> >  restricted to ASCII when it is possible to do so.
> >
> > +.. _s-tmpfiles.d:
> > +
> > +tmpfiles.d
> > +--
> > +
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, must not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +`_
> > +interface.
>
> This is an oddly specific list of directories and not at all the
> directories that I would have expected to be handled by tmpfiles.d.  My
> naive expectation would be that the most common path handled by tmpfiles.d
> would be /run, /tmp, and /var/tmp.  I read through the other messages in
> this bug but I didn't see the explanation for why those directories in
> particular.
>
> Given that neither /var (apart from /var/tmp) nor /etc are transient, I
> would have expected packages to simply ship the directories under those
> paths that they need in the package.  Why is that not the right approach?
> Could you explain when tmpfiles.d should be used instead of shipping the
> directory in the package?

It's not only for transient hierarchies as in memory based, but also
for hierarchies that can be blown away and the system is supposed to
recover from. /var is state, and if random things under it are lost,
it should be possible to recover without having to throw away the
whole installation and start over. Of course there will be some
limits, but for the really trivial stuff (ie: "I need to store some
cached data somewhere so I need a directory under /var") it should be
possible to cleanly re-set up in an automated fashion after a reboot.
Not only this, but tmpfiles.d help also enforce that the right
metadata (dac/mac/acl) are set, again without having to reinstall
packages. Also more specifically, for image-based systems we want to
be able to have the vendor tree (ie: content shipped by packages)
restricted to /usr and optionally /etc. One of the goals we have for
Trixie is to no longer ship anything under /var (and /boot) hard-coded
in packages.

So the list of directories there is provided as an example, I can make
it more or less specific as needed.

> > +The ``tmpfiles.d`` file format is defined by the ``systemd`` project, and 
> > is
> > +guaranteed to be stable. Ideally, such definitions should be defined 
> > upstream
> > +where applicable, and shipped as they are by Debian packages.
> > +
> > +Details about the syntax and installation paths for ``tmpfiles.d`` are 
> > defined
> > +by its `reference implementation's documentation,
> > +`_ and 
> > will
> > +not be redefined here.
>
> I'm clearly missing something, but I was naively expecting this section to
> start with something more like this:
>
> Packages that need to create files or directories in file systems that
> may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
> ``/var/tmp``) should do so via configuration files in the
> ``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
> defined by the `systemd tmpfiles.d documentation
> `__.
>
> However, reading that documentation, it sounds like most of the cases for
> other directories are handled by other systemd unit configuration
> directives.  We should say that explicitly here and reproduce the list of
> other directories that should be handled directly by the unit file if
> that's what we want people to do.

I'd be more than delighted to recommend using
StateDirectory=/RuntimeDirectory= and friends as the first choice, and
can certainly do so. However, note that those work best for cases
where there is a service which is the clear owner (they can be shared,
with some caveats that we are trying to solve upstream if ephemeral
users are used, but still needs an owner), and this is important for
lifetime management (ie: when to delete). There are also cases where
there is no clear service that is the owner and to whose lifecycle the
directory should be tied to, and for that tmpfiles.d is the solution.

> What's the plan for creating directories in /run on non-systemd systems?
> I had assumed that tmpfiles.d would be used for those directories so that
> we can use the same mechanism for both systemd and non-systemd systems,
> but it looks like that's not ideal for systemd systems.  Is it safe to 

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Hector Oron]

Hello,

  To be honest, I only updated ppc64el netboot image with the following patch:

--- a/build/pkg-lists/netboot/ppc64el.cfg
+++ b/build/pkg-lists/netboot/ppc64el.cfg
@@ -1,5 +1,6 @@
 input-modules-${kernel:Version}
 nic-modules-${kernel:Version}
+fb-modules-${kernel:Version} ?
 usb-modules-${kernel:Version}
 virtio-modules-${kernel:Version} ?

I built the installer posted at:
https://people.debian.org/~zumbi/netboot_ppc64el/

and Timonthy was able to test that. I could expand the change to ppc64
(be) and cdrom targets and test that.

Note, the ppc64el installer images are unusable with that change, at
least on the Raptor systems, and since the change only affects power
package lists, I'd consider it as low impact/risk. I know we are close
to a release, and it is very bad timing, however if it can be merged,
it'd be great, otherwise we'll have to wait until the first point
release.

Thanks for your support.

On Wed, 7 Jun 2023 at 12:29, Cyril Brulebois  wrote:
>
> Hi,
>
> Hector Oron Martinez  (2023-06-07):
> > We found latest installer for bookworm is missing ast DRM kernel
> > module, causing graphical failure on ppc64el Raptor machines. Could
> > you please consider the following change or similar for the
> > debian-installer bookworm release.
> >
> >   
> > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/34
>
> Thanks for the patch, but this is too late. We can consider that for
> unstable, and later on via a point release.
>
> I know for a fact we have fbdev in ppc64el builds, as we've suffered a
> regression there (#1033058, for which someone still needs to find a real
> fix on the kernel side, hint hint wink wink); isn't that generic driver
> sufficient to get some basic output?
>
> Also, I don't understand what's going on with the build/Makefile part:
>  1. This is a temporary workaround for 3 architectures that run into
> issues under UEFI/SB, which isn't quite relevant for ppc64el. (The
> idea was to avoid having to re-upload linux and linux-signed-* for
> just a few additions to the fb-modules udeb.)
>  2. If you look at the following commit, I suppose you'll get the very
> same impression as I have: this merge request is very likely to
> trigger a direct FTBFS on ppc64el.
>   
> https://salsa.debian.org/installer-team/debian-installer/-/commit/32e4d58c263fc5454067a7217ee7103cfb12bc1b
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

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

[Simon McVittie]

On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, must not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +`_
> > +interface.
> 
> This is an oddly specific list of directories and not at all the
> directories that I would have expected to be handled by tmpfiles.d.

Sorry, in my previous reading of this bug I had been concentrating on
the mechanics of how to make tmpfiles.d(5) something that maintainers can
rely on if it's convenient/helpful, and I'd missed that Luca is asking
for its use to be mandatory in some cases.

I would personally be inclined to concentrate on making tmpfiles.d(5)
something that we can rely on and encourage the use of where appropriate,
even on non-systemd systems, so that (upstream and downstream) maintainers
can move towards it of their own accord because it's more convenient
than other options, and put aside the question of making it generally a
"should" or "must" for the moment.

I believe (please correct me if I'm wrong) that Luca's intention here
is that this is drawing a line between:

- the static files of the OS: /usr and the /usr-like top-level directories
  (the ones that get merged by the /usr merge), which should be statically
  shipped in packages and managed by dpkg (or on "immutable" systems
  that use image-based/tree-based upgrades, maybe by ostree or casync
  or similar, from an tree originally constructed from dpkg packages)

- this specific system's persistent state: /var and parts of /etc

with the intention of eventually enabling functionality like being
able to do a "factory reset" to the equivalent of a freshly installed
system by deleting (most of) /etc and /var, rebooting, and letting the
OS re-create them from a template below /usr; or doing the equivalent
for individual packages by deleting only their part of /etc and /var.

/etc is somewhere between static files and state, because traditionally
it has been a mixture of files that the sysadmin or installer must provide
(like /etc/passwd); configuration files that are shipped by a package and
can be edited by the sysadmin (like /etc/systemd/logind.conf); and
integration glue that links up one package with another, can in principle
be edited by the sysadmin, but in practice is rarely edited
(like /etc/profile.d/flatpak.sh).

Various upstream projects including systemd have been trying to reduce
the extent to which /etc and /var are included in the data.tar.* of a .deb
or other packaging systems' equivalents, by moving the integration glue
to a /usr-like directory (/lib/udev/rules.d, /usr/share/dbus-1/system.d),
reserving the corresponding /etc directory for sysadmin configuration
(/etc/udev/rules.d, /etc/dbus-1/system.d), and providing a way for the
sysadmin to "mask" any integration files they want the system to ignore.

If we disregard conffiles and configuration files in /etc for the
moment, there are basically three ways for a package to get a file onto
the running system:

- ship it in the data.tar.* of a .deb
- create it from a maintainer script and also during boot
- maybe via tmpfiles.d(5)
- or maybe open-coded
- have the package create it at runtime, on-demand
- this clearly doesn't work if the package's code runs unprivileged
  and relies on root having created a directory for it already

For /usr and the /usr-like directories, shipping files in the .deb is by
far the most common, although a few packages need to create files here
via maintainer scripts or triggers (for example
/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache which is a summary
of files created by multiple packages, and is updated whenever those
packages are added, removed or changed).

For /run, /tmp and /var/tmp, I think there's consensus that shipping files
in those directories in the .deb is a bug, because at the next reboot,
the file will be deleted, leaving the files that dpkg thinks it's managing
out of sync with the files that actually exist. At the moment, these are
variously created by maintainer scripts, systemd units/init scripts, or the
daemons themselves, with some duplication, and no good way to get an
overview of which packages "own" which locations: dpkg doesn't know anything
about them, and systemd knows about some but not all of them.

tmpfiles.d seems like a good way to keep track of who "owns" those
transient files and directories. I think a Policy "must" is probably too
strong here, but a "should" might be reasonable?

For the persistent parts of /var, several packages ship regular files
(as opposed to directories) in the .deb. I think there might be rough
consensus that doing so is at least a "code smell", but quite a 

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Cyril Brulebois]

Hi,

Hector Oron Martinez  (2023-06-07):
> We found latest installer for bookworm is missing ast DRM kernel
> module, causing graphical failure on ppc64el Raptor machines. Could
> you please consider the following change or similar for the
> debian-installer bookworm release.
> 
>   https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/34

Thanks for the patch, but this is too late. We can consider that for
unstable, and later on via a point release.

I know for a fact we have fbdev in ppc64el builds, as we've suffered a
regression there (#1033058, for which someone still needs to find a real
fix on the kernel side, hint hint wink wink); isn't that generic driver
sufficient to get some basic output?

Also, I don't understand what's going on with the build/Makefile part:
 1. This is a temporary workaround for 3 architectures that run into
issues under UEFI/SB, which isn't quite relevant for ppc64el. (The
idea was to avoid having to re-upload linux and linux-signed-* for
just a few additions to the fb-modules udeb.)
 2. If you look at the following commit, I suppose you'll get the very
same impression as I have: this merge request is very likely to
trigger a direct FTBFS on ppc64el.
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/32e4d58c263fc5454067a7217ee7103cfb12bc1b


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Bill Allombert]

On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> 
> > I think what's a bit peculiar here is using "must" for a case where
> > there might be package-specific exceptions.  In other cases, Policy uses
> > "should" for these cases.  Typically "must" rules are simple and
> > completely determinate.
> 
> I prefer that too, but in this case, it feels like must is appropriate for
> at least systemd configuration files.  And also, just intuitively, I feel
> like must is correct when people are using diversions rather than a native
> mechanism.  Diversions add weird edge cases and we really shouldn't be
> using them lightly.
> 
> The wording I proposed and that Luca has now adopted therefore uses must
> with a caveat.  Does that sound okay to you?

I do not think appropriate for the policy to list systemd or any
other packages specifically in this section.

If a package set up a diversion that breaks another, then it is buggy,
whatever policy say. If the diversion does not cause any breakage, there is
no purpose for policy to declare it a RC bug.

In general, policy proscription are only useful when the description of a
better mechanism is provided.  But there is no place for that in this section.

It would more suitable to have a separate section or document defining the
interface between systemd and other packages, that would explain how to avoid
diversion by providing better solutions rather than direct proscriptions, with
more details than just "use native systemd configuration files".

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1037186: debian-installer: bookworm d-i graphics are not shown on Raptor system

[Hector Oron Martinez]

Source: debian-installer
Version: 20230526
Severity: important
X-Debbugs-Cc: tpear...@raptorcs.com, zu...@debian.org

Hello,

We found latest installer for bookworm is missing ast DRM kernel module, 
causing graphical failure on ppc64el Raptor machines. Could you please consider 
the following change or similar for the debian-installer bookworm release.

  https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/34

Regards

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

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