Bug#1036081: pre-unblock: mariadb/1:10.11.3-1

[Otto Kekäläinen]

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

A new MariaDB 10.11 upstream minor maintenance 10.11.3 is pending at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/46

This pre-unblock request is to get a decision from the Bookworm
release team if you prefer to accept this 10.11.3 into Bookworm, or if
you wish it to be postponed to a stable update in Bookworm some time
later in fall 2023.


As the main maintainer I suggest the release team would decide to
include this 10.11.3 in Debian Bookworm at this point in time. There
is extensive CI in place pre-upload, and extensive autopkgtests and
other quality assurance post-upload. The MariaDB packages in stable
releases have a good track record of having unsurprising minor
maintenance releases. The MariaDB 10.11.2 release was the first one
announced GA (general availability), so this 10.11.3 includes many
important upstream bugfixes (though many of them were already
cherry-picked into 10.11.2-4 in Debian). The benefit of having known
important bugfixes included in Bookworm outweighs the risks of
potential unknown and unlikely regressions in this case.

This request does not have an exact debdiff, as the 10.11.3 import
work was done today and later this week we might add one or two more
bugfix commits to it.

Bug#1000518: logcheck: separate filtering for apt term.log and or unattended-upgrades-dpkg.log etc?

[Paul Wise]

On Wed, 24 Nov 2021 21:37:36 +0800 Paul Wise wrote:

> I'm currently using the attached hacky script with lots of regexes to
> implement apt upgrade log filtering.

Here is an updated version of the script.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


debian-filter-unattended-upgrades-report
Description: application/shellscript


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

Bug#1036080: wine: Close, Maximise, Minimise titlebar symbols wrong

[Christian Gelinek]

Package: wine
Version: 8.0~repack-4
Severity: minor
X-Debbugs-Cc: cgeli...@radlogic.com.au

Dear Maintainer,

After installing wine, the symbols for the close, minimise and maximise buttons 
are wrong: instead of the X for close for example, a square is shown.

This was discussed on the WineHQ forum [0] and includes a manual fix, which is
simply copying a font file:

cp /usr/share/wine/fonts/marlett.ttf $WINEPREFIX/drive_c/windows/Fonts/

solved the issue for me, I now see the correct icons.

[0]: https://forum.winehq.org/viewtopic.php?p=139055

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

-- 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-8-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 wine depends on:
ii  wine64  8.0~repack-4

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks20230212-2

Versions of packages libwine depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libglib2.0-0 2.74.6-2
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgstreamer-plugins-base1.0-0   1.22.0-3
ii  libgstreamer1.0-01.22.0-2
ii  libpcap0.8   1.10.3-1
ii  libpulse016.1+dfsg1-2+b1
ii  libudev1 252.6-1
ii  libunwind8   1.6.2-3
ii  libusb-1.0-0 2:1.0.26-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libz-mingw-w64   1.2.13+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

Versions of packages libwine recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 8.0~repack-4
ii  gstreamer1.0-plugins-good  1.22.0-5
ii  libasound2-plugins 1.2.7.1-1
ii  libcups2   2.4.2-3
ii  libdbus-1-31.14.6-1
ii  libgl1 1.6.0-1
ii  libgl1-mesa-dri22.3.6-1+deb12u1
ii  libgnutls303.7.9-2
ii  libgssapi-krb5-2   1.20.1-1+b1
ii  libkrb5-3  1.20.1-1+b1
ii  libodbc2   2.3.11-2
ii  libosmesa6 22.3.6-1+deb12u1
ii  libsdl2-2.0-0  2.26.5+dfsg-1
ii  libv4l-0   1.22.1-5+b2
ii  libvulkan1 1.3.239.0-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.22.0-2
ii  gstreamer1.0-plugins-bad   1.22.0-4
ii  gstreamer1.0-plugins-ugly  1.22.0-2
pn  ttf-mscorefonts-installer  

Versions of packages wine64 depends on:
ii  libc62.36-9
ii  libwine  8.0~repack-4

Versions of packages wine64 recommends:
pn  wine32  

Versions of packages wine64 suggests:
pn  wine64-preloader  

Versions of packages wine is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   8.0~repack-4

-- no debconf information

Bug#1036079: RFP: firecracker -- micro KVM-based virtual machine monitor

[mooff]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: mooff@awful.cooking

* Package name: firecracker
* URL : https://firecracker-microvm.github.io/
* License : Apache 2.0
  Programming Lang: Rust, Python
  Description : Firecracker is a virtual machine monitor (VMM) that uses 
the Linux Kernel Virtual Machine (KVM) to create and run microVMs.

> Firecracker has a minimalist design. It excludes unnecessary devices and 
> guest-facing functionality to reduce the memory footprint and attack surface 
> area of each microVM. This improves security, decreases the startup time, and 
> increases hardware utilization. Firecracker has also been integrated in 
> container runtimes, for example Kata Containers and Weaveworks Ignite.

(From firecracker/README.md)

This would make a great addition to Debian.

Bug#1036078: unblock: docker-registry/2.8.2+ds1-1

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: docker-regis...@packages.debian.org, z...@debian.org
Control: affects -1 + src:docker-registry

Please unblock package docker-registry

[ Reason ]
Upstream micro release for CVE-2023-2253 (Catalog API endpoint can lead to OOM
via malicious user input).

[ Impact ]
Fix security issue.

[ Tests ]
New unittest is added. The package has autopkgtest.

[ Risks ]

The debdiff contains some noise code style changes, otherwise they are trivial.

[ 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 testing

[ Other info ]
I attached a filtered debdiff, with following command,

 filterdiff --exclude '*/releases/*' --exclude '*/script/*' --exclude 
'*/.github/*' \
   --exclude '*.hcl'  --exclude '*.yml' --exclude '*/Dockerfile' \
   --exclude '*/Makefile' --exclude '*/.mailmap'  --exclude '*_test.go'

unblock docker-registry/2.8.2+ds1-1
diff -Nru -w docker-registry-2.8.1+ds1/configuration/configuration.go 
docker-registry-2.8.2+ds1/configuration/configuration.go
--- docker-registry-2.8.1+ds1/configuration/configuration.go2022-03-09 
01:52:36.0 +0800
+++ docker-registry-2.8.2+ds1/configuration/configuration.go2023-05-11 
18:11:57.0 +0800
@@ -194,6 +194,7 @@
} `yaml:"redis,omitempty"`
 
Health Health `yaml:"health,omitempty"`
+   Catalog Catalog `yaml:"catalog,omitempty"`
 
Proxy Proxy `yaml:"proxy,omitempty"`
 
@@ -244,6 +245,16 @@
} `yaml:"policy,omitempty"`
 }
 
+// Catalog is composed of MaxEntries.
+// Catalog endpoint (/v2/_catalog) configuration, it provides the configuration
+// options to control the maximum number of entries returned by the catalog 
endpoint.
+type Catalog struct {
+   // Max number of entries returned by the catalog endpoint. Requesting n 
entries
+   // to the catalog endpoint will return at most MaxEntries entries.
+   // An empty or a negative value will set a default of 1000 maximum 
entries by default.
+   MaxEntries int `yaml:"maxentries,omitempty"`
+}
+
 // LogHook is composed of hook Level and Type.
 // After hooks configuration, it can execute the next handling automatically,
 // when defined levels of log message emitted.
@@ -670,6 +681,11 @@
if v0_1.Loglevel != Loglevel("") {
v0_1.Loglevel = Loglevel("")
}
+
+   if v0_1.Catalog.MaxEntries <= 0 {
+   v0_1.Catalog.MaxEntries = 1000
+   }
+
if v0_1.Storage.Type() == "" {
return nil, errors.New("no 
storage configuration provided")
}
diff -Nru -w docker-registry-2.8.1+ds1/context/doc.go 
docker-registry-2.8.2+ds1/context/doc.go
--- docker-registry-2.8.1+ds1/context/doc.go2022-03-09 01:52:36.0 
+0800
+++ docker-registry-2.8.2+ds1/context/doc.go2023-05-11 18:11:57.0 
+0800
@@ -15,7 +15,7 @@
 // The above will store the version in the context and will be available to
 // the logger.
 //
-// Logging
+// # Logging
 //
 // The most useful aspect of this package is GetLogger. This function takes
 // any context.Context interface and returns the current logger from the
@@ -65,7 +65,7 @@
 // added to the request context, is unique to that context and can have
 // request scoped variables.
 //
-// HTTP Requests
+// # HTTP Requests
 //
 // This package also contains several methods for working with http requests.
 // The concepts are very similar to those described above. We simply place the
diff -Nru -w docker-registry-2.8.1+ds1/context/http.go 
docker-registry-2.8.2+ds1/context/http.go
--- docker-registry-2.8.1+ds1/context/http.go   2022-03-09 01:52:36.0 
+0800
+++ docker-registry-2.8.2+ds1/context/http.go   2023-05-11 18:11:57.0 
+0800
@@ -246,11 +246,7 @@
return ctx.vars
}
 
-   if strings.HasPrefix(keyStr, "vars.") {
-   keyStr = strings.TrimPrefix(keyStr, "vars.")
-   }
-
-   if v, ok := ctx.vars[keyStr]; ok {
+   if v, ok := ctx.vars[strings.TrimPrefix(keyStr, "vars.")]; ok {
return v
}
}
diff -Nru -w docker-registry-2.8.1+ds1/debian/changelog 
docker-registry-2.8.2+ds1/debian/changelog
--- docker-registry-2.8.1+ds1/debian/changelog  2022-06-29 20:32:34.0 
+0800
+++ docker-registry-2.8.2+ds1/debian/changelog  2023-05-13 23:21:12.0 
+0800
@@ -1,3 +1,14 @@
+docker-registry (2.8.2+ds1-1) unstable; urgency=medium
+
+  * Team upload
+  * New upstream version 2.8.2+ds1
+

Bug#1034889: mariadb: CVE-2022-47015

[Otto Kekäläinen]

Hi!

New upstream import has been done and is pending at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bullseye

Additionally I have
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14
(#1035949) pending review as we might want to include it in the same
upload.

Judging on notes at
https://security-tracker.debian.org/tracker/CVE-2022-47015 it might be
that Debian security does not consider this fix urgent, and we might
want instead to wait for the next stable release of Debian 11
"Bullseye", although no date fo 11.8 is yet up at
https://release.debian.org/.

Bug#1032937: systemd-resolved: Fixed in systemd 251.4-1ubuntu4 (06 Sep 2022)

[Marcel Partap]

Package: systemd-resolved
Version: 252.5-2~bpo11+1
Followup-For: Bug #1032937

Ubuntu had this in their systemd.postinst since 5 years:
> ef4adf4 Dimitri John Ledkov   5 years ago  63│ # Use stub resolve.conf by 
> default on new installs
> 20bc8a3 Dimitri John Ledkov   5 years ago  64│ if [ -z "$2" ]; then
> 20bc8a3 Dimitri John Ledkov   5 years ago  65│ mkdir -p 
> /run/systemd/resolve
> 20bc8a3 Dimitri John Ledkov   5 years ago  66│ if [ -e /etc/resolv.conf 
> ]; then
> 20bc8a3 Dimitri John Ledkov   5 years ago  67│ cp 
> /etc/resolv.conf /run/systemd/resolve/stub-resolv.conf
> 20bc8a3 Dimitri John Ledkov   5 years ago  68│ fi
> b04f573 Dimitri John Ledkov   5 years ago  69│ # If /etc/resolv.conf is a 
> bind-mount, moving or replacing
> b04f573 Dimitri John Ledkov   5 years ago  70│ # /etc/resolv.conf may fail
> b04f573 Dimitri John Ledkov   5 years ago  71│ ln -snf 
> ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf || true
> ef4adf4 Dimitri John Ledkov   5 years ago  72│ fi

and moved the relevant copy operation into systemd-resolved.postinst in 
September.
Any reason not to apply the same, @Luca?

Workaround for live-build can be a 
/usr/share/live/build/hooks/normal/0001-systemd-resolved-unbreak.hook.chroot
> #!/bin/sh
> mkdir -p /run/systemd/resolve/
> cp -a /etc/.resolv.conf.systemd-resolved.bak 
> /run/systemd/resolve/stub-resolv.conf

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (510, 'unstable'), (509, 'experimental'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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 systemd-resolved depends on:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libc6   2.36-5
ii  libssl1.1   1.1.1n-1
ii  libssl3 3.0.8-1
ii  libsystemd-shared   252.6-1
ii  systemd 252.6-1

Versions of packages systemd-resolved recommends:
ii  libnss-myhostname  252.6-1
pn  libnss-resolve 

Versions of packages systemd-resolved suggests:
ii  policykit-1  122-3
ii  polkitd  122-3

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Steve McIntyre (2023-05-15 02:54:02)
> On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> >On Sun, 14 May 2023 at 22:37, Josh Triplett  wrote:
> >
> >> The x86-64 ABI is set. Feel free to make the case to the next
> >> architecture designer that their new ABI should have the dynamic linker
> >> in `/usr/lib`. That would *not* have the same downsides, as long as
> >> everyone agrees on a path.
> >
> >In practice it is not, though. There are other distributions that
> >change PT_INTERP for their own purposes, they've already been listed
> >in this thread. And I am still not hearing any concrete, factual use
> >case that would be impaired by such a change. I'm beginning to
> >seriously think there aren't any? Is that really the case?
> 
> The ABI has been agreed and set down in documentation that *just
> about* everybody has been following since its inception. This includes
> the most basic set of definitions of what an x86-64 program must look
> like, including the interpreter path. If this path is changed, then
> *at the most basic level* we'd be making programs that are not valid
> by the ABI we've agreed to. This is an *external interface contract*,
> not something we should ever consider changing without significant
> cross- and inter-project discussion.
> 
> Pointing at gentoo or nixos as examples of projects that have decided
> to break compatibility doesn't cut it, I'm afraid. They're well known
> for changing fundamental things around Linux and (basically) not caring about
> interoperability. That attitude is *not* Debian's.

me and Luca have different ideas about how bootstrapping a Debian chroot should
look like and I don't want to make an argument *for* changing PT_INTERP here as
I think that keeping compatibility with others by following ABI is a good thing
and because I think (and hope -- but Helmut is doing that analysis right now)
that the debootstrap problem can be solved in a way I envision without changing
PT_INTERP. But what I do not understand about the argument against Luca's
proposal is:

Obviously, with Luca's proposal, binaries from packages built with a different
dynamic linker path in them would not work on distributions without merged-/usr
symlinks. But if the property of stuff from Debian being able to run on
non-Debian non-merged-/usr systems is an important one, then why was it okay to
have merged-/usr as the default? Because with merged-/usr we already changed
the interface contract for a lot of things because now binaries and libraries
can also be found at other locations than on non-merged-/usr systems. A script
with a /usr/bin/bash shebang built on and for Debian will not work on a system
without the symlinks.

So did we not years ago decide, that the result of the "cross- and
inter-project discussion" is, that everybody is going merged-/usr and that's
why we need it too and that's why it is okay to build a system where binaries
and scripts built for it just may not run on those other systems that do not do
it?  With merged-/usr we already *did* "change fundamental things around" for
reasons that are really not clear to me (but which i do not want to discuss
here) and as a result did not "care about interoperability" (with those who do
not also adopt it). In my own Debian work I so far only got extra work because
of merged-/usr and I do not see the benefits (yet) and I was hoping that
"changing fundamental things around Linux and (basically) not caring about
interoperability" was *not* Debian's attitude but alas here we are.

So have we not already burned the bridges to the non-merged-/usr world? Why was
it okay back then to say "we can make this change because all other important
players are doing merged-/usr so we can/have to as well". And now in the
PT_INTERP discussion somehow we care again about those systems? I thought we
already had the "cross- and inter-project discussion" about merged-/usr and
because the result was "yes, go for it" we did it too. But if that is the case,
why do we now care for a subset of the interoperability problems caused by
merged-/usr for systems that don't have it?

As I said, I don't care much about the PT_INTERP value but I don't understand
yet, why this argument about interoperability with non-merged-/usr systems is
working now but it didn't wasn't enough to stop another very fundamental change
in how we build a Linux distro.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1036076: rust-mysqlclient-sys appears to be unsound when used with mariadb.

[Peter Green]

Package: rust-mysqlclient-sys
Severity: serious

I was looking at why rust-diesel was not migrating to testing
(other than the freeze obviously) and noticed that rust-mysqlclient-sys
was not built on 32-bit architectures. As with a bunch of other
packages I correctly suspected this was mostly a case of unportable
bindgen-generated tests and started preparing fixes for them.

However while doing so, I rapidly came to the conclusion that something
else was wrong. Specifically I noticed significant discrepancies
between the "mysql" (actually mariadb) C headers on my system and the
rust bindings in rust-mysqlclient-sys.

The tests in the crate only test that the size/alignment of the
structures defined in the crate are consistent with what they were
when the bindings were generated. They do not check in any way that
they are consistent with the structures defined by the C headers on
the user's system. There are no functional tests either.

My conclusion is that attempting to use this crate with mariadb
is highly unsound, though I don't know enough about how the mysql
client library is used to determine in what way exactly it will break
and whether the breakage is likely to be immediately apparent or more
subtle.

Bug#1036075: liquidsoap: Binary link missing

[savoyard]

Package: liquidsoap
Version: 1.4.3-3
Severity: normal

Dear Maintainer,

enable_replaygain_metadata() looks for 
/usr/share/liquidsoap/1.4.3/bin/extract-replaygain by default:

2023/05/15 06:32:15 [extract.replaygain:4] Replaygain extraction failed: 
/bin/sh: 1: /usr/share/liquidsoap/1.4.3/bin/extract-replaygain: not found

This bug can be fixed by adding the following line to liquidsoap.links:

usr/share/liquidsoap/bin usr/share/liquidsoap/1.4.3/bin

Sincerely,

savoyard

-- 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 4.19.0 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages liquidsoap depends on:
ii  adduser   3.118
ii  curl  7.74.0-1.3+deb11u7
ii  libao41.2.2+20180113-1.1
ii  libasound21.2.4-1.1
ii  libavcodec58  7:4.3.6-0+deb11u1
ii  libavdevice58 7:4.3.6-0+deb11u1
ii  libavformat58 7:4.3.6-0+deb11u1
ii  libavutil56   7:4.3.6-0+deb11u1
ii  libc6 2.31-13+deb11u6
ii  libcamomile-ocaml-data1.0.2-3
ii  libexif12 0.6.22-3
ii  libfaad2  2.10.0-1
ii  libflac8  1.3.3-2+deb11u1
ii  libgavl1  1.4.0-5
ii  libgcc-s1 10.2.1-6
ii  libgd32.3.0-2
ii  libgif7   5.1.9-2
ii  libglib2.0-0  2.66.8-1
ii  libgstreamer-plugins-base1.0-01.18.4-2
ii  libgstreamer1.0-0 1.18.4-2.1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblo70.31-1
ii  libmad0   0.15.1b-10
ii  libmagic1 1:5.39-3
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.4-0.1
ii  libopus0  1.3.1-0.1
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-3
ii  libportaudio2 19.6.0-1.1
ii  libpulse0 14.2-2
ii  libsamplerate00.2.1+ds0-1
ii  libsdl-image1.2   1.2.12-12
ii  libsdl-ttf2.0-0   2.0.11-6
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libshine3 3.1.1-2
ii  libsoundtouch12.2+ds1-2
ii  libspeex1 1.2~rc1.2-1.1
ii  libssl1.1 1.1.1n-0+deb11u4
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.6-0+deb11u1
ii  libswscale5   7:4.3.6-0+deb11u1
ii  libtag1v5 1.11.1+dfsg.1-3
ii  libtheora01.1.1+dfsg.1-15
ii  libtiff5  4.2.0-1+deb11u4
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libxpm4   1:3.5.12-1.1~deb11u1
ii  ocaml-base-nox4.11.1-4
ii  sox   14.4.2+git20190427-2+deb11u2

Versions of packages liquidsoap recommends:
ii  logrotate 3.18.0-2+deb11u1
ii  vorbis-tools  1.4.0-11+b1
ii  vorbisgain0.37-2+b1

Versions of packages liquidsoap suggests:
pn  festival
ii  icecast22.4.4-4
pn  mplayer 
pn  youtube-dl  

-- no debconf information

Bug#1036067: [Pkg-nagios-devel] Bug#1036067: nagvis: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for the updated translation, it's committed in git.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1035568: dnsmasq is broken on new bookworm installations

[Trent W. Buck]

On Fri 05 May 2023 15:17:37 +, Jens Meißner wrote:
> dnsmasq on bookworm fails to start after installation because the dns port 53 
> is already is use by systemd-resolved.
> After stopping systemd-resolved dnsmasq will start but refuses all dns 
> queries with the Extended DNS Error Code 14 "Not Ready".
> This error is reproducible on new installation.

First of all, this should block dnsmasq.service (binary package "dnsmasq"), but
it should NOT block /usr/sbin/dnsmasq (binary package "dnsmasq-base").
The latter is needed by things like libvirtd and network-manager!



Here is how I solved this on my Debian 11 router:

  1. in /etc/dnsmasq.d/cyber-kludges.conf

  # Don't fight nsd and systemd-resolved for control over ports.
  # Also don't shit yourself at boot time if dnsmasq starts before the 
ifaces are up.
  # The combination of options is a little confusing.
  # "--ignore-address=203.7.155.4" does something COMPLETELY unrelated, so
  # instead we need to whitelist the OTHER dmz address (203.7.155.1).
  # Then we need to whitelist the other ifaces, else it would bind ONLY to 
203.7.155.1.
  bind-dynamic
  interface=lo
  interface=byod
  interface=lan
  listen-address=203.7.155.1
  no-dhcp-interface=dmz
  listen-address=10.194.71.1
  no-dhcp-interface=vpn
  except-interface=internet


  # Proxy DNSv4/DNSv6 from the internet.
  # HARD CODE the upstream servers.
  # We SHOULD get them dynamically from systemd-networkd (the 
DHCPv4/RA/DHCPv6 client on the "internet" interface).
  # However, that requires third-party software like 
https://gitlab.com/craftyguy/networkd-dispatcher
  # Since Aussie Broadband rarely (if ever) change these, hard-coding them 
is Good EnoughTM.
  # I considered also/instead adding the Cloudflare and/or Google anycast 
DNS servers from here:
  # https://github.com/systemd/systemd/blob/main/docs/DISTRO_PORTING.md
  # ...but those DNS servers will direct us to more distant hosts.
  # For example, "deb.debian.org" is
  #  8ms away using the address from AB or CF, but
  # 22ms away using the address from Google.
  no-resolv
  all-servers
  cache-size=8192
  server=202.142.142.142
  server=202.142.142.242
  server=2403:5800:100:1::142
  server=2403:5800:1:5::242

  # THIS BIT IS ONLY NEEDED BECAUSE I *ALSO* RUN NSD.
  # IT IS NOT NEEDED FOR systemd-resolve + dnsmasq.
  # Don't go out to the internet and back in, for our own domains.
  # This also means e.g. "logserv" still works when the internet is down.
  server=/cyber.com.au/155.7.203.in-addr.arpa/203.7.155.4

  2. in /etc/systemd/network/00-dmz.network, tell systemd-networkd (and thus 
resolved) about dnsmasq

  [Match]
  Name=dmz
  [Link]
  RequiredForOnline=no
  [Network]
  Domains=cyber.com.au
  Address=203.7.155.1/26
  Address=203.7.155.4/26
  Address=203.7.155.49/26
  # THESE NEXT TWO LINES ARE THE RELEVANT ONES FOR 1035568
  Domains=cyber.com.au ~155.7.203.in-addr.arpa
  DNS=203.7.155.1

   3. install libnss-resolve and make this link

  lrwxrwxrwx 1 root root 24 Feb 24  2021 /etc/resolv.conf -> 
/lib/systemd/resolv.conf

In other words, what I have is:

  a. local nss users go

   libnss_resolve
   -> resolved (via socket)
  -> dnsmasq on 203.7.155.1 (for cyber.com.au and 
155.7.203.in-addr.arpa)

  -> whatever systemd-networkd got from upstream DHCP/DHCPv6 (for every 
other domain)

  b. local /etc/resolv.conf users go

   -> resolved on 127.0.0.53 (via UDP)
   [rest as above]

Because of the quirky way to code this in dnsmasq,
there is no good way to write a general default dnsmasq.conf to hook it up this 
way.

The other potential way to hook this up is to simply tell resolved not to 
listen on 127.0.0.53:53 (DNSStubListener=no in /etc/systemd/resolved.conf).
HOWEVER, it then means that name resolution is different for glibc (nss) versus 
everyone else, because

  a. local nss users go

 libnss_resolve
 -> resolved (via socket)
 -> whatever systemd-networkd got from upstream DHCP/DHCPv6 (for all 
domains)

 ...NEVER see RRs in dnsmasq.

  b. local resolv.conf users cannot go to resolved, because it now only listens 
on a AF_UNIX socket, not AF_DGRAM (UDP).

 So it either points directly upstream (typical legacy setup in dhclient) 
and bypasses BOTH dnsmasq and resolved; or
 it's set to 127.0.0.1 (i.e. dnsmasq) and bypasses resolved.

 Note that networkd has NO WAY to tell dnsmasq what DNS server(s) are 
supplied by upstream .network files / DHCP responses.
 networkd can only tell resolved that (I last checked back in v247).


PS: I have also seen deeply inconsistent results when there are unqualified 
names in /etc/hosts (e.g. "10.1.2.3 alice")
because libnss_files.so, dnsmasq, and resolved treat those differently.  In 
essence, 

Bug#1035850: groovy: missing Depends/Recommends/Suggests: libjsp-api-java ?

[tony mancill]

On Wed, May 10, 2023 at 09:15:40AM +0200, Andreas Beckmann wrote:
> Package: groovy
> Version: 2.4.21-7
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> 0m28.4s ERROR: FAIL: Broken symlinks:
>   /usr/share/groovy/lib/jsp-api.jar -> ../../java/jsp-api.jar (groovy)

Thank you for the bug report Andreas.  This bug was introduced when I
updated the package to switch to depend on libservlet-api-java instead
of libservlet3.1-java.

(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020429)

I will add the missing dependency.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Mon, 15 May 2023 at 02:26, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That's self-evidently not true, as there are other distributions where
> > that already happens, it's been already mentioned.
>
> You've mentioned this a couple of times but I don't think I've seen the
> message where the details were explained.  Maybe this was only in your
> message posted to debian-gcc, which wasn't part of this thread?  (It's
> also possible that I just missed it somewhere.)
>
> That message only mentions GUIX, which I don't know very much about, but
> my recollection (maybe wrong?) is that it's a NIX variant that is doing
> special tricks to support immutable package trees and
> roll-forward/roll-back upgrades.  I can see why that might be motivation
> to build incompatible binaries in order to preserve some other invariant
> they're trying for as the point of their distribution (in particular, I
> suspect they're pinning binaries to a specific version of the dynamic
> loader as part of the whole immutable tree strategy).  That's a perfectly
> fine decision in a distribution that's trying to do something very
> different and is a bit of a science experiment, but I don't think that
> describes Debian.
>
> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, major
> player in Linux distributions, and I'm not sure how much they care about
> compatibility with anyone else.)

This is a counter-example to confute the assertion that *everybody*
does the same thing, which has been made multiple times. I'm not sure
whether it's an experiment or not, I mean if you ask their
users/developers I think they'd tell you it's very much production
ready, but it is largely irrelevant: it exists, and that's the only
reason why it was mentioned, as it shows that it is _possible_ to do
that and be a working distribution. Doesn't imply it's automatically
desirable, but that was not the intention.

> > Besides, we are not talking about sacred religious texts - the point is
> > making things work. If they do, is it _really_
> > non-compliant/incompatible?
>
> I understand your point in making this argument, but please understand
> that this sort of willingness to change things if one didn't think they
> would cause problems didn't work very well, and was part of what led to
> the development of standardized ABIs in the first place.  Those of us who
> have been around longer than Linux have ABIs have a bit of a strong
> reaction here (I think this is also what you're seeing from Steve),
> because we remember the bad old days.  I still have compatibility code
> around to handle the fact that gcc on IRIX miscompiled calls to inet_ntoa
> because gcc didn't correctly implement the IRIX ABI.
>
> People are very bad at judging whether their new idea would be *really*
> incompatible.  This is why these days everyone tries to follow the ABI
> pretty closely.
>
> And in any case, changing PT_INTERP is trivially and obviously
> incompatible; the binary will simply not run on a system that doesn't have
> that path.  So it's not like we have to carefully judge nuance here.  Your
> argument, so far as I can tell, is basically "but no one will ever want to
> run those binaries on a non-/usr-merged system anyway," which is basically
> conceding the incompatibility point since the ABI doesn't require merged
> /usr.

Not quite: my argument is that binaries from these packages are not
intended and not required to be ran on non-Debian systems, so there's
no incompatibility introduced in the first place - everything still
works where it is supposed to, exactly as it was before.

> There's also some other history here: Debian is not super-happy with the
> PT_INTERP because ideally we'd prefer it use a path compatible with our
> multiarch approach.  I believe we raised that and no one had any interest
> in trying to change anything, so we lived with the limitations that
> creates.  (And I think that was the right decision.)
>
> > Thanks, that's the first actual real example mentioned so far. And it's
> > an interesting one: taking a $random Debian package and using it on a
> > completely different, non-Debian system. Is that a supported use case?
> > If so, does that mean that I can go ahead and raise a Severity: serious
> > bug on any package that doesn't work in such a way?
>
> I feel like you're distorting my argument here to try to make some sort of
> slippery slope argument, and it's coming across as possibly more
> aggressive than you had intended.

No aggression intended whatsoever, sorry if it appeared that way. I am
trying to understand what the rules are.

> The world does not divide neatly into supported and unsupported use cases.
> There are a lot of things I do to computers that I expect to work in some
> situations but not in others.  That includes, say, having a Debian chroot
> on some other OS and running binaries from that chroot without going into
> the chroot.  Often that will absolutely not work.  Sometimes it will 

Bug#1036071: libgsl27: please add Breaks: libgsl25 for smoother opgrades from bullseye

[Dirk Eddelbuettel]

On 15 May 2023 at 03:15, Andreas Beckmann wrote:
| On 15/05/2023 02.58, Dirk Eddelbuettel wrote:
| > | Yes thank you -- that sounds sensible.  And we would then nag the release
| > | team to get this out in the release?
| 
| yes
| 
| > Oh, and to be extra plain: upload to unstable as a 'serious' bug fix?
| 
| Yes, without extra changes that do not qualify as targeted fixes.

Fully agreed.  Coming right up as a one-line fix per your one-line diff.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1036074: brasero: Brasero crashes on second copy-to-file (.iso)

[bud]

Package: brasero
Version: 3.12.3-2
Severity: normal
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
I copied the 21 DVDs from testing into disk.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I started from the menu invocation. Brasero accurately detected the DVD and 
suggested a file name. I could not navigate to the desired directory, by the 
way. The copy completed and I used the .iso without problems later. I removed 
the DVD (in various methods, including the Brasero menu action), inserted 
another DVD (again in sundry ways, waiting until after selecting the DVD->disk 
copy function again did not cause a crash immediately) and clicked on Disk Copy 
again crashed Brasero. The copy completed once, although Brasero did not show 
the final dialog which would allow returning to the main dialog, so I had to 
kill Brasero then.
I switched to the command line and the manual page indicates "copy=PATH". I 
looked for a more complete explanation before trying first, the output desired 
path, then /media/cdrom, then /dev/sr0, which Brasero accepted. Brasero also 
quits back to the shell, so there is no clear way to try for a second copy that 
way.
At least four of the copies stalled. Brasero simply kept trying without a 
timeout. At least two of these DVDs showed no artifacts impeding burning or 
reading. In each case I cleaned the DVD and burned it again (using Brasero on 
buster). Since my goal was to ensure the copies completed accurately, I count 
it as a success.

   * What was the outcome of this action?
Brasero crashes when asked to copy a second DVD to disk in a single session. 
   * What outcome did you expect instead?
I expect that the copy function should work until the user closes the 
application.

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

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

Versions of packages brasero depends on:
ii  brasero-common  3.12.3-2
ii  gstreamer1.0-plugins-base   1.22.0-3
ii  gvfs1.50.3-1
ii  libbrasero-media3-1 3.12.3-2
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-3-0  3.24.37-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libtotem-plparser18 3.26.6-1+b1
ii  libtracker-sparql-3.0-0 3.4.2-1
ii  libxml2 2.9.14+dfsg-1.2

Versions of packages brasero recommends:
ii  brasero-cdrkit  3.12.3-2
ii  yelp42.2-1

Versions of packages brasero suggests:
pn  libdvdcss2  
ii  tracker 3.4.2-1
pn  vcdimager   

-- no debconf information

Bug#1023585: lists.debian.org: create debian-loongarch: for new port loong64 (LoongArch 64 bits little-endian)

[Bo YU]

Package: lists.debian.org
Followup-For: Bug #1023585

Dear Maintainer,

I thought the upstream support for loong64 is well and it is in suitable
situation to port it on Debian. They almost finished the rebootstrap and
to wait to be added into buildd.d.o. IIMC. If the debian-loongarch mail
list was created will push the procedure.

TBH I am not a real user/developer as RISC-V porter but I can offer my
help if I can in feature.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Russ Allbery]

Luca Boccassi  writes:

> That's self-evidently not true, as there are other distributions where
> that already happens, it's been already mentioned.

You've mentioned this a couple of times but I don't think I've seen the
message where the details were explained.  Maybe this was only in your
message posted to debian-gcc, which wasn't part of this thread?  (It's
also possible that I just missed it somewhere.)

That message only mentions GUIX, which I don't know very much about, but
my recollection (maybe wrong?) is that it's a NIX variant that is doing
special tricks to support immutable package trees and
roll-forward/roll-back upgrades.  I can see why that might be motivation
to build incompatible binaries in order to preserve some other invariant
they're trying for as the point of their distribution (in particular, I
suspect they're pinning binaries to a specific version of the dynamic
loader as part of the whole immutable tree strategy).  That's a perfectly
fine decision in a distribution that's trying to do something very
different and is a bit of a science experiment, but I don't think that
describes Debian.

(Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, major
player in Linux distributions, and I'm not sure how much they care about
compatibility with anyone else.)

> Besides, we are not talking about sacred religious texts - the point is
> making things work. If they do, is it _really_
> non-compliant/incompatible?

I understand your point in making this argument, but please understand
that this sort of willingness to change things if one didn't think they
would cause problems didn't work very well, and was part of what led to
the development of standardized ABIs in the first place.  Those of us who
have been around longer than Linux have ABIs have a bit of a strong
reaction here (I think this is also what you're seeing from Steve),
because we remember the bad old days.  I still have compatibility code
around to handle the fact that gcc on IRIX miscompiled calls to inet_ntoa
because gcc didn't correctly implement the IRIX ABI.

People are very bad at judging whether their new idea would be *really*
incompatible.  This is why these days everyone tries to follow the ABI
pretty closely.

And in any case, changing PT_INTERP is trivially and obviously
incompatible; the binary will simply not run on a system that doesn't have
that path.  So it's not like we have to carefully judge nuance here.  Your
argument, so far as I can tell, is basically "but no one will ever want to
run those binaries on a non-/usr-merged system anyway," which is basically
conceding the incompatibility point since the ABI doesn't require merged
/usr.

There's also some other history here: Debian is not super-happy with the
PT_INTERP because ideally we'd prefer it use a path compatible with our
multiarch approach.  I believe we raised that and no one had any interest
in trying to change anything, so we lived with the limitations that
creates.  (And I think that was the right decision.)

> Thanks, that's the first actual real example mentioned so far. And it's
> an interesting one: taking a $random Debian package and using it on a
> completely different, non-Debian system. Is that a supported use case?
> If so, does that mean that I can go ahead and raise a Severity: serious
> bug on any package that doesn't work in such a way?

I feel like you're distorting my argument here to try to make some sort of
slippery slope argument, and it's coming across as possibly more
aggressive than you had intended.

The world does not divide neatly into supported and unsupported use cases.
There are a lot of things I do to computers that I expect to work in some
situations but not in others.  That includes, say, having a Debian chroot
on some other OS and running binaries from that chroot without going into
the chroot.  Often that will absolutely not work.  Sometimes it will work,
and it's convenient that it will work for some obscure recovery situations
or other weird one-off use cases.  I've also copied files from working
systems to broken systems running a different distribution before, and
there's a list of caveats as long as my arm, but sometimes it's a quick
fix for something.

But mostly my reaction is because breaking the ABI is a Really Big Deal.
Constructing the Linux ABI and getting the details actually published was
a hard-fought, arduous endeavor.  I doubt anyone enjoyed it; it's the sort
of annoying compatibility work that provides tons of small, subtle
benefits and takes a great deal of truly thankless work, and people often
don't realize all the tiny ways that it has made the world a better place,
or the range of weird compatibility problems that can arise from messing
with it.  Diverging from it is not something to do lightly, precisely
*because* it's often extremely difficult to understand what the effects
could be or what might break.

While I appreciate how it would make bootstrapping Debian somewhat more

Bug#1036073: libtbb12: please add Breaks against libtbb2 for smoother upgrades from bullseye

[Andreas Beckmann]

Package: libtbb12
Version: 2021.8.0-1
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

libtbb2 from bullseye and libtbb12 from bookworm are not co-installable
due to libtbbmalloc2. But such transitive conflicts are sometimes hard
for apt to figure out correctly, and instead it tries to keep obsolete
packages installed and upgradable packages at the older version.
Turning the transitive conflict on a lower scoring package) into an
explicit one (on a package with a higher score) makes apt to the right
thing: remove (a stack of) obsolete library packages in order toinstall
new ones and upgrade dependencies.

Please consider applying the attached patch.


Andreas

(unless someone beats me to it, I'll take care of this one)
>From dc76321a128d4defcc1e77d0f5712743b8b4f84b Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Mon, 8 May 2023 19:33:51 +0200
Subject: [PATCH] libtbb12: add explicit Breaks against libtbb2

---
 debian/changelog | 8 
 debian/control   | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 7aa18445..f0b2b28a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+onetbb (2021.8.0-2) UNRELEASED; urgency=medium
+
+  * libtbb12: Add explicit Breaks against libtbb2 for smoother upgrades from
+bullseye. The the existing transitive Breaks via libtbbmalloc2 is not
+sufficient for all upgrade paths.  (Closes: #)
+
+ -- Andreas Beckmann   Mon, 08 May 2023 19:29:28 +0200
+
 onetbb (2021.8.0-1) unstable; urgency=medium
 
   * New upstream version 2021.8.0
diff --git a/debian/control b/debian/control
index 81ee5679..9f5dbeb1 100644
--- a/debian/control
+++ b/debian/control
@@ -48,6 +48,8 @@ Depends: libtbbmalloc2 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
+Breaks:
+ libtbb2 (<< 2021),
 Description: parallelism library for C++ - runtime files
  TBB is a library that helps you leverage multi-core processor
  performance without having to be a threading expert. It represents a
-- 
2.20.1

Bug#1036071: libgsl27: please add Breaks: libgsl25 for smoother opgrades from bullseye

[Andreas Beckmann]

On 15/05/2023 02.58, Dirk Eddelbuettel wrote:

| Yes thank you -- that sounds sensible.  And we would then nag the release
| team to get this out in the release?


yes


Oh, and to be extra plain: upload to unstable as a 'serious' bug fix?


Yes, without extra changes that do not qualify as targeted fixes.

Andreas

Bug#1036072: libuhd4.3.0: please add Breaks against libuhd3.15.0 for smoother upgrades from bullseye

[Andreas Beckmann]

Package: libuhd4.3.0
Version: 4.3.0.0+ds1-4
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

while libuhd3.15.0 from bullseye and libuhd4.3.0 from bookworm are
co-installable (by keeping libboost-regex1.74.0 at the bullseye version
which provides the virtual libboost-regex1.74.0-icu67), this causes apt
on several bullseye->bookworm upgrade paths to keep the obsolete
libboost-regex1.74.0-icu67 installed by not upgrading some upgradable
packages.
If we instead add a Breaks against the obsolete libuhd3.15.0, this will
help apt making the right choice: removing libuhd3.15.0 (and a bunch of
other obsolete libraries depending on it), making
libboost-regex1.74.0-icu67 less used and easier to be replaced with
libboost-regex1.74.0-icu72 (by simply upgrading libboost-regex1.74.0).

Please consider applying the attached patch.


Andreas
diff -Nru uhd-4.3.0.0+ds1/debian/changelog uhd-4.3.0.0+ds1/debian/changelog
--- uhd-4.3.0.0+ds1/debian/changelog2022-12-16 04:21:07.0 +0100
+++ uhd-4.3.0.0+ds1/debian/changelog2023-05-11 12:21:51.0 +0200
@@ -1,3 +1,10 @@
+uhd (4.3.0.0+ds1-5) UNRELEASED; urgency=medium
+
+  * libuhd4.3.0: Add Breaks: libuhd3.15.0 for smoother upgrades from bullseye.
+(Closes: #)
+
+ -- Andreas Beckmann   Thu, 11 May 2023 12:21:51 +0200
+
 uhd (4.3.0.0+ds1-4) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff -Nru uhd-4.3.0.0+ds1/debian/control uhd-4.3.0.0+ds1/debian/control
--- uhd-4.3.0.0+ds1/debian/control  2022-09-13 04:47:53.0 +0200
+++ uhd-4.3.0.0+ds1/debian/control  2023-05-11 12:21:50.0 +0200
@@ -63,6 +63,7 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Suggests: uhd-host
+Breaks: libuhd3.15.0 (<< 4)
 Multi-Arch: same
 Description: universal hardware driver for Ettus Research products - library
  Host library for the Universal Hardware Driver for Ettus Research products.

Bug#1036071: libgsl27: please add Breaks: libgsl25 for smoother opgrades from bullseye

[Dirk Eddelbuettel]

On 14 May 2023 at 19:50, Dirk Eddelbuettel wrote:
| 
| On 15 May 2023 at 02:21, Andreas Beckmann wrote:
| | Package: libgsl27
| | Version: 2.7.1+dfsg-3
| | Severity: serious
| | Tags: patch
| | User: debian...@lists.debian.org
| | Usertags: piuparts
| | 
| | Hi,
| | 
| | libgsl25 from bullseye and libgsl27 from bookworm are not co-installable
| | due to their strict dependency on libgslcblas0. Sometimes apt has
| | problems handling this transitive conflict correctly (i.e. removing the
| | obsolete library) and instead tries to keep the obsolete package
| | installed and hold some upgradable packages at their bullseye versions.
| | Turning the transitive conflict into an explicit one helps apt making
| | the right choice.
| | 
| | Please consider applying the attached patch.
| 
| Yes thank you -- that sounds sensible.  And we would then nag the release
| team to get this out in the release?

Oh, and to be extra plain: upload to unstable as a 'serious' bug fix?

Dirk

| Dirk
|  
|  
| | Andreas
| | x[DELETED ATTACHMENT 
0001-libgsl27-Add-Breaks-libgsl25-for-smoother-upgrades-f.patch, plain text]
| 
| -- 
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Steve McIntyre]

I'm *trying* to assume good faith here, but I'm running out of energy
to do so.

On Mon, May 15, 2023 at 01:42:27AM +0100, Luca Boccassi wrote:
>On Mon, 15 May 2023 at 01:14, Russ Allbery  wrote:
>
>> Incidentally, that remains true even if we only do that in distribution
>> packages.  I certainly have copied binaries from a Debian package to other
>> Linux systems before for various reasons and expected them to run.  Sure,
>> this might not work for other reasons outside of our control, but that's
>> no reason to be gratuitously incompatible by breaking the ABI,
>> particularly for what seem to be annoyances of our own creation with known
>> workarounds.
>
>Thanks, that's the first actual real example mentioned so far. And
>it's an interesting one: taking a $random Debian package and using it
>on a completely different, non-Debian system. Is that a supported use
>case? If so, does that mean that I can go ahead and raise a Severity:
>serious bug on any package that doesn't work in such a way?

Russ has described copying *binaries* out of packages and running them
elsewhere. I've done that too, from time to time. This is one of the
things made possible by the ABI contract being followed.

You are the one proposing to break that contract, thereby
*guaranteeing* this will fail on systems where otherwise it could
work. I think the onus is on *you* to justify why this is a valid and
useful thing to do. Your apparent lack of care for agreed standards
here is horrifying.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Steve McIntyre]

On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
>On Sun, 14 May 2023 at 22:37, Josh Triplett  wrote:
>
>> The x86-64 ABI is set. Feel free to make the case to the next
>> architecture designer that their new ABI should have the dynamic linker
>> in `/usr/lib`. That would *not* have the same downsides, as long as
>> everyone agrees on a path.
>
>In practice it is not, though. There are other distributions that
>change PT_INTERP for their own purposes, they've already been listed
>in this thread. And I am still not hearing any concrete, factual use
>case that would be impaired by such a change. I'm beginning to
>seriously think there aren't any? Is that really the case?

The ABI has been agreed and set down in documentation that *just
about* everybody has been following since its inception. This includes
the most basic set of definitions of what an x86-64 program must look
like, including the interpreter path. If this path is changed, then
*at the most basic level* we'd be making programs that are not valid
by the ABI we've agreed to. This is an *external interface contract*,
not something we should ever consider changing without significant
cross- and inter-project discussion.

Pointing at gentoo or nixos as examples of projects that have decided
to break compatibility doesn't cut it, I'm afraid. They're well known
for changing fundamental things around Linux and (basically) not
caring about interoperability. That attitude is *not* Debian's.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Bug#1036071: libgsl27: please add Breaks: libgsl25 for smoother opgrades from bullseye

[Dirk Eddelbuettel]

On 15 May 2023 at 02:21, Andreas Beckmann wrote:
| Package: libgsl27
| Version: 2.7.1+dfsg-3
| Severity: serious
| Tags: patch
| User: debian...@lists.debian.org
| Usertags: piuparts
| 
| Hi,
| 
| libgsl25 from bullseye and libgsl27 from bookworm are not co-installable
| due to their strict dependency on libgslcblas0. Sometimes apt has
| problems handling this transitive conflict correctly (i.e. removing the
| obsolete library) and instead tries to keep the obsolete package
| installed and hold some upgradable packages at their bullseye versions.
| Turning the transitive conflict into an explicit one helps apt making
| the right choice.
| 
| Please consider applying the attached patch.

Yes thank you -- that sounds sensible.  And we would then nag the release
team to get this out in the release?

Dirk
 
 
| Andreas
| x[DELETED ATTACHMENT 
0001-libgsl27-Add-Breaks-libgsl25-for-smoother-upgrades-f.patch, plain text]

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Mon, 15 May 2023 at 01:14, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > Why would "software compiled on Debian" fail to work in other
> > environments? Well, there are many reasons actually, people invented
> > containers/flatpaks/snaps exactly for that reason. But nothing do with
> > anything discussed here though, as far as I can tell?
>
> My understanding is that this specific thread is about a mention that we
> may want to change PT_INTERP to /usr/lib64/ld-linux-x86-64.so.2 or some
> similar path.
>
> If PT_INTERP points to a file that doesn't exist, the program is obviously
> not going to run.  The Linux x86_64 ABI says it must point to
> /lib64/ld-linux-x86-64.so.2.  If we build binaries that use some other
> value, then we are not building ABI-compliant binaries and they may not
> run on other systems.  This is the whole point of an ABI.

This is not about locally compiled software or such, only packages
(and maybe even just a subset of them).

> An obvious specific example of such a system would be one that didn't
> merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other
> path, but that's just one obvious example.  There may be others; the whole
> point of an ABI is that you do not change things like this, not even if
> you can't personally imagine why your change wouldn't be harmful.  There's
> a whole process for changing an ABI that involves everyone else agreeing
> as well, and unless one goes through that process, the ABI is what it is.
> Debian not building ABI-compliant binaries would be highly surprising.

That's self-evidently not true, as there are other distributions where
that already happens, it's been already mentioned. Besides, we are not
talking about sacred religious texts - the point is making things
work. If they do, is it _really_ non-compliant/incompatible?

> Incidentally, that remains true even if we only do that in distribution
> packages.  I certainly have copied binaries from a Debian package to other
> Linux systems before for various reasons and expected them to run.  Sure,
> this might not work for other reasons outside of our control, but that's
> no reason to be gratuitously incompatible by breaking the ABI,
> particularly for what seem to be annoyances of our own creation with known
> workarounds.

Thanks, that's the first actual real example mentioned so far. And
it's an interesting one: taking a $random Debian package and using it
on a completely different, non-Debian system. Is that a supported use
case? If so, does that mean that I can go ahead and raise a Severity:
serious bug on any package that doesn't work in such a way?

Kind regards,
Luca Boccassi

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

[Otto Kekäläinen]

This is not a fix, but could help make the situation easier to
detect/debug for users:

* https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14
* https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/37

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Mon, 15 May 2023 at 01:07, Peter Pentchev  wrote:
>
> On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> > On Sun, 14 May 2023 at 22:37, Josh Triplett  wrote:
> > >
> > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > > > The loader is still available via the old path, so external/third
> > > > party/local/other software works unchanged. This should negatively
> > > > only affect our 1st party packages, when running on a non-merged
> > > > distro.
> > > > And are _all_ our packages really 100% compatible with other distros
> > > > at all? Are they even supposed to be?
> > >
> > > People build things on Debian that are not Debian packages. People
> > > compile binaries on Debian, and expect them to work on any system that
> > > has sufficiently new libraries.
> > >
> > > This is *not* about Debian packages failing to work on other
> > > distributions; this is about *software compiled on Debian* faliing to
> > > work in other environments.
> >
> > Why would "software compiled on Debian" fail to work in other
> > environments? Well, there are many reasons actually, people invented
> > containers/flatpaks/snaps exactly for that reason. But nothing do with
> > anything discussed here though, as far as I can tell?
>
> If an ELF executable, compiled on Debian, records its interpreter as
> /usr/lib/ld-linux.so.2, what happens when one tries to run it on
> a non-usr-merged system? Even one with a recent enough glibc version?

This is not about locally built ELF executables, no difference in those.

Kind regards,
Luca Boccassi

Bug#1036071: libgsl27: please add Breaks: libgsl25 for smoother opgrades from bullseye

[Andreas Beckmann]

Package: libgsl27
Version: 2.7.1+dfsg-3
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

libgsl25 from bullseye and libgsl27 from bookworm are not co-installable
due to their strict dependency on libgslcblas0. Sometimes apt has
problems handling this transitive conflict correctly (i.e. removing the
obsolete library) and instead tries to keep the obsolete package
installed and hold some upgradable packages at their bullseye versions.
Turning the transitive conflict into an explicit one helps apt making
the right choice.

Please consider applying the attached patch.


Andreas
>From 921fc21217b8f1d517b021e30ec86d443975694f Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 11 May 2023 11:28:11 +0200
Subject: [PATCH] libgsl27: Add Breaks: libgsl25 for smoother upgrades from
 bullseye

libgsl27 and libgsl25 are not co-installable due to their strict
dependency on libgslcblas0. Let's make the transitive conflict explicit
to help apt making the right choice, i.e. remove the obsolete library.

Closes: #
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 52d4b6a..350c94d 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, libgslcblas0 (= ${binary:Version})
 Conflicts: gsl, libgsl0, libgsl0ldbl
+Breaks: libgsl25
 Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4)
 Suggests: gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html
 Description: GNU Scientific Library (GSL) -- library package 
-- 
2.20.1

Bug#1036070: libboost-thread1.74.0: please add Breaks against libboost-regex1.74.0-icu67

[Andreas Beckmann]

Package: libboost-thread1.74.0
Version: 1.74.0+ds1-20
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

while analyzing piuparts bullseye->bookworm upgrade logs, I noticed
several cases where apt has problems upgrading libboost-regex1.74.0
because obsolete packages depending on the virtual package
libboost-regex1.74.0-icu67 make apt keep the old version installed.
The new version provides libboost-regex1.74.0-icu72, but the score
between the two virtual ones is usually a tie, favoring the installed
one.

While there is no direct dependency relationship between
libboost-regex1.74.0 and libboost-thread1.74.0, in all cases I looked
into libboost-thread1.74.0 was installed, too, and had a higher score,
thus making it an ideal candidate for adding some Breaks.

One prominent example is wesnoth which fails to upgrade:

...
  Starting 2 pkgProblemResolver with broken count: 2
  Investigating (0) wesnoth-1.14-core:amd64 < 1:1.14.15-1 @ii mK Ib >
  Broken wesnoth-1.14-core:amd64 Depends on libboost-regex1.74.0-icu67:amd64 < 
none @un H >
Considering libboost-regex1.74.0:amd64 1 as a solution to 
wesnoth-1.14-core:amd64 34
Added libboost-regex1.74.0:amd64 to the remove list
Fixing wesnoth-1.14-core:amd64 via keep of libboost-regex1.74.0:amd64
  Investigating (0) wesnoth-1.16-core:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-core:amd64 Depends on libboost-regex1.74.0-icu72:amd64 < 
none @un H >
Considering libboost-regex1.74.0:amd64 1 as a solution to 
wesnoth-1.16-core:amd64 33
Holding Back wesnoth-1.16-core:amd64 rather than change 
libboost-regex1.74.0-icu72:amd64
   Try to Re-Instate (0) libboost-regex1.74.0:amd64
  Investigating (0) wesnoth-1.16-utbs:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-utbs:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-utbs:amd64 0
Holding Back wesnoth-1.16-utbs:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-trow:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-trow:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-trow:amd64 0
Holding Back wesnoth-1.16-trow:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-dw:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-dw:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-dw:amd64 0
Holding Back wesnoth-1.16-dw:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-dm:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-dm:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-dm:amd64 0
Holding Back wesnoth-1.16-dm:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-sof:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-sof:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-sof:amd64 0
Holding Back wesnoth-1.16-sof:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-ei:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-ei:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-ei:amd64 0
Holding Back wesnoth-1.16-ei:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-nr:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-nr:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-nr:amd64 0
Holding Back wesnoth-1.16-nr:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-tsg:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-tsg:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-tsg:amd64 0
Holding Back wesnoth-1.16-tsg:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-ttb:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken wesnoth-1.16-ttb:amd64 Depends on wesnoth-1.16-core:amd64 < none | 
1:1.16.9-1 @un uH > (>= 1:1.16)
Considering wesnoth-1.16-core:amd64 33 as a solution to 
wesnoth-1.16-ttb:amd64 0
Holding Back wesnoth-1.16-ttb:amd64 rather than change 
wesnoth-1.16-core:amd64
  Investigating (0) wesnoth-1.16-sotbe:amd64 < none -> 1:1.16.9-1 @un uN Ib >
  Broken 

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Russ Allbery]

Luca Boccassi  writes:

> Why would "software compiled on Debian" fail to work in other
> environments? Well, there are many reasons actually, people invented
> containers/flatpaks/snaps exactly for that reason. But nothing do with
> anything discussed here though, as far as I can tell?

My understanding is that this specific thread is about a mention that we
may want to change PT_INTERP to /usr/lib64/ld-linux-x86-64.so.2 or some
similar path.

If PT_INTERP points to a file that doesn't exist, the program is obviously
not going to run.  The Linux x86_64 ABI says it must point to
/lib64/ld-linux-x86-64.so.2.  If we build binaries that use some other
value, then we are not building ABI-compliant binaries and they may not
run on other systems.  This is the whole point of an ABI.

An obvious specific example of such a system would be one that didn't
merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other
path, but that's just one obvious example.  There may be others; the whole
point of an ABI is that you do not change things like this, not even if
you can't personally imagine why your change wouldn't be harmful.  There's
a whole process for changing an ABI that involves everyone else agreeing
as well, and unless one goes through that process, the ABI is what it is.
Debian not building ABI-compliant binaries would be highly surprising.

Incidentally, that remains true even if we only do that in distribution
packages.  I certainly have copied binaries from a Debian package to other
Linux systems before for various reasons and expected them to run.  Sure,
this might not work for other reasons outside of our control, but that's
no reason to be gratuitously incompatible by breaking the ABI,
particularly for what seem to be annoyances of our own creation with known
workarounds.

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

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Peter Pentchev]

On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> On Sun, 14 May 2023 at 22:37, Josh Triplett  wrote:
> >
> > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > > The loader is still available via the old path, so external/third
> > > party/local/other software works unchanged. This should negatively
> > > only affect our 1st party packages, when running on a non-merged
> > > distro.
> > > And are _all_ our packages really 100% compatible with other distros
> > > at all? Are they even supposed to be?
> >
> > People build things on Debian that are not Debian packages. People
> > compile binaries on Debian, and expect them to work on any system that
> > has sufficiently new libraries.
> >
> > This is *not* about Debian packages failing to work on other
> > distributions; this is about *software compiled on Debian* faliing to
> > work in other environments.
> 
> Why would "software compiled on Debian" fail to work in other
> environments? Well, there are many reasons actually, people invented
> containers/flatpaks/snaps exactly for that reason. But nothing do with
> anything discussed here though, as far as I can tell?

If an ELF executable, compiled on Debian, records its interpreter as
/usr/lib/ld-linux.so.2, what happens when one tries to run it on
a non-usr-merged system? Even one with a recent enough glibc version?

G'luck,
Peter
 
-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1036069: gnat: 'gprconfig --show-targets' fails with constraint_error

[Ian Stewart]

Package: gnat
Version: 12.2
Severity: normal
X-Debbugs-Cc: eki...@gmail.com


Reproduction Steps:
1. Install 'gnat' and 'gnat-mingw-w64-x86-64-posix' from package
manager.
2. Run 'gprconfig --show-targets'.

Current Behavior: 

The invocation fails with 'raised CONSTRAINT_ERROR : gpr-names.adb:231 range 
check failed'

Expected Behavior:

A listing of 'x86_64-gnu-linux' and 'x86_64-windows' as available
targets is displayed.

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

Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/24 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gnat depends on:
ii  gnat-12  12.2.0-14

gnat recommends no packages.

Versions of packages gnat suggests:
pn  ada-reference-manual-2012  

-- no debconf information

Bug#1036068: design-desktop-animation: uninstallable on 32-bit architecturs due to blender

[Andreas Beckmann]

Package: design-desktop-animation
Version: 3.0.27
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is uninstallable on
32-bit architectures since it depends on blender which is only available
on 64-bit architectures nowadays.

I'm not sure whether this is somehow expressable in the dependencies of
an arch:all package.


cheers,

Andreas

Bug#1034908: Update libabsl-dev to new upstream version/snapshot for newer protobuf

[Benjamin Barenblat]

Control: owner 1034908 !

On Sun, 30 Apr 2023 22:29:27 -0500 Steven Robbins  wrote:
> The reported build error is:
> 
> dpkg-shlibdeps: error: cannot find library libgtest.so.1.12.1 needed by 
> debian/libabsl20230125/usr/lib/x86_64-linux-gnu/
> libabsl_per_thread_sem_test_common.so.20230125.0.0 
> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
> 
> How did libabsl20230125 get such a dependency?  Debian has never shipped 
> libgtest.so -- was this built against a locally-built libgtest
> somehow?

Yes. Historically, Abseil has dynamically linked its unit tests against
a one-off libgtest.so built from /usr/src/googletest. Depending on the
local libgtest.so was never a problem because Abseil never shipped any
public libraries that depended on GoogleTest. As of 20230125, however,
Abseil ships a library that (a) is intended for public consumption and
(b) depends on GoogleTest, which brings us to this issue.

> My recommendation is to preferably build libgtest in your own build process 
> -- 
> this ensures gtest is built with the same compiler options as your test code; 
> or else link against the provided static libgtest.a.

On Mon, 1 May 2023 18:39:06 +0530 Praveen Arimbrathodiyil 
 wrote:
> I will leave it to abseil maintainer to decide which approach to take.

I’m about to do an upload to experimental that encourages the first
option. abseil 20230125.3-1 and later will avoid shipping dynamic
libraries for any Abseil library that depends on googletest; library
consumers will have to manually link against libgtest. This only affects
consumers who want to use Abseil libraries that involve GoogleTest
(e.g., libabsl_scoped_mock_log).

Thank you both for bringing this to my attention, and thank you,
Praveen, for all the work you’ve done keeping Abseil going in Debian!

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Sun, 14 May 2023 at 22:37, Josh Triplett  wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > The loader is still available via the old path, so external/third
> > party/local/other software works unchanged. This should negatively
> > only affect our 1st party packages, when running on a non-merged
> > distro.
> > And are _all_ our packages really 100% compatible with other distros
> > at all? Are they even supposed to be?
>
> People build things on Debian that are not Debian packages. People
> compile binaries on Debian, and expect them to work on any system that
> has sufficiently new libraries.
>
> This is *not* about Debian packages failing to work on other
> distributions; this is about *software compiled on Debian* faliing to
> work in other environments.

Why would "software compiled on Debian" fail to work in other
environments? Well, there are many reasons actually, people invented
containers/flatpaks/snaps exactly for that reason. But nothing do with
anything discussed here though, as far as I can tell?

> If you build a dynamically linked binary that only depends on glibc, you
> can expect it to be reasonably portable, to any system that uses glibc
> and has a sufficiently new version.
>
> Debian stable is, in fact, one of the common environments people use to
> compile binaries for distribution.

"sufficiently new version" is doing a lot of work there. We have
shlibs dependencies for a reason. In fact, the most common environment
used to distribute binaries is the EOL Ubuntu 16.04, slowly switching
to the soon-to-be-EOL 18.04. glibc is not forward-compatible, new
symbols are added all the time and are used all the time, and you
don't jump on a brand new distribution to do that kind of work, that
would be self-defeating.

> > So, what I am asking is, what actual, real difference does it make if,
> > by default (and with an override available for example), packages
> > built on Debian for Debian record the ld path to point to its (actual)
> > location on Debian, via say a compiler spec file that is injected in a
> > deb build?
>
> Making binaries built *on* Debian different than binaries built *for*
> Debian would introduce a needless additional source of complexity,
> compared to just compiling code the same way in both cases.

That's not how it works today already. There are several significant
differences between just running "gcc sources.c" and building a
package via debhelper on a buildd, they are not the same thing at all,
and they haven't been since forever, there are dozens of
compiler/linker options that the Debian package build environment
sets. Or will you now also ask the distribution to rollback multiarch,
hardening, SOURCE_DATE_EPOCH, -ffile-prefix-map and all the other
reproducibility options, and so on? These and many more are all
"needless additional sources of complexity, compared to just compiling
code the same way" too. Because guess what, there are people who
couldn't possibly care less about
multiarch/security/reproducibility/etc, and there will also be a
subset of users who considers a subset of those compiler options
"needless". So are you going to push to have all of that reverted? And
also are you going to propose a Policy change that forbids adding any
new compiler/linker option to the package build process?

> To frame this in different terms: consider that one of the major goals
> of systemd has been to harmonize across distributions and eliminate
> needless variations that don't serve much actual purpose (e.g.
> variations in config file paths for the same config file). Consider how
> much effort systemd went to work with distributions, understand and deal
> with the *important* variations, and try to convince them to abandon the
> *unimportant* variations. Now imagine if someone came along and said
> "let's patch systemd to put unit files in /purple/; it'll work with
> everything in our distribution".

Pretty sure the Nix folks are already doing pretty much that. And if
it works for their case, all the power to them.

> Or, imagine if someone said "let's inject an argument to gzip, only for
> building the .gz files sihpped in our packages of course, to modify the
> gzip header and remove a few of the extraneous additional fields; it'll
> be fine, because we've patched our gzip to parse it"

Not really related, archives are _intended_ to be opened anywhere for
any reason. Do you have any actual related use case that would no
longer work? Because that would be the easiest and most convincing
counter-factual that could be provided.

> The x86-64 ABI is set. Feel free to make the case to the next
> architecture designer that their new ABI should have the dynamic linker
> in `/usr/lib`. That would *not* have the same downsides, as long as
> everyone agrees on a path.

In practice it is not, though. There are other distributions that
change PT_INTERP for their own purposes, they've already been listed
in this thread. And I am still not 

Bug#1036067: nagvis: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nagvis
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033958: binutils: reproducible builds: build paths/tarball sort order

[Vagrant Cascadian]

Control: found 1033959 2.40-2
Control: found 1033958 2.40-2

Marking issues with versions in which it is still present.

live well,
  vagrant

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Josh Triplett]

On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> The loader is still available via the old path, so external/third
> party/local/other software works unchanged. This should negatively
> only affect our 1st party packages, when running on a non-merged
> distro.
> And are _all_ our packages really 100% compatible with other distros
> at all? Are they even supposed to be?

People build things on Debian that are not Debian packages. People
compile binaries on Debian, and expect them to work on any system that
has sufficiently new libraries.

This is *not* about Debian packages failing to work on other
distributions; this is about *software compiled on Debian* faliing to
work in other environments.

If you build a dynamically linked binary that only depends on glibc, you
can expect it to be reasonably portable, to any system that uses glibc
and has a sufficiently new version.

Debian stable is, in fact, one of the common environments people use to
compile binaries for distribution.

> So, what I am asking is, what actual, real difference does it make if,
> by default (and with an override available for example), packages
> built on Debian for Debian record the ld path to point to its (actual)
> location on Debian, via say a compiler spec file that is injected in a
> deb build?

Making binaries built *on* Debian different than binaries built *for*
Debian would introduce a needless additional source of complexity,
compared to just compiling code the same way in both cases.

To frame this in different terms: consider that one of the major goals
of systemd has been to harmonize across distributions and eliminate
needless variations that don't serve much actual purpose (e.g.
variations in config file paths for the same config file). Consider how
much effort systemd went to work with distributions, understand and deal
with the *important* variations, and try to convince them to abandon the
*unimportant* variations. Now imagine if someone came along and said
"let's patch systemd to put unit files in /purple/; it'll work with
everything in our distribution".

Or, imagine if someone said "let's inject an argument to gzip, only for
building the .gz files sihpped in our packages of course, to modify the
gzip header and remove a few of the extraneous additional fields; it'll
be fine, because we've patched our gzip to parse it"

The x86-64 ABI is set. Feel free to make the case to the next
architecture designer that their new ABI should have the dynamic linker
in `/usr/lib`. That would *not* have the same downsides, as long as
everyone agrees on a path.

- Josh Triplett

Bug#1018206: luatex loses or changes text when discretionaries with priorities are used

[Preuße]

Control: reassign -1 texlive-binaries

On 27.08.2022 00:58, Peter Mueller wrote:

 As described in https://tex.stackexchange.com/q/652458

 , luatex loses or changes text
(not formatting!) in particular circumstances.


As far as I understand this is an issue in the luatex binary. So I
change the assigned package.

H.
--
sigfault

Bug#1036054: pixelart does not work

[Preuße]

Control: tags -1 + pending fixed-upstream

On 14.05.2023 17:56, Louis wrote:

Dear Louis,


texlive-pictures includes pixelart v1.0.0, which does not work (see
below). It has two bugs, that have been fixed in version v1.0.2
(available on CTAN https://ctan.org/pkg/pixelart).


Many thanks for the report! I tag this bug as pending and
fixed-upstream, however I won't do another upload for bookworm. I'll fix
it shortly after next Debian release.

Hilmar
--
sigfault

Bug#1036066: jtreg6: missing hamcrest.jar in com.sun.javatest.regtest.tool.Tool classpath

[Vladimir Petko]

Source: jtreg6
Version: 6.1+2-1ubuntu1
Severity: normal
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

com.sun.javatest.regtest.tool.Tool looks for hamcrest.jar in the jtreg/lib
directory[1] for junit tests.
Would it be possible to consider a patch that adds a link to hamcrest.jar so
that junit tests pass?

[1] src/share/classes/com/sun/javatest/regtest/tool/Tool.java:1700


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

Kernel: Linux 6.2.0-20-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit eaa6c6c99745d3620c7532c76c7c882388bcc54c
Author: Vladimir Petko 
Date:   Mon May 15 08:46:44 2023 +1200

missing hamcrest.jar

diff --git a/debian/jtreg6.links b/debian/jtreg6.links
index 9693cd1..0fa18f9 100644
--- a/debian/jtreg6.links
+++ b/debian/jtreg6.links
@@ -2,6 +2,7 @@ usr/share/jtreg/bin/jtreg   /usr/bin/jtreg
 usr/share/jtreg/bin/jtdiff  /usr/bin/jtdiff
 
 usr/share/java/hamcrest-core.jar/usr/share/jtreg/lib/hamcrest-core.jar
+usr/share/java/hamcrest.jar /usr/share/jtreg/lib/hamcrest.jar
 usr/share/java/javatest.jar /usr/share/jtreg/lib/javatest.jar
 usr/share/java/jcommander.jar   /usr/share/jtreg/lib/jcommander.jar
 usr/share/java/jh.jar   /usr/share/jtreg/lib/jh.jar
@@ -10,6 +11,7 @@ usr/share/java/junit4.jar   
/usr/share/jtreg/lib/junit.jar
 usr/share/java/testng.jar   /usr/share/jtreg/lib/testng.jar
 
 usr/share/java/hamcrest-core.jar
/usr/share/jtreg/share/java/hamcrest-core.jar
+usr/share/java/hamcrest.jar 
/usr/share/jtreg/share/java/hamcrest.jar
 usr/share/java/javatest.jar 
/usr/share/jtreg/share/java/javatest.jar
 usr/share/java/jcommander.jar   
/usr/share/jtreg/share/java/jcommander.jar
 usr/share/java/jh.jar   /usr/share/jtreg/share/java/jh.jar

Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed

[Andreas Beckmann]

On 14/05/2023 19.43, Paul Gevers wrote:

/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64.
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!


How has ddcci-dkms been installed?
How did the dkms.conf go missing?
Please show the current layout of the source tree:
  ls -laR /usr/src/ddcci-*
Why hasn't ddcci been upgraded to the bookworm version (0.4.2)?

Andreas

PS: I don't see any errors during piuparts upgrade tests of ddcci-dkms + 
linux-headers-amd64


PPS: Of course the bullseye version (0.3.3) will fail to build for a 6.1 
kernel (if it gets that far), but that's nothing unexpected


PPPS: if you install the bookworm version of ddcci-dkms, it should a) 
restore the missing file and b) be compatible with current kernels

Bug#1036065: jtreg6: errors in jasm tests despite libasmtools-java installed

[Vladimir Petko]

Source: jtreg6
Version: 6.1+2-1ubuntu1
Severity: normal
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

openjdk-8 adds asmtools dependency, but tests[1] requiring asmtools still fail,
e.g.

Error:  compiler/conversions/TestPrimitiveConversions.java

--rerun:(4/368)*--
cd /tmp/hotspot/JTwork/scratch && \\
/build/openjdk-8-tuB2dS/openjdk-8-8u372-ga/build/bootcycle-
build/images/j2s>
-classpath /usr/share/java/asmtools.jar \\
org.openjdk.asmtools.jasm.Main -d
/tmp/hotspot/JTwork/classes/compiler/conv>
result: Error. can't find jasm


test result: Error. can't find jasm

The errors apply to 11 and 17 as well.

In order to avoid this error, asmtools need to be present in the manfest of the
jtreg.jar, e.g. here is excerpt of the jtreg 6.2+1 MANIFEST.MF[2]
--
Class-Path: javatest.jar asmtools.jar
--
Please consider the attached patch to add asmtools.jar to the jtreg classpath.

[1]https://buildd.debian.org/status/fetch.php?pkg=openjdk-8=all=8u372-ga-1=1683819721=0
[2] https://builds.shipilev.net/jtreg/jtreg-6.2%2B1.zip


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

Kernel: Linux 6.2.0-20-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit 2360ee1532ced475af53125f0bc13d1ec3c41e98
Author: Vladimir Petko 
Date:   Mon May 15 08:28:28 2023 +1200

add asmtools to classpath

diff --git a/debian/control b/debian/control
index 2515941..269aa92 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends:
  libjtharness-java (>= 6.0),
  libxalan2-java,
  libhamcrest-java,
+ libasmtools-java,
  testng
 Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/java-team/jtreg.git
@@ -28,7 +29,8 @@ Depends:
  javahelp2,
  libjtharness-java (>= 6.0),
  libhamcrest-java,
- libxalan2-java
+ libxalan2-java,
+ libasmtools-java,
 Recommends: testng
 Conflicts: jtreg
 Description: Regression Test Harness for the OpenJDK platform
diff --git a/debian/jtreg6.links b/debian/jtreg6.links
index 9693cd1..682feab 100644
--- a/debian/jtreg6.links
+++ b/debian/jtreg6.links
@@ -8,6 +8,7 @@ usr/share/java/jh.jar   
/usr/share/jtreg/lib/jh.jar
 usr/share/java/jtreg.jar/usr/share/jtreg/lib/jtreg.jar
 usr/share/java/junit4.jar   /usr/share/jtreg/lib/junit.jar
 usr/share/java/testng.jar   /usr/share/jtreg/lib/testng.jar
+usr/share/java/asmtools.jar /usr/share/jtreg/lib/asmtools.jar
 
 usr/share/java/hamcrest-core.jar
/usr/share/jtreg/share/java/hamcrest-core.jar
 usr/share/java/javatest.jar 
/usr/share/jtreg/share/java/javatest.jar
@@ -16,3 +17,4 @@ usr/share/java/jh.jar   
/usr/share/jtreg/share/java/jh.jar
 usr/share/java/jtreg.jar/usr/share/jtreg/share/java/jtreg.jar
 usr/share/java/junit4.jar   /usr/share/jtreg/share/java/junit.jar
 usr/share/java/testng.jar   /usr/share/jtreg/share/java/testng.jar
+usr/share/java/asmtools.jar 
/usr/share/jtreg/share/java/asmtools.jar
diff --git a/debian/patches/add-asmtools-to-classpath.patch 
b/debian/patches/add-asmtools-to-classpath.patch
new file mode 100644
index 000..ee79b17
--- /dev/null
+++ b/debian/patches/add-asmtools-to-classpath.patch
@@ -0,0 +1,16 @@
+Description: Provide path to asmtools.jar
+ A number of hotspot tests use java asmtools. Provide path to asmtools.jar
+Author: Vladimir Petko 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/jtreg6/+bug/2015011
+Last-Update: 2023-04-03
+--- a/make/build.xml
 b/make/build.xml
+@@ -144,7 +144,7 @@
+ 
+ 
+ 
+-
++
+ 
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index df57d95..d2c5b73 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 launchers.patch
 add-jcommander-to-classpath.patch
 use-release-instead-of-source-target.patch
+add-asmtools-to-classpath.patch

Bug#1036064: rss-bridge: Package newer upstream version (TwitterBridge no longer working)

[Matija Nalis]

Package: rss-bridge
Version: 2022-01-20+dfsg1-1
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr

Dear Maintainer,

Twitter changed server side again, and thus TwitterBridge stopped working
(unable to find usernames and get tweets).

Updating to latest version of Debian rss-bridge was not effective.
Using latest upstream github branch fixed the issue.

Can we have the package updated to the latest upstream git master?
It fixes the issue:
https://github.com/RSS-Bridge/rss-bridge/issues/3239#issuecomment-1546648731

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

Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rss-bridge depends on:
ii  php-common  2:76
ii  php-curl2:7.4+76
ii  php-mbstring2:7.4+76
ii  php-parsedown   1.7.4-1
ii  php-xml 2:7.4+76
ii  php7.4-curl [php-curl]  7.4.33-1+deb11u3
ii  php7.4-json [php-json]  7.4.33-1+deb11u3
ii  php7.4-mbstring [php-mbstring]  7.4.33-1+deb11u3
ii  php7.4-xml [php-xml]7.4.33-1+deb11u3

Versions of packages rss-bridge recommends:
ii  apache2 [httpd] 2.4.56-1~deb11u2
ii  libapache2-mod-php7.4 [libapache2-mod-php]  7.4.33-1+deb11u3

Versions of packages rss-bridge suggests:
pn  php-memcached  
pn  php-sqlite3

-- Configuration Files:
/etc/rss-bridge/config.ini.php changed [not included]
/etc/rss-bridge/whitelist.txt changed [not included]

-- no debconf information

Bug#1035935: libpodofo: CVE-2023-31555 CVE-2023-31556 CVE-2023-31568

[Salvatore Bonaccorso]

Hi Moritz,

On Thu, May 11, 2023 at 02:10:44PM +0200, Moritz Mühlenhoff wrote:
> Source: libpodofo
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for libpodofo.
> 
> CVE-2023-31555[0]:
> | podofoinfo 0.10.0 was discovered to contain a segmentation violation
> | via the function PoDoFo::PdfObject::DelayedLoad.
> 
> https://github.com/podofo/podofo/issues/67
> https://github.com/podofo/podofo/commit/3759eb6aae7c01f2d8670f16ac46f5e116c7f468
> 
> CVE-2023-31556[1]:
> | podofoinfo 0.10.0 was discovered to contain a segmentation violation
> | via the function PoDoFo::PdfDictionary::findKeyParent.
> 
> https://github.com/podofo/podofo/issues/66
> https://github.com/podofo/podofo/commit/8d3e9104ea10f8b53a0b5a2a806e6388acd41a40
> 
> CVE-2023-31568[2]:
> | Podofo v0.10.0 was discovered to contain a heap buffer overflow via
> | the component PoDoFo::PdfEncryptRC4::PdfEncryptRC4.
> 
> https://github.com/podofo/podofo/issues/72
> Fixed by: 
> https://github.com/podofo/podofo/commit/29d59f604b37159e938a2f46acd4856cfd1e7bac

Would appreicate if you can double check as well, my triage on those
issues: I looked at all three and further recent libpodofo issues and
the upstream "refactoring" in
https://github.com/podofo/podofo/commit/a2eca000e5a4337fb79ee8215d06413785653184
seems to be the cause. I then verified these three above with an ASAN
build of podofo.

If you think this is wrong, then let's revert
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/35925ae1ecb64f1cae0d3f456f0453532cfc6eaa
.

Regards,
Salvatore

Bug#1035056: [pre-approval] plasma-desktop 5.27.X

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On 28-04-2023 15:29, Hefee wrote:

before invest time, to do the debdiff and all paperwork for Plasma 5.27.X LTS
packages, there's need to be a idea, how to get it into stable.


Please read the freeze policy [2] and the FAQ [3] very carefully and 
make sure your request meets the requirements of this phase of the 
freeze and make sure you can answer every relevant question from the 
FAQ. Please only pursue if you convinced the answer is yes.



Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci
time frame,


What does that mean (sorry, I don't have the energy to look this up, too 
many unblock requests to process)?



when stable will be release, we would be at ~5.27.5. I
wanted to ask, if we find a solution together to get the new version
into bookworm. Upstream wants to give bugfix releases over 2 years.


So you consider bumping 5.27.2 to 5.27.5 a targeted fix? Would you 
request the same in a stable point update (because that's about the same 
level at this phase of the release)?



Plasma 5.27 is a LTS branch, that is stable and only bug fixes with be
released with next minor versions. No transitions nor API changes.


[From FAQ] can you point at an upstream document that explains their policy?


Plasma is ~50 pacakges - see a list of packages:


I think you know by now, this fits extremely bad with the way the Freeze 
is handled as we review everything and need to watch that everything 
migrates. We're not going to give a set of key packages a cart blanch 
this late in the freeze especially when we've NACK-ed already easier 
things. E.g. although we're convinced the MariaDB unblock [4] really had 
all best intentions and we hate to deny unblocks, it contained a bunch 
of changes not meeting the freeze policy. We're frozen to ensure 
stability and no surprises. The freeze policy is not ment to manage 
packages (that's up to the maintainers), it's meant to ensure we can 
manage the release process. In this particular case, we also don't have 
tools to ensure the set remains coherent, does the set ensure they 
migrate as a whole? If not, how bad would it be when some pieces migrate 
and others can't before the release?


For your info, I'm going to try hard to ensure KDE and plasma are going 
to be removed from the key package set for trixie, which means that you 
don't need our involvement until much later in the trixie freeze. 
However, that won't help you anymore this time around because a) that 
key package set definition change isn't going to happen before the 
release and b) it's too late in the freeze to matter anymore.


Paul

[2] https://release.debian.org/testing/freeze_policy.html
[3] https://release.debian.org/testing/FAQ.html
[4] https://bugs.debian.org/1033811


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036030: asciidoc-base: asciidoc fails to find icons for embedding; iconsdir apparently mismatching asciidoc-common layout

[Matthias Andree]

I think not fixing this in the package as a regular fix (it's a patch
after all) is ill-advised,
but for those who find this bug unfixed in their installation:

The workaround is to install asciidoc through pip install --user
asciidoc instead, or possibly with pipx.

Example in line #6 of my test build script here:
https://gitlab.com/fetchmail/fetchmail/-/commit/bf6c7b1eb8d476eb8c71419096e5f5470d205dfb#c5cb59670c749d48bf0114e280b297d49e50f3ac_0_6

Bug#1036062: frr: CVE-2023-31490

[Salvatore Bonaccorso]

Source: frr
Version: 8.4.2-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/FRRouting/frr/issues/13099
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for frr.

CVE-2023-31490[0]:
| An issue found in Frrouting bgpd v.8.4.2 allows a remote attacker to
| cause a denial of service via the bgp_attr_psid_sub() function.


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-31490
https://www.cve.org/CVERecord?id=CVE-2023-31490
[1] https://github.com/FRRouting/frr/issues/13099

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1036061: frr: CVE-2023-31489

[Salvatore Bonaccorso]

Source: frr
Version: 8.4.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/FRRouting/frr/issues/13098
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for frr.

CVE-2023-31489[0]:
| An issue found in Frrouting bgpd v.8.4.2 allows a remote attacker to
| cause a denial of service via the bgp_capability_llgr() function.


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-31489
https://www.cve.org/CVERecord?id=CVE-2023-31489
[1] https://github.com/FRRouting/frr/issues/13098

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Theodore Ts'o]

On Sun, May 14, 2023 at 06:03:59PM +0200, Michael Biebl wrote:
> > Please reassign it there together with instructions how to fix it, i.e.
> > what should be done in the maintainer scripts.

Can someone send the instructions on how to fix this?

I'm always amused by people who claim systemd is "simpler" to
understand than init.d scripts.  :-)

I have no clue what's going on; is default.target obsolete?  If we
change the Wanted-by in a systemd unit file, what magic incantation is
required?  Can someone point me at documentation that describes all of
this?

Thanks,

- Ted

Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Otto Kekäläinen]

Control: retitle -1 mariadb-plugin-gssapi-server: crash on partial
upgrade of libk5crypto3

Filed now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036055
for krb5 maintainers to advise on.

Bug#1035976: [Aptitude-devel] Bug#1035976: Bug#1035976: aptitude dies with SEGV

[Axel Beckert]

Hi Harald,

Harald Dunkel wrote:
> apparently it is not sufficient to just add the entry to sources.list.d.
> I had to update the local cache to make aptitude die.

Ok, another try:

# pbuilder update --autocleanaptcache
# pbuilder login
## apt install aptitude wget gpg ca-certificates
## wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o 
/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg
## echo "deb https://apt.releases.hashicorp.com bookworm main" > 
/etc/apt/sources.list.d/hashicorp.list
## apt update
Hit:1 http://debian.ethz.ch/debian sid InRelease
Get:2 https://apt.releases.hashicorp.com bookworm InRelease [12.9 kB]
Get:3 https://apt.releases.hashicorp.com bookworm/main amd64 Packages [84.4 kB]
## aptitude

TUI comes up. No crash.

> > * Do you have any custom settings for settings influencing aptitude's
> >package display like "Aptitude::UI::Package-Display-Format" or
> >"Aptitude::UI::Default-Grouping"?
> 
> No, I just have
> 
>   # cat .aptitude/config

Looks harmless indeed.

> > * Under which locale settings does it happen for you?
> 
> On some systems I have set LANG=C or LANG=en_US.UTF-8, but I can reproduce
> this using
> 
>   # locale
>   LANG=
>   LANGUAGE=
>   LC_CTYPE="POSIX"
>   LC_NUMERIC="POSIX"
>   LC_TIME="POSIX"
>   LC_COLLATE="POSIX"
>   LC_MONETARY="POSIX"
>   LC_MESSAGES="POSIX"
>   LC_PAPER="POSIX"
>   LC_NAME="POSIX"
>   LC_ADDRESS="POSIX"
>   LC_TELEPHONE="POSIX"
>   LC_MEASUREMENT="POSIX"
>   LC_IDENTIFICATION="POSIX"
>   LC_ALL=
> 
> I doubt that this is related to the locale.

Thanks. I indeed think we can rule that out, too.

Then again, I'm out of ideas now, except for looking with strace where
the crash happens.

> > If you neither use any of these settings nor use a non-english locale,
> > is there any chance that you can install these packages (for
> > bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the
> > debian-goodies package) on one of the affected machines:
> > 
> > strace aptitude-dbgsym libapt-pkg6.0-dbgsym
> > libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg
> > libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym
> > libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym
> > liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym
> > libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym
> > libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym
> > zlib1g-dbgsym
> > 
> 
> libelogind0? This breaks systemd.

Ah, sorry, didn'y notice that.

Wanted to avoid that you need to install debian-goodies for
find-dbgsym-packages so I ran "find-dbgsym-packages --all aptitude" on
one of my systems. Seems as if the output actually depends on which
alternatives have been chosen on the local system. Of course
libsystemd0-dbgsym is fine as well if you have libsystemd0 installed.

(I also doubt that all of these are really necessary. Probably
"aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym
libcwidget4-dbgsym libgcc-s1-dbgsym libncursesw6-dbgsym
libsigc++-2.0-0v5-dbgsym libxapian30-dbgsym" already suffice to cover
everything which might be involved in such a crash, especially since
it does not happen when downloading or accessing the package lists.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

On Sun, 2023-05-14 at 19:40 +0200, Ben Hutchings wrote:
[...]
> This works for me with all the QEMU graphics devices.  But I haven't
> tested on real hardware.

Now tested successfully on 2 custom desktops:

- Asus P8Z68-V LX motherboard, Intel Core i5 2500 CPU, integrated GPU
- ASRock B450 PRO4, AMD Ryzen 5 3600 CPU, Radeon RX580 GPU

and 2 laptops:

- Lenovo ThinkPad T420, Intel Core i5 2nd gen CPU, integrated GPU
- Lenovo ThinkPad T460, Intel Core i5 6th gen CPU, integrated GPU

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#1036060: unblock: libfinance-quote-perl/1.54-3

[gregor herrmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libfinance-quote-p...@packages.debian.org
Control: affects -1 + src:libfinance-quote-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libfinance-quote-perl/1.54-3 to unstable, targetting
bookworm.

In comparison to -2, the upload contains 4 patches from upstream Git
commits/PRs. While this sounds a bit scary at this stage of the
freeze, all changes are minimal and fix issues.

I'm attaching a full debdiff but in practice the code changes are as
follows (the rest is documentation, patch metadata, a skipped online
test, …):

1) debian/patches/GH263_URL_MorningstarJP.patch: 1 URL changed:

- --- a/lib/Finance/Quote/MorningstarJP.pm
+++ b/lib/Finance/Quote/MorningstarJP.pm
@@ -32,7 +32,7 @@
 
 # NAV information (basis price)
 $MORNINGSTAR_JP_URL =
- -  ('https://www.morningstar.co.jp/FundData/DownloadStdYmd.do?fnc=');
+  ('https://www.wealthadvisor.co.jp/FundData/DownloadStdYmd.do?fnc=');
 
 sub methods { return ( morningstarjp => \ ); }
 sub labels  { return ( morningstarjp => [qw/symbol date nav/] ); }


2) debian/patches/GH262_Regex_FTfunds.patch: 1 regexp changed:

- --- a/lib/Finance/Quote/FTfunds.pm
+++ b/lib/Finance/Quote/FTfunds.pm
@@ -182,7 +182,7 @@
my $currency;
my $price;
if ($webdoc->content =~
- - m[Price 
[(]([A-Z]{3})[)]([\.\,0-9]*)]  )
+   m[]*>Price 
[(]([A-Z]{3})[)]([\.\,0-9]*)]  )
 {
$currency = $1;
$price= $2;


3) debian/patches/GH267_TRV_AlphaVantage.patch: 1 entry added to a
   hash table:

- --- a/lib/Finance/Quote/AlphaVantage.pm
+++ b/lib/Finance/Quote/AlphaVantage.pm
@@ -58,6 +58,7 @@
 '.SA'  => "BRL",# Brazil   Sao Paolo
 '.BR'  => "EUR",# Belgium  Brussels
 '.TO'  => "CAD",# Canada   Toronto
+'.TRV' => "CAD",# CanadaToronto Venture
 '.V'   => "CAD",#  Toronto Venture
 '.TRT' => "CAD",# CanadaToronto
 '.SN'  => "CLP",# ChileSantiago


4) debian/patches/GH268_URL_YahooJSON.patch: 1 URL changed:

- --- a/lib/Finance/Quote/YahooJSON.pm
+++ b/lib/Finance/Quote/YahooJSON.pm
@@ -35,7 +35,7 @@
 
 our $VERSION = '1.54'; # VERSION
 
- -my $YIND_URL_HEAD = 
'https://query1.finance.yahoo.com/v7/finance/quote?symbols=';
+my $YIND_URL_HEAD = 
'https://query1.finance.yahoo.com/v6/finance/quote?symbols=';
 my $YIND_URL_TAIL = '';
 
 sub methods {

(This is Debian bug #1035690)


All these changes are also in the new 1.55 upstream release which
I've chosen not to take as it also contains other/more code changes.

Having these changes in bookworm would help users to have working
stock quote modules, and as the changes are minimal there should be
no risk for regressions.


unblock libfinance-quote-perl/1.54-3
age-days 5 libfinance-quote-perl/1.54-3



Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmRhJ9RfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgauYg/+IpHCLWKfRn18h5jiQruWhQkosM3n8cPaXVqiCbm2V1o/I4DC5Rx6xK4W
uZ/255jydt1DI771a4p2zlgl/svKIXCBCqsk9c3aUzpCrkeAVghOW6OGqD9X2P+Q
o8W1ADpEbG/gI6kGHn7Yj5x428L6PtG/t0rUTEKnEEUznPnLFufszFkr1/aifwbr
bbX1sjSxcdNQjtaiMVRusK7CD8sfqgRaDSZJC7iN9NjIbMnYEo/3UYiSDpBnXC6/
QP/VZrAdrbfsmWCahJtcZ/ZlvpKN1rmQI6fnaTIFFGewQmyj2uMAnVa1bLSm2lI0
6yo5oc33TDfxCR0nnJOr4jE3ruB1sYenIoUilNxLtglCRCJZhoZCQP6IPq2wCTe3
U18L4dH0lAppXGx7MHq2bnEXTV5JB6pcz0EBDe66iupmotQrgOwoNRVOt8A6GMah
2+MCWGSTub2Z0RAFQWv/HTdSZWhsjq+TgMNoxOcxGjXBUdgBAl+JkrfxeZ3e2RLd
oY42kFhTIimDKnyHOe9CdA2Zp/PvISnHdafiMoeHBrnZfMmvG3dttqcxDxn9GPAL
wievCeyj27th12taQN5/Rg5qPU07cr3yiFE9v8ccSsKPcQzmT27nx+qFEYALcYxn
fXlgcIMsRuWaIfc1okSgus7Q8QhxAQk3Ep2vZrPQ5cuoOC91so4=
=apkh
-END PGP SIGNATURE-
diff -Nru libfinance-quote-perl-1.54/debian/changelog 
libfinance-quote-perl-1.54/debian/changelog
--- libfinance-quote-perl-1.54/debian/changelog 2023-02-05 14:24:34.0 
+0100
+++ libfinance-quote-perl-1.54/debian/changelog 2023-05-14 20:04:45.0 
+0200
@@ -1,3 +1,17 @@
+libfinance-quote-perl (1.54-3) unstable; urgency=medium
+
+  * Add patch GH263_URL_MorningstarJP.patch from upstream Git repo.
+URL change in MorningstarJP.pm. (GH#263)
+  * Add patch GH262_Regex_FTfunds.patch from upstream Git repo.
+Tweak regex to fix FTfunds.pm. (GH#262)
+  * Add patch GH267_TRV_AlphaVantage.patch from upstream Git repo.
+Added currency map .TRV => CAD. (GH#267)
+  * Add patch GH268_URL_YahooJSON.patch from upstream Git repo.
+Quick fix to YahooJSON.pm. (GH#268)
+Thanks to David Engel for the bug report. (Closes: #1035690)
+
+ -- gregor herrmann   Sun, 14 May 2023 20:04:45 +0200
+
 libfinance-quote-perl (1.54-2) unstable; urgency=medium
 
   * Drop 

Bug#1036059: unblock: resteasy3.0/3.0.26-6

[Emmanuel Bourg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: resteasy...@packages.debian.org
Control: affects -1 + src:resteasy3.0

Please unblock package resteasy3.0

This update drops the dependency on libtomcat9-java
which won't be part of Bookworm (#1033366)

Thank you,

Emmanuel Bourg

unblock resteasy3.0/3.0.26-6
diff --git a/debian/changelog b/debian/changelog
index 68db1eab6..148149f7d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+resteasy3.0 (3.0.26-6) unstable; urgency=medium
+
+  * Team upload.
+  * Depend on libservlet-api-java and libel-api-java instead of libtomcat9-java
+(Closes: #1033366)
+
+ -- Emmanuel Bourg   Sun, 14 May 2023 19:12:25 +0200
+
 resteasy3.0 (3.0.26-5) unstable; urgency=medium
 
   * patches: Replace javax/activation with jakarta/activation, fixes noise
diff --git a/debian/control b/debian/control
index bd18212da..47fdea4fd 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends-Indep:
  javahelper,
  junit4,
  libcommons-io-java,
+ libel-api-java,
  libgeronimo-annotation-1.3-spec-java,
  libhttpclient-java,
  libjackson2-core-java,
@@ -22,8 +23,8 @@ Build-Depends-Indep:
  libjboss-logging-java,
  libjboss-logging-tools-java,
  libmaven-install-plugin-java,
- libslf4j-java,
- libtomcat9-java,
+ libservlet-api-java,
+ libslf4j-java
 Standards-Version: 4.5.1
 Vcs-Git: https://salsa.debian.org/java-team/resteasy.git
 Vcs-Browser: https://salsa.debian.org/java-team/resteasy
diff --git a/debian/libresteasy3.0-java.classpath 
b/debian/libresteasy3.0-java.classpath
index 2dfc0599a..89a972771 100644
--- a/debian/libresteasy3.0-java.classpath
+++ b/debian/libresteasy3.0-java.classpath
@@ -1,2 +1,2 @@
-usr/share/java/resteasy-jaxrs.jar  /usr/share/java/slf4j-api.jar 
/usr/share/java/httpclient.jar /usr/share/java/commons-io.jar 
/usr/share/java/geronimo-annotation-1.3-spec.jar 
/usr/share/java/tomcat9-el-api.jar /usr/share/java/jakarta-activation.jar
+usr/share/java/resteasy-jaxrs.jar  /usr/share/java/slf4j-api.jar 
/usr/share/java/httpclient.jar /usr/share/java/commons-io.jar 
/usr/share/java/geronimo-annotation-1.3-spec.jar 
/usr/share/java/jakarta-activation.jar
 usr/share/java/resteasy-jackson2-provider.jar  
/usr/share/java/jackson-core.jar /usr/share/java/jackson-databind.jar 
/usr/share/java/jackson-jaxrs-base.jar 
/usr/share/java/jackson-jaxrs-json-provider.jar 
/usr/share/java/jackson-module-jaxb-annotations.jar
diff --git a/debian/maven.rules b/debian/maven.rules
index 30c686e5e..51bec29df 100644
--- a/debian/maven.rules
+++ b/debian/maven.rules
@@ -12,7 +12,7 @@ org.yaml snakeyaml * s/.*/1.x/ * *
 com.sun.istack istack-commons-runtime * s/debian/2.17/ * *
 s/jboss/javassist/ javassist * s/.*/debian/ * *
 s/org.jboss.spec.javax.annotation/org.apache.geronimo.specs/ 
s/jboss-annotations-api_1.2_spec/geronimo-annotation_1.3_spec/ * s/.*/debian/ * 
*
-s/org.jboss.spec.javax.servlet/org.apache.tomcat/ 
s/jboss-servlet-api_3.1_spec/tomcat-servlet-api/ * s/.*/9.x/ * *
-s/org.jboss.spec.javax.el/org.apache.tomcat/ 
s/jboss-el-api_3.0_spec/tomcat-el-api/ * s/.*/9.x/ * *
+s/org.jboss.spec.javax.servlet/javax.servlet/ 
s/jboss-servlet-api_3.1_spec/javax.servlet-api/ * s/.*/debian/ * *
+s/org.jboss.spec.javax.el/javax.el/ s/jboss-el-api_3.0_spec/javax.el-api/ * 
s/.*/debian/ * *
 s/org.jboss.spec.javax.ws.rs/javax.ws.rs/ 
s/jboss-jaxrs-api_2.0_spec/javax.ws.rs-api/ * s/.*/debian/ * *
 s/javax.activation/jakarta.activation/ s/activation/jakarta.activation-api/ * 
s/.*/debian/ * *

Bug#1034624: zfs-dkms: Please revert corruption-causing optimization in 2.1.10 release

[M. Zhou]

Control: fixed -1 2.1.11-1

2.1.11-1 has migrated to testing.

Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java

[Olek Wojnar]

Control: tag -1 pending

Thanks for letting me know about the impending removal and the suggested 
fix!


On 5/14/23 10:04, Markus Koschany wrote:

Control: tags -1 patch

Hi,


bazel-bootstrap already build-depends on libgeronimo-annotation-1.3-spec-java.
The fix is trivial. Patch is attached.



Thank you very much for the patch! I'm preparing the upload now.


-Olek



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036058: unblock: qtbase-opensource-src/5.15.8+dfsg-8

[Dmitry Shachnev]

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

Please unblock package qtbase-opensource-src.

[ Reason ]
The new upload fixes bug #1035790 (missing Breaks+Replaces: libqtcore4).

[ Impact ]
Some Buster → Bullseye → Bookworm upgrades will fail with dpkg error about
overwriting files.

[ Tests ]
No tests, but the change is trivial and just partially reverts an older
change (where these Breaks/Replaces were removed).

[ Risks ]
Just adding Breaks/Replaces against an ancient package which is not even
present in stable. No risk.

[ 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 testing

unblock qtbase-opensource-src/5.15.8+dfsg-8

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+qtbase-opensource-src (5.15.8+dfsg-8) unstable; urgency=medium
+
+  * Add back Breaks/Replaces for libqtcore4 (closes: #1035790).
+
+ -- Dmitry Shachnev   Sat, 13 May 2023 14:12:14 +0300
+
 qtbase-opensource-src (5.15.8+dfsg-7) unstable; urgency=medium
 
   * Update a11y_root.diff. This time the code waits for Qt loop to process the
--- a/debian/control
+++ b/debian/control
@@ -89,6 +89,8 @@ Provides: qtbase-abi-5-15-8
 Depends: shared-mime-info, ${misc:Depends}, ${shlibs:Depends}
 Recommends: qttranslations5-l10n
 Suggests: libthai0
+Breaks: libqtcore4 (<< 4:4.8.7+dfsg-20~)
+Replaces: libqtcore4 (<< 4:4.8.7+dfsg-20~)
 Description: Qt 5 core module
  Qt is a cross-platform C++ application framework. Qt's primary feature
  is its rich set of widgets that provide standard GUI functionality.


signature.asc
Description: PGP signature

Bug#1036055: Acknowledgement (libk5crypto3: depend on latest libkrb5support0 to avoid crashing at load time)

[Otto Kekäläinen]

control: affects -1 mariadb-plugin-gssapi-server
control: block 1035944 by -1

Seems the package already has correct depends in
https://salsa.debian.org/debian/krb5/-/blob/master/debian/control#L354-358:

Package: libk5crypto3
Section: libs
Breaks: libkrb5-3 (<= 1.18~), libgssapi-krb5-2 (<= 1.18~)
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}

However version 1.18 in Bullseye has:

± docker run -it --rm -v ${PWD}:/build -w /build debian:bullseye bash
root@7990e2966f5b:/build# apt update && apt show libk5crypto3
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security
InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8183 kB]
Get:5 http://deb.debian.org/debian-security bullseye-security/main
amd64 Packages [240 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64
Packages [14.6 kB]
Package: libk5crypto3
Version: 1.18.3-6+deb11u3
Priority: optional
Section: libs
Source: krb5
Maintainer: Sam Hartman 
Installed-Size: 303 kB
Depends: libc6 (>= 2.25), libkrb5support0 (>= 1.16)


and version 1.20 in Bookworm has:

Package: libk5crypto3
Version: 1.20.1-1+b1
Priority: optional
Section: libs
Source: krb5 (1.20.1-1)
Maintainer: Sam Hartman 
Installed-Size: 267 kB
Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.16)

I don't understand where this hard-coded ">= 1.16" comes from. I
searched the krb5 source debian/ for string '16' and I can't find
anything which could explain this.

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

Control: tag -1 patch

On Sun, 2023-05-14 at 00:21 +0200, Ben Hutchings wrote:
[...]
> So I suppose there's a regression in either efifb or fbdev_drv.

I'm not spotting any functional changes in fbdev or the submodules it
depends on between bullseye and bookworm.  So this implicates either
efifb or, as you mentioned, GRUB.

> > Via QEMU, under BIOS and UEFI, results are:
> > 
> >   +-+-+-+-+
> >   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
> >   +-+++++++
> >   | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
> >   +-+++++++
> >   | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
> >   | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   +-+++++++
> 
> I started testing with QEMU and OVMF from unstable, and I'm instead
> seeing Xorg failing to start in the same cases you see glitches.  The
> relevant error message seems to be this one:
> http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c=504
[...]

I tested with QEMU from bullseye and OVMF from unstable, and again I
saw Xorg failing to start, rather than glitches.  Weird.

I also patched the kernel to report the internal screen_info structure
and the fb_var_screeninfo structure passed in and out of
FBIOPUT_VSCREENINFO.  The key difference is:

- With -vga qxl, screen_info says 32 bpp, X wants 32 bpp, the kernel
  agrees with that.
- With -vga std or -vga cirrus screen_info says 24 bpp, X wants 32
  bpp, and the kernel says 24 bpp.

I think the problem is this GRUB has native drivers for Bochs and
Cirrus that reprogram the framebuffer bit depth, and the kernel is then
confused about what the bit depth is supposed to be.  With QXL, GRUB
doesn't have a native driver so it doesn't reconfigure the framebuffer.

Unfortunately, with Secure Boot we have to use a monolithic GRUB build
so I can't easily exclude video_bochs and video_cirrus to see if that
improves matters.

But what does works for me is:

--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
--- END ---

A full patch is attached.

This works for me with all the QEMU graphics devices.  But I haven't
tested on real hardware.


Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
From 49a5e562850e3ae4f64ed2d61bd582d8adedc393 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Sun, 14 May 2023 19:17:45 +0200
Subject: [PATCH] Always use 32 bpp for GRUB EFI graphical menu (Closes:
 #1036019)

---
 build/boot/x86/grub/grub-efi.cfg | 2 +-
 debian/changelog | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/build/boot/x86/grub/grub-efi.cfg b/build/boot/x86/grub/grub-efi.cfg
index 0a9a67d48..14708c7bc 100644
--- a/build/boot/x86/grub/grub-efi.cfg
+++ b/build/boot/x86/grub/grub-efi.cfg
@@ -5,7 +5,7 @@ else
 fi
 
 if loadfont $font ; then
-  set gfxmode=800x600
+  set gfxmode=800x600x32
   set gfxpayload=keep
   insmod efi_gop
   insmod efi_uga
diff --git a/debian/changelog b/debian/changelog
index 4624187fe..6be6864b5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 debian-installer (20230428) UNRELEASED; urgency=medium
 
+  [ Cyril Brulebois ]
   * Bump Linux kernel ABI to 6.1.0-9.
   * Switch source format from 1.0 to 3.0 (native).
 
+  [ Ben Hutchings ]
+  * Always use 32 bpp for GRUB EFI graphical menu (Closes: #1036019)
+
  -- Cyril Brulebois   Thu, 27 Apr 2023 22:52:15 +0200
 
 debian-installer (20230427) unstable; urgency=medium


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

Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed

[Paul Gevers]

Control: reassign -1 ddcci-dkms
Control: severity -1 serious

Hi Tim,

Thanks for filing issues you encounter when upgrading. Judging from you 
comments I think the issue is in ddcci-dkms, hence I assign it there for 
further triaging. However, I know a lot of changes happened in the dkms 
landscape, so I include Andreas in CC too; maybe some ordering is wrong 
on ddcci-dkms "just" needs a rebuild with a newer dkms.


Paul

On 13-05-2023 18:02, Tim Small wrote:

Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: t...@seoss.co.uk

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: bullseye
I am upgrading to: bookworm
Upgrade date: 2023-05-06
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:


deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib

# Security updates
deb http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware
deb-src http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware


deb http://deb.debian.org/debian-debug/ bookworm-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main

- Was the system pre-update a 'pure' system only containing packages
   from the previous release? If not, which packages were not from that
   release?

   yes

- Did any packages fail to upgrade?

linux-image-6.1.0-7-amd64

With the ddcci-dkms installed, and enabled for building before the
upgrade, the following occurred during upgrade:

/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64.
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-6.1.0-7-amd64 (--configure):
  installed linux-image-6.1.0-7-amd64 package post-installation script 
subprocess returned error exit status 1
Setting up linux-headers-6.1.0-7-amd64 (6.1.20-2) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64.
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-7-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.1.0-7-amd64 (--configure):
  installed linux-headers-6.1.0-7-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
  linux-headers-amd64 depends on linux-headers-6.1.0-7-amd64 (= 6.1.20-2); 
however:
   Package linux-headers-6.1.0-7-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
  dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-amd64:
  linux-image-amd64 depends on linux-image-6.1.0-7-amd64 (= 6.1.20-2); however:
   Package linux-image-6.1.0-7-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
  dependency problems - leaving unconfigured
Errors were encountered while processing:
  linux-image-6.1.0-7-amd64
  linux-headers-6.1.0-7-amd64
  linux-headers-amd64
  linux-image-amd64


- Were there any problems with the system after upgrading?


Further Comments/Problems:


Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036057: xorgxrdp: update d/watch + patch

[Patrice Duroux]

Package: xorgxrdp
Version: 1:0.9.19-1
Severity: normal

Dear Maintainer,

Here is a patch for.

Thanks,
Patrice


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

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

Versions of packages xorgxrdp depends on:
ii  libc6  2.36-9
ii  libepoxy0  1.5.10-1
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.7-3

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+23

xorgxrdp suggests no packages.

-- no debconf information
diff --git a/debian/watch b/debian/watch
index 27adada..d66bd48 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
 version=4
-https://github.com/neutrinolabs/@PACKAGE@/releases 
.*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+https://github.com/neutrinolabs/@PACKAGE@/tags \
+(?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1036041: upgrade-reports: Dell XPS 9550 fails to boot after bullseye to bookworm upgrade - grub/bios interaction bug?

[Paul Gevers]

Control: reassign -1 src:grub2
Control: severity -1 serious

Hi Tim,

Thanks for reporting the issues your facing. The comments in the report 
suggest this is an issue with GRUB, so I'm reassigning it to that 
package for further triaging.


Paul

On 14-05-2023 10:52, Tim Small wrote:

Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: t...@seoss.co.uk

My previous release is: bullseye
I am upgrading to: bookworm
Upgrade date: 2022-05-06
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:


deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib

# Security updates
deb http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware
deb-src http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware


deb http://deb.debian.org/debian-debug/ bookworm-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main

- Were there any problems with the system after upgrading?

System fails to boot after upgrade - hangs after loading initramfs.

On enabling debug within grub, the hang occurs at:

kern/verifiers.c:88: file: /boot/initrd.img-6.1.0-8-amd64 type: 131076
kern/verifiers.c:103: trying verifier pgp
kern/verifiers.c:103: trying verifier tpm


Can be worked around with:

GRUB_TERMINAL=console

... with this setting in place the system boots as expected.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036056: xrdp: update d/watch + patch

[Patrice Duroux]

Package: xrdp
Version: 0.9.21.1-1
Severity: normal

Dear Maintainer,

Here is a patch for a better d/watch file that solve uscan search.

Regards,
Patrice


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

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

Versions of packages xrdp depends on:
ii  adduser3.132
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libfuse2   2.9.9-6+b1
ii  libjpeg62-turbo1:2.1.5-2
ii  libopus0   1.3.1-3
ii  libpam0g   1.5.2-6
ii  libssl33.0.8-1
ii  libx11-6   2:1.8.4-2
ii  libxfixes3 1:6.0.0-2
ii  libxrandr2 2:1.5.2-2+b1
ii  ssl-cert   1.1.2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages xrdp recommends:
ii  fuse3 [fuse]  3.14.0-4
ii  xorgxrdp  1:0.9.19-1

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.36-9
ii  libepoxy0  1.5.10-1
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.7-3

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+23

Versions of packages xrdp is related to:
pn  vnc-server   
ii  xserver-xorg-legacy  2:21.1.7-3

-- no debconf information
diff --git a/debian/watch b/debian/watch
index 27adada6..c20879d8 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
 version=4
-https://github.com/neutrinolabs/@PACKAGE@/releases 
.*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+ https://github.com/neutrinolabs/@PACKAGE@/tags \
+ (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1036055: libk5crypto3: depend on latest libkrb5support0 to avoid crashing at load time

[Otto Kekäläinen]

Package: libk5crypto3
Version: 1.20-1
Severity: normal

While updating libk5crypto3 from Bullseye to Bookworm version on a
system running MariaDB with the GSSAPI plugin enabled it was
discovered that restarting MariaDB results directly in it crashing on
signal 11. Stack trace points to interaction on libkrb5.so.3 and
libk5crypto.so.3.

Full details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035944

Issue was solved by simply updating libkrb5-3 from Bullseye to the
Bookworm version. This suggests that in libk5crypto3 the existing

Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.16)

should probably be updated to:

Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.20)

This would pull in all these:

libssl3 3.0.8-1
libgssapi-krb5-2 1.20.1-1+b1
libkrb5support0 1.20.1-1+b1
libkrb5-3 1.20.1-1+b1

Bug#1035361: SAUCE RC bugs to be fixed for bookworm

[Ian Jackson]

I have just pushed 0.9.2.  I will file an unblock request later today.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Pásztor János]

Dear Bastian,

On 2023-05-11 17:42, Bastian Blank wrote:

Control: tags -1 wontfix

On Wed, May 10, 2023 at 03:09:04AM +0200, Guilhem Moulin wrote:

Please consider the enclosed patch.  The aim is to also activate
incomplete VGs at early boot stage, like lvm2 used to do before
2.03.15-1, and be a no op on “normal systems” once execution has been
handed over to init(1).

Nope, not really.  Half VG was never a real thing.  It might work in
some cases.


Well, it was a thing between 2014 and 2023, as based on my logs my 
machine has that config since then.



The patch doesn't break src:cryptsetup's autopkgtests.  It also solves
the present regression AFAICT, at least for the reproducers I tested.

I'm actually closing that report.  Because half configs are hard to
handle.

Bastian



I would kindly ask you to reconsider this and give a second chance to 
similar configs.
Or at least add an entry to here: 
https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html 
so that people could avoid a boot error right after the upgrade.


Regards,
János Pásztor

Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell

[Pásztor János]

Dear Guilheim,

On 2023-05-10 02:38, Guilhem Moulin wrote:

Control: tag -1 - unreproducible
Control: reassign -1 lvm2 2.03.15-1
Control: forcemerge 1018730 -1
Control: affects -1 cryptsetup-initramfs

Thanks for the the reproducer!  Much appreciated.  So the problem is
that your VG spans over multiple PVs, but the LVs that are required at
early boot stage (the ones holding the root FS and the resume device)
reside only on the first PV so cryptsetup-initramfs rightfully never
tries to unlock the second one (which only holds /home hence is not
needed that early).

This used to work, but it looks like lvm2's udev rules never try to
activate complete LVs residing on incomplete VGs, hence the deadlock.
This mostly affects cryptsetup-initramfs and perhaps the issue could be
mitigated there, but this is an lvm2 regression and non-luks systems can
be affected too [0] so I'm reassign the bug accordingly.  (Turns out it
was already reported, hence also merging.)

A quick fix for your particular setup is to edit crypttab(5), add the
‘initramfs’ option for the ‘4Tsolid’, and rebuild the initramfs image.
That should force the device to be considered at initramfs stage.



Thanks for highlighting the 'initramfs' option, it did the trick!
Finally I could remove the custom hook from initramfs generation and go 
back to a mainline setup.


Regards,
János Pásztor

Bug#1036054: pixelart does not work

[Louis]

Package: texlive-pictures
Version: 2022.20230122-3
Severity: normal

Dear Maintainer,
texlive-pictures includes pixelart v1.0.0, which does not work (see
below). It has two bugs, that have been fixed in version v1.0.2
(available on CTAN https://ctan.org/pkg/pixelart).

Thanks for your work,
Louis Paternault (author of pixelart)

##
Example file: mwe.tex

> \documentclass{article}
>
> \usepackage{pixelart}
>
> \begin{document}
> Hello, world!
> \end{document}

Document should compile flawlessly with LuaLaTeX (the resulting document
should be the same as the one produced by the exact same file, without
the line \usepackage{pixelart}). Instead, compilation fails.

> $ lualatex mwe.tex
> This is LuaHBTeX, Version 1.15.0 (TeX Live 2022/Debian) 
> […]
> (/usr/share/texlive/texmf-dist/tex/latex/pixelart/pixelart.sty
> […]
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/pgflibrarypatterns.cod
> e.tex))cannot open pixelart.lua: No such file or directory
> stack traceback:
>   [C]: in function 'dofile'
>   [\directlua]:1: in main chunk.
> \luadirect ... { \luacode@maybe@printdbg {#1} #1 }
>   
> l.15 \luadirect{dofile("pixelart.lua")}
>  
> ? Type  to proceed, S to scroll future error messages,
> R to run without stopping, Q to run quietly,
> I to insert something, E to edit your file,
> 1 or ... or 9 to ignore the next 1 to 9 tokens of input,
> H for help, X to quit.
> ? 
> ! Emergency stop.
> \luadirect ... { \luacode@maybe@printdbg {#1} #1 }
>   
> l.15 \luadirect{dofile("pixelart.lua")}
>  
>  385 words of node memory still in use:
>2 hlist, 1 rule, 1 dir, 3 kern, 1 glyph, 4 attribute, 48 glue_spec, 4 
> attrib
> ute_list, 1 if_stack, 1 write, 1 pdf_colorstack nodes
>avail lists: 2:20,3:2,5:5,7:2,9:3
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on mwe.log.


##
mwe.fls

PWD /home/louis/tmp
INPUT /var/lib/texmf/web2c/luahbtex/lualatex.fmt
INPUT ./mwe.tex
OUTPUT mwe.log
INPUT 
/usr/share/texlive/texmf-dist/tex/latex/latexconfig/lualatexquotejobname.lua
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ltluatex.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-main.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-init.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic-merged.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-compat.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended-merged.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-log.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-basics-gen.lua
OUTPUT /home/louis/.texlive2022/texmf-var/m_t_x_t_e_s_t.tmp
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-parsers.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-configuration.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-status.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-2022-10-03.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-fallback.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-multiscript.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-scripts.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/generic/unicode-data/ScriptExtensions.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/Scripts.txt
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-loaders.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-unicode.lua
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/PropList.txt
INPUT 
/usr/share/texlive/texmf-dist/tex/generic/unicode-data/WordBreakProperty.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/SpecialCasing.txt
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lua-uni-algos/lua-uni-case.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lua-uni-algos/lua-uni-parse.lua
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/CaseFolding.txt
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-colors.lua
INPUT 

Bug#1036053: kde-plasma-desktop: my desktop freez offen times

[MatinBRad]

Package: kde-plasma-desktop
Version: 5:111
Severity: normal
X-Debbugs-Cc: matinbirjandi...@chmail.ir

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 6.0.0-0.deb11.6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
LC_ALL to default locale: No such file or directory
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 kde-plasma-desktop depends on:
ii  kde-baseapps  4:20.12.0+5.111
ii  plasma-desktop4:5.20.5-4
ii  plasma-workspace  4:5.20.5-6
ii  udisks2   2.9.2-2+deb11u1
ii  upower0.99.11-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.20.5-1
ii  sddm  0.19.0-3
ii  xserver-xorg  1:7.7+22

Versions of packages kde-plasma-desktop suggests:
ii  kdeconnect  20.12.3-2

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "fa_IR.UTF-8",
LC_MONETARY = "fa_IR.UTF-8",
LC_COLLATE = "fa_IR.UTF-8",
LC_MEASUREMENT = "fa_IR.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Michael Biebl]

Control: reassign -1 e2fsprogs

Am 14.05.23 um 11:30 schrieb Andreas Beckmann:

On 09/05/2023 17.48, Michael Biebl wrote:
Andreas, you filed this with RC severity with the justification that 
systemd units are not enabled. I don't see that, so could you please 
clarify.


What I could find out so far is the change of WantedBy target not 
being properly cleaned up on upgrades, but that doesn't strike me as 
RC (and would need to be done in e2fsprogs)


Yes, looks like this is in the e2fsprogs realm.

Please reassign it there together with instructions how to fix it, i.e. 
what should be done in the maintainer scripts.


IMO the expected outcome from e2fsprogs perspective should be identical 
system configuration (w.r.t. enabled systemd units) after both fresh 
install and upgrade from bullseye, regardless of the installation status 
of systemd.

If e2fsprogs doesn't care about this, it can downgrade the severity.


Andreas





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032407: Cannot start mariadb-server unless manually mkdir -p /var/lib/mysql

[Jérôme Charaoui]

Control: forwarded -1 
https://github.com/puppetlabs/puppetlabs-mysql/issues/1566


After hitting this bug when upgrading a MariaDB server to bookworm, I 
submitted a bug report upstream:


https://github.com/puppetlabs/puppetlabs-mysql/issues/1566

-- Jérôme

Bug#1036052: node-react-hot-loader_4.13.1+~cs12.12.4-1_all-buildd.changes REJECTED

[Aurelien Jarno]

Source: node-react-hot-loader
Version: 4.13.1+~cs12.12.4-1
Severity: serious

On 2023-05-12 05:48, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package node-global, version 4.4.0~4.13.1+~cs=
> 12.12.4-1, for all,
> however unstable already has version 4.13.1+~cs8.8.2-1.
> Uploads to unstable must have a higher version than present in unstable.
> 
> Mapping sid to unstable.
> 
> =3D=3D=3D
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#1036051: bpfcc: Please enable build on riscv64

[Aurelien Jarno]

Source: bpfcc
Version: 0.26.0+ds-1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

Support for riscv64 has been added to bpfcc in upstream version 0.25.
Enabling it on the debian packaging side is just about adding the
architecture to debian/control. I have attached the patch I tested,
would it be possible to include it in the next upload?

Thanks,
Aurelien
diff -Nru bpfcc-0.26.0+ds/debian/control bpfcc-0.26.0+ds/debian/control
--- bpfcc-0.26.0+ds/debian/control
+++ bpfcc-0.26.0+ds/debian/control
@@ -38,7 +38,7 @@
 Rules-Requires-Root: no
 
 Package: libbpfcc
-Architecture: amd64 arm64 ppc64el ppc64 s390x armhf
+Architecture: amd64 arm64 ppc64el ppc64 s390x armhf riscv64
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Multi-Arch: same
 Description: shared library for BPF Compiler Collection (BCC)
@@ -52,7 +52,7 @@
  to control BPF programs from userspace.
 
 Package: libbpfcc-dev
-Architecture: amd64 arm64 ppc64el ppc64 s390x armhf
+Architecture: amd64 arm64 ppc64el ppc64 s390x armhf riscv64
 Section: libdevel
 Depends: ${misc:Depends},
  libbpfcc (= ${binary:Version})
@@ -97,7 +97,7 @@
  This package provides the command-line tools and examples
 
 Package: libbpf-tools
-Architecture: amd64 arm64 ppc64el
+Architecture: amd64 arm64 ppc64el riscv64
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Description: tools for BPF Compiler Collection based on libbpf (BTF and CO-RE)
@@ -114,7 +114,7 @@
  At this time this package contains subset of tools from bpfcc-tools
 
 Package: bpfcc-introspection
-Architecture: amd64 arm64 ppc64el ppc64
+Architecture: amd64 arm64 ppc64el ppc64 riscv64
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libbpfcc (= ${binary:Version})

Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java

[Markus Koschany]

Control: tags -1 patch

Hi,


bazel-bootstrap already build-depends on libgeronimo-annotation-1.3-spec-java.
The fix is trivial. Patch is attached.

Regards,

Markus


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

Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java

[Markus Koschany]

diff -Nru bazel-bootstrap-4.2.3+ds/debian/changelog bazel-bootstrap-4.2.3+ds/debian/changelog
--- bazel-bootstrap-4.2.3+ds/debian/changelog	2023-03-14 18:46:36.0 +0100
+++ bazel-bootstrap-4.2.3+ds/debian/changelog	2023-05-14 15:40:19.0 +0200
@@ -1,3 +1,12 @@
+bazel-bootstrap (4.2.3+ds-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-dependency on libtomcat9-java and replace
+tomcat9-annotations-api.jar with geronimo-annotation-1.3-spec.jar.
+(Closes: #1035995)
+
+ -- Markus Koschany   Sun, 14 May 2023 15:40:19 +0200
+
 bazel-bootstrap (4.2.3+ds-8) unstable; urgency=high
 
   * Correctly update 32-bit autopkgtests
diff -Nru bazel-bootstrap-4.2.3+ds/debian/control bazel-bootstrap-4.2.3+ds/debian/control
--- bazel-bootstrap-4.2.3+ds/debian/control	2023-03-13 21:26:15.0 +0100
+++ bazel-bootstrap-4.2.3+ds/debian/control	2023-05-14 15:40:19.0 +0200
@@ -59,7 +59,6 @@
  libprotoc-dev,
  libreactive-streams-java,
  librx-java,
- libtomcat9-java,
  libtruth-java,
  libxz-java,
  default-jdk-headless,
diff -Nru bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch
--- bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch	1970-01-01 01:00:00.0 +0100
+++ bazel-bootstrap-4.2.3+ds/debian/patches/javax.annotations.patch	2023-05-14 15:40:19.0 +0200
@@ -0,0 +1,32 @@
+From: Markus Koschany 
+Date: Sun, 14 May 2023 15:34:17 +0200
+Subject: javax.annotations
+
+Switch to geronimo-annotation-1.3-spec. Do not require libtomcat9-java.
+
+Bug-Debian: https://bugs.debian.org/1035995
+Forwarded: no
+---
+ tools/distributions/debian/debian_java.BUILD | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tools/distributions/debian/debian_java.BUILD b/tools/distributions/debian/debian_java.BUILD
+index 497df78..5cfbd91 100755
+--- a/tools/distributions/debian/debian_java.BUILD
 b/tools/distributions/debian/debian_java.BUILD
+@@ -55,13 +55,13 @@ java_import(
+ # libtomcat9-java
+ java_import(
+ name = "tomcat_annotations_api",
+-jars = ["tomcat9-annotations-api.jar"],
++jars = ["geronimo-annotation-1.3-spec.jar"],
+ )
+ 
+ # For bootstrapping java toolcahin
+ filegroup(
+ name = "tomcat_annotations_api-jars",
+-srcs = ["tomcat9-annotations-api.jar"],
++srcs = ["geronimo-annotation-1.3-spec.jar"],
+ )
+ 
+ # libjava-allocation-instrumenter-java
diff -Nru bazel-bootstrap-4.2.3+ds/debian/patches/series bazel-bootstrap-4.2.3+ds/debian/patches/series
--- bazel-bootstrap-4.2.3+ds/debian/patches/series	2023-03-14 18:46:36.0 +0100
+++ bazel-bootstrap-4.2.3+ds/debian/patches/series	2023-05-14 15:40:19.0 +0200
@@ -30,3 +30,4 @@
 grpc-absl_synchronization.patch
 exclude_build_data.patch
 fix-install_base_key-generation.patch
+javax.annotations.patch


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

Bug#1033835: polyml: autopkgtest regression: output on stderr

[Nilesh Patra]

Hi Jessica,

On Sun, 2 Apr 2023 15:22:49 +0200 Paul Gevers  wrote:

Source: polyml
Version: 5.7.1-5
Control: found -1 5.7.1-4
Severity: serious
Your package has an autopkgtest, great. However, it fails since July 
2020. Can you please investigate the situation and fix it? I copied some 


Looks like polyml is failing its autopkgtest. As the release happens is 
happening soon, would you consider to take a quick look at this?



autopkgtest [19:23:44]: test upstream-polyc: [---
/usr/bin/ld: warning: /tmp/polyobj.2070.o: missing .note.GNU-stack 
section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a 
future version of the linker

Test035.ML => Passed
Test162.ML => Passed

[...]

Test026.ML => Passed
autopkgtest [19:24:05]: test upstream-polyc: ---]
autopkgtest [19:24:05]: test upstream-polyc:  - - - - - - - - - - 
results - - - - - - - - - -
upstream-polyc   FAIL stderr: /usr/bin/ld: warning: 
/tmp/polyobj.2070.o: missing .note.GNU-stack section implies executable 
stack


Thanks
Nilesh

Bug#1035813: brltty: Fails to start on early boot

[Sebastian Humenda]

Hi

Samuel Thibault schrieb am 10.05.2023,  1:49 +0200:
>Sebastian Humenda, le mar. 09 mai 2023 15:53:05 +0200, a ecrit:
>> On my Debian Bookworm system, I've configured BRLTTY with speech output over
>> espeak-ng and a USB braille device. However, I am unable to use BRLTTY for my
>> password entry of my encrypted /home partition;
>
>Does it start after that?

Yes, it does. Sometimes even after lightdm has, with Orca, announced that a
password is required.

>> I've enabled the option that BRLTTY is pat of the initramfs, but I suspect it
>> is present, but not started. Is there any other action required?
>
>AFAIK all is needed is enabling it in /etc/default/brltty and running
>update-initramf -u (which prints "Installing BRLTTY into initramfs)

Yes, indeed.

>> I also think that the dependencies of BRLTTY prevent it from being started by
>> systemd at an earlier stage. I'm not familiar with the Systemd boot process,
>> but it could be related to requiring paths like /var/lib/brltty to be mounted
>
>Yes, the brltty service expresses that it needs /var/lib/brlty and
>BrlAPI. But that shouldn't be requiring /home/

Yes, but I thought that sysemd might order the mounts by some means which
would, just as an implementation detail, mount /home before it declares /var
to be present (unlikely though).

>I tried to install a system with an encrypted /home, and brltty does get
>started before the /home passphrase step. You can probably check
>journalctl and other systemd tools to see what is actually happening.

The flood of messages is a bit overwelming. The systemd unit of BRLTTY
(journalctl -u brltty) is obviously not helpful. To you suggest to read
/var/log/syslog from the boot on?

Thanks
Sebastian


signature.asc
Description: PGP signature

Bug#1036050: poppler-utils: pdfseparate does not accept width in page number format

[Axel Stammler]

Package: poppler-utils
Version: 20.09.0-3.1+deb11u1
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

calling

separate -f 9 -l 10 sek2_biologie.pdf sek2_biologie_%2d.pdf

results in

Syntax Error: 'sek2_biologie %2d.pdf' must contain '%d' (or any variant 
respecting printf format) if more than one page should be extracted, in order 
to print the page number

even though this should be an acceptable variant of a Print F format string.


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

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

Versions of packages poppler-utils depends on:
ii  libc6  2.31-13+deb11u6
ii  libcairo2  1.16.0-5
ii  libfreetype6   2.10.4+dfsg-1+deb11u1
ii  liblcms2-2 2.12~rc1-2
ii  libpoppler102  20.09.0-3.1+deb11u1
ii  libstdc++6 10.2.1-6

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- debconf-show failed

Bug#1036049: cryptsetup-initramfs: support for compressed modules

[Kevin Locke]

Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: wishlist
Tags: patch

Dear Maintainer,

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension.
This causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.  Although compression is not
currently enabled in any Debian kernel configuration that I'm aware
of, it would be nice if cryptsetup-initramfs could support this
configuration for downstream distributions and users with custom
kernels.

I've attached a patch to add support, as done by initramfs-tools:
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
Note that the situation has changed a bit since that commit and kmod
now supports zstd (Bug 990092) in addition to xz (Bug 772628).

Thanks for considering,
Kevin

-- Package-specific info:

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

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

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.35.0-4+b3
ii  cryptsetup  2:2.6.1-4~deb12u1
ii  debconf [debconf-2.0]   1.5.82
ii  initramfs-tools [linux-initramfs-tool]  0.142

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.220
ii  kbd2.5.1-1+b1

cryptsetup-initramfs suggests no packages.

-- debconf information excluded
>From e52a22ea1ccc9bc66f80d1e3d2eb9ed5e92e4022 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Sat, 13 May 2023 22:37:01 -0600
Subject: [PATCH] initramfs: cryptroot support compressed modules

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension. This
causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.

Match module files with additional extensions, as in
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
for initramfs-tools.  Note that kmod now supports zstd (Bug 990092) in
addition to xz (Bug 772628).

Signed-off-by: Kevin Locke 
---
 debian/initramfs/hooks/cryptroot | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/initramfs/hooks/cryptroot b/debian/initramfs/hooks/cryptroot
index 35577865..7b438593 100644
--- a/debian/initramfs/hooks/cryptroot
+++ b/debian/initramfs/hooks/cryptroot
@@ -266,8 +266,8 @@ populate_CRYPTO_MODULES() {
 add_modules() {
 local glob="$1" found=n
 shift
-for mod in $(find -H "$@" -name "$glob.ko" -type f -printf '%f\n'); do
-manual_add_modules "${mod%.ko}"
+for mod in $(find -H "$@" -name "$glob.ko*" -type f -printf '%f\n'); do
+manual_add_modules "${mod%.ko*}"
 found=y
 done
 [ "$found" = y ] && return 0 || return 1
-- 
2.39.2

Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Andreas Metzler]

On 2023-05-07 Andreas Metzler  wrote:
[...]
> The only proper fix would be to use versioned symbols for libpoppler
> (and libpoppler-glib while we are at it). This should not be rocket
> science, just tie it to the soname.

> But that needs to happen upstream.

Something like attached patch.
cu Andreas
Description: Use symbol versioning for libpoppler
 .
 This needs to be applied upstream when the soname is bumped.
Author: Andreas Metzler 
Origin: vendor
Bug-Debian: https://bugs.debian.org/969907
Forwarded: no
Last-Update: 2023-05-14

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -572,16 +572,31 @@ ADD_GPERF_FILE(TimesBoldWidths)
 ADD_GPERF_FILE(TimesBoldItalicWidths)
 ADD_GPERF_FILE(TimesItalicWidths)
 ADD_GPERF_FILE(TimesRomanWidths)
 ADD_GPERF_FILE(ZapfDingbatsWidths)
 
+set(POPPLER_SOVERSION_NUMBER "126")
+
+set(LINKER_SCRIPT "${CMAKE_BINARY_DIR}/libpoppler.map")
+configure_file(
+"${CMAKE_SOURCE_DIR}/poppler/libpoppler.map.in"
+${LINKER_SCRIPT})
+
 if(MSVC)
 add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
-add_library(poppler ${poppler_SRCS})
+add_library(poppler ${poppler_SRCS} ${LINKER_SCRIPT})
 generate_export_header(poppler BASE_NAME poppler-private EXPORT_FILE_NAME "${CMAKE_CURRENT_BINARY_DIR}/poppler_private_export.h")
-set_target_properties(poppler PROPERTIES VERSION 126.0.0 SOVERSION 126)
+set_target_properties(poppler PROPERTIES
+	VERSION ${POPPLER_SOVERSION_NUMBER}.0.0
+	SOVERSION ${POPPLER_SOVERSION_NUMBER})
+
+if(UNIX AND (NOT APPLE))
+	set_target_properties(poppler PROPERTIES
+		LINK_OPTIONS LINKER:--version-script=${LINKER_SCRIPT})
+endif()
+
 if(MINGW AND BUILD_SHARED_LIBS)
 get_target_property(POPPLER_SOVERSION poppler SOVERSION)
 set_target_properties(poppler PROPERTIES SUFFIX "-${POPPLER_SOVERSION}${CMAKE_SHARED_LIBRARY_SUFFIX}")
 endif()
 target_link_libraries(poppler LINK_PRIVATE ${poppler_LIBS})
--- /dev/null
+++ b/poppler/libpoppler.map.in
@@ -0,0 +1,4 @@
+POPPLER_@POPPLER_SOVERSION_NUMBER@ {
+  global:
+*;
+};

Bug#1036048: puppet-module-sbitio-monit: Package description mentions unexistant below explanation

[Beatrice Torracca]

Package: puppet-module-sbitio-monit
Severity: minor

Hi,

the description of the package puppet-module-sbitio-monit now ends with the 
sentence «See below for details.», but there is no information below that 
sentence.

Thanks,

beatrice

Bug#1035966: unblock: google-android-installers/1675172738

[Fab Stz]

Control: tags 1035966 - moreinfo

Le vendredi 12 mai 2023, 10:07:46 CEST Sebastian Ramacher a écrit :
> Control: tags -1 moreinfo confirmed
> 
> On 2023-05-11 21:48:18 +0200, Fab Stz wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Please unblock package google-android-installers
> > 
> > At the time of writing this, I'm waiting for my sponsor to upload the
> > latest version to unstable.
> 
> Please remove the moreinfo tag once the package is available in
> unstable.
> 
> Cheers

Bug#988581: Re

[Zakari Bikienga]

Lieber Freund,

Wie geht es dir? Ich weiß, dass meine Botschaft Sie überraschen wird, aber
alles, was hier niedergeschrieben wird, ist die Wahrheit. Wir arbeiten im
Rahmen der UN und der EU daran, alle Opfer von Cyberbetrug auf der ganzen
Welt zu entschädigen. Die EU/UN hat sich 2012 mit der
Cybercrime-Fundraising-Organisation zusammengetan, um alle Opfer von
Cyberbetrug zu entschädigen. Die Auswahl erfolgt nur nach dem
Zufallsprinzip, sodass Sie das Glück haben, kontaktiert zu werden, da Ihre
detaillierte E-Mail-Adresse in unserem System angezeigt wird. Gerne geben
wir Ihnen weitere Einzelheiten zu Ihrer positiven Antwort bekannt, damit
Sie Ihren eigenen Anteil erhalten können. Sie können mir jedoch bei Bedarf
Fragen stellen. Wir freuen uns, bald von Ihnen zu hören.

Grüße,
Fatima William.

Bug#1036047: unblock: nlopt/2.7.1-5

[Nilesh Patra]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nl...@packages.debian.org
Control: affects -1 + src:nlopt

Please unblock package nlopt

[ Reason ]
This upload was done due to address a piuparts error while
upgrading nlopt from bullseye -> bookworm, see #1035629.

[ Impact ]
Loss of files in usr/share/doc/libnlopt0 maybe observed, and
over-writing files too, which is not desired.

[ Tests ]
Manual tests done locally by upgrading from version in bullseye to
bookworm, and then removing packages individually, and inspected the
contents of the doc directories -- did not see any surprises.

[ Risks ]
As the upload touches only the doc section only, the package is
un-affected in terms of it's core (library) functionality. No big risks.

[ 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 testing

unblock nlopt/2.7.1-5
diff -Nru nlopt-2.7.1/debian/changelog nlopt-2.7.1/debian/changelog
--- nlopt-2.7.1/debian/changelog2022-04-14 15:10:53.0 +
+++ nlopt-2.7.1/debian/changelog2023-05-14 09:35:20.0 +
@@ -1,3 +1,13 @@
+nlopt (2.7.1-5) unstable; urgency=medium
+
+  * Team Upload.
+  * Add maintscript to convert libnlopt-dev doc
+symlink to directory (Closes: #1035629)
+  * Add a preinst to remove examples directory in libnlopt0
+which should be present in -dev only
+
+ -- Nilesh Patra   Sun, 14 May 2023 09:35:20 +
+
 nlopt (2.7.1-4) unstable; urgency=medium
 
   * Team upload
diff -Nru nlopt-2.7.1/debian/libnlopt0.preinst 
nlopt-2.7.1/debian/libnlopt0.preinst
--- nlopt-2.7.1/debian/libnlopt0.preinst1970-01-01 00:00:00.0 
+
+++ nlopt-2.7.1/debian/libnlopt0.preinst2023-05-14 09:35:20.0 
+
@@ -0,0 +1,6 @@
+#!/bin/sh -e
+# directory moved to -dev package, the symlink from past upgrade should be 
removed
+if [ -d /usr/share/doc/libnlopt0/examples ]; then
+   rm -rf /usr/share/doc/libnlopt0/examples
+fi
+#DEBHELPER#
diff -Nru nlopt-2.7.1/debian/libnlopt-dev.maintscript 
nlopt-2.7.1/debian/libnlopt-dev.maintscript
--- nlopt-2.7.1/debian/libnlopt-dev.maintscript 1970-01-01 00:00:00.0 
+
+++ nlopt-2.7.1/debian/libnlopt-dev.maintscript 2023-05-14 09:35:20.0 
+
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/libnlopt-dev libnlopt0 2.7.1-5~

Bug#1035629: libnlopt-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Nilesh Patra]

Hi

Thanks for explaining it to me.

On 14/05/23 14:08, Andreas Beckmann wrote:

On 14/05/2023 10.22, Nilesh Patra wrote:

Could you help explain where exactly the overwriting is happening?


In bullseye libnlopt-dev ships /usr/share/doc/libnlopt-dev as a symlink 
to libnlopt0

dpkg retains this symlink on upgrades to bookworm
In bookworm libnlopt-dev ships /usr/share/doc/libnlopt-dev as a directory


I've fixed it with a symlink_to_dir


...
libnlopt-dev ships /usr/share/doc/libnlopt-dev/examples/*, too, which 
ends up as
/usr/share/doc/libnlopt0/examples/*, but these could already be files 
owned by

another package.


And added a preinst to remove examples/ from libnlopt0, as it really 
should not be there.


Best
Nilesh

Bug#1031851: debhelper: makefile/dh_install should set prefix= and other standard variables

[Niels Thykier]

Control: tags -1 moreinfo

Gioele Barabucci:

Package: debhelper
Version: 13.11.4

Currently `dh_install` for makefile-based project sets the `DESTDIR` 
variable only.


[...]

A code search shows that setting `prefix=` and `sysconfdir=` is quite 
common in `d/rules` files:


https://codesearch.debian.net/search?q=%5B%5E-%5Dprefix%3D%2Fusr+path%3Adebian%2Frules=0=1



I find it curious that a number of these matches do not seem to apply to 
`make install` or `dh_auto_install`. Instead they are sometimes also 
used for `make` (e.g., the build phase rather than the install phase).


Just to set the expectations of how much benefit this change can result 
in as far as "reducing the number of cases with explicit prefix=/usr".


My "gut" feeling from scrolling over ~5 pages leaves me with a 40%/50% 
rate of cases where the package might benefit from it to the point where 
prefix=/usr would disappear (if/when people use dh_auto_install rather 
than "make install" - not all the "make install" lines I saw could 
easily be converted).


Given that debhelper sets `DESTDIR`, couldn't it also set `prefix` and 
all other common makefile variables, just like it does for 
autoconf-based projects (see 
)?


Regards,



It could. I think there are two important cases to consider:

 1) How many packages will this change break?

 2) How easy will it be for people to realize this change is what breaks
stuff and how to resolve it. Like can we come with a "one-size fits
all" answer for how to undo this change if it breaks a specific
package?

I think those two questions should be the counter-weight compared to the 
gain when evaluating whether we should apply this change and I would 
like to see the numbers/proposals for these to before saying whether we 
should move forward with this change.


Note: I am assuming this would require a compat bump. So for the 
answers, it is really about how painful will that compat bump be for the 
users of debhelper.


Best regards,
Niels

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Niels Thykier]

Michael Biebl:

Hello Niels, hello Sebastian



Hi Michael,



Am 24.03.23 um 16:28 schrieb Niels Thykier:

Sebastian Ramacher:

[...]

Any progress here? If this issue should be fixed for bookworm, time is
running short.

Cheers


I find that anytime I look at this bug my motivation to work on Debian 
instantly vanishes. In fact, I cannot even motivate myself to read the 
bug log to figure out what the consensus is. Accordingly, I will play 
the constitution 2.1.1 and step out of the way.
My attempt to raise this issue with debhelper and the release-team was 
to gather a consensus with how to deal with the affected packages.
A change to debhelper seemed liked the most straightforward approach to 
me.


I agree with all of this and I think you were both entitled and correct 
in raising the issue. I am still open to this being a bug in debhelper.


It was not meant as an attempt to force Niels into something he 
feels uncomfortable with, which he obviously does.

I apologize to Niels for that and hereby close this bug report.

Michael


Your reaction here does not match what I had expected from my email and 
I suspect my intentions were not perceived by you as I intended them. To 
start with the most important points:


You have done *nothing* to me that requires an apology from you.

You have *not* forced me to do something I am uncomfortable with.

As far as I am concerned, there was and is *no* conflict between
you and I.

We are good if you ask me. I am mostly sad that I made you think
otherwise, but that is on me.


Coming back to what I wanted to communicate: Starting with the context, 
the timing of my email came after two mails asking for an update on this 
bug that had not been answered by anyone. I.e., my email was a response 
to the requests for a update on the bug - both requests were in my view 
reasonable.
  As the named maintainer/uploader of debhelper, there is always an 
implicit assumption that I will be proactive in dealing with bugs, when 
there is no clear owner of the bug. Especially bugs that affect the 
upcoming release during the freeze. Given that I did not see a response 
and I could not easily identify a clear owner of the bug, I felt these 
emails hanged on me via the implicit assumption.


I wanted to make it very clear that I would *not* be able to live up to 
that assumption. If someone wanted this change, they would have to do it 
without involving me at any point. I was hoping that someone would take 
end to end ownership and deliver it without involving me. As opposed to 
a PR/patch that I would have to review - or leaving me to discuss with 
the RT what kind of change was acceptable this stage - or leaving me to 
reopen the discussion with the tech-ctte whether allowing services in 
/usr is acceptable as it would open up for file moves between /lib and 
/usr/lib, which they said they would not want when the original bug was 
filed (#995569).


  I would not have been able to do that and I doubt I will be able to do
  that any time soon.

But if someone wanted to do that. Great! It would have been a burden off 
my shoulder. On the flip-side, if no one else was willing to do the 
work, then I would not have to feel bad about not being able to do it 
either.  Either way would relieve me of the pressure of this bug.


Eventually, dh_installsystemd (et al.) will probably have to support 
/usr/lib. If someone fixes that now, great. If someone fixes later, great.


I do not mind the change. I mind the assumption that I will be doing it 
(in this or in future releases). Feel free to reopen this bug. As long 
as we all agree that for the timing being, *I* will *not* be interacting 
with the bug, do any design or review of the solution, or deal with any 
fallout of implementing the solution.
  Whoever owns up to dealing with all of that gets to deliver this 
feature. They get to do it without having to follow the NMU rules as far 
as I am concerned unless a co-maintainer steps up and takes ownership of 
this bug, because to me that is part of "stepping out of the way" when 
you are not volunteering to do the work.



In summary:

 * I do not feel you did anything wrong or owe me an apology.

 * I mind doing the work; not the change. If you (anyone) want
   this change and you commit to doing it. Please reopen the bug and go
   ahead as long as you do not "depend" on or "need" me for any part of
   it.

I hope my intentions were more clear this time.

Best regards,
Niels

Bug#1036046: bullseye-pu: package debian-parl/1.9.27+deb11u1

[Andreas Beckmann]

Followup-For: Bug #1036046
diff --git a/debian/changelog b/debian/changelog
index 3e541dc..632788c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+debian-parl (1.9.27+deb11u1) bullseye; urgency=medium
+
+  * rebuild using newer boxer-data
++ stop include lightning; closes: bug#1035344
++ stop include thunderbird-l10n-si; closes: bug#1000872
+
+ -- Andreas Beckmann   Mon, 01 May 2023 15:51:40 +0200
+
 debian-parl (1.9.27) unstable; urgency=medium
 
   * rebuild using newer boxer-data
diff --git a/debian/control b/debian/control
index 6a1da5c..7ebcaf9 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: cdbs,
  boxer (>= 0.004~),
  shellcheck,
 # lock to boxer-data minor release: Feature additions should be documented
- boxer-data (>= 10.8),
+ boxer-data (>= 10.8.28+deb11u1~),
  boxer-data (<< 10.9)
 Standards-Version: 4.4.0
 Homepage: https://wiki.debian.org/DebianParl
diff --git a/debian/gbp.conf b/debian/gbp.conf
index dad7295..4cc4bf2 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,6 @@
 # Configuration file for git-buildpackage and friends
 
 [DEFAULT]
+debian-branch = bullseye
 sign-tags = True
 filter = */.git*

Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV

[Harald Dunkel]

Control: tag -1 -moreinfo

Hi Axel,

apparently it is not sufficient to just add the entry to sources.list.d.
I had to update the local cache to make aptitude die.

On 2023-05-13 23:29:14, Axel Beckert wrote:


* Do you have any custom settings for settings influencing aptitude's
   package display like "Aptitude::UI::Package-Display-Format" or
   "Aptitude::UI::Default-Grouping"?



No, I just have

# cat .aptitude/config
aptitude "";
aptitude::Keep-Unused-Pattern "";
aptitude::Delete-Unused-Pattern "";
aptitude::UI "";
aptitude::UI::Prompt-On-Exit "false";
aptitude::UI::Advance-On-Action "true";
APT "";
APT::Install-Recommends "false";


* Under which locale settings does it happen for you?



On some systems I have set LANG=C or LANG=en_US.UTF-8, but I can reproduce
this using

# locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

I doubt that this is related to the locale.


If you neither use any of these settings nor use a non-english locale,
is there any chance that you can install these packages (for
bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the
debian-goodies package) on one of the affected machines:

strace aptitude-dbgsym libapt-pkg6.0-dbgsym
libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg
libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym
libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym
liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym
libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym
libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym
zlib1g-dbgsym



libelogind0? This breaks systemd.


Regards
Harri

Bug#1036046: bullseye-pu: package debian-parl/1.9.27+deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:debian-parl
Control: block 1035344 with -1
Control: block 1000872 with -1
Control: affects 1036044 + src:debian-design
Control: block 1000737 with 1036044

debian-parl needs to be rebuilt against newer boxer-data to drop
dependencies on packages lo longer built by src:thunderbird, e.g.
lightning. Currently design-parl* are uninstallable in bullseye.

Effective binary debdiff caused by this rebuild:

$ debdiff parl-desktop_1.9.27_all.deb parl-desktop_1.9.27+deb11u1_all.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: task-laptop, acpi-support, acpi-support-base, alsa-utils, anacron, 
apt-listchanges, aptitude, bash-completion, bluez, catfish, 
debian-security-support, evince, firefox-esr, gnome-disk-utility, 
jitterentropy-rngd, libgl1-mesa-dri, libreoffice-calc, libreoffice-gtk3, 
libreoffice-impress, libreoffice-writer, lightdm, [-lightning,-] mlocate, 
mousepad, mpv, needrestart, network-manager-gnome, nuntius, parcimonie, 
pasystray, pavucontrol, pinentry-gtk2, popularity-contest, pulseaudio, 
pulseaudio-utils, pulsemixer, shotwell, slick-greeter, systemd, thunar, 
thunderbird, unattended-upgrades, unicode-screensaver, usermode, uuid-runtime, 
volumeicon-alsa, webext-dav4tbsync, webext-https-everywhere, 
webext-privacy-badger, webext-ublock-origin-firefox, xfce4-notifyd, 
xfce4-panel, xfce4-power-manager, xfce4-power-manager-plugins, 
xfce4-pulseaudio-plugin, xfce4-session, xserver-xorg
Version: [-1.9.27-] {+1.9.27+deb11u1+}

$ debdiff parl-desktop-world_1.9.27_all.deb 
parl-desktop-world_1.9.27+deb11u1_all.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: parl-desktop, firefox-esr-l10n-ach, firefox-esr-l10n-af, 
firefox-esr-l10n-an, firefox-esr-l10n-ar, firefox-esr-l10n-ast, 
firefox-esr-l10n-az, firefox-esr-l10n-be, firefox-esr-l10n-bg, 
firefox-esr-l10n-bn, firefox-esr-l10n-br, firefox-esr-l10n-bs, 
firefox-esr-l10n-ca, firefox-esr-l10n-cak, firefox-esr-l10n-cs, 
firefox-esr-l10n-cy, firefox-esr-l10n-da, firefox-esr-l10n-de, 
firefox-esr-l10n-dsb, firefox-esr-l10n-el, firefox-esr-l10n-en-ca, 
firefox-esr-l10n-en-gb, firefox-esr-l10n-eo, firefox-esr-l10n-es-ar, 
firefox-esr-l10n-es-cl, firefox-esr-l10n-es-es, firefox-esr-l10n-es-mx, 
firefox-esr-l10n-et, firefox-esr-l10n-eu, firefox-esr-l10n-fa, 
firefox-esr-l10n-ff, firefox-esr-l10n-fi, firefox-esr-l10n-fr, 
firefox-esr-l10n-fy-nl, firefox-esr-l10n-ga-ie, firefox-esr-l10n-gd, 
firefox-esr-l10n-gl, firefox-esr-l10n-gn, firefox-esr-l10n-gu-in, 
firefox-esr-l10n-he, firefox-esr-l10n-hi-in, firefox-esr-l10n-hr, 
firefox-esr-l10n-hsb, firefox-esr-l10n-hu, firefox-esr-l10n-hy-am, 
firefox-esr-l10n-ia, firefox-esr-l10n-id, firefox-esr-l10n-is, 
firefox-esr-l10n-it, firefox-esr-l10n-ja, firefox-esr-l10n-ka, 
firefox-esr-l10n-kab, firefox-esr-l10n-kk, firefox-esr-l10n-km, 
firefox-esr-l10n-kn, firefox-esr-l10n-ko, firefox-esr-l10n-lij, 
firefox-esr-l10n-lt, firefox-esr-l10n-lv, firefox-esr-l10n-mk, 
firefox-esr-l10n-mr, firefox-esr-l10n-ms, firefox-esr-l10n-my, 
firefox-esr-l10n-nb-no, firefox-esr-l10n-ne-np, firefox-esr-l10n-nl, 
firefox-esr-l10n-nn-no, firefox-esr-l10n-oc, firefox-esr-l10n-pa-in, 
firefox-esr-l10n-pl, firefox-esr-l10n-pt-br, firefox-esr-l10n-pt-pt, 
firefox-esr-l10n-rm, firefox-esr-l10n-ro, firefox-esr-l10n-ru, 
firefox-esr-l10n-si, firefox-esr-l10n-sk, firefox-esr-l10n-sl, 
firefox-esr-l10n-son, firefox-esr-l10n-sq, firefox-esr-l10n-sr, 
firefox-esr-l10n-sv-se, firefox-esr-l10n-ta, firefox-esr-l10n-te, 
firefox-esr-l10n-th, firefox-esr-l10n-tr, firefox-esr-l10n-uk, 
firefox-esr-l10n-ur, firefox-esr-l10n-uz, firefox-esr-l10n-vi, 
firefox-esr-l10n-xh, firefox-esr-l10n-zh-cn, firefox-esr-l10n-zh-tw, 
hunspell-af, hunspell-an, hunspell-ar, hunspell-be, hunspell-bg, hunspell-bn, 
hunspell-bo, hunspell-br, hunspell-bs, hunspell-ca, hunspell-cs, 
hunspell-de-at, hunspell-de-ch, hunspell-de-de, hunspell-dz, hunspell-el, 
hunspell-en-au, hunspell-en-ca, hunspell-en-gb, hunspell-en-us, hunspell-es, 
hunspell-eu, hunspell-fr-classical, hunspell-gd, hunspell-gl, hunspell-gu, 
hunspell-gug, hunspell-he, hunspell-hi, hunspell-hr, hunspell-hu, hunspell-id, 
hunspell-is, hunspell-it, hunspell-kk, hunspell-kmr, hunspell-ko, hunspell-lo, 
hunspell-lt, hunspell-lv, hunspell-ml, hunspell-ne, hunspell-nl, hunspell-no, 
hunspell-oc, hunspell-pl, hunspell-pt-br, hunspell-pt-pt, hunspell-ro, 
hunspell-ru, hunspell-si, hunspell-sk, hunspell-sl, hunspell-sr, hunspell-sv, 
hunspell-sw, hunspell-te, hunspell-th, hunspell-tr, hunspell-uk, hunspell-uz, 
hunspell-vi, hyphen-af, hyphen-as, hyphen-bn, hyphen-da, hyphen-de, 
hyphen-en-gb, hyphen-kn, hyphen-mr, hyphen-pa, hyphen-ta, hyphen-zu, 
libreoffice-l10n-af, 

Bug#1036045: unblock: opencascade/7.6.3+dfsg1-6

[Tobias Frost]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: opencasc...@packages.debian.org
Control: affects -1 + src:opencascade

Please unblock package opencascade

Helmut Grohne reported in #1035009 a missing Conflict: on several
package, leading in certtain circumstances to installation errors.
(Details in the bug)

Additionally, this upload fixes two lintian *errors*:
(E: depends-on-obsolete-package), suggestiong renaming two Depends:
 libfreetype6-dev with libfreetype-dev
 libgl1-mesa-dev with libgl-dev

[ Risks ]
Changes are trivial

piuparts is happy as well
(CI: https://salsa.debian.org/science-team/opencascade/-/pipelines/527866,
 piuparts job: 
https://salsa.debian.org/science-team/opencascade/-/jobs/4214165)


[ 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 testing

unblock opencascade/7.6.3+dfsg1-6

-- 
Cheers,
tobi

Bug#1036044: bullseye-pu: package debian-design/3.0.22+deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

debian-design needs to be rebuilt against newer boxer-data to drop
dependencies on packages lo longer built by src:thunderbird, e.g.
lightning. Currently design-desktop* are uninstallable in bullseye.

Effective binary debdiff caused by this rebuild:

$ debdiff design-desktop_3.0.22_all.deb design-desktop_3.0.22+deb11u1_all.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: alsa-utils, apt-listchanges, aptitude, bzip2, debian-security-support, 
dfc, evince, firefox-esr, less, libgl1-mesa-dri, libreoffice-calc, 
libreoffice-gtk3, libreoffice-impress, libreoffice-writer, lightdm, 
[-lightning,-] links, mc, mpv, mtr-tiny, nano, ncdu, needrestart, 
network-manager-gnome, pasystray, pavucontrol, popularity-contest, pulseaudio, 
pulseaudio-utils, pulsemixer, rsync, slick-greeter, thunar, thunderbird, 
unicode-screensaver, usermode, volumeicon-alsa, webext-dav4tbsync, wget, 
xfce4-notifyd, xfce4-panel, xfce4-power-manager, xfce4-power-manager-plugins, 
xfce4-pulseaudio-plugin, xfce4-session, xserver-xorg
Version: [-3.0.22-] {+3.0.22+deb11u1+}


Andreas
diff --git a/debian/changelog b/debian/changelog
index d5bd904..0d3aa41 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debian-design (3.0.22+deb11u1) bullseye; urgency=medium
+
+  * rebuild using newer boxer-data
++ stop include lightning; closes: bug#1000737
+
+ -- Andreas Beckmann   Mon, 01 May 2023 17:12:37 +0200
+
 debian-design (3.0.22) unstable; urgency=medium
 
   * rebuild using newer boxer-data
diff --git a/debian/control b/debian/control
index 3e204a3..0c74743 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: cdbs,
  boxer (>= 1.1.0),
  shellcheck,
 # lock to boxer-data minor release: Feature additions should be documented
- boxer-data (>= 10.8),
+ boxer-data (>= 10.8.28+deb11u1~),
  boxer-data (<< 10.9)
 Standards-Version: 4.5.1
 Homepage: https://wiki.debian.org/Design
diff --git a/debian/gbp.conf b/debian/gbp.conf
index dad7295..4cc4bf2 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,6 @@
 # Configuration file for git-buildpackage and friends
 
 [DEFAULT]
+debian-branch = bullseye
 sign-tags = True
 filter = */.git*

Bug#1036043: bullseye-pu: package boxer-data/10.8.28+deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:boxer-data
Control: block 1035347 with -1

This is a data update to remove packages no longer built by
src:thunderbird, e.g. lightning. This is needed for rebuilding
src:debian-design and src:debian-parl in order to drop the unavailable
dependencies and make their binary packages installable again in
bullseye.


Andreas
diff --git a/buster/classes/Desktop/email/thunderbird/locale/ASIA.yml 
b/buster/classes/Desktop/email/thunderbird/locale/ASIA.yml
index 9769349..17ae2c3 100644
--- a/buster/classes/Desktop/email/thunderbird/locale/ASIA.yml
+++ b/buster/classes/Desktop/email/thunderbird/locale/ASIA.yml
@@ -19,7 +19,6 @@ parameters:
 - thunderbird-l10n-ko
 - thunderbird-l10n-ms
 - thunderbird-l10n-ru
-- thunderbird-l10n-si
 - thunderbird-l10n-tr
 - thunderbird-l10n-vi
 - thunderbird-l10n-zh-cn
diff --git a/buster/classes/Desktop/scheduling/lightning/init.yml 
b/buster/classes/Desktop/scheduling/lightning/init.yml
index 722a476..6a9d60e 100644
--- a/buster/classes/Desktop/scheduling/lightning/init.yml
+++ b/buster/classes/Desktop/scheduling/lightning/init.yml
@@ -5,7 +5,6 @@ parameters:
   doc:
 desktop-scheduling:
   pkg:
-- include Thunderbird extension Lightning
+- include Thunderbird extension DAV-4-TbSync
   pkg:
-- lightning
 - webext-dav4tbsync
diff --git a/debian/changelog b/debian/changelog
index cd1891a..77ff1cd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+boxer-data (10.8.28+deb11u1) bullseye; urgency=medium
+
+  [ Jonas Smedegaard ]
+  * update class Desktop.scheduling.lightning:
+stop install package lightning (gone)
+  * update class Desktop.email.thunderbird.locale:
++ update subclass ASIA to stop include package thunderbird-l10n-si
+(Closes: #1035347)
+
+ -- Andreas Beckmann   Mon, 01 May 2023 15:43:00 +0200
+
 boxer-data (10.8.28) unstable; urgency=medium
 
   * fix exclude node showmebox-gnustep in autopkgtests
diff --git a/debian/gbp.conf b/debian/gbp.conf
index dad7295..4cc4bf2 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,6 @@
 # Configuration file for git-buildpackage and friends
 
 [DEFAULT]
+debian-branch = bullseye
 sign-tags = True
 filter = */.git*

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Cyril Brulebois]

Cyril Brulebois  (2023-05-14):
> Also, I should note that while my focus was on netboot-gtk mini.iso
> (because it's much quicker to rebuild/tweak than a netinst image), I'm
> replicating those results with the netinst images:
[…]
>  - Bookworm RC 1 has a “text-like” GRUB, all good.
>  - Bookworm RC 2 has a “graphical” GRUB, issues!

While adjusting my “nasty” approach to make sure it would build on all
three modified archs (amd64, arm64, i386), it occurred to me that:

 - Of course the trivial patch wouldn't work, because some builds aren't
   “pure GTK” builds, like cdrom-xen, and that one would also need the
   686-pae flavour on i386.

 - Of course it wouldn't work on arm64 either, since that one doesn't
   ship vboxvideo.ko.

 - And more importantly, we have the fb-modules udeb in various places,
   including for builds that aren't about the graphical installer…


And at this point, it seems fair to say that at least the Linux kernel
isn't perfect, as problems show up even without X in the picture!

 - With Bookworm RC 1 netinst amd64 (again under UEFI), switch from
   default “Graphical install” to “Install”: the text installer shows
   up with both std and cirrus.

 - With Bookworm RC 2 netinst amd64 (again under UEFI), switch from
   default “Graphical install” to “Install”: the screen is garbled
   with std, split with cirrus.


This is easily confirmed:

 - Triggering a debian-installer “netboot” build (not “netboot-gtk”):
   the resulting mini.iso exhibits the same problems as Bookwork RC 2
   using “Install”, with both std and cirrus.

 - Patching that “netboot” build to benefit from the extra DRM modules
   makes those issues go away, with both std and cirrus.

 - Alternatively, not patching the “netboot” build but reverting the same
   patch as mentioned before makes those issues go away, with both std and
   cirrus:
 
https://salsa.debian.org/installer-team/debian-installer/-/commit/a4dc8c0fe7ad1a0c1506125ad9985f78819a1bb2


For the very short term (RC 3), I think I'll implement the following:

 1. Consider archs with the graphical installer (that's been my main
focus until a few hours ago, when I started realizing the console
without X was also impacted), even if other archs include fb-modules
as well.
This means: amd64, arm64, i386. Those happen to also do EFI/SB.

 2. Hardcode list of of modules to be added:
  drm_shmem_helper.ko
  drm_ttm_helper.ko
  drm_vram_helper.ko
  tiny/bochs.ko
  tiny/cirrus.ko
  ttm/ttm.ko
  vboxvideo/vboxvideo.ko [!arm64, i.e. amd64 and i386 only]

 3. For each of these 3 archs, deploy each of these modules. Do that for
each build that includes drm.ko (which should be synonymous with
fb-modules being deployed, given drm.ko is mandatory in the common
fb-modules file, included from the arch-specific ones in src:linux),
and do that without a condition on GTK detection or /usr/bin/Xorg's
presence.

This should be targeted enough (touching 3 archs, two of which are getting
a lot of attention; leaving all others entirely untouched), yet generic
enough to work around issues that show up in both text and graphical
versions of the installer, by patching all relevant builds (netboot,
netboot-gtk, those used by debian-cd, etc.).

I'll push a v2 of my nasty branch once I've performed some clean-up and
some more testing.


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


signature.asc
Description: PGP signature

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Andreas Beckmann]

On 09/05/2023 17.48, Michael Biebl wrote:
Andreas, you filed this with RC severity with the justification that 
systemd units are not enabled. I don't see that, so could you please 
clarify.


What I could find out so far is the change of WantedBy target not being 
properly cleaned up on upgrades, but that doesn't strike me as RC (and 
would need to be done in e2fsprogs)


Yes, looks like this is in the e2fsprogs realm.

Please reassign it there together with instructions how to fix it, i.e. 
what should be done in the maintainer scripts.


IMO the expected outcome from e2fsprogs perspective should be identical 
system configuration (w.r.t. enabled systemd units) after both fresh 
install and upgrade from bullseye, regardless of the installation status 
of systemd.

If e2fsprogs doesn't care about this, it can downgrade the severity.


Andreas

Bug#1035364: lttng-modules-dkms: fails to build module on bullseye for Linux 5.10.0-22-amd64

[Andreas Beckmann]

Followup-For: Bug #1035364
Control: tag -1 bullseye
Control: block -1 with 1035464

Please get 2.13.9 unblocked for bookworm. 2.13.8 still does not build
for the 5.10 LTS kernel in bullseye, so it will fail during upgrades
from bullseye to bookworm (even after the bullseye version got fixed)
since both 5.10 and 6.1 kernels and headers will be installed.


Andreas

Bug#1035364: lttng-modules-dkms: fails to build module on bullseye for Linux 5.10.0-22-amd64

[Andreas Beckmann]

Followup-For: Bug #1035364
Control: tag -1 + patch

Attached is a patch which is a collection of several commits from the
upstream stable-2.12 branch to restore compatibility with the Linux 5.10
LTS kernel in bullseye.


Andreas
>From eb69797441ee560f51be5ec1621e34eb9c7df123 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Fri, 12 May 2023 14:46:53 +0200
Subject: [PATCH] cherry-pick upstream fixes for Linux 5.10 LTS support

---
 debian/changelog  |   7 +
 debian/gbp.conf   |   2 +-
 debian/lttng-modules-dkms.dkms.in |   2 +
 ...call-blk_status_to_errno-in-blk_upda.patch |  58 +++
 ...-the-rq_disk-field-in-struct-request.patch | 155 ++
 ...ndom-remove-unused-tracepoints-v5.18.patch |  45 +
 ...emove-unused-tracepoints-v5.10-v5.15.patch |  44 +
 ...racepoints-removed-in-stable-kernels.patch |  50 ++
 ...djust-range-v5.10.137-in-block-probe.patch |  91 ++
 ...ix-jbd2-use-the-correct-print-format.patch | 152 +
 ...e-the-correct-print-format-v5.10.163.patch |  57 +++
 ...7-fix-jbd2-upper-bound-for-v5.10.163.patch |  48 ++
 debian/patches/series |   9 +
 13 files changed, 719 insertions(+), 1 deletion(-)
 create mode 100644 
debian/patches/0034-fix-block-don-t-call-blk_status_to_errno-in-blk_upda.patch
 create mode 100644 
debian/patches/0039-fix-block-remove-the-rq_disk-field-in-struct-request.patch
 create mode 100644 
debian/patches/0051-fix-random-remove-unused-tracepoints-v5.18.patch
 create mode 100644 
debian/patches/0052-fix-random-remove-unused-tracepoints-v5.10-v5.15.patch
 create mode 100644 
debian/patches/0053-fix-random-tracepoints-removed-in-stable-kernels.patch
 create mode 100644 
debian/patches/0059-fix-adjust-range-v5.10.137-in-block-probe.patch
 create mode 100644 
debian/patches/0074-fix-jbd2-use-the-correct-print-format.patch
 create mode 100644 
debian/patches/0076-fix-jbd2-use-the-correct-print-format-v5.10.163.patch
 create mode 100644 debian/patches/0077-fix-jbd2-upper-bound-for-v5.10.163.patch

diff --git a/debian/changelog b/debian/changelog
index 5140940..8be1997 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lttng-modules (2.12.5-1+deb11u1) bullseye; urgency=medium
+
+  * Cherry-pick upstream fixes for Linux 5.10 LTS support from 2.12.7, 2.12.8,
+2.12.9, 2.12.11, 2.12.12, 2.12.13.  (Closes: #1035364)
+
+ -- Andreas Beckmann   Fri, 12 May 2023 14:41:40 +0200
+
 lttng-modules (2.12.5-1) unstable; urgency=medium
 
   * [8e0b514] New upstream version 2.12.5
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 2236634..ac5b4ec 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,3 @@
 [DEFAULT]
 upstream-branch=upstream/latest
-debian-branch=debian/sid
+debian-branch=debian/bullseye
diff --git a/debian/lttng-modules-dkms.dkms.in 
b/debian/lttng-modules-dkms.dkms.in
index e97ec7d..fa75167 100644
--- a/debian/lttng-modules-dkms.dkms.in
+++ b/debian/lttng-modules-dkms.dkms.in
@@ -169,10 +169,12 @@ BUILT_MODULE_LOCATION[$i]="probes/"
 DEST_MODULE_LOCATION[$i]="/extra/probes"
 i=$((i+1))
 
+if [ -f "$kernel_source_dir/include/trace/events/random.h" ]; then
 BUILT_MODULE_NAME[$i]="lttng-probe-random"
 BUILT_MODULE_LOCATION[$i]="probes/"
 DEST_MODULE_LOCATION[$i]="/extra/probes"
 i=$((i+1))
+fi
 
 BUILT_MODULE_NAME[$i]="lttng-probe-rcu"
 BUILT_MODULE_LOCATION[$i]="probes/"
diff --git 
a/debian/patches/0034-fix-block-don-t-call-blk_status_to_errno-in-blk_upda.patch
 
b/debian/patches/0034-fix-block-don-t-call-blk_status_to_errno-in-blk_upda.patch
new file mode 100644
index 000..4923336
--- /dev/null
+++ 
b/debian/patches/0034-fix-block-don-t-call-blk_status_to_errno-in-blk_upda.patch
@@ -0,0 +1,58 @@
+From 42a03cb282877dbefbf7da733d71131fa0f83ae0 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 14 Dec 2021 15:13:20 -0500
+Subject: [PATCH 34/87] fix: block: don't call blk_status_to_errno in
+ blk_update_request (v5.16)
+
+See upstream commit :
+
+  commit 8a7d267b4a2c71a5ff5dd9046abea7117c7d0ac2
+  Author: Christoph Hellwig 
+  Date:   Mon Oct 18 10:45:18 2021 +0200
+
+block: don't call blk_status_to_errno in blk_update_request
+
+We only need to call it to resolve the blk_status_t -> errno mapping for
+tracing, so move the conversion into the tracepoints that are not called
+at all when tracing isn't enabled.
+
+Change-Id: Ic556cee1d82e44a93a1467f55d45b6e17a48d387
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Mathieu Desnoyers 
+---
+ instrumentation/events/lttng-module/block.h | 19 ++-
+ 1 file changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/instrumentation/events/lttng-module/block.h 
b/instrumentation/events/lttng-module/block.h
+index c78de802..edd433e8 100644
+--- a/instrumentation/events/lttng-module/block.h
 b/instrumentation/events/lttng-module/block.h
+@@ -380,7 +380,24 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(block_rq_with_error, 

Bug#1036042: build-depends on libgmock-dev

[A Mennucc1]

Package: libhwy-dev
Version: 1.0.3-3
Severity: normal
Tags: ftbfs

Dear mantainer,

I tried to build the above version from source  (using the git tree
 master 491551e d/changelog: Upload 1.0.3-3 to unstable
) and it failed; it succeded once I installed the package libgmock-dev.

Regards

a.



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

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

Versions of packages libhwy-dev depends on:
ii  libhwy1 1.0.3-3

libhwy-dev recommends no packages.

libhwy-dev suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature