Bug#1034555: unblock: fluidsynth/2.3.1-2

[Fabian Greffrath]

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

Please unblock package fluidsynth

[ Reason ]
This revision fixes a regression that was introduced upstream between
the 2.3.0 and 2.3.1 releases and has been fixed in the 2.3.2 release.

[ Impact ]
The regression introduced a multi-second gap between looping MIDI
tracks. Since fluidsynth is the default renderer for MIDI music in
SDL2, this will affect *a lot* of games in Debian.

[ Tests ]
n/a

[ Risks ]
None, I'd say. The fix has been backported from the upstream GIT
repository and is in the 2.3.2 version, which has already been
released. The output of `git show -w c0e2ef` on the commit in question
has three lines of code changes, the rest is indentation:

--- a/src/midi/fluid_midi.c
+++ b/src/midi/fluid_midi.c
@@ -2179,6 +2179,8 @@ fluid_player_callback(void *data, unsigned int msec)
 fluid_atomic_int_set(&player->seek_ticks, -1); /* clear seek_ticks 
*/
 }
 
+if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+{
 /* Once we've run out of MIDI events, keep playing until no voices 
are active */
 if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
 {
@@ -2207,6 +2209,7 @@ fluid_player_callback(void *data, unsigned int msec)
 {
 status = FLUID_PLAYER_PLAYING;
 }
+}
 
 /* Once there's no reason to keep playing, we're actually done */
 if(status == FLUID_PLAYER_DONE)


[ 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 ]
n/a

unblock fluidsynth/2.3.1-2
diff -Nru fluidsynth-2.3.1/debian/changelog fluidsynth-2.3.1/debian/changelog
--- fluidsynth-2.3.1/debian/changelog   2022-12-30 16:10:11.0 +0100
+++ fluidsynth-2.3.1/debian/changelog   2023-04-18 07:48:30.0 +0200
@@ -1,3 +1,11 @@
+fluidsynth (2.3.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Apply patch from upstream to fix seamless looping between MIDI
+files.
+
+ -- Fabian Greffrath   Tue, 18 Apr 2023 07:48:30 +0200
+
 fluidsynth (2.3.1-1) unstable; urgency=medium
 
   * New upstream version 2.3.1
diff -Nru 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
--- 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  1970-01-01 01:00:00.0 +0100
+++ 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  2023-04-18 07:47:25.0 +0200
@@ -0,0 +1,76 @@
+From c0e2ef4243b83f29620b2078fc0f1198bafd7d90 Mon Sep 17 00:00:00 2001
+From: derselbst 
+Date: Sun, 2 Apr 2023 17:31:24 +0200
+Subject: [PATCH 46/49] Fix seamless looping between MIDI files
+
+Fixes #1227
+---
+ src/midi/fluid_midi.c | 45 +++
+ 1 file changed, 24 insertions(+), 21 deletions(-)
+
+diff --git a/src/midi/fluid_midi.c b/src/midi/fluid_midi.c
+index 0676c452..b72c3914 100644
+--- a/src/midi/fluid_midi.c
 b/src/midi/fluid_midi.c
+@@ -2178,34 +2178,37 @@ fluid_player_callback(void *data, unsigned int msec)
+ player->start_msec = msec;  /* should be the (synth)-time of 
the last tempo change */
+ fluid_atomic_int_set(&player->seek_ticks, -1); /* clear 
seek_ticks */
+ }
+-
+-/* Once we've run out of MIDI events, keep playing until no voices 
are active */
+-if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
++
++if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+ {
+-/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
+-if(!player->end_pedals_disabled)
++/* Once we've run out of MIDI events, keep playing until no 
voices are active */
++if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
+ {
+-for(i = 0; i < synth->midi_channels; i++)
++/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
++if(!player->end_pedals_disabled)
+ {
+-fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
+-fluid_synth_cc(player->synth, i, SOSTENUTO_SWITCH, 0);
++for(i = 0; i < synth->midi_channels; i++)
++{
++fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
++fluid_synth

Bug#1034554: internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[Mathieu Malaterre]

Source: gcc-13
Version:  13-20230411-1

I cannot compile highway on riscv/rv64gcv1p0 with gcc-13.

Compilation fais with:

% /usr/bin/g++-13 -freport-bug -DHWY_SHARED_DEFINE
-I"/home/malat/highway-1.0.4~git20230317.8681eb8" -g -O2
-ffile-prefix-map=/home/malat/highway-1.0.4~git20230317.8681eb8=.
-fstack-protector-strong -Wformat -Werror=format-security
-DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE
-fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion
-Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions
-march=rv64gcv1p0 -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD
-MT CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-MF CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o.d
-o CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-c 
'/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc'
during RTL pass: vsetvl
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:
In function 'void
hwy::N_RVV::ForeachCountAndMisalign::operator()(T, D) const
[with T = unsigned char; D = hwy::N_RVV::Simd;
Test = hwy::N_RVV::TestGenerate]':
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:133:3:
internal compiler error: in finalize_new_accesses, at
rtl-ssa/changes.cc:471
  133 |   }
  |   ^
0xf4b18d rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:471
0xf4c0a7 
rtl_ssa::function_info::change_insns(array_slice)
../../src/gcc/rtl-ssa/changes.cc:659
0xb4f1e7 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:717
0xb4f1e7 change_insn
../../src/gcc/config/riscv/riscv-vsetvl.cc:1028
0xb4f1e7 pass_vsetvl::cleanup_insns() const
../../src/gcc/config/riscv/riscv-vsetvl.cc:3951
0xb59891 pass_vsetvl::lazy_vsetvl()
../../src/gcc/config/riscv/riscv-vsetvl.cc:4211
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4241
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4222
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Bug#1034553: libplist FTCBFS for arm32: wrong python library directory

[Helmut Grohne]

Source: libplist
Version: 2.2.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libplist fails to cross build from source for arm32, because it gets the
python library directory wrong and uses the build architecture one. It
extracts it from sysconfigdata, so we need to export
_PYTHON_SYSCONFIGDATA_NAME to fix that. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru libplist-2.2.0/debian/changelog 
libplist-2.2.0/debian/changelog
--- libplist-2.2.0/debian/changelog 2021-02-03 13:59:02.0 +0100
+++ libplist-2.2.0/debian/changelog 2023-04-18 07:53:04.0 +0200
@@ -1,3 +1,10 @@
+libplist (2.2.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix arm32 FTCBFS: Export _PYTHON_SYSCONFIGDATA_NAME. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 18 Apr 2023 07:53:04 +0200
+
 libplist (2.2.0-6) unstable; urgency=medium
 
   [ Dylan Aïssi ]
diff --minimal -Nru libplist-2.2.0/debian/rules libplist-2.2.0/debian/rules
--- libplist-2.2.0/debian/rules 2021-02-03 13:59:02.0 +0100
+++ libplist-2.2.0/debian/rules 2023-04-18 07:53:02.0 +0200
@@ -10,6 +10,7 @@
 
 include /usr/share/dpkg/default.mk
 
+export 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
 PYVER=$(shell py3versions -vd)
 
 %:

Bug#1030223: gobject-introspection mini-policy: separate GIR XML from -dev package to make cross-compilation possible?

[Helmut Grohne]

Hi Simon,

On Wed, Feb 01, 2023 at 10:39:30AM +, Simon McVittie wrote:
> Ideally, when cross-compiling Flatpak, we'd prefer to build it with
> a build profile like cross or nogir that has the effect of building it with
> ./configure --disable-introspection, which disables the generation of the
> files marked [*]. However, that would make this build profile cause a
> functional change to the contents of libflatpak-dev, which is strongly
> discouraged.

I agree in principle. The problem with changing the contents of
libflatpak-dev is twofold. For one thing, a binary package name (such as
libflatpak-dev) implicitly defines an interface and a contract between
cooperating packages. The present interface includes the gir files and
having them vanish from libflatpak-dev on specifying a nogir profile
would break the interface contract. The other reason for the
discouragement is being able to validate profiles using reproducible
builds.

> If we separated the GIR XML into a new binary package, perhaps named
> gir1.2-flatpak-1.0-dev or something like that, then we would be able to
> turn off both gir1.2-flatpak-1.0 and gir1.2-flatpak-1.0-dev under the
> nogir build profile (similar to how the noudeb, nocil and noinsttest
> profiles work), making cross-compilation possible (as long as you don't
> care about GObject-Introspection-based language bindings).

Such separation solves both the interface contract and the
reproducibility aspect. Let me propose another alternative. Rather than
have gir1.2-flatpak-1.0-dev be a real binary package, we can provide it
as a virtual one from libflatpak-dev. The mini-policy would then have to
be updated such that using the gir files requires depending on a
gir*-dev package and that a dependency on the regular lib*-dev package
is insufficient. When enabling the nogir profile, the virtual package is
removed thus no interface is broken. This variant still breaks
reproducibility of course.

> I think this would require changes to dependent packages if they make
> use of the GIR XML (because build-depending on libflatpak-dev would
> no longer be enough, and it would also be necessary to build-depend on
> gir1.2-flatpak-1.0-dev  or similar). If so, this would have to
> be done on a package-by-package basis, with dependent packages changed
> before their dependency. A migration path would be to add
> Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) on libflatpak-dev.

In essence, I am saying that this migration path could be the final
result thus eliminating the NEW trip, but not eliminating the need to
update dependent packages. Note that dpkg resolves profiles in binary
package relations at build time, so you can write:

Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) 

> A side benefit of this would be that we could separate out the GIR XML
> that is provided by src:gobject-introspection (#859013) into one or more
> similar gir1.2-*-dev packages.

Of course, a separation by real binary packages would not be prohibited.

In your second mail, you propose storing pre-built gir files in debian/.
I dislike this proposal, because it poses continuous extra effort for
maintainers. We already struggle with symbols files and shouldn't add
another variant of them. I understand that this looks attractive from a
cross builder's point of view, but I think cross building should bear
the effort here, not gnome package maintainers. I hope you can agree
with that.

Given this, would you agree that nogir would make sense right now as a
non-reproducible profile? It still requires updating all reverse
dependencies, yeah, but we can do so in parallel. For the migration
period, we would have missing dependencies in the presence of nogir
profiles, but these would solely affect users of the nogir profile,
which would be the ones to report and fix such missing dependencies.
Regular users (and buildds in particular) would never experience issues
due to such missing dependencies.

Helmut

Bug#1034552: pullseq hangs on arm64

[tony mancill]

Package: pullseq
Version: 1.0.2-3
Severity: important

pullseq hangs on arm64 (including its autopkgtest).

See https://github.com/bcthomas/pullseq/issues/10 for more information.

Filing a bug for visibility.  I will upload a fix momentarily.

Cheers,
tony

Bug#1017542: Systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

Hello,

Just wanted to report that this bug is somewhat still in debian testing, 
this happens every time I shutdown this virtual machine


>systemd-shutdown[1]: Failed to finalize DM devices, ignoring.


linux 6.1.0-7-amd64
systemd 252.6-1
cryptsetup 2:2.6.1-3

partitons:

/boot ext4
/ luks2+ext4
/home luks2+ext4

efi enabled secure boot enabled.

Bug#1034206: unblock: owslib/0.27.2-3

[Sebastiaan Couwenberg]

On 4/11/23 06:48, Bas Couwenberg wrote:

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

Please unblock package owslib

It is affected by CVE-2023-27476 reported in #1034182.

[ Reason ]
Fixes security issue and missing recommended dependencies.

[ Impact ]
Unfixed security issue.

[ Tests ]
Upstream test suite.

[ Risks ]
Low, the changes are pretty straight forward.

[ 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 ]
Testing autoremoval of rdeps would remove qgis which is one of, if not the, 
most important GIS packages for users.

The package has not been unloaded to unstable yet.

unblock owslib/0.27.2-3


Since there was no objection to the pending changes from git that were 
included in tirex (#1034242), owslib (0.27.2-3) has been uploaded to 
unstable.


Kind Regards,

Bas

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

Bug#573824: not fix in newest upstream version 1.1

[肖盛文]

control: tag -1 - fixed-upstream

This bug is not fixed in the newest upstream version 1.1.

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Dmitry Baryshkov]

18 апреля 2023 г. 05:35:00 GMT+03:00, Roger Shimizu  пишет:
>Dear Dmitry,
>
>Thanks for your response!
>Very informative.
>
>And the ultimate goal is to have a debian-installer image.
>So this firmware upload is just the first step.

Thanks for the information. Short answer: please do not touch the partitions 
you don't have to. 


>
>Let me reply to you inline below.
>
>On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov
> wrote:
>>
>> On Mon, 17 Apr 2023 at 03:09, Roger Shimizu  wrote:
>> >
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Roger Shimizu 
>> > X-Debbugs-Cc: debian-de...@lists.debian.org
>> >
>> > * Package name: linux-board-support-package-dragonboard845c
>> >   Version : 20190529180356-v4
>> >   Upstream Author : Linaro
>> > * URL : 
>> > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware
>> > * License : non-free
>> >   Description : Firmware for dragonboard845c / RB3
>> >
>> >  This package contains the binary firmware for GPU, USB, DSP hardware
>> >  coprocessors found on SDM845, which is the main SoC on the
>> >  Dragonboard 845c / RB3.
>>
>> Generally, I think there is some misunderstanding here. Most of the
>> firmware has been pushed to linux-firmware already (where possible).
>> You probably have some other intentions here. If so, please describe them.
>
>Thanks for the upstreaming work!
>I checked package firmware-qcom-soc [1], and found GPU / Audio DSP /
>Modem firmware is already there.
>
>[1] https://packages.debian.org/unstable/firmware-qcom-soc
>
>> I took a glance at the package sources on salsa. So, let's go at this
>> one by one.
>>
>> firmware-qcom-dragonboard845c.install:
>>
>> [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845
>>
>> This is the file that is only used by the _host_ when programming the
>> device. As such, it should not be a part of the en-device firmware. It
>> has no use for the RB3 itself.
>>
>> [0-9]*/aop.mbn lib/firmware/qcom/sdm845
>>
>> Bootloader. It should not be a part of /lib/firmware/
>
>Since my ultimate goal is to make an installer image, the bootloader
>part is necessary.
>Because we don't have the source code for this, and we have to flash
>this file to one
>partition of the UFS on the board in order to boot the system, we have
>to treat it as
>firmware.

Does Debian installer update the BIOS of your PC during installation? No.

Is RB3 (or RB5) somehow different from your PC in this area? No.

Please don't touch the system partitions. User might have some custom code 
there. They might have a customized bootloader. Last, but not least, updating 
the bootloader might brick the board, if power gets turned off at the improper 
time, leaving the user with the hardware requiring one to perform additional 
rescue process through QDL.

>
>If you have a better idea for the path name, rather than /lib/firmware/,
>please let me know.

>
>> [0-9]*/BTFM.bin lib/firmware/qcom/sdm845
>>
>> This is the filesystem image with bluetooth firmware files. Relevant
>> files are already part of the /lib/firmware/qca. If anything important
>> is missing there, it should directly into
>
>Good to know it's already upstreamed, and it's under qca folder.

>
>> [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845
>> [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845
>> [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845
>>
>> These three files are also used by the bootloader process, and as such
>> they should not be a part of /lib/firmware.
>>
>> [0-9]*/dspso.bin lib/firmware/qcom/sdm845
>>
>> This is probably the only important file for now. This is the
>> filesystem image with the shared libraries and executable code for the
>> DSPs when executing compute applications there.
>> We were putting it to /lib/firmware/qcom/sdm845 and mounting it later,
>> because it was easier to do so (if the image is not present in
>> /lib/firmware, the rootfs can try mounting dspso parition). For proper
>> Debian packaging the image should be unpacked to some agreed location.
>> fastrpc daemons then should be taught about this location.
>
>Yes, we need to integrate this into the installer.

No. This needs to be integrated into the system runtime, not into the installer.

>
>> [0-9]*/hyp.mbn lib/firmware/qcom/sdm845
>> [0-9]*/imagefv.elf lib/firmware/qcom/sdm845
>> [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845
>> [0-9]*/sec.dat lib/firmware/qcom/sdm845
>> [0-9]*/storsec.mbn lib/firmware/qcom/sdm845
>> [0-9]*/tz.mbn lib/firmware/qcom/sdm845
>> [0-9]*/xbl.elf lib/firmware/qcom/sdm845
>> [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845
>> [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845
>>
>> Again, mostly bootloader stuff. I highly doubt that /lib/firmware
>> should be polluted with these files.
>>
>> renesas_usb_fw.mem lib/firmware
>>
>> So, this is the Renesas firmware, which gets copyrighted by Qualcomm.
>> We noticed this some time ago (and the fact that the supplier of the
>> firmware, Thundercomm, also pulled the file without having a clear
>> orig

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[J]

Thank you so much, thats exactly what I was missing. I commented out the -p
in
ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
in
/usr/lib/systemd/system/unbound.service

And now I have a pidfile back that I can use.
Unless there is any better way? I tried to override the unbound.service but
I'm not sure ExecStart= can be overrode.

On Sun, 16 Apr 2023 at 18:52, J  wrote:

> Hi!
> I'm having an issue where unbound is not creating the pid file
> I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
> I also see that this path is hard coded in `/etc/init.d/unbound` as
> `PIDFILE="/run/unbound.pid"`
>
> The only thing that fixes it is commenting out `. /lib/lsb/init-functions`
> in  `/etc/init.d/unbound` which is obviously not what I want to do
>
> On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
>
>> Thank you for filing a new Bug report with Debian.
>>
>> You can follow progress on this Bug here: 1034494:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> Your message has been sent to the package maintainer(s):
>>  unbound packagers 
>>
>> If you wish to submit further information on this problem, please
>> send it to 1034...@bugs.debian.org.
>>
>> Please do not send mail to ow...@bugs.debian.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter  wrote:
>
> Hi Lisandro,
>
> thanks for your response!
>
> Am Samstag 15 April 2023 15:15:08 schrieben Sie:
> > On Thu, 13 Apr 2023 at 14:15, Bernhard Reiter 
> > >"qtwebengine-opensource-src No security support upstream and
> > >backports not feasible, only for use on trusted content"
>
> > If we follow that reasoning we shouldn't be shipping Plasma at all, as
> > many things use Qt5's webengine.
>
> Konqueror is advertised as web browser, which means it will (offer to)
> open URLs from different sources, e.g. when clicked from emails which means
> external URLs and data.

Same goes with KMail too :-)

> Other components from plasma may not share the same exposure to outside
> data, and thus would be less vulnerable. It seems that this would warrant
> some more examination.

Whatever uses webengine/webkit/ has the same
issue. Well, for as long as they are a pile of embedded code, at least
to start with.

> If it is true that other components show the same risks, then yes, I'd say
> that we should either get the security situation changed or really do not
> ship those components by default. They may risk systems like
> the dynamic loading of remote objects from java did which would be a problem
> for both Debian and upstream.

Same thing I said when I opposed packaging webengine, you see :-) But
now it is packaged, and here we are :)

> It seems to big a topic for this issue.
> What would be the right place in debian to bring this up?

Debian devel, maybe? But I did ask the same thing years ago. The reply
was "what is the difference with a PDF?" Whatever handles untrusted
code has the same issue. The only difference here is that we can not
really keep track of everything that goes on a web engine, so no
security support, which does not mean we try to apply patches if we
can.

But please feel free to do whatever you think is right. That's your
freedom, and that's good :)

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

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Roger Shimizu]

Dear Dmitry,

Thanks for your response!
Very informative.

And the ultimate goal is to have a debian-installer image.
So this firmware upload is just the first step.

Let me reply to you inline below.

On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov
 wrote:
>
> On Mon, 17 Apr 2023 at 03:09, Roger Shimizu  wrote:
> >
> > Package: wnpp
> > Severity: wishlist
> > Owner: Roger Shimizu 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: linux-board-support-package-dragonboard845c
> >   Version : 20190529180356-v4
> >   Upstream Author : Linaro
> > * URL : 
> > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware
> > * License : non-free
> >   Description : Firmware for dragonboard845c / RB3
> >
> >  This package contains the binary firmware for GPU, USB, DSP hardware
> >  coprocessors found on SDM845, which is the main SoC on the
> >  Dragonboard 845c / RB3.
>
> Generally, I think there is some misunderstanding here. Most of the
> firmware has been pushed to linux-firmware already (where possible).
> You probably have some other intentions here. If so, please describe them.

Thanks for the upstreaming work!
I checked package firmware-qcom-soc [1], and found GPU / Audio DSP /
Modem firmware is already there.

[1] https://packages.debian.org/unstable/firmware-qcom-soc

> I took a glance at the package sources on salsa. So, let's go at this
> one by one.
>
> firmware-qcom-dragonboard845c.install:
>
> [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845
>
> This is the file that is only used by the _host_ when programming the
> device. As such, it should not be a part of the en-device firmware. It
> has no use for the RB3 itself.
>
> [0-9]*/aop.mbn lib/firmware/qcom/sdm845
>
> Bootloader. It should not be a part of /lib/firmware/

Since my ultimate goal is to make an installer image, the bootloader
part is necessary.
Because we don't have the source code for this, and we have to flash
this file to one
partition of the UFS on the board in order to boot the system, we have
to treat it as
firmware.

If you have a better idea for the path name, rather than /lib/firmware/,
please let me know.

> [0-9]*/BTFM.bin lib/firmware/qcom/sdm845
>
> This is the filesystem image with bluetooth firmware files. Relevant
> files are already part of the /lib/firmware/qca. If anything important
> is missing there, it should directly into

Good to know it's already upstreamed, and it's under qca folder.

> [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845
> [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845
> [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845
>
> These three files are also used by the bootloader process, and as such
> they should not be a part of /lib/firmware.
>
> [0-9]*/dspso.bin lib/firmware/qcom/sdm845
>
> This is probably the only important file for now. This is the
> filesystem image with the shared libraries and executable code for the
> DSPs when executing compute applications there.
> We were putting it to /lib/firmware/qcom/sdm845 and mounting it later,
> because it was easier to do so (if the image is not present in
> /lib/firmware, the rootfs can try mounting dspso parition). For proper
> Debian packaging the image should be unpacked to some agreed location.
> fastrpc daemons then should be taught about this location.

Yes, we need to integrate this into the installer.

> [0-9]*/hyp.mbn lib/firmware/qcom/sdm845
> [0-9]*/imagefv.elf lib/firmware/qcom/sdm845
> [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845
> [0-9]*/sec.dat lib/firmware/qcom/sdm845
> [0-9]*/storsec.mbn lib/firmware/qcom/sdm845
> [0-9]*/tz.mbn lib/firmware/qcom/sdm845
> [0-9]*/xbl.elf lib/firmware/qcom/sdm845
> [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845
> [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845
>
> Again, mostly bootloader stuff. I highly doubt that /lib/firmware
> should be polluted with these files.
>
> renesas_usb_fw.mem lib/firmware
>
> So, this is the Renesas firmware, which gets copyrighted by Qualcomm.
> We noticed this some time ago (and the fact that the supplier of the
> firmware, Thundercomm, also pulled the file without having a clear
> origin). We have been trying to clear licensing terms for this file,
> however Renesas is unresponsive. Originally this file came from the
> author (Renesas) without proper license. Thus I do not believe it
> passes required checks by ftpmasters.

If this is the issue, we can remove this blob.
But basically, this is a non-free package, and if we can redistribute
the file it should not be a problem.
The file is on linaro archive for years for free download to anymore.
And you informed Renesas about this,
so if they don't agree with the redistribution, they will ask you to
pull it off long time ago.

> linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp
> linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux
>
> I don't know what this is, but judging from the name (ABL) it also
> should not be part of /lib/firmware. Especially the AOSP fil

Bug#1033862: kernel 6.1.20-2 still has problems with this nvidia chip (nouveau)

[A. F. Cano]

Noticed that the kernel got upgraded to 6.1.20-2.  The nouveau driver
still has problems dealing with this video chip.  These lines are at the
end of the dmesg output below.

[   33.713265] nouveau :00:0d.0: bus: MMIO write of 00340001 FAULT at 00b000
[   49.943297] nouveau :00:0d.0: bus: MMIO write of 00640001 FAULT at 00b010
[   49.944307] nouveau :00:0d.0: bus: MMIO write of 00310001 FAULT at 00b020
[   52.689049] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b020
[   52.689261] nouveau :00:0d.0: bus: MMIO write of 00640001 FAULT at 00b010
[   52.689915] nouveau :00:0d.0: bus: MMIO write of 00310001 FAULT at 00b020
[   53.398186] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b020
[   53.398405] nouveau :00:0d.0: bus: MMIO write of 00640001 FAULT at 00b010
[   53.399479] nouveau :00:0d.0: bus: MMIO write of 00660001 FAULT at 00b020
[   53.417445] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010

Complete output of dmesg after booting 6.1.20-2 follows:

[0.00] Linux version 6.1.0-7-amd64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 
SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-7-amd64 
root=UUID=28bd15dd-cd17-45c8-93e0-65decc995980 ro quiet
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] signal: max sigframe size: 1440
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xaffa] usable
[0.00] BIOS-e820: [mem 0xaffb-0xaffbdfff] ACPI data
[0.00] BIOS-e820: [mem 0xaffbe000-0xaffe] ACPI NVS
[0.00] BIOS-e820: [mem 0xafff-0xafff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: Hewlett-Packard s5737c/2A6C, BIOS 6.0109/29/2010
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3013.690 MHz processor
[0.005436] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.005439] e820: remove [mem 0x000a-0x000f] usable
[0.011210] AGP: No AGP bridge found
[0.011266] last_pfn = 0xaffb0 max_arch_pfn = 0x4
[0.011459] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.015608] found SMP MP-table at [mem 0x000ff780-0x000ff78f]
[0.015636] Using GB pages for direct mapping
[0.016004] RAMDISK: [mem 0x312dd000-0x34965fff]
[0.016009] ACPI: Early table checksum verification disabled
[0.016012] ACPI: RSDP 0x000FB2A0 14 (v00 HPQOEM)
[0.016018] ACPI: RSDT 0xAFFB 44 (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016024] ACPI: FACP 0xAFFB0200 84 (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016030] ACPI: DSDT 0xAFFB0460 004DD4 (v01 HPQOEM SLIC-CPC 
0001 INTL 20051117)
[0.016033] ACPI: FACS 0xAFFBE000 40
[0.016036] ACPI: APIC 0xAFFB0390 90 (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016040] ACPI: MCFG 0xAFFB0420 3C (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016043] ACPI: OEMB 0xAFFBE040 73 (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016047] ACPI: SRAT 0xAFFB5240 A0 (v03 AMDFAM_F_10 
0002 AMD  0001)
[0.016050] ACPI: HPET 0xAFFB52E0 38 (v01 HPQOEM SLIC-CPC 
20100929 MSFT 0097)
[0.016053] ACPI: SLIC 0xAFFBE0C0 000176 (v01 HPQOEM SLIC-CPC 
0001 MSFT 0001)
[0.016057] ACPI: SSDT 0xAFFB5320 000458 (v01 HPQOEM SLIC-CPC 
0001 AMD  0001)
[0.016060] ACPI: Reserving FACP table memory at [mem 0xaffb0200-0xaffb0283]
[0.016061] ACPI: Reserving DSDT table memory at [mem 0xaffb0460-0xaffb5233]
[0.016062] ACPI: Reserving FACS table memory at [mem 0xaffbe000-0xaffbe03f]
[0.016063] ACPI: Reserving APIC table memory at [mem 0xaffb0390-0xaffb041f]
[0.016065] ACPI: Reserving MCFG table memory at [mem 0xaffb0420-0xaffb045b]
[0.016066] ACPI: Reserving OEMB table memory at [mem 0xaffbe040-0xaffbe0b2]
[0.016067] ACPI: Reserving SRAT table memory at [mem 0xaffb5240-0xaffb52df]
[0.016068] ACPI: Reserving HPET table memory at [mem 0xaffb52e0-0xaffb5317]
[0.016069] ACPI: Reserving SLIC table memory at [mem 0xaffbe0c0-0xaffbe235]
[0.016070] ACPI: Reserving SSDT table memory at [mem 0xaffb532

Bug#1034551: kmod: Include iwlwifi.conf from Ubuntu

[Jamie Bainbridge]

Package: kmod
Version: 28-1
Severity: important

Hello,

I have a laptop with iwlwifi wireless card:

 $ sudo lspci -nn | grep Net
 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59)

This hardware requires the firmware-iwlwifi package, and the firmware
works fine. However, on nonfree install or nonfree Live, the wireless
interface repeatedly dies as soon as it's used with "Microcode SW error
detected. Restarting" in dmesg and long firmware dump from the driver.
it's not possible to even "apt update" because the interface dies.

Ubuntu ships a file in its kmod package with the following contents:

 # /etc/modprobe.d/iwlwifi.conf
 # iwlwifi will dyamically load either iwldvm or iwlmvm depending on the
 # microcode file installed on the system.  When removing iwlwifi, first
 # remove the iwl?vm module and then iwlwifi.
 remove iwlwifi \
 (/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs
 /sbin/rmmod) \
 && /sbin/modprobe -r mac80211

Adding this file to Debian resolves the problem.

This is a request to include the above iwlwifi.conf file in Debian's
kmod package too.

I can only assume from the massive Ubuntu install base that this file
doesn't cause any problems for devices which don't need the modules
loaded in this order, while also resolving whatever problem requires
that modules are loaded in the order which the above file forces.

I could not find any previous bug with this request. I also couldn't
find Ubuntu's history of this package to find why it was included there
in the first place. It's been there for a very long time, at least since
kmod 9 from over 10 years ago.

Given that Ubuntu has shipped this file for so long, the risk of any
regression in Debian seems extremely low.

Thank you,
Jamie

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

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

Versions of packages kmod depends on:
ii  libc6  2.31-13+deb11u5
ii  libkmod2   28-1
ii  liblzma5   5.2.5-2.1~deb11u1
ii  libssl1.1  1.1.1n-0+deb11u4
ii  lsb-base   11.1.0

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Rod Webster]

Package: r8168-dkms
Version: r8168-dkms
Severity: important
Tags: upstream newcomer
X-Debbugs-Cc: r...@vmn.com.au

Dear Maintainer,


   * What led up to the situation?
We are linuxcnc users which is packaged in Bookworm. Linuxcnc requires the
PREEMPT_RT real time kernel as a prerequisite. We have found excessive latency
in the real time environment since Debian moved to the 5.x kernels.  We note
that RT latency/jitter has significantly improved in the 6.x kernels and is
better again with the 6.3 kernel compiled from kernel.org sources where
latency/jitter is on a par with the 4.x kernels found in Buster.

We also note that the latency/jitter is significantly improved where a kernel
based on pristine source from kernel.org is used. We are disappointed that
Debian's implementation of the PREEMPT_RT kernel results in significantly less
performance than the upstream sources. In our recent testing, we found the 6.3
kernel gave a 265% improvement in latency/jitter over the default Debian
Bookworm 6.1.x Real time kernel. Similar improvement has also been noted
between Debian's 6.1 kernel and one we compiled from upstream source.

Network latency/jitter when we communicate point to point from a Debian PC to
an ethernet connected motion card is also another significant issue for us that
was not present in the 4.x kernels. This has not been resolved in the 6.1 to
6.3 kernels.

Linuxcnc uses a 1 ms realtime thread and we regularly see "Error Finishing
Read" reported.  This error disables the connection becasue our 1 ms thread has
been overrun. This issue mainly affects Realtek NIC hardware and s of real
concern where the motion hardware could be commanding components weiging
several thousand pounds.

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

We have found installing the R8168-dkms driver with the 6.3 kernel we compiled
has resulted a 400% improvement in network latency (from approx 800 usec)to
about 200 usec) when compared with the default R8169 kernel module driver.

We are no longer able to locate the R8168-dkms driver in the repositories,
despite it being listed as available in package search. We have downloaded a
.deb file from the Sid packages to install the correct driver.

The R8168-dkms description says to report use of the driver so the R8169 kernel
module can be updated.

   * What was the outcome of this action?

A combination of the 6.3 kernel and installing the R8168-dkms driver has
resolved our issues. However, this is not something a normal user would expect
or have the skills to do.

   * What outcome did you expect instead?

We expect that Debian Bookworm:
 1. Has acceptible jitter/latency in a PREEMPT_RT real time environment
 2. Correctly supports Realtek NIC devices covered by the R8168-dkms diver
using the default R8169 kernel module as discussed on the Realtek web site.
 3. The R8168-dkms driver to continue to be made available in the Bookworm
repositories.
 4. Does not negatively affect real time performance when benchamarked against
the kernel.org sources.
 5. This issue may require escalation upstream.


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

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

Bug#1034504: diffoscope: Wrong binary called for the Procyon Java decompiler

[Emmanuel Bourg]

Control: notfound -1 240
Control: close -1

Wrong report, sorry

Bug#1034462: Pipewire: Inappropriate ioctl for device

[Al Ma]

reassign 1034462 pipewire-media-session 0.4.1-3
thanks
I use snapshots rather than backports (for unrelated reasons). After replacing  
pipewire-media-session with wireplumber 0.4.2-1, the particular ioctl error 
message is gone (but there are others instead). Therefore, bug report 
reassigned to the (dying) pipewire-media-session.

Bug#1034549: libncurses-dev: ships header files that can't be compiled (ncurses_cfg.h)

[Steve Langasek]

Package: libncurses-dev
Version: 6.4-2
Severity: normal

The libncurses-dev package ships several header files that can't be
compiled, because they depend on ncurses_cfg.h which is not available.

$ grep -rl ncurses_cfg /usr/include/
/usr/include/tic.h
/usr/include/curses.h
/usr/include/nc_tparm.h
$

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Bug#999526: Taking over package into Debian Python Team maintenance and fixing bug (Was: mdp: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{versi

[Yaroslav Halchenko]

Hi Andreas,

Thank you very much for offering help.  I think Tiziano would not mind,
so please feel very welcome to a) for the sake of b) or any other
goodness you would like to bring ;)

Note though that MDP is pretty much inactive project since a few years
back.  It seems it is still used by some and somewhat maintained
upstream, so might indeed be worthwhile keeping afloat in Debian but I
would not cry if it got RMed.

After/if packaging moves to a new repo on salsa, we can submit a
PR to add an empty out debian/ and add stub debian/README to that
upstream repo to signal that packaging moved to salsa.

Cheers,

On Mon, 17 Apr 2023, Andreas Tille wrote:

> Hi Tiziano and Yaroslav,

> I'd volunteer to

>a) take over package into Debian Python Team (including
>   using Salsa Git and Maintainer address of DPT) and
>b) apply the patch and upload the package

> I'm not interested in just doing b) and hope you will find the time to
> care for the package if you are not happy with a).  Please note that
> there was an NMU which is not taken over in your repository at Github.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Vagrant Cascadian]

On 2023-04-17, Aurelien Jarno wrote:
> On 2023-04-16 15:16, Vagrant Cascadian wrote:
>> On 2023-04-16, Aurelien Jarno wrote:
>> > I have tried adding a simple .sbuildrc defining $build_path to '/build'
>> > to zandonai.d.o. Unfortunately while it more or less does what you want
>> > for the build path, it completely clutter the logs, as any text matching
>> > "build" is now replaced by "<>":
>> >
>> > https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring&arch=s390x&ver=42.1-1%2Bb2&stamp=1681671508&raw=0
>> 
>> >
>> > I guess one option is to use a build path unlikely to match any string
>> > from a build log, like with the randomized directory. Something like
>> > "/build/reproducible-path/"?
>> 
>> Just for clarity, then the the PKGBUILDIR would end up being
>> /build/reproducible-path/PACKAGE-VERSION ? That works! Or something even
>> shorter ... e.g. /build/path/PACKAGE-VERSION or
>> /build/debian/PACKAGE-VERSION ? Really, the 2nd directory matters
>> little, as long as it is predictible. :)
>
> Yes, setting $build_path to '/build/debian' indeed means that
> PKGBUILDDIR is /build/debian/PACKAGE-VERSION.
>
> Unfortunately the string 'build/debian' appears in a few build logs:
> 0ad
...
> xtables-addons
>
> Do you have other short suggestions? Do we want to show it has been
> built on a debian buildd? In that case /build/debian-buildd might do it.

Well, then a verification build using reproducible builds will be
"lying" that it is built on a buildd. :)

Hrm. "DeBiAn" ? Kind of hard on the eyes. Less ugly, "/build/Debian"?
Still somewhat likely to to have inappropriate matches? "fixedpath"?

Or just go with "reproducible-path" as it is not tragically long if it
seems unlikely to match inappropriately. :)

Is sbuild replacing the string mandatory; could we do without that
feature? What would we loose? Might require patching sbuild...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6

[Aurelien Jarno]

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

[ Reason ]
There are multiple fixes in this upload, all coming from the upstream
stable branch:
- Multiple crashes or memory leak in printf-family functions
- Overflow fix in the AVX2 implementation of wcsnlen

[ Impact ]
In case the update isn't approved, systems will be left with issues
which combined with other vulnerabilities might lead to denial of
service.

[ Tests ]
The upstream fixes come with additional tests, which represent a
significant part of the diff.

[ Risks ]
The most risky parts are probably the printf-family functions changes,
however those changes are in testing/sid for ~1.5 years (since glibc
2.32), but have only been identified as problematic recently. The
wcsnlen fix is in testing/sid for ~4 months. All of those changes come
with additional tests.

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

[ Changes ]
Let me comment the changelog:

 - Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
   (obsolete).

The upstream stable branch for glibc 2.31 now includes the fix
introduced in glibc 2.31-13+deb11u5 to fix some crash on some CPU.
Therefore this patch is not needed anymore.

 - Fix memory leak in printf-family functions with long multibyte strings.

   This fixes a memory leak that might lead to OOM when calling with
   long multibyte strings. The simplest reproducer is:
 printf("%.1371337ls", L"A\n");

 - Fix a crash in printf-family due to width/precision-dependent
   allocations.

   This fixes a crash due to a missing overflow check in the requested
   precision. The simplest reproducer is:
 fprintf (fp, "%2$.*1$a", 0x7fff, 1e200);

 - Fix a segfault in printf handling thousands separator.

   This segmentation fault has been fixed as a side effect of the
   previous fix, but comes with a specific test. The simplest reproducer
   is:
 setlocale(LC_ALL, "en_US.UTF-8");
 printf("%'1000d\n", 1000);

 - Fix an overflow in the AVX2 implementation of wcsnlen when crossing
   pages.

   The overflow happens when wcsnlen is called with a huge maxlen
   argument (e.g. (1UL << 63)), triggering an assertion in the wcsnlen
   code.
diff --git a/debian/changelog b/debian/changelog
index 50f6135b..3d95edf8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+glibc (2.31-13+deb11u6) UNRELEASED; urgency=medium
+
+  [ Aurelien Jarno ]
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+  (obsolete).
+- Fix memory leak in printf-family functions with long multibyte strings.
+- Fix a crash in printf-family due to width/precision-dependent
+  allocations.
+- Fix a segfault in printf handling thousands separator.
+- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
+  pages.
+
+ -- Aurelien Jarno   Sun, 16 Apr 2023 18:58:33 +0200
+
 glibc (2.31-13+deb11u5) bullseye; urgency=medium
 
   * debian/patches/local-require-bmi-in-avx2-ifunc.diff: new patch extracted
diff --git a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff 
b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
deleted file mode 100644
index 936f89ae..
--- a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-This patch is extracted from upstream commit 83c5b368226c ("x86-64: Require
-BMI2 for strchr-avx2.S"). It changes the common ifunc AVX2 selector to require
-the BMI2 instructions, and the backported fixes for memchr and strlen rely on
-that change.
-
 a/sysdeps/x86_64/multiarch/ifunc-avx2.h
-+++ b/sysdeps/x86_64/multiarch/ifunc-avx2.h
-@@ -21,28 +21,28 @@ IFUNC_SELECTOR (void)
- 
- extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
- 
- static inline void *
- IFUNC_SELECTOR (void)
- {
-   const struct cpu_features* cpu_features = __get_cpu_features ();
- 
-   if (CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
-+  && CPU_FEATURES_CPU_P (cpu_features, BMI2)
-   && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
- {
-   if (CPU_FEATURES_ARCH_P (cpu_features, AVX512VL_Usable)
--&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable)
--&& CPU_FEATURES_CPU_P (cpu_features, BMI2))
-+&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable))
-   return OPTIMIZE (evex);
- 
-   if (CPU_FEATURES_

Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.

[Ben Westover]

Hello,

On 4/17/23 2:13 PM, Bastian Germann wrote:
Please see 
https://salsa.debian.org/cryptocoin-team/xmrig/-/commit/fa8aaf366f7168be3d30ba9c1d7e5fdaf9bb11bb to get an idea of what is to exclude. Please use the Debian replacements for those libraries. adl and libethash are not yet available (see also #1034528), so please build with WITH_KAWPOW=OFF and WITH_ADL=OFF.


I looked into this when I first started packaging xmrig. Unfortunately, 
for many of these third party libraries, Debian's packaging of them 
won't work because the version included in xmrig is specially modified 
and contains lots of xmrig-specific functions that aren't easy to work 
around. For example, many of argon2's functions directly have xmrig in 
the name, and work a bit differently to those of the original project. 
The source also directly includes headers that exist in the original 
source but not a packaged version, and which are also modified 
specifically for xmrig. If I were to get rid of all the third party 
libraries that don't work easily with Debian's packaged versions, there 
wouldn't be much xmrig functionality left.


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034547: manpages-dev: *stat might return EOVERFLOW also for time related fields

[Uwe Kleine-König]

Package: manpages-dev
Version: 6.03-1
Severity: normal
X-Debbugs-Cc: uklei...@debian.org

Hello,

the manpage for stat, fstat, lstat and fstatat specify that the error
EOVERLFLOW means:

  pathname or fd refers to a file whose  size,  inode  number,  or
  number  of  blocks  cannot  be represented in, respectively, the
  types off_t, ino_t, or blkcnt_t.  This error can occur when, for
  example,  an  application  compiled on a 32-bit platform without
  -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds
  (1<<31)-1 bytes.

However at least in libc6-2.35 and later EOVERFLOW is also returned if
st_atim.tv_sec, st_mtim.tv_sec or st_ctim.tv_sec don't fit into an
int32_t on platforms with __TIME_SIZE == 32.

Best regards
Uwe

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

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

Versions of packages manpages-dev depends on:
ii  manpages  6.03-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.11.2-2

-- no debconf information

Bug#1034546: RFS: luametatex/2.10.07-1 [ITP] -- Next generation ConTeXt processing engine

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : luametatex
   Version  : 2.10.07-1
   Upstream contact : Hans Hagen 
 * URL  : https://github.com/contextgarden/luametatex
 * License  : MIT, GPL-2+, ICU, PD
 * Vcs  : https://github.com/debian-tex/luametatex
   Section  : tex

The source builds the following binary packages:

  luametatex - Next generation ConTeXt processing engine

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/luametatex/luametatex_2.10.07-1.dsc

Changes for the initial release:

 luametatex (2.10.07-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1034501)

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: reassign -1 hw-detect

On 17/04/2023 at 17:52, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-17):

Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the
pipeline, and restore it when running install_firmware_pkg.


I think I'd be happy to take this patch for bookworm, as a workaround…


Here is another patch for hw-detect moving the install_firmware_pkg()
call outside the pipeline instead of playing with file descriptors.


… before considering a real/better fix after bookworm.


Feel free to pick either patch you like. Both work for me.

To be fair, I searched if other firmware packages than firmware-ipw2x00 
had a preinst script using debconf dialog which required this fix, and 
the only other one I found is firmware-ivtv which is not related with 
networking or storage.



PS: shouldn't this bug report be reassigned to hw-detect ?


Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


I've never cloned a bug report, so I'd rather leave it to a more 
experienced user.

Bug#1034545: crashed while exporting a PDF

[Marco d'Itri]

Package: qvge
Version: 0.6.3-2
Severity: normal

I think that the destination directory was not writeable.

#0  0x55f6035d798d in CEditorScene::drawBackground(QPainter*, QRectF 
const&) ()
#1  0x55f60360e5d9 in CNodeEditorScene::drawBackground(QPainter*, QRectF 
const&) ()
#2  0x7fe2d6090776 in QGraphicsScene::render(QPainter*, QRectF const&, 
QRectF const&, Qt::AspectRatioMode)
(this=, painter=0x7fff37dc0b68, target=, 
source=, aspectRatioMode=)
at graphicsview/qgraphicsscene.cpp:1837
#3  0x55f603617298 in CPDFExport::save(QString const&, CEditorScene&, 
QString*) const ()
#4  0x55f6035c2eb5 in CImportExportUIController::doExport(CEditorScene&, 
IFileSerializer const&) ()
#5  0x55f6035c33f9 in CImportExportUIController::exportPDF(CEditorScene&)
()
#6  0x55f60356be6e in CNodeEditorUIController::exportPDF() ()
#7  0x55f603577bc0 in QtPrivate::FunctorCall, 
QtPrivate::List<>, void, void (CNodeEditorUIController::*)()>::call(void 
(CNodeEditorUIController::*)(), CNodeEditorUIController*, void**) ()
#8  0x55f6035776e0 in void QtPrivate::FunctionPointer::call, void>(void 
(CNodeEditorUIController::*)(), CNodeEditorUIController*, void**) ()
#9  0x55f6035769b5 in QtPrivate::QSlotObject, void>::impl(int, 
QtPrivate::QSlotObjectBase*, QObject*,--Type  for more, q to quit, c to 
continue without paging--c
 void**, bool*) ()
#10 0x7fe2d50e8f4f in QtPrivate::QSlotObjectBase::call(QObject*, void**)
(a=0x7fff37dc0f60, r=0x55f604fdf200, this=0x55f6054b35f0)
at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#11 doActivate(QObject*, int, void**)
(sender=0x55f60544edd0, signal_index=4, argv=0x7fff37dc0f60)
at kernel/qobject.cpp:3923
#12 0x7fe2d50e21ef in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**)
(sender=sender@entry=0x55f60544edd0, m=m@entry=0x7fe2d6277d00 
, local_signal_index=local_signal_index@entry=1, 
argv=argv@entry=0x7fff37dc0f60) at kernel/qobject.cpp:3983
#13 0x7fe2d5d5c782 in QAction::triggered(bool)
(this=this@entry=0x55f60544edd0, _t1=)
at .moc/moc_qaction.cpp:376
#14 0x7fe2d5d5f3ab in QAction::activate(QAction::ActionEvent)
(this=0x55f60544edd0, event=) at kernel/qaction.cpp:1161
#15 0x7fe2d5ee3b62 in 
QMenuPrivate::activateCausedStack(QVector > const&, QAction*, 
QAction::ActionEvent, bool)
(this=this@entry=0x55f6050848c0, causedStack=..., 
action=action@entry=0x55f60544edd0, action_e=action_e@entry=QAction::Trigger, 
self=self@entry=true)
at widgets/qmenu.cpp:1407
#16 0x7fe2d5eeb994 in QMenuPrivate::activateAction(QAction*, 
QAction::ActionEvent, bool)
(this=0x55f6050848c0, action=0x55f60544edd0, action_e=QAction::Trigger, 
self=) at widgets/qmenu.cpp:1484
#17 0x7fe2d5da4db8 in QWidget::event(QEvent*)
(this=0x55f605045170, event=0x7fff37dc1540) at kernel/qwidget.cpp:9044
#18 0x7fe2d5d62fae in QApplicationPrivate::notify_helper(QObject*, QEvent*)
(this=this@entry=0x55f604ef00d0, receiver=receiver@entry=0x55f605045170, 
e=e@entry=0x7fff37dc1540) at kernel/qapplication.cpp:3640
#19 0x7fe2d5d6b552 in QApplication::notify(QObject*, QEvent*)
(this=, receiver=0x55f605045170, e=)
at kernel/qapplication.cpp:3084
#20 0x7fe2d50b16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
(receiver=0x55f605045170, event=0x7fff37dc1540)
at kernel/qcoreapplication.cpp:1064
#21 0x7fe2d50b18ce in QCoreApplication::sendSpontaneousEvent(QObject*, 
QEvent*) (receiver=, event=)
at kernel/qcoreapplication.cpp:1474
#22 0x7fe2d5d6965e in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool, bool)
(receiver=0x55f605045170, event=event@entry=0x7fff37dc1540, 
alienWidget=, nativeWidget=0x55f605045170, 
buttonDown=buttonDown@entry=0x7fe2d62a69f0 , 
lastMouseReceiver=..., spontaneous=true, onlyDispatchEnterLeave=false) at 
kernel/qapplication.cpp:2622
#23 0x7fe2d5dbe025 in QWidgetWindow::handleMouseEvent(QMouseEvent*)
(this=this@entry=0x55f605c5bb80, event=event@entry=0x7fff37dc17f0)
at kernel/qwidgetwindow.cpp:580
#24 0x7fe2d5dc0f60 in QWidgetWindow::event(QEvent*)
(this=0x55f605c5bb80, event=0x7fff37dc17f0) at kernel/qwidgetwindow.cpp:300
#25 0x7fe2d5d62fae in QApplicationPrivate::notify_helper(QObject*, QEvent*)
(this=, receiver=0x55f605c5bb80, e=0x7fff37dc17f0)
at kernel/qapplication.cpp:3640
#26 0x7fe2d50b16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
(receiver=0x55f605c5bb80, event=0x7fff37dc17f0)
at kernel/qcoreapplication.cpp:1064
#27 0x7fe2d50b18ce in QCoreApplication::sendSpontaneousEvent(QObject*, 
QEvent*) (receiver=, event=)
at kernel/qcoreapplication.cpp:1474
#28 0x7fe2d553d3ed in 
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
 (e=0x55f605c05ac0)
at kernel/qguiapplication.cpp:2278
#29 0x7fe2d5511cac in 
QWindowSystemInterface::sendWind

Bug#1034544: RFS: torctl/0.5.7-1 [ITP] -- Redirect all traffic through tor network

[Danial Behzadi دانیال بهزادی]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : torctl
   Version  : 0.5.7-1
   Upstream contact : BlackArch 
 * URL  : https://github.com/BlackArch/torctl
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/danialbehzadi/torctl
   Section  : net

The source builds the following binary packages:

  torctl - Redirect all traffic through tor network

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/torctl/torctl_0.5.7-1.dsc

Changes for the initial release:

 torctl (0.5.7-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1034507)

Regards,

Bug#1034543: xfce4: No MTA installed in default XFCE desktop

[Holger Wansing]

Package: xfce4
Version: 4.18
Severity: normal

Dear Maintainer,

I did a fresh installation of testing (bookworm), and installed XFCE as
desktop.
Installation went fine without any problems.

Logging into the XFCE user session works fine too.

Then I wanted to file an installation-report with reportbug, that failed in
the first attempt with

"The MTA /usr/sbin/sendmail is not available; exiting."

This is indeed correct, sendmail is not installed, and exim or postfix are not 
installed as well.
I guess this is not a good default for a new system?
Or is this expected?


Feel free to ask, if you need more information or tests.


Holger



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

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

Versions of packages xfce4 depends on:
pn  libxfce4ui-utils 
ii  thunar   4.16.8-1
pn  xfce4-appfinder  
pn  xfce4-panel  
pn  xfce4-pulseaudio-plugin  
ii  xfce4-session4.16.0-1
ii  xfce4-settings   4.16.0-1+deb11u1
ii  xfconf   4.16.0-2
ii  xfdesktop4   4.16.0-1
ii  xfwm44.16.1-1

Versions of packages xfce4 recommends:
ii  desktop-base  11.0.3
ii  tango-icon-theme  0.8.90-8
ii  thunar-volman 4.16.0-1
ii  xfce4-notifyd 0.6.2-1
ii  xorg  1:7.7+22

Versions of packages xfce4 suggests:
pn  xfce4-goodies


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

Bug#1034542: XFCE: unable to open a terminal from the panel - Input/output error

[Holger Wansing]

Package: xfce4
Version: 4.18
Severity: normal

Dear Maintainer,

I did a fresh installation of testing (bookworm), and installed XFCE as
desktop.
Installation went fine without any problems.

Logging into the XFCE user session works fine too.

Then I tried to open a terminal from the default panel at the bottom.
That failed. Error message says (roughly translated from German):

"The preselected terminal could not be started. Input/output error."

Selecting "xfce-terminal" from the menu worked though.


Feel free to ask, if you need more information or tests.


Holger



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

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

Versions of packages xfce4 depends on:
pn  libxfce4ui-utils 
ii  thunar   4.16.8-1
pn  xfce4-appfinder  
pn  xfce4-panel  
pn  xfce4-pulseaudio-plugin  
ii  xfce4-session4.16.0-1
ii  xfce4-settings   4.16.0-1+deb11u1
ii  xfconf   4.16.0-2
ii  xfdesktop4   4.16.0-1
ii  xfwm44.16.1-1

Versions of packages xfce4 recommends:
ii  desktop-base  11.0.3
ii  tango-icon-theme  0.8.90-8
ii  thunar-volman 4.16.0-1
ii  xfce4-notifyd 0.6.2-1
ii  xorg  1:7.7+22

Versions of packages xfce4 suggests:
pn  xfce4-goodies


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

Bug#1034541: tzdata: Please upload tzdata 2023c-3exp1

[Vincent Blut]

Package: tzdata
Version: 2023c-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 chrony

Hi,

chrony in experimental depends on tzdata-legacy but it is no longer available
since you uploaded tzdata 2023c-3 into unstable. That makes chrony in
experimental uninstallable.

Could you please ensure that changes made to tzdata in unstable are merged
back into experimental for the time being?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZD2mxAAKCRAQn1qAt/bg
AWfqAP47t2mlazoAVJ5ETQrQjPoej5ENIJfJofI+Tkp5l9MfowD7BYcRiiJ0Hv68
0JVhCXnNrUky8bu7b/zcwCNB0PFYUwE=
=5DEQ
-END PGP SIGNATURE-

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Aurelien Jarno]

Hi,

On 2023-04-16 15:16, Vagrant Cascadian wrote:
> On 2023-04-16, Aurelien Jarno wrote:
> > I have tried adding a simple .sbuildrc defining $build_path to '/build'
> > to zandonai.d.o. Unfortunately while it more or less does what you want
> > for the build path, it completely clutter the logs, as any text matching
> > "build" is now replaced by "<>":
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring&arch=s390x&ver=42.1-1%2Bb2&stamp=1681671508&raw=0
> 
> >
> > I guess one option is to use a build path unlikely to match any string
> > from a build log, like with the randomized directory. Something like
> > "/build/reproducible-path/"?
> 
> Just for clarity, then the the PKGBUILDIR would end up being
> /build/reproducible-path/PACKAGE-VERSION ? That works! Or something even
> shorter ... e.g. /build/path/PACKAGE-VERSION or
> /build/debian/PACKAGE-VERSION ? Really, the 2nd directory matters
> little, as long as it is predictible. :)

Yes, setting $build_path to '/build/debian' indeed means that
PKGBUILDDIR is /build/debian/PACKAGE-VERSION.

Unfortunately the string 'build/debian' appears in a few build logs:
0ad
apktool
gatk-bwamem
gatk-fermilite
gkl
grpc-java
haskell-debian
libsis-jhdf5-java
mupdf
nacl
openjfx
pytorch
xtables-addons

Do you have other short suggestions? Do we want to show it has been
built on a debian buildd? In that case /build/debian-buildd might do it.

> We have noticed various packages (for better or worse) do tend to derive
> information from the top-level build directory by assuming it is
> PACKAGE-VERSION; probably good to cater to that assuption.
> 
> Anything along the above lines sounds good, really! Although once a
> particular bikeshed is chosen, ideally we should commit to it for the
> forseeable future! :)

Yes, definitely.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1034540: rhvoice: out of date language list

[Jakub Wilk]

Package: rhvoice
Version: 1.8.0+dfsg-3
Severity: minor

The package description reads:

Initially, RHVoice could speak only Russian. Now it also supports 
English, Esperanto and Georgian. 


There are many other supported languages these days.

--
Jakub Wilk

Bug#1034539: podman - Please install quadlet and systemd generator symlins

[Bastian Blank]

Package: podman
Version: 4.4.0+ds1-1
Severity: normal

podman 4.4 introduces quadlet and with it "real" systemd style units to
manage containers.  See https://www.redhat.com/sysadmin/quadlet-podman

Please install the quadlet binary and the appropriate symlinks to use it
as systemd generator (see Makefile where they need to go).

Bastian

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

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

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

Versions of packages podman recommends:
ii  buildah   1.28.2+ds1-1+b2
pn  catatonit | tini | dumb-init  
ii  dbus-user-session 1.14.6-1
ii  fuse-overlayfs1.10-1
ii  slirp4netns   1.2.0-1
ii  uidmap1:4.13+dfsg1-1+b1

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

-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 2] No such file or directory: 
'/etc/cni/net.d/87-podman-bridge.conflist'

-- no debconf information

Bug#1034538: gox doesn't work under linux/ppc64le

[Timothy Pearson]

Package: gox
Version: 0.3.0-8+b5

When attempting to build a package with the bundled gox version in Debian, it 
doesn't seem to understand linux/ppc64le and silently exits.  Installing the 
upstream version directly with "go install" yields a working gox binary.  Issue 
first discovered with the gitlab runner, report filed at 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30954.

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

[Peymaneh]

Am 17. April 2023 18:35:02 MESZ schrieb Nilesh Patra :
>In your fix, why not use Andreas' suggestion to install it via
>"pkg-config --variable=systemdsystemunitdir systemd" ?
>You might need to revert your fix again otherwise.

That's true, my thinking was that, being in the middle of the freeze, going 
with the smallest possible change can cause the least issues, but I wrote 
myself a todo to go with Andreas' suggestion once that's over :)

Bug#1034446: unblock: linux/6.1.24-1

[Salvatore Bonaccorso]

Hi Paul,

On Sat, Apr 15, 2023 at 09:41:02PM +0200, Paul Gevers wrote:
> Hi Salvatore,
> 
> On 15-04-2023 17:02, Salvatore Bonaccorso wrote:
> > Would you in principle agree on that, imporantly, at this stage of the
> > release? The current debian/changelog is attached.
> 
> I'm pretty sure I've mentioned this to you before, but to be clear to
> everybody I'll state it in public here: we currently trust the kernel
> maintainers to make the right decision until (around) the full freeze under
> the condition that they consider the following:
> 
> * would you propose the same for a point release?

Yes confirmed.

> * if activity in the archive on the d-i front is ongoing or expected
>   check with d-boot.

Right, I do CC as well respectively Cyril specifically and be verbose
with him on plans. So do check with d-i people accordingly.

What I cannot assure is that we never will see regressions in such
point releases, and in fact for instance currently on bullseye we have
for instance #1022126 (got long to get addressed) or #1031753 (to be
fixed in next upload).

So I completely agree, around the time before the full freeze those
updates then need to be postponed to the point releases to not risk
blocking the release.

Regards,
Salvatore

Bug#1034509: Acknowledgement (darktable: Crashes when scrolling through a collection)

[Michael Below]

Am Montag, dem 17.04.2023 um 22:44 +0300 schrieb Michael Below:
>  I will try to send it by separate
> mail.
> 
Sorry, it doesn't go through. I will try dropbox or something like that
tomorrow.

Cheers
Michael

Bug#1034536: gnome-terminal: entire terminal window can go blank e.g., when accessing remote serial console over ipmi

[andrew bezella]

Package: gnome-terminal
Version: 3.46.8-1
Severity: normal

Dear Maintainer,

when using gnome-terminal i sometimes find that the entire window
(including the title bar and the tabs as well as all the text area)
has gone completely blank.  it is still responsive to key strokes.

this typically happens when i am using conserver to connect to a
host's serial console over ipmi while rebooting the remote host.
if my laptop's screen locks or if i switch to another workspace
and then return, often i find gnome-termninal in this completely
black state.  i used rxvt-unicode for many years in this workflow
without experiencing this issue.

i apologize for the vague nature of this bug report and hope i am
directing it at the proper component.

thanks in advance.

andy

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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.6-1
ii  dbus-x11 [dbus-session-bus]   1.14.6-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-terminal-data   3.46.8-1
ii  gsettings-desktop-schemas 43.0-1
ii  libatk1.0-0   2.46.0-5
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libglib2.0-0  2.74.6-1
ii  libgtk-3-03.24.37-2
ii  libpango-1.0-01.50.12+ds-1
ii  libstdc++612.2.0-14
ii  libuuid1  2.38.1-5+b1
ii  libvte-2.91-0 0.70.3-1
ii  libx11-6  2:1.8.4-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.3-1
ii  nautilus-extension-gnome-terminal  3.46.8-1
ii  yelp   42.2-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1034509: Acknowledgement (darktable: Crashes when scrolling through a collection)

[Michael Below]

Am Montag, dem 17.04.2023 um 16:22 -0300 schrieb David Bremner:
> Michael Below  writes:
> 
> > Darktable should take more care in handling its input data. If data
> > (in
> > the XMP file?) is broken, darktable should discard the invalid
> > input
> > data. Anyhow, no kind of input data should lead darktable to a
> > segmentation fault  ("Speicherzugriffsfehler").
> > 
> > I am attaching the XMP file.
> 
> Can you also provide (somehow, presumably not by email) the RAF file?
> I'm afraid static analysis of XMP files is not likely to yield much
> information.

It is a family picture (Easter egg hunt), so I do not want to see it in
a public place like the bugtracker, but I'm happy to provide the
picture to you for your own work. I will try to send it by separate
mail.

Michael

Bug#1034509: Acknowledgement (darktable: Crashes when scrolling through a collection)

[David Bremner]

Michael Below  writes:

> Darktable should take more care in handling its input data. If data (in
> the XMP file?) is broken, darktable should discard the invalid input
> data. Anyhow, no kind of input data should lead darktable to a
> segmentation fault  ("Speicherzugriffsfehler").
>
> I am attaching the XMP file.

Can you also provide (somehow, presumably not by email) the RAF file?
I'm afraid static analysis of XMP files is not likely to yield much
information.

Failing that you could try to generate a backtrace; I believe there are
instructions on darktable.org.

d

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Isaac True (2023-04-17 10:49:20)
> > Why would you have to run flash-kernel again?
> 
> When it's being initially installed it won't have the additional command line
> flag that forces it to ignore the EFI check, so it won't run and you would
> have to run it manually afterwards with the flag. I agree that an env
> variable/config file would be better here.
> 
> > The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
> 
> the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI?
> FK_IGNORE_EFI? Names are hard.
> 
> My intention behind the name was something like "force *despite* EFI", but I
> think FK_IGNORE_EFI does indeed fit a lot better. .
> 
> > I overall like this approach, although the main drawback is having to write
> > to /etc/default/flash-kernel 
> 
> I agree with this - it's a bit more awkward having to create and write a
> file, but I like that it opens the door to allow both methods to work. The
> user can either set the env variable, or it can be set in the file itself.

I've had a private chat with Vagrant yesterday and we agreed that the best way
forward would be to solve this in the same way the environment variable
FK_MACHINE works which can also be set using /etc/flash-kernel/machine and is
essentially and override for /proc/device-tree/model.

So in the same fashion we could have FK_IGNORE_EFI as an environment variable
which can also be set by having /etc/flash-kernel/ignore-efi which is an
override for the existence of /sys/firmware/efi.

Would you like to amend your patch to add support for
/etc/flash-kernel/ignore-efi in addition to FK_IGNORE_EFI? I'd be willing to
test the result in our CI environment. :)

> I'm not sure if it makes sense to add the "! ischroot" check like in that
> merge request though, as I feel like that's a different topic. What do you
> think?

The "! ischroot" is not strictly required for my use-case. I added it because
with it, we get the nice property, that outside of a chroot (i.e. when not
creating a bootable image for another machine) the presence of efi will not get
ignored. This would mean that after creating the bootable image, one would not
have to remove /etc/flash-kernel/ignore-efi to get back to a system that
potentially could support efi in the future. But I do not require this extra
complexity. I think there is value in making FK_IGNORE_EFI behave the same as
FK_MACHINE without any hidden surprises like the "! ischroot" check.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1034535: Installer boot menu displayed in text mode when UEFI secure boot is enabled

[Pascal Hambourg]

Package: debian-installer
Severity: minor

Boot method: USB stick
Image version: debian-bookworm-DI-rc1-amd64-netinst.iso
Boot mode: UEFI

When secure boot is disabled, GRUB displays the menu in graphic mode as 
expected.

When secure boot is enabled, GRUB briefly displays error messages:

 prohibited by secure boot policy
 no video mode activated

and displays the menu in text mode.

This is caused by loadfont failing in /boot/grub/grub.cfg:

if loadfont $prefix/font.pf2 ; then
  set gfxmode=800x600
  set gfxpayload=keep
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod gfxterm
  insmod png
  terminal_output gfxterm
fi

A recent change in grub prohibits loading fonts from outside the signed 
image, so loadfont was adapted to try and load the requested font from 
the embedded memdisk first instead of $prefix.


If I understand correctly, loadfont allows two types of arguments:
- a radix, which is expanded into $prefix/fonts/.pf2
- a pathname starting with / or (

The "magic" looking up (memdisk) first instead of $prefix works only 
with a radix whereas grub.cfg uses a full pathname. Also, it tries to 
load font.pf2 whereas the embedded font file is unicode.pf2.


I tested to replace "$prefix/font.pf2" with "unicode" or 
"(memdisk)/fonts/unicode.pf2" in /boot/grub/grub.cfg and the graphical 
menu was back. Actually, if I remove the loadfont command and the 'if' 
condition, as far as I can see the graphical menu is displayed 
correctly, except the border frame replaced by "?" in the menu entry 
editor, so maybe the condition could be removed.


PS: Maybe the issue also exists in live images ? Didn't check.

Bug#1034534: dcfldd: memory leaks causing out of memory

[Joao Eriberto Mota Filho]

Package: dcfldd
Version: 1.9-1
Severity: important
Tags: upstream
X-Debbugs-Cc: David Polverari 

This bug was taken from dcfldd project[1].

[1] https://github.com/resurrecting-open-source-projects/dcfldd/issues/16

Out of memory: Killed process 9737 (dcfldd-v1.9) total-vm:847432kB,
anon-rss:844620kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1696kB
oom_score_adj:0

Prepare:

swapoff -a  # Just for a faster OOM
fallocate -l 10G test.dd  #create bigger file than your RAM

The bug:
dcfldd diffwr=on if=/dev/zero of=test.dd  # OOM kill

Default option (without diffwr) isn't affected.

The problem:
When destination blocks are same (not written), memory blocks remain allocated.

Eriberto

Bug#1034509: Acknowledgement (darktable: Crashes when scrolling through a collection)

[Michael Below]

Hi,

in the meantime I found that removing one RAF file and the
corresponding XMP has fixed my problem. I am able to re-import the RAF
file into a separate collection and use it without issues. But when I
import the RAF file with the XMP file into another separate collection
darktable crashes again.

Darktable should take more care in handling its input data. If data (in
the XMP file?) is broken, darktable should discard the invalid input
data. Anyhow, no kind of input data should lead darktable to a
segmentation fault  ("Speicherzugriffsfehler").

I am attaching the XMP file.

Cheers
Michael



DSCF8970.RAF.xmp
Description: XML document

Bug#1034533: unblock: connman/1.41-3

[Bastian Germann]

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

Please unblock package connman.

[ Reason ]
Open CVE-2023-28488 in bookworm

[ Impact ]
User is vulnerable for CVE-2023-28488.

[ Tests ]
Exploit at https://github.com/moehw/poc_exploits/tree/master/CVE-2023-28488

[ Risks ]
None.

[ 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 connman/1.41-3diff -Nru connman-1.41/debian/changelog connman-1.41/debian/changelog
--- connman-1.41/debian/changelog   2022-08-19 07:20:06.0 +0200
+++ connman-1.41/debian/changelog   2023-04-14 11:45:14.0 +0200
@@ -1,3 +1,9 @@
+connman (1.41-3) unstable; urgency=medium
+
+  * gdhcp: Verify and sanitize packet length first (CVE-2023-28488)
+
+ -- Vignesh Raman   Fri, 14 Apr 2023 15:15:14 
+0530
+
 connman (1.41-2) unstable; urgency=medium
 
   * d/patches: (Closes: #1016976)
diff -Nru 
connman-1.41/debian/patches/gdhcp-Verify-and-sanitize-packet-length-first.patch 
connman-1.41/debian/patches/gdhcp-Verify-and-sanitize-packet-length-first.patch
--- 
connman-1.41/debian/patches/gdhcp-Verify-and-sanitize-packet-length-first.patch 
1970-01-01 01:00:00.0 +0100
+++ 
connman-1.41/debian/patches/gdhcp-Verify-and-sanitize-packet-length-first.patch 
2023-04-14 11:45:14.0 +0200
@@ -0,0 +1,58 @@
+From 99e2c16ea1cced34a5dc450d76287a1c3e762138 Mon Sep 17 00:00:00 2001
+From: Daniel Wagner 
+Date: Tue, 11 Apr 2023 08:12:56 +0200
+Subject: [PATCH] gdhcp: Verify and sanitize packet length first
+
+Avoid overwriting the read packet length after the initial test. Thus
+move all the length checks which depends on the total length first
+and do not use the total lenght from the IP packet afterwards.
+
+Fixes CVE-2023-28488
+
+Reported by Polina Smirnova 
+---
+ gdhcp/client.c | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/gdhcp/client.c b/gdhcp/client.c
+index 7efa7e45..82017692 100644
+--- a/gdhcp/client.c
 b/gdhcp/client.c
+@@ -1319,9 +1319,9 @@ static bool sanity_check(struct ip_udp_dhcp_packet 
*packet, int bytes)
+ static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd,
+   struct sockaddr_in *dst_addr)
+ {
+-  int bytes;
+   struct ip_udp_dhcp_packet packet;
+   uint16_t check;
++  int bytes, tot_len;
+ 
+   memset(&packet, 0, sizeof(packet));
+ 
+@@ -1329,15 +1329,17 @@ static int dhcp_recv_l2_packet(struct dhcp_packet 
*dhcp_pkt, int fd,
+   if (bytes < 0)
+   return -1;
+ 
+-  if (bytes < (int) (sizeof(packet.ip) + sizeof(packet.udp)))
+-  return -1;
+-
+-  if (bytes < ntohs(packet.ip.tot_len))
++  tot_len = ntohs(packet.ip.tot_len);
++  if (bytes > tot_len) {
++  /* ignore any extra garbage bytes */
++  bytes = tot_len;
++  } else if (bytes < tot_len) {
+   /* packet is bigger than sizeof(packet), we did partial read */
+   return -1;
++  }
+ 
+-  /* ignore any extra garbage bytes */
+-  bytes = ntohs(packet.ip.tot_len);
++  if (bytes < (int) (sizeof(packet.ip) + sizeof(packet.udp)))
++  return -1;
+ 
+   if (!sanity_check(&packet, bytes))
+   return -1;
+-- 
+2.30.2
+
diff -Nru connman-1.41/debian/patches/series connman-1.41/debian/patches/series
--- connman-1.41/debian/patches/series  2022-08-19 07:20:06.0 +0200
+++ connman-1.41/debian/patches/series  2023-04-14 11:45:14.0 +0200
@@ -3,3 +3,4 @@
 wispr-Add-reference-counter-to-portal-context.patch
 wispr-Update-portal-context-references.patch
 gweb-Fix-OOB-write-in-received_data.patch
+gdhcp-Verify-and-sanitize-packet-length-first.patch

Bug#1034519: chrony: AppArmor profile denies creation of chrony.ppsX.sock

[Vincent Blut]

Control: severity -1 important
Control: tags -1 moreinfo

Hi Ryan,

Le 2023-04-17 14:54, Ryan Govostes a écrit :
> Package: chrony
> Version: 4.3
> Severity: normal
> X-Debbugs-Cc: rgovos...@gmail.com
> 
> Dear Maintainer,
> 
> gpsd and chronyd can communicate via domain sockets such as 
> /var/run/chrony.ttyS0.sock. chronyd creates the sockets and gpsd connects to 
> them.
> 
> However, the AppArmor profile for chronyd is too strict; it only allows the 
> creation of sockets for tty devices, and not pps devices.
> 
> @{run}/chrony.tty{,*}.sock rw,

Indeed, this rule is too restrictive…
 
> The corresponding rules on the gpsd profile are:
> 
> /{,var/}run/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> /tmp/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> 
> Could these be relaxed to allow /var/run/chrony.*.sock?

…This might be too permissive though. Could you please tell me if changing the
rule to "@{run}/chrony{,.clk}.{tty,pps}*.sock rw," meets your need?
 
> Ryan

Cheers,
Vincent

P.S: run "apparmor_parser -r /etc/apparmor.d/usr.sbin.chronyd" after modifying
the profile.


signature.asc
Description: PGP signature

Bug#1034516: gpsd: Default GPSD_OPTIONS should include -n

[Bernd Zeimetz]

Hi,


> The lead developer of gpsd says that, "You should always use the '-n' 
> flag"[1].
> 

the lead developer of gpsd refuses to understand how systemd works and is
rather unpleasant to deal with.


> However, GPSD_OPTIONS in /etc/default/gpsd does not default to including it.
> 
> Version 3.22 has a bug (fixed in 3.24 I believe) in which PPS devices are not
> properly used if -n is not passed.[2]

Then -n would be a workaround...

In the "default" way (and that is: for most cases don't do anything except
somthing via the socket talks to gpsd), which is the only sane option for
distributions imho, gpsd is configured to talk to a gps device when udev will
recognize one. So there is no need for -n.

If there is a need for anything else - change the configuration.


Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1034532: O: gpsd -- Global Positioning System - daemon

[Bernd Zeimetz]

Package: wnpp
Severity: normal
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gpsd


Hi!

I intend to orphan the gpsd package.

While it was fun to work on the package back at the time when ESR was
the lead developer, things have changed unfortunately.

If you want to take over the maintenance of the package:
- expect a hostile upstream, especially when you talk about
  distro requirements, systemd or similar things
- expect words that will fail to pass any kind of code of conduct.
- expect breaking API and ABI changes with every version.
- expect scons as build system, which is a major source of PAIN in
  every imaginable body part.
- you should have some knowledge about libraries, symbols, API/ABIs,
  building shared/static libs and similar things, you might need
  to be able to debug the build/usage of all these things,
  althouigh lately the scons stuff worked okayish most of the time.

I'm happy to help to take over the maintenance of the package,
guess I have a bit of in depth knowledge as I've fixed various bugs
on the upstream side, too



The package description is:
 The gpsd service daemon can monitor one or more GPS devices connected to
 a host computer, making all data on the location and movements of the
 sensors available to be queried on TCP port 2947.
 .
 With gpsd, multiple GPS client applications can share access to devices
 without contention or loss of data. Also, gpsd responds to queries with a
 format that is substantially easier to parse than the different standards
 emitted by GPS devices.
 .
 This also includes common tools ubxtool and gpsctl for device configuration
 of the local hardware as well as a ntpshmmon to check generated refclock data.



Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1034531: ITP: obs-scene-as-transition -- plugin for OBS Studio to use a Scene as a Transition

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Andi Stone 

* Package name: obs-scene-as-transition
  Version : 1.1.0
  Upstream Contact: Andi Stone 
* URL : 
https://obsproject.com/forum/resources/scene-as-transition.1704
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to use a Scene as a Transition

 This plugin can be used to create all kinds of transitions. It is recommended
 to get the most out of this plugin that you use other powerful plugins such
 as obs-move-transition to create advanced movements.

 Is possible to make the transitions dynamic by passing information from other
 ways. An example would be putting a text source on the transition scene and
 having it updated with the name of the scene or game you are transitioning to.

 Some features:

   - Choose a scene to use as a transition.
   - Set the total transition duration.
   - Set a what point the scene changes (Time or Percentage).
   - Choose a filter to trigger on the transition scene when the transition
 starts.

Bug#1034530: mtrg: mrtg.postinst uses useradd/groupadd (passwd) while mrtg.postrm uses deluser/delgroup (adduser)

[Patrice Duroux]

Package: mtrg
Version: 2.17.10-4
Severity: normal

Dear Maintainer,

Just by looking at this piuparts issue:
https://piuparts.debian.org/sid/source/m/mrtg.html,
I think that this is due to the use of userdel/groupdel instead of
deluser/delgroup
or add depends on adduser in the debian/control file.

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

Bug#1034528: pyethash: Switch to GitHub source and build libethash

[Bastian Germann]

Source: pyethash
Severity: wishlist

Please build the library from its GitHub source and add a libethash binary
package with corresponsing development package. This will be used for #1003917.

Bug#1034529: vim-runtime: perl subroutine body fails to indent in bookworm (regression from bullseye)

[Matthijs van Duin]

Package: vim-runtime
Version: 2:9.0.1378-1
Severity: normal
X-Debbugs-Cc: matthijsvand...@gmail.com

Dear Maintainer,

I noticed when editing perl code in vim that pressing enter after the
opening brace of a subroutine no longer indents like you'd expect:

// expected:
sub foo {
_<-- cursor here

// actual:
sub foo {
_<-- cursor here

This worked correctly in debian bullseye (vim 8.2).


The culprit appears to be that syntax/perl.vim has introduced

syn region perlSubDeclaration ...

which seems to confuse GetPerlIndent() in indent/perl.vim. If I add
tests for this region name the issue appears to be fixed:

@@ -133,6 +133,7 @@ function! GetPerlIndent()
 \ || synid == "perlHereDoc"
 \ || synid == "perlBraces"
 \ || synid == "perlStatementIndirObj"
+\ || synid == "perlSubDeclaration"
 \ || synid =~ "^perlFiledescStatement"
 \ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
 let brace = strpart(line, bracepos, 1)
@@ -151,6 +152,7 @@ function! GetPerlIndent()
 \ || synid == "perlMatchStartEnd"
 \ || synid == "perlBraces"
 \ || synid == "perlStatementIndirObj"
+\ || synid == "perlSubDeclaration"
 \ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
 let ind = ind - shiftwidth()
 endif

But beware that I don't really know how this function works or whether
this is a correct fix, it was just a random guess that seemed to produce
the desired result.


The issue can alternatively be fixed by reverting the

" Functions
...various perlSub* match rules...
syn match perlFunction ...

section of syntax/perl.vim to its previous (vim 8.2) version, except
with perlSignature renamed to perlSubSignature to ensure it gets
highlighted correctly.



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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim-gtk3 [vim]  2:9.0.1378-1

vim-runtime suggests no packages.

-- no debconf information

Bug#1034527: unblock: nageru/2.2.1-1

[Steinar H. Gunderson]

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

Please unblock package nageru

Please consider unblocking Nageru 2.2.1-1. It contains a number
of focused fixes, mostly for crash bugs related to video stream
inputs (e.g. from video files, or from the network). As upstream,
I made 2.2.1 specifically as a set of targeted fixes over 2.2.0
to make this feature less broken for bookworm.

Nageru is a leaf package, so there should be fairly low risk.
I've tested both myself and had user reports verifying the fixes
(in upstream git).

There are no Debian package changes (beyond the changelog),
only upstream changes. debdiff is attached.

[ 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 nageru/2.2.1-1
diff -Nru nageru-2.2.0/debian/changelog nageru-2.2.1/debian/changelog
--- nageru-2.2.0/debian/changelog   2022-11-23 09:26:33.0 +0100
+++ nageru-2.2.1/debian/changelog   2023-04-17 18:37:27.0 +0200
@@ -1,3 +1,10 @@
+nageru (2.2.1-1) unstable; urgency=medium
+
+  * New upstream release.
+* Fixes several crash bugs related to video inputs. (Closes: #1034471)
+
+ -- Steinar H. Gunderson   Mon, 17 Apr 2023 18:37:27 +0200
+
 nageru (2.2.0-2) unstable; urgency=medium
 
   * Remove ppc64el from futatabi's architecture list.
diff -Nru nageru-2.2.0/meson.build nageru-2.2.1/meson.build
--- nageru-2.2.0/meson.build2022-11-15 00:25:44.0 +0100
+++ nageru-2.2.1/meson.build2023-04-17 18:35:47.0 +0200
@@ -1,4 +1,4 @@
-project('nageru', 'cpp', default_options: ['buildtype=debugoptimized'], 
version: '2.2.0')
+project('nageru', 'cpp', default_options: ['buildtype=debugoptimized'], 
version: '2.2.1')
 
 cxx = meson.get_compiler('cpp')
 qt5 = import('qt5')
diff -Nru nageru-2.2.0/nageru/cef_capture.cpp 
nageru-2.2.1/nageru/cef_capture.cpp
--- nageru-2.2.0/nageru/cef_capture.cpp 2022-11-15 00:25:44.0 +0100
+++ nageru-2.2.1/nageru/cef_capture.cpp 2023-04-17 18:35:47.0 +0200
@@ -165,8 +165,6 @@
});
 }
 
-#define FRAME_SIZE (8 << 20)  // 8 MB.
-
 void CEFCapture::configure_card()
 {
if (video_frame_allocator == nullptr) {
diff -Nru nageru-2.2.0/nageru/decklink_capture.cpp 
nageru-2.2.1/nageru/decklink_capture.cpp
--- nageru-2.2.0/nageru/decklink_capture.cpp2022-11-15 00:25:44.0 
+0100
+++ nageru-2.2.1/nageru/decklink_capture.cpp2023-04-17 18:35:47.0 
+0200
@@ -24,8 +24,6 @@
 #include "shared/memcpy_interleaved.h"
 #include "v210_converter.h"
 
-#define FRAME_SIZE (8 << 20)  // 8 MB.
-
 using namespace std;
 using namespace std::chrono;
 using namespace std::placeholders;
diff -Nru nageru-2.2.0/nageru/defs.h nageru-2.2.1/nageru/defs.h
--- nageru-2.2.0/nageru/defs.h  2022-11-15 00:25:44.0 +0100
+++ nageru-2.2.1/nageru/defs.h  2023-04-17 18:35:47.0 +0200
@@ -3,11 +3,12 @@
 
 #include 
 
-#define MAX_FPS 60
+#define TYPICAL_FPS 60
 #define FAKE_FPS 25  // Must be an integer.
 // #define MAX_VIDEO_CARDS 16  // defined in shared_defs.h.
 #define MAX_ALSA_CARDS 16
 #define MAX_BUSES 256  // Audio buses.
+#define FRAME_SIZE (8 << 20)  // 8 MB. (FIXME: Not enough for a 2160p frame!)
 
 // For deinterlacing. See also comments on InputState.
 #define FRAME_HISTORY_LENGTH 5
diff -Nru nageru-2.2.0/nageru/ffmpeg_capture.cpp 
nageru-2.2.1/nageru/ffmpeg_capture.cpp
--- nageru-2.2.0/nageru/ffmpeg_capture.cpp  2022-11-15 00:25:44.0 
+0100
+++ nageru-2.2.1/nageru/ffmpeg_capture.cpp  2023-04-17 18:35:47.0 
+0200
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -43,8 +44,6 @@
 #include 
 #endif
 
-#define FRAME_SIZE (8 << 20)  // 8 MB.
-
 using namespace std;
 using namespace std::chrono;
 using namespace bmusb;
@@ -454,24 +453,63 @@
}
 }
 
-AVPixelFormat get_vaapi_hw_format(AVCodecContext *ctx, const AVPixelFormat 
*fmt)
+template
+AVPixelFormat get_hw_format(AVCodecContext *ctx, const AVPixelFormat *fmt)
 {
-   for (const AVPixelFormat *fmt_ptr = fmt; *fmt_ptr != -1; ++fmt_ptr) {
-   for (int i = 0;; ++i) {  // Termination condition inside loop.
-   const AVCodecHWConfig *config = 
avcodec_get_hw_config(ctx->codec, i);
-   if (config == nullptr) {  // End of list.
-   fprintf(stderr, "Decoder %s does not support 
device.\n", ctx->codec->name);
-   break;
-   }
-   if (config->methods & 
AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX &&
-   config->device_type == AV_HWDEVICE_TYPE_VAAPI &&
-   config->pix_fmt == *fmt_ptr) {
+   bool found_config_of_right_type = false;
+   for (int i = 0;; ++i) {  // Termination conditi

Bug#1034091: RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision

[Petter Reinholdtsen]

Control: retitle -1 ITP: whisper -- Robust Speech Recognition via Large-Scale 
Weak Supervision

I have decided to upload this package to experimental under the unbrella
of the Deep Learning Team.  I suspect it should go into contrib because
of the state of its neural network models.

Not quite sure how to handle the models.  Perhaps create a non-free
package with one model, or simply ask people to download the model
individually?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034307: RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models

[Petter Reinholdtsen]

Control: retitle -1 ITP: tiktoken -- fast BPE tokeniser for use with OpenAI's 
models

I've decided to upload this package to experimental under the umbrella
of the Deep Learning Team.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034144: RFP: openai triton -- fast BPE tokeniser for use with OpenAI's models

[Petter Reinholdtsen]

Control: retitle -1 ITP: openai triton -- fast BPE tokeniser for use with 
OpenAI's models

I decided to upload this package to experimental under the Debian Deep
Learning team umbrella.

Sadly it is uploaded without the swinx documentation, which I could not
get to build.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034526: azure-cli: Better collaboration with upstream

[Gregor Riepl]

Package: azure-cli
Version: 2.45.0-1
Severity: important
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

Upstream has had lots of bug reports due to discrepancies between the version
packaged in Debian and Ubuntu and Microsoft's own "official" Debian packages:
https://github.com/Azure/azure-cli/issues/19640

Virtually all of these bugs were reported upstream instead of the Debian
project, causing fallout on their side, whilst the Debian packages remain
broken.

Please consider working closer together with upstream to reach the same release
quality, or (possibly) fix the bug reporting channel, so bugs specific to the
Debian version are reported where they belong (i.e. BTS and not upstream's
Github).

As an alternative, please consider renaming the Debian packages, so there is
less ambiguity which version is installed.

Examples of bugs that should have been reported in Debian instead of upstream:
https://github.com/Azure/azure-cli/issues/25826
https://github.com/Azure/azure-cli/issues/25950
https://github.com/Azure/azure-cli/issues/25122
https://github.com/Azure/azure-cli/issues/24959
https://github.com/Azure/azure-cli/issues/24656
https://github.com/Azure/azure-cli/issues/24308

Thank you for your consideration.


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

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

Versions of packages azure-cli depends on:
ii  python33.11.2-1+b1
ii  python3-azure-cli  2.45.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#1034525: pymongo: uses invalid architecture wildcards

[Graham Inggs]

Source: pymongo
Version: 3.11.0-1
Severity: important

Hi Maintainer

Pymongo uses invalid architecture wildcards 'any-armel' and
'any-armhf' in debian/control, causing the binary packages
python3-pymongo-ext and python3-bson-ext to not be available on armel
and armhf [1][2].  These should be replaced by 'any-arm'.

I'm filing this bug with severity important instead of serious, as
these binary packages have never been available on these
architectures.

Regards
Graham


[1] https://packages.debian.org/unstable/python3-pymongo-ext
[2] https://packages.debian.org/unstable/python3-bson-ext

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

[Nilesh Patra]

On Mon, Apr 17, 2023 at 03:47:43PM +, Peymaneh wrote:
> Am 16.04.23 um 17:37 schrieb Nilesh Patra:
> > Can you take care of this?
> 
> thanks for the mail Nilesh, I missed the bugreport.

In your fix, why not use Andreas' suggestion to install it via
"pkg-config --variable=systemdsystemunitdir systemd" ?
You might need to revert your fix again otherwise.

> I uploaded a fix just now and will contact the release team for unblocking.

I think that won't be needed. Caddy is a non-key package with (hopefully)
passing autopkgtest. You'll need to ask release team if full-freeze starts
before the next 20 days.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards

[Graham Inggs]

Source: libretro-bsnes-mercury
Version: 094+git20220807-6
Severity: serious

Hi Maintainer

Since the upload of 094+git20220807-6, the
kodi-game-libretro-bsnes-mercury-* binary packages are no longer built
on armel and armhf [1][2][3].  This is due to the use of invalid
architecture wildcards 'any-armel' and 'any-armhf'.  These should be
replaced by 'any-arm' for each of three
kodi-game-libretro-bsnes-mercury-* binary packages in debian/control,
as follows:

-Architecture: any-amd64 any-arm64 any-armel any-armhf any-i386
any-powerpc any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64

+Architecture: any-amd64 any-arm64 any-arm any-i386 any-powerpc
any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64

Regards
Graham


[1] 
https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-accuracy
[2] 
https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-balanced
[3] 
https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-performance

Bug#984623: pychess: Fails to switch off sound

[Sebastian Pipping]

Release 1.0.4 includes a related fix 
(https://github.com/pychess/pychess/pull/2017) so I am expecting an 
update to 1.0.4 (issue 1034523) to fix the sound issue as a side effect.

Bug#987999: pychess: Puzzles don't open

[Sebastian Pipping]

I confirm the issue for both 1.0.0 and 1.0.3.  It appears fixed in 
1.0.4, so a bump to 1.0.4 (issue 1034523) would fix this issue as a side 
effect.

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Cyril Brulebois]

Hi,

Sorry it took some time to reply to that particular bug…

Pascal Hambourg  (2023-04-17):
> On 07/04/2023 at 01:05, I wrote:
> > Ugly attached patch works for me as PoC.
> > Copy fd 0 into fd 9 (because it looked unused) before entering the
> > pipeline, and restore it when running install_firmware_pkg.

I think I'd be happy to take this patch for bookworm, as a workaround…

> Here is another patch for hw-detect moving the install_firmware_pkg()
> call outside the pipeline instead of playing with file descriptors.

… before considering a real/better fix after bookworm.

> PS: shouldn't this bug report be reassigned to hw-detect ?

Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


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


signature.asc
Description: PGP signature

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

[Peymaneh]

Hi

Am 16.04.23 um 17:37 schrieb Nilesh Patra:

Can you take care of this?


thanks for the mail Nilesh, I missed the bugreport.

I uploaded a fix just now and will contact the release team for 
unblocking :)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034523: pychess: Please update PyChess to 1.0.4

[Sebastian Pipping]

Package: pychess
Version: 1.0.3-1
Severity: normal
X-Debbugs-Cc: sebast...@pipping.org


Hi!

PyChess version 1.0.4 with bugfixes has been released upstream by now.  It
would be great to get these fixes to users of Debian.  Any chance you could
update PyChess to 1.0.4 in Debian?

Thanks and best, Sebastian

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi Lisandro,

thanks for your response!

Am Samstag 15 April 2023 15:15:08 schrieben Sie:
> On Thu, 13 Apr 2023 at 14:15, Bernhard Reiter 
> >"qtwebengine-opensource-src No security support upstream and
> >backports not feasible, only for use on trusted content"

> If we follow that reasoning we shouldn't be shipping Plasma at all, as
> many things use Qt5's webengine.

Konqueror is advertised as web browser, which means it will (offer to)
open URLs from different sources, e.g. when clicked from emails which means
external URLs and data. 

Other components from plasma may not share the same exposure to outside
data, and thus would be less vulnerable. It seems that this would warrant
some more examination. 

If it is true that other components show the same risks, then yes, I'd say 
that we should either get the security situation changed or really do not 
ship those components by default. They may risk systems like
the dynamic loading of remote objects from java did which would be a problem 
for both Debian and upstream.

It seems to big a topic for this issue.
What would be the right place in debian to bring this up?

Thanks again,
Bernhard


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

Bug#1034522: gnome-control-center: Crash when changing user picture

[Merlin Cooper]

Package: gnome-control-center
Version: 1:43.4.1-1
Severity: normal
X-Debbugs-Cc: mxanthropoc...@outlook.com

Dear Maintainer,

When changing the user picture to a custom one (not one of the built-in ones, 
which works fine), gnome-control-center crashes with a segmentation fault

Here is the log:

MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-control-center:30841): Gsk-WARNING **: 01:26:10.668: Linking failure in 
shader:
error: looping not supported i915 fragment shaders, all loops must be 
statically unrollable.
Gsk-Message: 01:26:10.674: Failed to realize renderer of type 'GskGLRenderer' 
for surface 'GdkWaylandToplevel': Linking failure in shader: error: looping not 
supported i915 fragment shaders, all loops must be statically unrollable.


(gnome-control-center:30841): user-accounts-cc-panel-WARNING **: 01:26:11.151: 
Error retrieving app filter for user (null): User 4294967295 does not exist

(gnome-control-center:30841): GLib-GObject-WARNING **: 01:26:11.286: invalid 
uninstantiatable type '(null)' in cast to 'GObject'

(gnome-control-center:30841): GLib-GObject-CRITICAL **: 01:26:11.287: 
g_object_set_data: assertion 'G_IS_OBJECT (object)' failed

(gnome-control-center:30841): user-accounts-cc-panel-WARNING **: 01:26:11.607: 
Impossible to update fingerprint manager state: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
net.reactivated.Fprint was not provided by any .service files
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-control-center:30841): Gsk-WARNING **: 01:26:14.051: Linking failure in 
shader:
error: looping not supported i915 fragment shaders, all loops must be 
statically unrollable.
Gsk-Message: 01:26:14.053: Failed to realize renderer of type 'GskGLRenderer' 
for surface 'GdkWaylandPopup': Linking failure in shader: error: looping not 
supported i915 fragment shaders, all loops must be statically unrollable.

MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-control-center:30841): Gsk-WARNING **: 01:26:18.625: Linking failure in 
shader:
error: looping not supported i915 fragment shaders, all loops must be 
statically unrollable.
Gsk-Message: 01:26:18.626: Failed to realize renderer of type 'GskGLRenderer' 
for surface 'GdkWaylandToplevel': Linking failure in shader: error: looping not 
supported i915 fragment shaders, all loops must be statically unrollable.


(gnome-control-center:30841): Gtk-CRITICAL **: 01:26:23.119: 
gtk_window_set_transient_for: assertion 'parent == NULL || GTK_IS_WINDOW 
(parent)' failed
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-control-center:30841): Gsk-WARNING **: 01:26:23.737: Linking failure in 
shader:
error: looping not supported i915 fragment shaders, all loops must be 
statically unrollable.
Gsk-Message: 01:26:23.738: Failed to realize renderer of type 'GskGLRenderer' 
for surface 'GdkWaylandToplevel': Linking failure in shader: error: looping not 
supported i915 fragment shaders, all loops must be statically unrollable.

Gtk-Message: 01:26:23.741: GtkDialog mapped without a transient parent. This is 
discouraged.
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-control-center:30841): Gsk-WARNING **: 01:26:26.614: Linking failure in 
shader:
error: looping not supported i915 fragment shaders, all loops must be 
statically unrollable.

(gnome-control-center:30841): user-accounts-cc-panel-WARNING **: 01:26:26.616: 
Couldn't realize GL renderer: Linking failure in shader: error: looping not 
supported i915 fragment shaders, all loops must be statically unrollable.

(gnome-control-center:30841): GdkPixbuf-CRITICAL **: 01:26:26.616: 
gdk_pixbuf_scale_simple: assertion 'GDK_IS_PIXBUF (src)' failed

(gnome-control-center:30841): GdkPixbuf-CRITICAL **: 01:26:26.618: 
gdk_pixbuf_save_to_callbackv: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
Segmentation fault


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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-6
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6

Bug#1034521: clasp: FTBFS with LTO enabled

[Lukas Märdian]

Package: clasp
Version: 3.3.5-4.2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

this package fails to execute its buildtime tests (dh_auto_test) on the s390x
architecture when compiled with an LTO enabled toolchain. On Ubuntu
(GCC-12 + LTO) we saw the following failure.

This does not directly affect Debian, but might, should Debian enable LTO by
default in the future. Please consider disabling LTO explicitly to avoid such
(future) failure, or feel free to reject this patch if you feel like it doesn't
apply.

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

  * d/rules: Disable LTO, to avoid FTBFS (test failure) on s390x


Thanks for considering the patch.

-- Lukas


2/3 Testing: test_opts
2/3 Test: test_opts
Command: "/<>/build.dir/hardening_mt/bin/test_potassco_opts"
Directory: /<>/build.dir/hardening_mt/libpotassco/tests
"test_opts" start time: Apr 12 14:19 UTC
Output:
--

~~~
test_potassco_opts is a Catch v1.12.2 host application.
Run with -? for options

---
Test value store
  store supports swap
---
./libpotassco/tests/test_value.cpp:95
...

./libpotassco/tests/test_value.cpp:100: FAILED:
  REQUIRE( Po::value_cast(x).parsed == 10 )
with expansion:
  0 == 10

===
test cases:  16 |  15 passed | 1 failed
assertions: 127 | 126 passed | 1 failed


Test time =   1.00 sec
--
Test Failed.
"test_opts" end time: Apr 12 14:19 UTC
"test_opts" time elapsed: 00:00:01
--

End testing: Apr 12 14:19 UTC

==> build.dir/hardening_mt/Testing/Temporary/LastTestsFailed.log <==
2:test_opts
make[1]: *** [debian/rules:49: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:29: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Build finished at 2023-04-12T14:19:21Z


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

Kernel: Linux 5.19.0-38-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru clasp-3.3.5/debian/rules clasp-3.3.5/debian/rules
--- clasp-3.3.5/debian/rules2022-11-19 11:10:37.0 +0100
+++ clasp-3.3.5/debian/rules2023-04-17 17:18:03.0 +0200
@@ -17,7 +17,7 @@
 DEB_CXXFLAGS_MAINT_APPEND = -O3 -Wall
 DEB_CPPFLAGS_MAINT_APPEND = -DNDEBUG
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

Bug#1034520: python3-cairo: unhelpful upstream changelog

[Jakub Wilk]

Package: python3-cairo
Version: 1.20.1-5+b1

This is unhelpful:

   $ zcat /usr/share/doc/python3-cairo/changelog.gz
   Changelog
   =

   .. currentmodule:: cairo

   .. include:: ../NEWS


--
Jakub Wilk

Bug#1034518: unblock: openstack-pkg-tools/123

[Thomas Goirand]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: openstack-pkg-to...@packages.debian.org
Control: affects -1 + src:openstack-pkg-tools

Please unblock package openstack-pkg-tools

[ Reason ]
Since we don't have /usr/bin/uwsgi_python3X (but only
/usr/bin/uwsgi_python311), openstack-pkg-tools's
init template isn't finding uwsgi's binary, and
none of the OpenStack API services can be started.

The fix searches correctly for /usr/bin/uwsgi_python311,
and uses it (as expected).

[ Impact ]
None of the API daemons of OpenStack can start without
this patch.

[ Tests ]
I've rebuilt and tested manually that the attached debdiff
fixes the situation.

[ Risks ]
Version 123, compared to the current Bookworm version 120,
includes 3 patches. Let me review them one by one.

https://salsa.debian.org/openstack-team/debian/openstack-pkg-tools/-/commit/c87b6a0a576b2acaa9d1b2f008196677ce6d42ea
Add pkgos_add_section().

To be completely honest, this commit isn't really needed,
as it adds a new function to all postinst. However, since
it isn't actually called currently (I'm using this elsewhere,
in a currently ongoing development), it's IMO safe to leave
it as-is, and I don't think it's necessary to add more work
to remove it (ie: I would need to revert the commit, upload
version 124, let this migrate to Bookworm, and re-upload
to unstable version 125 with this commit again).

Please allow this to get in, it's really harmless as long
as sh parses it and there's no syntax error, which is the
case.

https://salsa.debian.org/openstack-team/debian/openstack-pkg-tools/-/commit/5498a3cd2e223578343ce61735a9e9dbd8515a2f
Remove ~bpo.* from the exported OSLO_PACKAGE_VERSION, because of new
restrictions in setuptools.

Under the latest version of setuptools (available in Bookworm),
complex Python module versions aren't allowed anymore. This
commit makes openstack-pkg-tools generate python module versions
(in the egg-info) that are compatible with setuptools.

https://salsa.debian.org/openstack-team/debian/openstack-pkg-tools/-/commit/ef6da658138ab7c68e714616f5b512107ab7cb24
Fix init template to support uwsgi with Python 3.11 and up.

That's the very important commit that I wish to get in
Bookworm. Without this one, OpenStack API runninf under
UWSGI wouldn't start.

[ 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 ]
Note that I will need unblocks for all OpenStack
API daemons after openstack-pkg-tools migrates to
Bookworm, as they need to be rebuilt using that new
version. I'll open separate bugs for them then.

unblock openstack-pkg-tools/123
diff -Nru openstack-pkg-tools-120/debian/changelog 
openstack-pkg-tools-123/debian/changelog
--- openstack-pkg-tools-120/debian/changelog2022-09-14 14:09:51.0 
+0200
+++ openstack-pkg-tools-123/debian/changelog2023-04-14 10:01:22.0 
+0200
@@ -1,3 +1,22 @@
+openstack-pkg-tools (123) unstable; urgency=medium
+
+  * Fix init template to support uwsgi with Python 3.11 and up.
+
+ -- Thomas Goirand   Fri, 14 Apr 2023 10:01:22 +0200
+
+openstack-pkg-tools (122) experimental; urgency=medium
+
+  * Remove ~bpo.* from the exported OSLO_PACKAGE_VERSION, because of new
+restrictions in setuptools.
+
+ -- Thomas Goirand   Mon, 13 Mar 2023 21:02:11 +0100
+
+openstack-pkg-tools (121) experimental; urgency=medium
+
+  * Add pkgos_add_section().
+
+ -- Thomas Goirand   Sat, 11 Mar 2023 14:53:35 +0100
+
 openstack-pkg-tools (120) unstable; urgency=medium
 
   * Deprecate option --no-py2 and --no-py3 (always package for PY3 only).
diff -Nru openstack-pkg-tools-120/init-template/init-script-template 
openstack-pkg-tools-123/init-template/init-script-template
--- openstack-pkg-tools-120/init-template/init-script-template  2022-09-14 
14:09:51.0 +0200
+++ openstack-pkg-tools-123/init-template/init-script-template  2023-04-14 
10:01:22.0 +0200
@@ -30,7 +30,7 @@
# Sid doesn't have /usr/bin/uwsgi_python3, so we need
# to search for a more specific daemon name. For stretch
# /usr/bin/uwsgi_python3 is fine.
-   for i in 3 35 36 37 38 39 ; do
+   for i in 3 35 36 37 38 39 310 311 312 313 314 315 316 317 318 319 ; do
if [ -x /usr/bin/uwsgi_python${i} ] ; then
DAEMON=/usr/bin/uwsgi_python${i}
fi
diff -Nru openstack-pkg-tools-120/pkgos_func openstack-pkg-tools-123/pkgos_func
--- openstack-pkg-tools-120/pkgos_func  2022-09-14 14:09:51.0 +0200
+++ openstack-pkg-tools-123/pkgos_func  2023-04-14 10:01:22.0 +0200
@@ -6,6 +6,18 @@
echo ${i% *}
 }
 
+pkgos_add_section () {
+local CONF_FILE SECTION
+CONF_FILE=${1}
+SECTION=${2}
+
+# Check if section exists
+if ! grep -q -E '^[ \t]*\['${SECTION}'\][ \t]*$' ${CONF_FILE} ; then
+   # If

Bug#1032647: nvidia-driver: Intermittent black screen after updating to 525.89.02-1

[Andreas Beckmann]

Control: tag -1 moreinfo

On 10/03/2023 14.28, Julien-Benjamin wrote:

Package: nvidia-driver
Version: 525.89.02-1


Could you retry with 525.105.17-1 from unstable?
And if that still doesn't work, with 530.41.03-1 from experimental?
(The packaged version of the 530 driver, not the one installed from the 
.run installer.)


Thanks

Andreas

Bug#1034517: sgt-puzzles: [intl:de] Update German help translation

[Helge Kreutzmann]

Package: sgt-puzzles
Version: 20230410.71cf891-1
Severity: wishlist
Tags: patch l10n

I noticed a new upstream version of sgt-puzzles. I rebuild the package
and additionally run "make -f Makefile.doc update-po". This turned out
~ 7 changed strings.

Please add the attached file as po/de.po for your next upload to
recomplete the translations. (Please note that the attached file is
compressed using xz due to the large size).

Greetings

  Helge


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

Kernel: Linux 6.1.22 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sgt-puzzles depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1

Versions of packages sgt-puzzles recommends:
ii  chromium [www-browser]   112.0.5615.49-2
ii  firefox-esr [www-browser]102.10.0esr-1
ii  konqueror [www-browser]  4:22.12.3-1
ii  links [www-browser]  2.28-1+b2
ii  lynx [www-browser]   2.9.0dev.12-1
ii  sugar-browse-activity [www-browser]  207-2
ii  w3m [www-browser]0.5.3+git20230121-2
ii  xdg-utils1.1.3-4.1

sgt-puzzles suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


sgt_help_de_20230410.71cf891-1.po.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#1034516: gpsd: Default GPSD_OPTIONS should include -n

[Ryan Govostes]

Package: gpsd
Version: 3.22
Severity: normal
X-Debbugs-Cc: rgovos...@gmail.com

Dear Maintainer,

The lead developer of gpsd says that, "You should always use the '-n' flag"[1].

However, GPSD_OPTIONS in /etc/default/gpsd does not default to including it.

Version 3.22 has a bug (fixed in 3.24 I believe) in which PPS devices are not
properly used if -n is not passed.[2]

1: https://gitlab.com/gpsd/gpsd/-/issues/239#note_1354103016
2: https://gitlab.com/gpsd/gpsd/-/issues/239

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.49-linuxkit (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gpsd depends on:
ii  adduser 3.118
pn  libbluetooth3   
ii  libc6   2.31-13+deb11u3
pn  libdbus-1-3 
pn  libgps28
pn  libusb-1.0-0
ii  lsb-base11.1.0
pn  netbase | systemd-sysv  
ii  python3 3.9.2-3

Versions of packages gpsd recommends:
pn  gpsd-tools  
pn  udev

Versions of packages gpsd suggests:
pn  apparmor  
pn  dbus  
pn  gpsd-clients  

Bug#1034515: unblock: openvswitch/3.1.0-2 (CVE-2023-1668)

[Thomas Goirand]

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

Please unblock package openvswitch

[ Reason ]
The latest upload fixes CVE-2023-1668, that is:

"Remote traffic denial of service via crafted packets with IP
proto 0."

[ Impact ]
An attacker cloud fool OVS into inserting wrong taffic flow
table entries that would wrongly redirect traffic, effectively
leading to a DoS.

[ Tests ]
Upstream has a full unit test suite, and the patch includes
new tests for this CVE.

[ Risks ]
The patch itself isn't that big, and I've checked that
OVS continues to work.

[ 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 openvswitch/3.1.0-2
diff -Nru openvswitch-3.1.0/debian/changelog openvswitch-3.1.0/debian/changelog
--- openvswitch-3.1.0/debian/changelog  2023-02-21 23:02:16.0 +0100
+++ openvswitch-3.1.0/debian/changelog  2023-04-11 11:54:40.0 +0200
@@ -1,3 +1,11 @@
+openvswitch (3.1.0-2) unstable; urgency=high
+
+  * CVE-2023-1668: Remote traffic denial of service via crafted packets with IP
+proto 0. Applied upstream patch: ofproto-dpif-xlate: Always mask ip proto
+field (Closes: #1034042).
+
+ -- Thomas Goirand   Tue, 11 Apr 2023 11:54:40 +0200
+
 openvswitch (3.1.0-1) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff -Nru 
openvswitch-3.1.0/debian/patches/CVE-2023-1668_ofproto-dpif-xlate_Always_mask_ip_proto_field.patch
 
openvswitch-3.1.0/debian/patches/CVE-2023-1668_ofproto-dpif-xlate_Always_mask_ip_proto_field.patch
--- 
openvswitch-3.1.0/debian/patches/CVE-2023-1668_ofproto-dpif-xlate_Always_mask_ip_proto_field.patch
  1970-01-01 01:00:00.0 +0100
+++ 
openvswitch-3.1.0/debian/patches/CVE-2023-1668_ofproto-dpif-xlate_Always_mask_ip_proto_field.patch
  2023-04-11 11:54:40.0 +0200
@@ -0,0 +1,425 @@
+Subject: CVE-2023-1668: ofproto-dpif-xlate: Always mask ip proto field.
+ The ofproto layer currently treats nw_proto field as overloaded to mean
+ both that a proper nw layer exists, as well as the value contained in
+ the header for the nw proto.  However, this is incorrect behavior as
+ relevant standards permit that any value, including '0' should be treated
+ as a valid value.
+ .
+ Because of this overload, when the ofproto layer builds action list for
+ a packet with nw_proto of 0, it won't build the complete action list that
+ we expect to be built for the packet.  That will cause a bad behavior
+ where all packets passing the datapath will fall into an incomplete
+ action set.
+ .
+ The fix here is to unwildcard nw_proto, allowing us to preserve setting
+ actions for protocols which we know have support for the actions we
+ program.  This means that a traffic which contains nw_proto == 0 cannot
+ cause connectivity breakage with other traffic on the link.
+Author: Aaron Conole 
+Date: Fri, 31 Mar 2023 17:17:27 -0400
+Reported-by: David Marchand 
+Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2134873
+Acked-by: Ilya Maximets 
+Signed-off-by: Aaron Conole 
+Signed-off-by: Ilya Maximets 
+Origin: upstream, 
https://github.com/openvswitch/ovs/commit/61b39d8c4797f1b668e4d5e5350d639fca6082a9.patch
+Bug-Debian: https://bugs.debian.org/1034042
+Last-Update: 2023-04-11
+
+diff --git a/include/openvswitch/meta-flow.h b/include/openvswitch/meta-flow.h
+index 045dce8f5fa..3b0220aaa25 100644
+--- a/include/openvswitch/meta-flow.h
 b/include/openvswitch/meta-flow.h
+@@ -2366,6 +2366,10 @@ void mf_format_subvalue(const union mf_subvalue 
*subvalue, struct ds *s);
+ void field_array_set(enum mf_field_id id, const union mf_value *,
+  struct field_array *);
+ 
++/* Mask the required l3 prerequisites if a 'set' action occurs. */
++void mf_set_mask_l3_prereqs(const struct mf_field *, const struct flow *,
++struct flow_wildcards *);
++
+ #ifdef __cplusplus
+ }
+ #endif
+diff --git a/lib/meta-flow.c b/lib/meta-flow.c
+index c576ae6202a..474344194fa 100644
+--- a/lib/meta-flow.c
 b/lib/meta-flow.c
+@@ -3676,3 +3676,28 @@ mf_bitmap_not(struct mf_bitmap x)
+ bitmap_not(x.bm, MFF_N_IDS);
+ return x;
+ }
++
++void
++mf_set_mask_l3_prereqs(const struct mf_field *mf, const struct flow *fl,
++   struct flow_wildcards *wc)
++{
++if (is_ip_any(fl) &&
++((mf->id == MFF_IPV4_SRC) ||
++ (mf->id == MFF_IPV4_DST) ||
++ (mf->id == MFF_IPV6_SRC) ||
++ (mf->id == MFF_IPV6_DST) ||
++ (mf->id == MFF_IPV6_LABEL) ||
++ (mf->id == MFF_IP_DSCP) ||
++ (mf->id == MFF_IP_ECN) ||
++ (mf->id == MFF_IP_TTL))) {
++WC_MASK_FIELD(wc, nw_proto);
++} else if ((fl->dl_type == htons(ETH_TYPE_ARP)) &&
++   ((mf->id == MFF_ARP_OP) ||
++(mf->id == MFF_ARP_SHA) ||
++   

Bug#1034514: python3-fastimport: "git" missing from description

[Jakub Wilk]

Package: python3-fastimport
Version: 0.9.14-2.1

Please mention "git" somewhere in the package description.

--
Jakub Wilk

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: tags -1 patch

On 07/04/2023 at 01:05, I wrote:


Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the 
pipeline, and restore it when running install_firmware_pkg.


Here is another patch for hw-detect moving the install_firmware_pkg() 
call outside the pipeline instead of playing with file descriptors.


PS: shouldn't this bug report be reassigned to hw-detect ?From 5186662ea53ff694ba3fc841f623a521c9091d54 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Mon, 17 Apr 2023 15:16:20 +0200
Subject: [PATCH] check-missing-firmware: Fix firmware license acceptance

The standard input of a command run within a pipeline is redirected,
which disrupts debconf. So move the install_firmware_pkg() call out
of the pipeline, else the debconf dialog is not displayed when the
firmware package preinst script requires a license acceptance.
---
 check-missing-firmware.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 5db0e180..5ea194d7 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -318,18 +318,32 @@ install_firmware_pkg () {
 # This does not use anna because debs can have arbitrary
 # dependencies, which anna might try to install.
 check_for_firmware() {
+	# any non-space character which is not a shell pattern meta-character * ? ! [ ]
+	# and cannot be part of a component name a-z - will do as a delimiter
+	local delim="^"
+	local list item dir fw_file fw_pkg_file component filename
+
 	echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
 	for dir in $@; do
 		# An index file might exist, mapping firmware files to firmware
 		# packages, saving us from iterating over each firmware *.deb:
 		if [ -f $dir/Contents-firmware ]; then
 			log "lookup with $dir/Contents-firmware"
+			# environment modification in a pipeline is not persistent, so use stdout
+			list=$(\
 			grep -f /tmp/grepfor $dir/Contents-firmware | while read fw_file fw_pkg_file component; do
+echo $fw_pkg_file$delim$component
+			done)
+			# do not call install_firmware_pkg() inside a pipeline because stdin is redirected,
+			# it disrupts debconf in the package preinst script if license agreement is required
+			for item in $(echo $list); do
+fw_pkg_file=${item%$delim*}
 # Don't install a package for each file it ships!
 if grep -qs "^$fw_pkg_file$" /tmp/pkginstalled 2>/dev/null; then
 	continue
 fi
 if check_deb_arch "$dir/$fw_pkg_file"; then
+	component=${item##*$delim}
 	log "installing firmware package $dir/$fw_pkg_file ($component)"
 	install_firmware_pkg "$dir/$fw_pkg_file" "$component" || true
 	echo "$fw_pkg_file" >> /tmp/pkginstalled
-- 
2.30.2

Bug#1034513: tinyssh: autopkgtest creates ~/.ssh/authorized_keys with wrong permission (depending on default umask)

[Lukas Märdian]

Package: tinyssh
Version: 20230101-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Hello Jan,

This package has been failing in Ubuntu for at least a year, skipping many new
(upstream) versions in -proposed. Its -proposed version broke many systemd
autopkgtest (and probably others), leading to unnecessary test runs to validate
those failures with tinyssh from -release.

Ubuntu's PAM configuration sets the user-session default umask to 0002 (instead
of the traditional 0022), as defined in "/etc/login.defs" via USERGROUPS_ENAB
(see /etc/pam.d/common-session*). Therefore, the autopkgtest (re-)creates
~/.ssh/authorized_keys with group-write permissions, which makes tinysshd reject
connections.

The issue does not directly affect Debian currently (due to using a 0022
default umask), but it could in the future, should Debian switch to using
the pam_umask.so module as done in Ubuntu (see [1] for reference).
IMHO the test should create the authorized_key file with correct permissions
in all cases, to make it work in any context, but feel free to reject this
patch if you feel like it doesn't apply.


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

  * d/tests: Create ~/.ssh/authorized_keys with proper umask (LP: #2016597)


Thanks for considering the patch.

-- Lukas


[1] https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096


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

Kernel: Linux 5.19.0-38-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tinyssh-20230101/debian/tests/05authorizedkeys 
tinyssh-20230101/debian/tests/05authorizedkeys
--- tinyssh-20230101/debian/tests/05authorizedkeys  2023-01-01 
09:33:58.0 +0100
+++ tinyssh-20230101/debian/tests/05authorizedkeys  2023-04-17 
15:09:51.0 +0200
@@ -51,6 +54,9 @@
 KEY=`cut -d ' ' -f2 < ~/.ssh/id_ed25519.pub`
 REST=`cut -d ' ' -f3- < ~/.ssh/id_ed25519.pub`
 
+# Create ~/.ssh/authorized_keys with proper permissions/umask (LP: #2016597)
+UMASK=$(umask)
+umask 22
 # now create malformed lines in authorization_keys
 # login MUST FAIL
 (
@@ -85,6 +91,7 @@
 
 # now add correct line to authorized_keys
 echo "${KEYTYPE} ${KEY}" >> ~/.ssh/authorized_keys
+umask $UMASK  # restore original umask
 
 ssh -p 1 127.0.0.1 'exit 0'
 exitcode=$?

Bug#370584: closed by Andreas Beckmann (lynx-cur-wrapper has been removed from Debian)

[Dan Jacobson]

Perhaps most are also applicable to the current lynx package.

Bug#1034512: tinyssh: Flaky testfailures on slow testbeds, due to tcpserver launching in the background

[Lukas Märdian]

Package: tinyssh
Version: 20230101-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Hello Jan,

on slower testbeds (like ppc64el or s390x) we can sometimes observer flaky test
failures, especially of "03exitcodes" and "04ftpd", that fail with a "Host key
verification failed." message, e.g.:
https://ci.debian.net/data/autopkgtest/testing/s390x/t/tinyssh/32945714/log.gz


This is due to the test launching "tcpserver", which launches "tinysshd" and
that one launches a subcommand (e.g. "ftpd") in the background. On slower
testbeds (mostly s390x and ppc64el ) this chain of commands leads to flaky
failures, due to the subcommand not being ready, when the test commands started
execution. I fix that by introducing a small delay ("sleep 1") after launching
"tcpserver", as done in the corresponding Python based testcase ("02handshake").

In Ubuntu, the attached patch was applied to achieve the following:
  * d/tests: Avoid flaky failures on slow testbeds


Thanks for considering the patch.

-- Lukas


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

Kernel: Linux 5.19.0-38-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tinyssh-20230101/debian/tests/03exitcodes 
tinyssh-20230101/debian/tests/03exitcodes
--- tinyssh-20230101/debian/tests/03exitcodes   2023-01-01 09:33:58.0 
+0100
+++ tinyssh-20230101/debian/tests/03exitcodes   2023-04-17 15:09:51.0 
+0200
@@ -22,6 +22,9 @@
 tinysshd-makekey -q sshkeydir
 tcpserver -HRDl0 127.0.0.1 1 tinysshd -- sshkeydir 2>tinysshd.log &
 tcpserverpid=$!
+# Give some extra time for tcpserver to start,
+# to avoid flaky test failures on slower testbeds
+sleep 1
 
 cleanup() {
   ex=$?
diff -Nru tinyssh-20230101/debian/tests/04sftp 
tinyssh-20230101/debian/tests/04sftp
--- tinyssh-20230101/debian/tests/04sftp2023-01-01 09:33:58.0 
+0100
+++ tinyssh-20230101/debian/tests/04sftp2023-04-17 15:09:51.0 
+0200
@@ -22,6 +22,9 @@
 tinysshd-makekey -q sshkeydir
 tcpserver -HRDl0 127.0.0.1 1 tinysshd -x sftp=/usr/lib/openssh/sftp-server 
-- sshkeydir 2>tinysshd.log &
 tcpserverpid=$!
+# Give some extra time for tcpserver to start,
+# to avoid flaky test failures on slower testbeds
+sleep 1
 
 cleanup() {
   ex=$?
diff -Nru tinyssh-20230101/debian/tests/05authorizedkeys 
tinyssh-20230101/debian/tests/05authorizedkeys
--- tinyssh-20230101/debian/tests/05authorizedkeys  2023-01-01 
09:33:58.0 +0100
+++ tinyssh-20230101/debian/tests/05authorizedkeys  2023-04-17 
15:09:51.0 +0200
@@ -21,6 +21,9 @@
 tinysshd-makekey -q sshkeydir
 tcpserver -HRDl0 127.0.0.1 1 tinysshd -- sshkeydir 2>tinysshd.log &
 tcpserverpid=$!
+# Give some extra time for tcpserver to start,
+# to avoid flaky test failures on slower testbeds
+sleep 1
 
 cleanup() {
   ex=$?
diff -Nru tinyssh-20230101/debian/tests/06transfer 
tinyssh-20230101/debian/tests/06transfer
--- tinyssh-20230101/debian/tests/06transfer2023-01-01 09:33:58.0 
+0100
+++ tinyssh-20230101/debian/tests/06transfer2023-04-17 15:09:51.0 
+0200
@@ -22,6 +22,9 @@
 tinysshd-makekey -q sshkeydir
 tcpserver -HRDl0 127.0.0.1 1 tinysshd -- sshkeydir 2>tinysshd.log &
 tcpserverpid=$!
+# Give some extra time for tcpserver to start,
+# to avoid flaky test failures on slower testbeds
+sleep 1
 
 cleanup() {
   ex=$?
diff -Nru tinyssh-20230101/debian/tests/07kex 
tinyssh-20230101/debian/tests/07kex
--- tinyssh-20230101/debian/tests/07kex 2023-01-01 09:33:58.0 +0100
+++ tinyssh-20230101/debian/tests/07kex 2023-04-17 15:09:51.0 +0200
@@ -21,6 +21,9 @@
 tinysshd-makekey -q sshkeydir
 tcpserver -HRDl0 127.0.0.1 1 tinysshd -- sshkeydir 2>tinysshd.log &
 tcpserverpid=$!
+# Give some extra time for tcpserver to start,
+# to avoid flaky test failures on slower testbeds
+sleep 1
 
 cleanup() {
   ex=$?

Bug#1023820: Re#1023820 hdf5: Dependencies not tight enough

[Drew Parsons]

reassign 1023820 src:hdf5
retitle 1023820 hdf5: Dependencies not tight enough
affects 1023820 python3-h5py
thanks

Bug#1023820 reported a failure in h5py:


import h5py

...
ImportError: /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103: version 
`HDF5_SERIAL_1.10.7' not found (required by 
/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/defs.cpython-310-x86_64-linux-gnu.so)


Current hdf5 is 1.10.8+repack1-1, and current libhdf5_serial.so.103 
provides HDF5_SERIAL_1.10.7 and HDF5_SERIAL_1.10.8 (and older symbols), 
so the error should not be ongoing. The user just needs to update to the 
version of hdf5 that h5py was build against.


But I think there is scope for hdf5 to tighten its dependency 
declaration as requested by the bug submitter.


Currently dpkg-shlibdeps (dh_shlibdeps) finds Depends: libhdf5-103-1 for 
hdf5 serial.  Given the issue reported here with missing HDF5_SERIAL_* 
symbols, the dependency should be versioned,

  Depends: libhdf5-103-1 (>= 1.10.8)
with the version number automated as needed

Actually hdf5 is already partly doing this.  The h5py MPI build already 
got Depends: libhdf5-openmpi-103-1 (>= 1.10.7).  It looks like the logic 
that's in place for hdf5-mpi needs to be propagated to hdf5-serial.


Checking the hdf5's debian/rules and the documentation for 
dh_makeshlibs, it looks like it might be enough to replace

  dh_makeshlibs -- -v$(libversion)
in override_dh_makeshlibs with
  dh_makeshlibs -VUpstream-Version -- -v$(libversion)

Or maybe the versioned dependency needs to be written into 
debian/libhdf5-cpp-103-1.symbols, perhaps via #MINVER# as done with 
libhdf5-openmpi-103-1.symbols

Bug#1034363: firefox: Non-default fonts no longer work

[Christian Marillat]

On 17 avril 2023 15:54, Thomas Schwinge  wrote:

> Hi!
>
> I too temporarily forced 'browser.display.use_document_fonts' to '0' in
> order to work around this issue, with Debian unstable firefox 112.0-1.
>
>
> I suppose it is 
> "Text becomes transparent on various sites, e.g. when a webfont" that
> we're running into?  "Opened 4 days ago" -- "Closed 2 days ago", so a
> patch appears to be available.

Patch is here :

https://phabricator.services.mozilla.com/rMOZILLACENTRALe05a8b4d30658a19e60a8cd13874e7beffed750a

main URL https://phabricator.services.mozilla.com/D175391

Christian

Bug#1034363: firefox: Non-default fonts no longer work

[Thomas Schwinge]

Hi!

I too temporarily forced 'browser.display.use_document_fonts' to '0' in
order to work around this issue, with Debian unstable firefox 112.0-1.


I suppose it is 
"Text becomes transparent on various sites, e.g. when a webfont" that
we're running into?  "Opened 4 days ago" -- "Closed 2 days ago", so a
patch appears to be available.


Grüße
 Thomas

Bug#1034360: ITP: supersonic -- A lightweight cross-platform desktop client for Subsonic music servers

[Antoine Beaupré]

retitle 1034360 RFP: supersonic -- A lightweight cross-platform desktop client 
for Subsonic music servers
thanks

The dependency tree on this is just too deep. Until Fyne, at least, is
packaged, I'm not going to look at this. It should also be noted that
Supersonic uses a *fork* of Fyne too... Some of the patches have been
submitted upstream so hopefully that will resolve, but that also makes
packaging this quite impractical.

For now, I've made a Flatpak which is awaiting approval on Flathub:

https://github.com/flathub/flathub/pull/4073

Bug#1033755: heimdal: CVE-2022-3116

[Salvatore Bonaccorso]

Hi Brian,

On Mon, Apr 10, 2023 at 02:54:42PM +0200, Salvatore Bonaccorso wrote:
> On Sat, Apr 08, 2023 at 01:44:33PM +0200, Salvatore Bonaccorso wrote:
> > Hi Brian,
> > 
> > On Sat, Apr 08, 2023 at 07:56:55PM +1000, Brian May wrote:
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Version: 7.8.git20221117.28daf24+dfsg-1.1
> > > 
> > > Are you sure this applies to the unstable version?
> > > 
> > > I can only find one out of two chunks in the patch. Maybe it was already
> > > fixed in the stable branch which we use for unstable?
> > 
> > I *was* almost sure this was only fixed in the master branch of
> > Heimdal and was not in 7.7.0 as well, and 7.8 does not seem to have
> > the change applied as well. 
> > 
> > But I will double-check again.
> > 
> > https://www.kb.cert.org/vuls/id/730793 contains some more information
> > and some distributions like Ubuntu did cherry pick the fix as well in
> > their respective 7.7.0 and 7.5.0 based versions.
> 
> Here is what ubuntu has backported for the older series, for 7.7.0
> https://launchpadlibrarian.net/628258298/heimdal_7.7.0+dfsg-1ubuntu1_7.7.0+dfsg-1ubuntu1.1.diff.gz
> and for 7.5.0 it is included in
> https://launchpadlibrarian.net/628240960/heimdal_7.5.0+dfsg-1_7.5.0+dfsg-1ubuntu0.1.diff.gz
> and the change for spnego/accept_sec_context.c still applies to the
> version in unstable.
> 
> The upstream code was refactored in master branch of upstream project,
> but the underlying issue seems what is touched there.
> 
> Unfortunately I have no further information available on the heimdal
> issue, still it might be worth getting this fixed via unstable in
> bookworm.
> 
> Let me know what you think, Brian.

I made the following change to the security-tracker metadata:

https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/99013142d2f81b3c821be4c6683e7157615977e2

The reason behind that is I think we should consider CVE-2022-3116 and
CVE-2021-44758 different issues, I'm not completely sure, but
CVE-2021-44758 was analogeous dealing with the code.

Regards,
Salvatore

Bug#1034511: apt-cacher-ng: Cron job does not delete old log.html.xz files

[richardn]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: normal
X-Debbugs-Cc: richard...@gmail.com

This line in the apt-cacher-ng daily cron job does not actually delete any 
'maint_*.log.html.xz' files

find /var/log/apt-cacher-ng -maxdepth 1 -name 'maint_*.log.html.xz' -or 
-name 'maint_*.log.html' -type f -user apt-cacher-ng -mtime +10 -delete

The find manpage under NON-BUGS "Operator precedence surprises" explains why 
this does not work.

Brackets with quotes are needed e.g.

find /var/log/apt-cacher-ng -maxdepth 1 \( -name 'maint_*.log.html.xz' 
-or -name 'maint_*.log.html' \) -type f -user apt-cacher-ng -mtime +10 -delete

Alternatively the " -or -name 'maint_*.log.html'" can be completely omitted, 
leaving

find /var/log/apt-cacher-ng -maxdepth 1 -name 'maint_*.log.html.xz' 
-type f -user apt-cacher-ng -mtime +10 -delete

as the next line in the cron job compresses all 'maint_*.log.html' files older 
than 5 days anyway


-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.132
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.21
ii  libbz2-1.0 1.0.8-5+b1
ii  libc-ares2 1.18.1-2
ii  libc6  2.36-8
ii  libevent-2.1-7 2.1.12-stable-8
ii  libevent-pthreads-2.1-72.1.12-stable-8
ii  libfuse2   2.9.9-6+b1
ii  libgcc-s1  12.2.0-14
ii  liblzma5   5.4.1-0.2
ii  libssl33.0.8-1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.6-1
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20230311

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-9
pn  doc-base  

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/port: keep
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/gentargetmode: No automated setup
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/cachedir: keep

Bug#1034510: bullseye-pu: package protobuf/3.12.4-1+deb11u1

[Helmut Grohne]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: proto...@packages.debian.org, g...@debian.org, 
debian-secur...@lists.debian.org
Control: affects -1 + src:protobuf

[ Reason ]

This update aims to fix three vulnerabilities in the protobuf package:

 * Fix CVE-2021-22569 (DoS in Java)
 * Fix CVE-2021-22570 (NULL pointer dereference)
 * Fix CVE-2022-1941 (memory DoS)

[ Impact ]

Ideally, a user wouldn't notice anything changed.

[ Tests ]

Testing was accidentally disabled in bullseye. See #1033989. This upload
re-enables testing. The patch for CVE-2022-1941 extends the test suite.

[ Risks ]

All of the patches deviate significantly from their respective upstream
commits. In case of CVE-2021-22569 and CVE-2022-1941, significant
porting was required. In case of CVE-2021-22570, the relevant change was
buried in a large commit. There definitely is a risk involved here. I do
appreciate a review of these patches.

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

[ Changes ]

Beyond fixing the vulnerabilities (see Reason section), this upload also
re-enables running tests during build.

Helmut
diff --minimal -Nru protobuf-3.12.4/debian/changelog 
protobuf-3.12.4/debian/changelog
--- protobuf-3.12.4/debian/changelog2021-01-16 23:12:54.0 +0100
+++ protobuf-3.12.4/debian/changelog2023-04-04 11:41:41.0 +0200
@@ -1,3 +1,13 @@
+protobuf (3.12.4-1+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Reenable test suite (Closes: #1033989)
+  * Fix CVE-2021-22569 (DoS in Java)
+  * Fix CVE-2021-22570 (NULL pointer dereference)
+  * Fix CVE-2022-1941 (memory DoS)
+
+ -- Helmut Grohne   Tue, 04 Apr 2023 11:41:41 +0200
+
 protobuf (3.12.4-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru protobuf-3.12.4/debian/elpa-test 
protobuf-3.12.4/debian/elpa-test
--- protobuf-3.12.4/debian/elpa-test1970-01-01 01:00:00.0 +0100
+++ protobuf-3.12.4/debian/elpa-test2023-04-04 11:41:41.0 +0200
@@ -0,0 +1 @@
+disable=please_run_dh_auto_test
diff --minimal -Nru protobuf-3.12.4/debian/patches/CVE-2021-22569.patch 
protobuf-3.12.4/debian/patches/CVE-2021-22569.patch
--- protobuf-3.12.4/debian/patches/CVE-2021-22569.patch 1970-01-01 
01:00:00.0 +0100
+++ protobuf-3.12.4/debian/patches/CVE-2021-22569.patch 2023-04-04 
11:41:41.0 +0200
@@ -0,0 +1,482 @@
+From 9638a5e5315bf73f5e7148c16181676372321892 Mon Sep 17 00:00:00 2001
+From: Adam Cozzette 
+Date: Wed, 5 Jan 2022 08:50:29 -0800
+Subject: [PATCH] Improve performance of parsing unknown fields in Java (#9371)
+
+Credit should go to @elharo for most of these Java changes--I am just
+cherry-picking them from our internal codebase. The one thing I did
+change was to give the UTF-8 validation tests their own Bazel test
+target. This makes it possible to give the other tests a shorter
+timeout, which is important for UnknownFieldSetPerformanceTest in
+particular.
+---
+ Makefile.am   |   1 +
+ java/core/BUILD   |  24 +-
+ .../com/google/protobuf/UnknownFieldSet.java  | 427 +-
+ .../UnknownFieldSetPerformanceTest.java   |  78 
+ .../google/protobuf/UnknownFieldSetTest.java  | 182 +++-
+ java/lite/pom.xml |   1 +
+ 6 files changed, 499 insertions(+), 214 deletions(-)
+ create mode 100644 
java/core/src/test/java/com/google/protobuf/UnknownFieldSetPerformanceTest.java
+
+Backport:
+ * Drop bazel BUILD file changes as Debian builds using ant
+ * Drop test cases as Debian does not run them
+ * Drop unnecessary de-finalization
+ * Drop unnecessary diamonds conversion
+
+diff --git a/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java 
b/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
+index ba2f9df08..5c482d62d 100644
+--- a/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
 b/java/core/src/main/java/com/google/protobuf/UnknownFieldSet.java
+@@ -43,13 +43,13 @@ import java.util.Map;
+ import java.util.TreeMap;
+ 
+ /**
+- * {@code UnknownFieldSet} is used to keep track of fields which were seen 
when parsing a protocol
++ * {@code UnknownFieldSet} keeps track of fields which were seen when parsing 
a protocol
+  * message but whose field numbers or types are unrecognized. This most 
frequently occurs when new
+  * fields are added to a message type and then messages containing those 
fields are read by old
+  * software that was compiled before the new types were added.
+  *
+  * Every {@link Message} contains an {@code UnknownFieldSet} (and every 
{@link Message.Builder}
+- * contains an {@link Builder}).
++ * contains a {@link Builder}).
+  *
+  * Most users will never need to use th

Bug#1028615: tracker.debian.org: tracker.d.o should display results of reproducible rebuilds, not just reproducible CI results

[Raphael Hertzog]

Hello Holger,

On Fri, 14 Apr 2023, Holger Levsen wrote:
> On Fri, Jan 13, 2023 at 06:49:48PM +0100, Holger Levsen wrote:
> > since some years, tracker.d.o is thankfully showing results from
> > https://tests.reproducible-builds.org/debian - which was and is awesome!
> > However, these are just continious integration test results and
> > not based on the binaries we publish on ftp.debian.org
> [...]
> > The data is available in json format here:
> > - https://rebuild.notset.fr/debian/results/debian_unstable.json
> > - https://rebuild.notset.fr/debian/results/debian_bookworm.json
> > - https://rebuild.notset.fr/debian/results/debian_bullseye.json
> > It would be great, if tracker.d.o could display both kind of results, CI 
> > *and*
> > rebuild results.
> 
> friendly ping on this. Also if there's anything we can do...!?!

My bandwidth for tracker.debian.org is quite limited and it seems unlikely
that I will tackle this on my own. That said the codebase is rather
sane and it should not be too hard for someone else to implement this...

It has even become much simpler since I implemented the ImportExternalData
mixin that makes it easy to download json and create action items (cf
181db12111b35f9f54e5ed07654d34cff604feb3 as an example).

I would suggest to only import the data from unstable, or at least to
only generate action items for packages in unstable. 

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1034494: unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound

[Simon Deziel]

When managed by systemd, unbound is started with the "-p" argument that 
tells it to not create a PID file at all. I don't know what use you have 
for the PID but you can obtain it with:


> systemctl show --property MainPID --value unbound

That's of course assuming unbound is managed by systemd.

HTH,
Simon

Bug#1034509: darktable: Crashes when scrolling through a collection

[Michael Below]

Package: darktable
Version: 4.2.1-4
Severity: normal
X-Debbugs-Cc: be...@judiz.de

Dear Maintainer,

I imported a collection of about 400 Fuji E4 RAW images (.RAF). I was able to 
go through all images for a first cull. Now I want to edit the remaining 
images. When I reach about half of the remaining collection darktable crashes 
while generating previews in the lightroom view. On the command line, I get 
“Speicherzugriffsfehler darktable” (memory access error).

I tried running darktable with the -d cache argument, then I get a lot of 
output like “generate mip 3 for image 7279 from scratch”. But there is no 
indication why it crashes.

I was able to import the directory with the collection in shotwell without 
crashing, it shows thumbnails for all 400something images. Other collections 
with a similar number of images do not show the issue.

Any ideas what to try next?

Thanks for your work!

Cheers
Michael

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

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

Versions of packages darktable depends on:
ii  libavif150.11.1-1
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcolord-gtk1   0.3.0-3
ii  libcolord2   1.4.6-2.2
ii  libcups2 2.4.2-3
ii  libcurl3-gnutls  7.88.1-8
ii  libexiv2-27  0.27.6-1
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgomp1 12.2.0-14
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.40-2
ii  libgtk-3-0   3.24.37-2
ii  libheif1 1.15.1-1
ii  libicu72 72.1-3
ii  libimath-3-1-29  3.1.6-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblensfun1  0.3.3-1
ii  liblua5.4-0  5.4.4-3
ii  libopenexr-3-1-303.1.5-4
ii  libopenjp2-7 2.5.0-1+b1
ii  libosmgpsmap-1.0-1   1.2.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libportmidi0 1:217-6.1
ii  libpugixml1v51.13-0.2
ii  librsvg2-2   2.54.5+dfsg-1
ii  libsdl2-2.0-02.26.4+dfsg-1
ii  libsecret-1-00.20.5-3
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.40.1-2
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-5
ii  libwebp7 1.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libx11-6 2:1.8.4-2
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxrandr2   2:1.5.2-2+b1
ii  zlib1g   1:1.2.13.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#1034508: unblock: sdop/0.90-2

[Bastian Germann]

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

Please unblock package sdop.

[ Reason ]
The fix for RC bug #1034080 is in the unstable version.

[ Impact ]
The package and its reverse dependencies will be autoremoved from testing if 
not unblocked.

[ Tests ]
Building the package twice in a row.

[ Risks ]
None.

[ 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 sdop/0.90-2diff -Nru sdop-0.90/debian/changelog sdop-0.90/debian/changelog
--- sdop-0.90/debian/changelog  2020-08-30 08:15:40.0 +0200
+++ sdop-0.90/debian/changelog  2023-04-08 18:19:00.0 +0200
@@ -1,3 +1,10 @@
+sdop (0.90-2) unstable; urgency=medium
+
+  * 30_fix-dh_auto_clean.diff: Fix failure to build from source twice in a
+row. Closes: #1034080
+
+ -- Andreas Metzler   Sat, 08 Apr 2023 18:19:00 +0200
+
 sdop (0.90-1) unstable; urgency=low
 
   * Fix watchfile.
diff -Nru sdop-0.90/debian/patches/30_fix-dh_auto_clean.diff 
sdop-0.90/debian/patches/30_fix-dh_auto_clean.diff
--- sdop-0.90/debian/patches/30_fix-dh_auto_clean.diff  1970-01-01 
01:00:00.0 +0100
+++ sdop-0.90/debian/patches/30_fix-dh_auto_clean.diff  2023-04-08 
18:18:36.0 +0200
@@ -0,0 +1,26 @@
+Description: Avoid dh_auto_clean breakage
+ dh_auto_clean uses "make -n" to check whether the distclean target is
+ available.
+ Having $(MAKE) in a recipe make -n a noop, i.e. the recipe is executed
+ when testing for the target existence and the actual effective later call
+ would fail.
+Author: Andreas Metzler 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1034080
+Forwarded: no
+Last-Update: 2023-04-08
+
+--- sdop-1.00.orig/Makefile.in
 sdop-1.00/Makefile.in
+@@ -50,8 +50,9 @@ build:; @cd src; $(MAKE) all \
+ 
+ clean:; cd src; $(MAKE) clean
+ 
+-distclean:; rm Makefile config.cache config.log config.status; \
+-cd src; $(MAKE) clean
++distclean:
++  rm -f Makefile config.cache config.log config.status
++  cd src && $(MAKE) clean
+ 
+ test:   build
+   cd testing; ./runtest
diff -Nru sdop-0.90/debian/patches/series sdop-0.90/debian/patches/series
--- sdop-0.90/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ sdop-0.90/debian/patches/series 2023-04-08 18:19:00.0 +0200
@@ -0,0 +1 @@
+30_fix-dh_auto_clean.diff

Bug#1024523: yad packaging

[grin]

I have created https://github.com/v1cont/yad/pull/233 in the upstream repo, it 
packages yad just fine to current (12.3).

Peter

Bug#1024523: yad packaging

[grin]

Hello Alexis,

Any success in updating yad? 
Were there any actual problems or this just faded out into oblivion?
Is there any problem in packaging it?
Do you need any help?

Thanks
Peter

Bug#1034504: diffoscope: Wrong binary called for the Procyon Java decompiler

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Mon, Apr 17, 2023 at 11:47:24AM +0200, Emmanuel Bourg wrote:
> diffoscope recommends procyon-decompiler, but calls the wrong binary.
> The procyon-decompiler package installs /usr/bin/procyon, and diffoscope
> calls 'procyon-decompiler' instead of 'procyon'.
> 
> This issue was reported on StackOverflow:
> https://stackoverflow.com/questions/51216673/how-to-use-procyon-decompiler-with-diffoscope

That stackoverflow post is from 4 years ago, and current diffoscope
(since v104) calls "p"ocyon", not "procyon-decompiler":

https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/d7ec9965e12efb76d88b8423cebccc59f53118d8


Can you please give us more informations on what you are experiencing,
or are you just notifying us of that stackoverflow post?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Andreas Beckmann]

Followup-For: Bug #969907
Control: tag -1 patch

https://salsa.debian.org/freedesktop-team/poppler/-/merge_requests/14
https://salsa.debian.org/multimedia-team/inkscape/-/merge_requests/4

Andreas

Bug#1034507: ITP: torctl -- Redirect all traffic through tor network

[Danial Behzadi]

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

* Package name: torctl
  Version : 0.5.7
  Upstream Contact: BlackArch
* URL : https://github.com/BlackArch/torctl
* License : GPL-3+
  Programming Lang: Bash
  Description : Redirect all traffic through tor network

Script to redirect all traffic through tor network including dns queries
for anonymizing entire system.

Bug#1033570: unblock: kdenlive/22.12.3-2

[Patrick Matthäi]

Am 15.04.2023 um 21:51 schrieb Paul Gevers:

Control: tags -1 confirmed

Hi Patrick,

Thanks.

On 14-04-2023 10:45, Patrick Matthäi wrote:
You may have guessed from the silence (see also our FAQ [1]) that 
we're not enthusiastic about mlt. I'm currently leaning towards the 
tpu route for kdenlive.


Please upload the version you have in unstable to 
testing-proposed-uploads with only an added changelog entry. I prefer 
a +deb12u1 version bump (because that will automatically be synced to 
unstable), but I can live with ~deb12u1 too if you prefer that.


Paul


Thank you, I have uploaded it :)

PS: It works better with testing-proposed-updates instead of 
testing-proposed-uploads :D

Bug#1034496: ITP: linux-board-support-package-rb5 -- Firmware for RB5

[Dmitry Baryshkov]

On Mon, 17 Apr 2023 at 03:18, Roger Shimizu  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Roger Shimizu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: linux-board-support-package-rb5
>   Version : 20210901-v6
>   Upstream Author : Linaro
> * URL : https://releases.linaro.org/96boards/rb5/qualcomm/firmware
> * License : non-free
>   Description : Firmware for RB5
>
>  This package contains the binary firmware for the SM8250, which is the
>  main SoC on the Robotics RB5.

As I wrote in the https://bugs.debian.org/1034495 discussion, most if
not all firmware files relevant to the board are a part of the
linux-firmware package already. If the intent is to provide additional
files (e.g. bootloader), please describe your usecases and the
intended layout.


-- 
With best wishes
Dmitry

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Dmitry Baryshkov]

On Mon, 17 Apr 2023 at 03:09, Roger Shimizu  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Roger Shimizu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: linux-board-support-package-dragonboard845c
>   Version : 20190529180356-v4
>   Upstream Author : Linaro
> * URL : 
> https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware
> * License : non-free
>   Description : Firmware for dragonboard845c / RB3
>
>  This package contains the binary firmware for GPU, USB, DSP hardware
>  coprocessors found on SDM845, which is the main SoC on the
>  Dragonboard 845c / RB3.

Generally, I think there is some misunderstanding here. Most of the
firmware has been pushed to linux-firmware already (where possible).
You probably have some other intentions here. If so, please describe them.

I took a glance at the package sources on salsa. So, let's go at this
one by one.

firmware-qcom-dragonboard845c.install:

[0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845

This is the file that is only used by the _host_ when programming the
device. As such, it should not be a part of the en-device firmware. It
has no use for the RB3 itself.

[0-9]*/aop.mbn lib/firmware/qcom/sdm845

Bootloader. It should not be a part of /lib/firmware/

[0-9]*/BTFM.bin lib/firmware/qcom/sdm845

This is the filesystem image with bluetooth firmware files. Relevant
files are already part of the /lib/firmware/qca. If anything important
is missing there, it should directly into

[0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845
[0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845
[0-9]*/devcfg.mbn lib/firmware/qcom/sdm845

These three files are also used by the bootloader process, and as such
they should not be a part of /lib/firmware.

[0-9]*/dspso.bin lib/firmware/qcom/sdm845

This is probably the only important file for now. This is the
filesystem image with the shared libraries and executable code for the
DSPs when executing compute applications there.
We were putting it to /lib/firmware/qcom/sdm845 and mounting it later,
because it was easier to do so (if the image is not present in
/lib/firmware, the rootfs can try mounting dspso parition). For proper
Debian packaging the image should be unpacked to some agreed location.
fastrpc daemons then should be taught about this location.

[0-9]*/hyp.mbn lib/firmware/qcom/sdm845
[0-9]*/imagefv.elf lib/firmware/qcom/sdm845
[0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845
[0-9]*/sec.dat lib/firmware/qcom/sdm845
[0-9]*/storsec.mbn lib/firmware/qcom/sdm845
[0-9]*/tz.mbn lib/firmware/qcom/sdm845
[0-9]*/xbl.elf lib/firmware/qcom/sdm845
[0-9]*/xbl_config.elf lib/firmware/qcom/sdm845
[0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845

Again, mostly bootloader stuff. I highly doubt that /lib/firmware
should be polluted with these files.

renesas_usb_fw.mem lib/firmware

So, this is the Renesas firmware, which gets copyrighted by Qualcomm.
We noticed this some time ago (and the fact that the supplier of the
firmware, Thundercomm, also pulled the file without having a clear
origin). We have been trying to clear licensing terms for this file,
however Renesas is unresponsive. Originally this file came from the
author (Renesas) without proper license. Thus I do not believe it
passes required checks by ftpmasters.

linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp
linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux

I don't know what this is, but judging from the name (ABL) it also
should not be part of /lib/firmware. Especially the AOSP file.

Next package:
network-manager-config-dragonboard845c.install

debian/eth-mac-addr.conf usr/lib/NetworkManager/conf.d/

I do not think this should be a part of the
firmware-qcom-dragonboard845c source package. It is not a firmware.

> If you have any concerns, or you can offer co-maintenance of the package in 
> Debian, please let me know.

Well, I'd like to understand your intentions with this package. Please
feel free to ask any questions regarding these files or about
packaging them.

-- 
With best wishes
Dmitry

Bug#1034506: Request to enable CONFIG_HSR as module

[Yoann Congal]

Source: linux
Severity: wishlist
Tags: newcomer patch
X-Debbugs-Cc: yoann.con...@smile.fr

Hi maintainers,

HSR (High-availability Seamless Redundancy) and PRP (Parallel Redundancy
Protocol) are two network protocols used in environment where network
node failure should not trigger a frame loss. Both provide seamless
failover against this kind of failure.

Both of these are enabled in kernel by CONFIG_HSR which is currently
disabled.

HSR and PRP are defined in IEC 62439-3:2016 and used in many industrial
standards (in our case, IEC 61850 about connected systems in electrical
substations)

This module is handled by iproute2 since 5.10 (available in bullseye).

I've already created a merge-request for this request : 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/682

Thank you for considering this request.

Best regards,

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

Kernel: Linux 6.1.0-0.deb11.5-rt-amd64 (SMP w/24 CPU threads; PREEMPT)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 68c1f55713be54ea994cffe051b0db36aa3690ca Mon Sep 17 00:00:00 2001
From: Yoann Congal 
Date: Fri, 17 Mar 2023 14:06:50 +0100
Subject: [PATCH] Enable PRP/HSR protocols in config as module

HSR (High-availability Seamless Redundancy) and PRP (Parallel Redundancy
Protocol) are two network protocols used in environment where network
node failure should not trigger a frame loss. Both provide seamless
failover against this kind of failure.

HSR and PRP are defined in IEC 62439-3:2016 and used in many industrial
standards.

This module is handled by iproute2 since 5.10 (available in bullseye).

Signed-off-by: Yoann Congal 
---
 debian/config/config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/config/config b/debian/config/config
index b4c4ebb7b2..50c8d3d360 100644
--- a/debian/config/config
+++ b/debian/config/config
@@ -7049,7 +7049,7 @@ CONFIG_DNS_RESOLVER=m
 ##
 ## file: net/hsr/Kconfig
 ##
-# CONFIG_HSR is not set
+CONFIG_HSR=m
 
 ##
 ## file: net/ieee802154/Kconfig
-- 
2.30.2

Bug#1033424: Uploaded (Was: image-factory: FTBFS in testing: AssertionError: pylint found issues:)

[Theppitak Karoonboonyanan]

I have uploaded Josef Schneider's NMU to the 3-day DELAYED queue, as
per his request.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/