Bug#1021032: vlc: playing mp4 videos results in a black screen

[Lyndon Brown]

On Mon, 03 Oct 2022 03:07:30 +0100 Lyndon Brown 
wrote:
> I have no idea at this time what the relevant difference is between
> them that's causing this.

Update.

So first of all I wondered whether differences in configure options
could be relevant. Before, I'd just used --disable-skins2. So I rebuilt
the upstream codebase with the following to duplicate much of the
debian package config: ../configure --disable-skins2 --config-cache --
disable-update-check --enable-fast-install --enable-a52 --enable-aa --
enable-aribsub --enable-avahi --enable-bluray --enable-caca --enable-
chromaprint --enable-chromecast --enable-dav1d --enable-dbus --enable-
dca --enable-dvbpsi --enable-dvdnav --enable-faad --enable-flac --
enable-fluidsynth --enable-freetype --enable-fribidi --enable-gles2 --
enable-gnutls --enable-harfbuzz --enable-jack --enable-kate --enable-
libass --enable-libmpeg2 --enable-libxml2 --enable-lirc --enable-mad --
enable-matroska --enable-mod --enable-mpc --enable-mpg123 --enable-mtp
--enable-ncurses --enable-notify --enable-ogg --enable-opus --enable-
pulse --enable-qt --enable-realrtsp --enable-samplerate --enable-sdl-
image --enable-sftp --enable-shine --enable-shout --enable-skins2 --
enable-sndio --enable-soxr --enable-spatialaudio --enable-speex --
enable-srt --enable-svg --enable-svgdec --enable-taglib --enable-theora
--enable-twolame --enable-upnp --enable-vdpau --enable-vnc --enable-
vorbis --enable-x264 --enable-x265 --enable-zvbi --disable-aom --
disable-crystalhd --disable-d3d11va --disable-decklink --disable-
directx --disable-dsm --disable-dxva2 --disable-fdkaac --disable-
fluidlite --disable-freerdp --disable-goom --disable-gst-decode --
disable-libtar --disable-libva --disable-live555 --disable-macosx --
disable-macosx-avfoundation --disable-macosx-qtkit --disable-mfx --
disable-microdns --disable-opencv --disable-projectm --disable-
schroedinger --disable-sparkle --disable-telx --disable-vpx --disable-
vsxu --disable-wasapi

This made no difference; it still worked fine unlike the debian package
rebuild.

So then I wondered about the possible affect of old artefacts within
the build directory of the upstream code build. (It wasn't clean, since
I'd previously used it for VLC dev work). Interestingly, deleting the
build directory to create a fresh start DID make a difference. Using
the same big configure command as above I now encounter the same issue
as the debian package.

This obviously might suggest that the "dirty" build directory contained
a plugin binary from a previous build and this was causing some
difference.

I wondered about your use of --disable-libva and so with that removed
from the above configure command, it was back to working again.

So long story short, the problem would seem to be connected somehow to
your use of --disable-libva.

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi Alberto, Sebastian,

Sebastian Krzyszkowiak wrote on Thu, Sep 29, 2022 at 06:15:56PM +0200:
> the patch that sets setAllowsServerPreconnect does not fix the
> original issue, however, this one does:
> https://github.com/WebKit/WebKit/pull/4790
> 
> With this applied on top of your recent backport of 2.38.0, WebKit
> becomes somewhat usable on arm64 in bullseye. It still crashes on some
> pages (such as Twitter), but in a different way (somewhere in JSC)
> which probably deserves a separate issue.

Thank you for finding this other PR -- I can confirm that fixes the
original issue which crashed almost immediately on any page, and also
confirm there are leftover crashes with a clang build on this patch.

Here's the backtrace I get:
(gdb) bt
#0  codeBlock () at ../Source/JavaScriptCore/interpreter/RegisterInlines.h:41
#1  codeBlock () at ../Source/JavaScriptCore/interpreter/CallFrameInlines.h:62
#2  operationArithNegateProfiledOptimize () at 
../Source/JavaScriptCore/jit/JITOperations.cpp:3361
#3  0x74148358 in ?? ()
#4  0x2ed44080 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

unfortunately it looks like gdb doesn't manage to unwind it properly (or
indeed corrupted), so that might be difficult to debug.

Since gcc build appears to fix the issue I think that's the way to go
for bullseye, at least until we understand where that makes a
difference...

Sebastian Krzyszkowiak wrote on Fri, Sep 30, 2022 at 01:01:55PM +0200:
> I can still see some backtraces showing up in logs due to preconnect
> attempts, so applying PR 4790 will likely still be a good idea, but it
> doesn't bring down the whole process anymore.

I agree on principle; out of curiousity where did you see these logs?
I do not see anything on stdout/stderr with the gcc build, but I would
assume this to be logged elsewhere or perhaps only if some magic env var
is set?

Thanks,
-- 
Dominique

Bug#1017357: simple-scan: Preference dialog shows no window decoration or Apply/OK/Cancel button

[Pascal Martin]

I tried both themes, and SimpleScan is (barely) usable. Here is the
interesting thing: SimpleScan main window's title bar is larger than other
applications, while the preference title bar is very narrow, barely high
enough to show the X button.

I have no such issue with other applications. Could I have a weird
SimpleScan desktop setup?

Thank you for taking the time to look into that bug report.

Pascal.

On Sun, Oct 2, 2022, 03:14 Jörg Frings-Fürst  wrote:

> Hello Martin,
>
> thank you for spending your time helping to make Debian better with
> this bug report.
>
> I think that the described problem is in MATE. The upper window bar is
> there, but it is too small.
>
> In the themes YaruGreen and YaruOk the bar is displayed correctly.
>
> That no buttons are present corresponds to the handling concept.
>
>
> I therefore close this bug.
>
> CU
> Jörg
>
>
> Am Sonntag, dem 14.08.2022 um 12:32 -0700 schrieb Pascal Martin:
> > Package: simple-scan
> > Version: 42.0-1
> > Severity: important
> > X-Debbugs-Cc: pascal.fb.mar...@gmail.com
> >
> > Dear Maintainer,
> >
> > I am trying to set preferences from either the "Scan" left menu or
> > the
> > "Hamburger" right menu. This opens the Preferences dialog, but there
> > is no
> > Window decoration and no Apply, OK or Cancel button visible. The top
> > of the
> > dialog looks like cut. The dialog appears to be modal and I am now
> > stuck: I
> > cannot close the dialog and simple-scan's main window is locked. The
> > only way
> > to exit that I found was to kill simple-scan from a terminal.
> >
> > Please see attached screen dump.
> >
> > I am using the Mate desktop (most packages are version 1.26.0-1,
> > 1.26.1-1 or
> > 1.26.2-1) running the Marco windows manager (1.26.0-2)
> >
> >
> > -- Package-specific info:
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers testing
> >   APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.18.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > LANGUAGE not set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages simple-scan depends on:
> > ii  dbus-user-session [default-dbus-session-bus]  1.14.0-2
> > ii  dbus-x11 [dbus-session-bus]   1.14.0-2
> > ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
> > ii  libc6 2.33-8
> > ii  libcairo2 1.16.0-6
> > ii  libcolord21.4.6-1
> > ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-2
> > ii  libglib2.0-0  2.72.3-1
> > ii  libgtk-3-03.24.34-1
> > ii  libgusb2  0.3.10-1
> > ii  libhandy-1-0  1.7.90-1
> > ii  libpackagekit-glib2-181.2.5-3
> > ii  libsane1  1.1.1-5
> > ii  libwebp7  1.2.2-2+b1
> > ii  libwebpmux3   1.2.2-2+b1
> > ii  xdg-utils 1.1.3-4.1
> > ii  zlib1g1:1.2.11.dfsg-4
> >
> > simple-scan recommends no packages.
> >
> > simple-scan suggests no packages.
> >
> > -- no debconf information
>
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54470 Lieser
>
>
> git:  https://jff.email/cgit/
>
> Threema: SYR8SJXB
> Wire: @joergfringsfuerst
> Skype: joergpenguin
> Ring: jff
> Telegram: @joergfringsfuerst
>
>
> My wish list:
>  - Please send me a picture from the nature at your home.
>
>

Bug#1011482: cgit: Package cgit-pink as a more up-to-date alternative for cgit

[Peter Colberg]

Hi Alejandro, Hi Daniel,

On Mon, May 23, 2022 at 10:44:16PM +0200, Alejandro Colomar wrote:
> Could you please package cgit-pink as an alternative to cgit that
> is well maintained?  cgit development has been stopped for a year
> now.
> 
> cgit-pink: 

Thank you for making me aware of this. Unfortunately, cgit-pink is not
a full-featured replacement for upstream cgit since it removes support
for Lua filters [1]. The commit message states that “Lua support is
unused”, which I don't follow as cgit ships with a collection of Lua
filters, hence Lua support is likely used in some installations.

I will keep this bug open since, while cgit still works for now, this
will change at some point as the git repository layout evolves. In the
meantime, please feel welcome to package cgit-pink in addition to cgit.

If you are aware of specific bugs in cgit that would be worthwhile
patching in Debian, I would be grateful if you could let me know.
At least the Fedora package is carrying a patch to use a newer git
version [2, 3], which might be a consideration for Debian, too.

[1] 
https://git.causal.agency/cgit-pink/commit/?id=d993e4be6731b1a806e2c7588334a3f485a5fd31
[2] 
https://src.fedoraproject.org/rpms/cgit/blob/79170ad8583966d3904879515d9348af459f2cba/f/cgit.spec
[3] https://git.kernel.org/

Thanks,
Peter

Bug#1021158: ITP: mrbuild -- Simple build system

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: mrbuild
  Version : 1.0
  Upstream Author : Dima Kogan 
* URL or Web page : https://github.com/dkogan/mrbuild
* License : MIT
  Description : Simple build system

This is the build system for mrcal, mrgingham and others

Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support

[Olly Betts]

On Sat, Sep 24, 2022 at 09:50:10PM +0100, Olly Betts wrote:
> On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote:
> > wxwidgets and glew disagree over EGL support, glew is built without,
> > wxwidgets (since 3.2) with.
> > 
> > That causes problems (crashes, "Unable to init glew library") in
> > software using glew and wxwidgets. Google finds multiple instances, I
> > know about hugin.

FWIW, these are the packages which seem to depend on both wx and glew
(just based on checking dependencies):

hugin
megaglest
qutemol
scorched3d
darkradiant
limesuite

The last two have already switched to wx3.2 in unstable and testing, but
I don't see reports in the BTS of glew-related problems, and didn't see
any issues from a quick test myself.  At least with darkradiant I did
get what looked like a GL rendered pane to appear - I'm not sure I
actually exercised any GL code with limesuite (it seems to need some
hardware I don't have to be useful).

Cheers,
Olly

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Lyndon Brown]

On Mon, 03 Oct 2022 00:52:41 +0100 Lyndon Brown 
wrote:
> On Mon, 2022-10-03 at 01:24 +0200, Sebastian Ramacher wrote:
> > On 2022-10-03 00:09:25 +0100, Lyndon Brown wrote:
> > > As you can see, mostly minor Qt updates.
> > 
> > But those are the only packages relevant for vlc in your upgrade.
So
> > it's probably Qt breaking vlc … and my test with 3.0.18 rc2 just
> > worked
> > as I built it with the current Qt version in unstable.
> > 
> > Cheers
> 
> Indeed, that's what I'm wondering.
> 
> Note that in the Ubuntu bug report
> (https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1991418) Remi
said
> that he could see the problem in Sid, but failed to reproduce with a
> custom rebuild of VLC.
> 
> I haven't tried a local package rebuild just yet to see if that's all
> that's needed. I may try one shortly unless you beat me to it. Will
be
> great if so.

Hmm, so firstly I started with the upstream 3.0.x branch, at the
3.0.17.3 tagged commit 426513d88e3e3dc671434db8e724ee5d1b7e1038 (not
finding a 3.0.17.4 tag). I cherry-picked two build fixes,
2202c892c8dc1381b596c53c2ebd3ca680061f95 (dav1d) and
b689202d9f1621e82acb0976b6bb31455735a535 (caca). I compiled this
successfully, and it just works, indicating that indeed just a rebuild
is needed.

However, I then rebuilt the debian package itself, and installed all of
the rebuilt versions of every vlc package I had installed, and it still
exhibits the issue. (I used these instructions:
https://www.ducea.com/2008/03/06/howto-recompile-debian-packages/).

I have no idea at this time what the relevant difference is between
them that's causing this.

Bug#869708: Duplicate of #969593?

[Michael van der Kolff]

Hey,

I think this is a dup of the above bug.

Thanks!

--Michael

Bug#1019847: firmware-amd-graphics: missing yellow_carp* firmware for AMD Rembrandt / Ryzen 9 6900HS / Radeon 680M

[Marco d'Itri]

Control: severity -1 important

On Sep 14, Mark Nipper  wrote:

> Similar to #1009618, this simply needs the yellow_carp* firmware
> files from the upstream Git repo to function mostly correctly.
> As of right now, they aren't included.  Without them, no usable
> text or graphical interface starts at boot without nomodeset,
> which isn't an ideal solution either obviously.
On my Lenovo T14s Gen3 AMD this causes the boot process to just hang 
after the "amdgpu: Topology: Add CPU node" message.

I fixed this by copying to my system the files from 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
 .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Lyndon Brown]

On Mon, 2022-10-03 at 01:24 +0200, Sebastian Ramacher wrote:
> On 2022-10-03 00:09:25 +0100, Lyndon Brown wrote:
> > As you can see, mostly minor Qt updates.
> 
> But those are the only packages relevant for vlc in your upgrade. So
> it's probably Qt breaking vlc … and my test with 3.0.18 rc2 just
> worked
> as I built it with the current Qt version in unstable.
> 
> Cheers

Indeed, that's what I'm wondering.

Note that in the Ubuntu bug report
(https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1991418) Remi said
that he could see the problem in Sid, but failed to reproduce with a
custom rebuild of VLC.

I haven't tried a local package rebuild just yet to see if that's all
that's needed. I may try one shortly unless you beat me to it. Will be
great if so.

Bug#1021157: missing firmwares for Qualcomm NFA725A

[Marco d'Itri]

Package: firmware-atheros
Version: 20210818-1
Severity: important

My Lenovo T14s Gen3 AMD laptop has a Qualcomm NFA725A Wi-Fi card (which 
is actually reported by lspci as QCNFA765), which needs some firmwares 
which are not available in the firmware-atheros package or in the 
upstream linux-firmware package.

The card works just fine with a 5.19 kernel after installing these files
in /usr/lib/firmware/ath11k/WCN6855/hw2.0/:
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/amss.bin
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/m3.bin
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/board-2.bin
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/regdb.bin

And then creating a symlink from /usr/lib/firmware/ath11k/WCN6855/hw2.1/ 
to hw2.0/ .

(I do not understand the structure of the directories in 
WCN6855/hw2.0/1.1/, so I choose the newest files.)

Some other firmwares from 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qca
 
are needed for Bluetooth support and are missing as well:

qca/rampatch_usb_00130201.bin
qca/nvm_usb_00130201_gf.bin

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1020698: O: dlocate -- fast alternative to dpkg -L and dpkg -S

[Guillem Jover]

Hi!

[ Sorry, should have CCed Craig, doing that now. ]

On Fri, 2022-09-30 at 04:07:05 +0200, Guillem Jover wrote:
> Hi!
> 
> On Sun, 2022-09-25 at 16:19:08 +0200, Tobias Frost wrote:
> > Package: wnpp
> > 
> > The current maintainer of dlocate, Craig Sanders ,
> > is no longer maintaining this packages.
> > 
> > Maintaining a package requires time and skills. Please only adopt this
> > package if you will have enough time and attention to work on it.
> > 
> > If you want to be the new maintainer, please see
> > https://www.debian.org/devel/wnpp/#howto-o for detailed
> > instructions how to adopt a package properly.
> 
> Hmm, if this is really unmaintained now, although given that this is a
> native package it is not clear to me, then given the relationship and
> namespace usage, I think this would fit nicely within the dpkg suite.
> So I'm willing to take this one if so.

Just to clarify, I'd would only ever consider taking this on, if the
upstream status is also really "unmaintained".

Thanks,
Guillem

Bug#1021150: cryptsetup: please upload to bullseye-backports

[Guilhem Moulin]

Hi,

On Sun, 02 Oct 2022 at 20:40:36 +0100, Luca Boccassi wrote:
> Could you please consider an upload of the latest cryptsetup to
> bullseye-backports?

Can certainly do that if it's useful.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1021156: calamares-settings-debian: Confusing/generic program names

[Guillem Jover]

Package: calamares-settings-debian
Version: 12.0.3-1
Severity: normal

Hi!

I just noticed that this package provides a dpkg-unsafe-io script,
which creates a calamares specific config file for dpkg. Looking
further I noticed the other installed program have concerningly
generic names such as "install-debian", "bootloader-config",
"sources-final" and "sources-media". I guess the same applies to the
desktop file "install-debian.desktop".

Do all of these need to be installed on the PATH? If they are internal
implementation details perhaps they could instead be installed under a
/usr/share/ directory? Otherwise could these be namespaced to denote
they are calamares specific?

Thanks,
Guillem

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Sebastian Ramacher]

On 2022-10-03 00:09:25 +0100, Lyndon Brown wrote:
> Control: retitle -1 vlc: playing videos results in a black screen
> Control: severity -1 grave
> 
> Ran into this today after installing daily Sid updates. Was fine
> yesterday. I think that some updates from yesterday, or perhaps the day
> before may have been delayed until today due to a dependency issue, so
> that may explain why I've only just experienced this.
> 
> This is not limited to mp4, I've also tried avi & mpg.
> 
> Logs indicate video format conversion failure, as per the original
> reporter's logs.
> 
> >From my apt log, these are the package updates that were installed
> today:
> 
>  - autoconf-archive:amd64 (20220903-1, 20220903-2)
>  - chromium:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
>  - chromium-common:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
>  - chromium-sandbox:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
>  - flex:amd64 (2.6.4-8, 2.6.4-8.1)
>  - libexempi8:amd64 (2.6.2-1, 2.6.2-2)
>  - libfido2-1:amd64 (1.11.0-1+b1, 1.12.0-1)
>  - libfl2:amd64 (2.6.4-8, 2.6.4-8.1)
>  - libfl-dev:amd64 (2.6.4-8, 2.6.4-8.1)
>  - libmediastreamer11:amd64 (1:5.0.37+dfsg-4, 1:5.0.37+dfsg-4+b1)
>  - libopenmpt0:amd64 (0.6.5-1, 0.6.6-1)
>  - libopenmpt-dev:amd64 (0.6.5-1, 0.6.6-1)
>  - libpixie-java:amd64 (1:1.1.6-4, 1:1.1.6-5)
>  - libqpdf29:amd64 (11.1.0-1, 11.1.1-1)
>  - libqt5concurrent5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5core5a:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5dbus5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5designer5:amd64 (5.15.4-2+b1, 5.15.6-2)
>  - libqt5gui5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5multimedia5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5multimediagsttools5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5multimediaquick5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5multimediawidgets5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5network5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5opengl5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5opengl5-dev:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5printsupport5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5qml5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5qmlmodels5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5qmlworkerscript5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5quick5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5quickcontrols2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
>  - libqt5quickparticles5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5quickshapes5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5quicktemplates2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
>  - libqt5quicktest5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5quickwidgets5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - libqt5sql5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5sql5-sqlite:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5svg5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5svg5-dev:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5test5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5texttospeech5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5waylandclient5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5waylandclient5-dev:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5waylandcompositor5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5waylandcompositor5-dev:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5widgets5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt5x11extras5:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5x11extras5-dev:amd64 (5.15.4-2, 5.15.6-2)
>  - libqt5xml5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
>  - libqt6concurrent6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6core6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6dbus6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6gui6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6network6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6opengl6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6openglwidgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6printsupport6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6shadertools6:amd64 (6.3.1-2, 6.3.1-3)
>  - libqt6sql6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6sql6-sqlite:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6test6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6widgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - libqt6xml6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
>  - linphone-desktop:amd64 (4.3.2-2, 4.3.2-2+b1)
>  - qml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - qml-module-qtgraphicaleffects:amd64 (5.15.4-2, 5.15.6-2)
>  - qml-module-qt-labs-platform:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
>  - qml-module-qtmultimedia:amd64 (5.15.4-2, 5.15.6-2)
>  - qml-module-qtqml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - qml-module-qtquick2:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - qml-module-qtquick-controls2:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
>  - qml-module-qtquick-controls:amd64 (5.15.4-2, 5.15.6-2)
>  - qml-module-qtquick-dialogs:amd64 (5.15.4-2, 5.15.6-2)
>  - qml-module-qtquick-extras:amd64 (5.15.4-2, 5.15.6-2)
>  - qml-module-qtquick-layouts:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
>  - qml-module-qtquick-privatewidgets:amd64 (5.15.4-2, 5.15.6-2)
>  - 

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Lyndon Brown]

Control: retitle -1 vlc: playing videos results in a black screen
Control: severity -1 grave

Ran into this today after installing daily Sid updates. Was fine
yesterday. I think that some updates from yesterday, or perhaps the day
before may have been delayed until today due to a dependency issue, so
that may explain why I've only just experienced this.

This is not limited to mp4, I've also tried avi & mpg.

Logs indicate video format conversion failure, as per the original
reporter's logs.

>From my apt log, these are the package updates that were installed
today:

 - autoconf-archive:amd64 (20220903-1, 20220903-2)
 - chromium:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
 - chromium-common:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
 - chromium-sandbox:amd64 (106.0.5249.61-1, 106.0.5249.91-1)
 - flex:amd64 (2.6.4-8, 2.6.4-8.1)
 - libexempi8:amd64 (2.6.2-1, 2.6.2-2)
 - libfido2-1:amd64 (1.11.0-1+b1, 1.12.0-1)
 - libfl2:amd64 (2.6.4-8, 2.6.4-8.1)
 - libfl-dev:amd64 (2.6.4-8, 2.6.4-8.1)
 - libmediastreamer11:amd64 (1:5.0.37+dfsg-4, 1:5.0.37+dfsg-4+b1)
 - libopenmpt0:amd64 (0.6.5-1, 0.6.6-1)
 - libopenmpt-dev:amd64 (0.6.5-1, 0.6.6-1)
 - libpixie-java:amd64 (1:1.1.6-4, 1:1.1.6-5)
 - libqpdf29:amd64 (11.1.0-1, 11.1.1-1)
 - libqt5concurrent5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5core5a:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5dbus5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5designer5:amd64 (5.15.4-2+b1, 5.15.6-2)
 - libqt5gui5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5multimedia5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5multimediagsttools5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5multimediaquick5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5multimediawidgets5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5network5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5opengl5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5opengl5-dev:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5printsupport5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5qml5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5qmlmodels5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5qmlworkerscript5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5quick5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5quickcontrols2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
 - libqt5quickparticles5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5quickshapes5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5quicktemplates2-5:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
 - libqt5quicktest5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5quickwidgets5:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - libqt5sql5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5sql5-sqlite:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5svg5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5svg5-dev:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5test5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5texttospeech5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5waylandclient5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5waylandclient5-dev:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5waylandcompositor5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5waylandcompositor5-dev:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5widgets5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt5x11extras5:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5x11extras5-dev:amd64 (5.15.4-2, 5.15.6-2)
 - libqt5xml5:amd64 (5.15.4+dfsg-5, 5.15.6+dfsg-2)
 - libqt6concurrent6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6core6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6dbus6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6gui6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6network6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6opengl6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6openglwidgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6printsupport6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6shadertools6:amd64 (6.3.1-2, 6.3.1-3)
 - libqt6sql6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6sql6-sqlite:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6test6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6widgets6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - libqt6xml6:amd64 (6.3.1+dfsg-9, 6.3.1+dfsg-10)
 - linphone-desktop:amd64 (4.3.2-2, 4.3.2-2+b1)
 - qml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtgraphicaleffects:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qt-labs-platform:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
 - qml-module-qtmultimedia:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qtqml:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtquick2:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtquick-controls2:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
 - qml-module-qtquick-controls:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qtquick-dialogs:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qtquick-extras:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qtquick-layouts:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtquick-privatewidgets:amd64 (5.15.4-2, 5.15.6-2)
 - qml-module-qtquick-shapes:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtquick-templates2:amd64 (5.15.4+dfsg-2, 5.15.6+dfsg-2)
 - qml-module-qtquick-window2:amd64 (5.15.4+dfsg-4, 5.15.6+dfsg-2)
 - qml-module-qtwayland-compositor:amd64 

Bug#1021155: wrong Vcs-* headers

[Michael Biebl]

Source: pangomm2.48
Version: 2.50.1-1
Severity: normal

The Vcs-* headers at
https://salsa.debian.org/gnome-team/pangomm2.48/-/blob/debian/master/debian/control.in#L19
should point at the pangomm2.48 repository.



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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

Bug#1021154: wrong Vcs-* in debian/control.in

[Michael Biebl]

Source: cairomm1.16
Version: 1.16.2-1
Severity: normal

The Vcs-* headers at
https://salsa.debian.org/gnome-team/cairomm1.16/-/blob/debian/master/debian/control.in#L19
should be updated to reference the cairomm1.16 repo


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

Bug#1021153: node-schema-utils: ftbfs due to changed output formatting/escaping

[Andreas Beckmann]

Package: node-schema-utils
Version: 3.1.1~ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Control: found -1 4.0.0~ds-1

Hi,

node-schema-utils recently started to FTBFS in sid (but not yet in
testing):

   dh_auto_test --buildsystem=nodejs
ln -s ../. node_modules/schema-utils
/bin/sh -ex debian/tests/pkg-js/test
+ jest --ci test/
PASS test/range.test.js
PASS test/hints.test.js
PASS test/api.test.js
FAIL test/index.test.js (6.825 s)
  ● Validation › should fail validation for postFormatter #1

expect(received).toMatchSnapshot()

Snapshot name: `Validation should fail validation for postFormatter #1 1`

- Snapshot  - 1
+ Received  + 1

@@ -5,11 +5,11 @@
 For loader options: webpack >= v2.0.0 no longer allows custom 
properties in configuration.
   Loaders should be updated to allow passing options via loader 
options in module.rules.
   Until loaders are updated one can use the LoaderOptionsPlugin to 
pass these options to the loader:
   plugins: [
 new webpack.LoaderOptionsPlugin({
-  // test: /\\.xxx$/, // may apply this only for some modules
+  // test: /\.xxx$/, // may apply this only for some modules
   options: {
 minify: …
   }
 })
   ]"

  413 |   minify: true,
  414 | },
> 415 | (msg) => expect(msg).toMatchSnapshot(),
  |  ^
  416 | {
  417 |   name: "Webpack",
  418 |   baseDataPath: "configuration",

  at fn (test/index.test.js:415:26)
  at Object. (test/index.test.js:45:9)

  ● Validation › should fail validation for postFormatter #2

expect(received).toMatchSnapshot()

Snapshot name: `Validation should fail validation for postFormatter #2 1`

- Snapshot  - 1
+ Received  + 1

  "Invalid configuration object. Webpack has been initialized using a 
configuration object that does not match the API schema.
-  - configuration.output.filename: A relative path is expected. However, 
the provided value \"/bar\" is an absolute path!
+  - configuration.output.filename: A relative path is expected. However, 
the provided value "/bar" is an absolute path!
 Please use output.path to specify absolute path and output.filename 
for the file name."

  453 |   },
  454 | },
> 455 | (msg) => expect(msg).toMatchSnapshot(),
  |  ^
  456 | {
  457 |   name: "Webpack",
  458 |   baseDataPath: "configuration",

  at fn (test/index.test.js:455:26)
  at Object. (test/index.test.js:45:9)

  ● Validation › should fail validation for ! in path

expect(received).toMatchSnapshot()

Snapshot name: `Validation should fail validation for ! in path 1`

- Snapshot  - 1
+ Received  + 1

  "Invalid configuration object. Object has been initialized using a 
configuration object that does not match the API schema.
-  - configuration.output.path: The provided value \"/somepath/!test\" 
contains exclamation mark (!) which is not allowed because it's reserved for 
loader syntax.
+  - configuration.output.path: The provided value "/somepath/!test" 
contains exclamation mark (!) which is not allowed because it's reserved for 
loader syntax.
 -> The output directory as **absolute path** (required)."

  609 |   },
  610 | },
> 611 | (msg) => expect(msg).toMatchSnapshot()
  |  ^
  612 |   );
  613 |
  614 |   createFailedTestCase(

  at fn (test/index.test.js:611:26)
  at Object. (test/index.test.js:45:9)

...

Some output formatting (escaping) seems to have changed.

Andreas


node-schema-utils.sid.build.gz
Description: application/gzip

Bug#1021117: Acknowledgement (llvm-15-dev: cmake fails on missing /usr/lib/llvm-15/bin/mlir-tblgen)

[Andreas Beckmann]

Control: severity -1 important
Control: tag -1 unreproducible

A few hours later I cannot reproduce that any more. Something must have 
been upgraded inbetween.


But I noticed a similar error with spirv-llvm-translator-14 on x32:

https://buildd.debian.org/status/fetch.php?pkg=spirv-llvm-translator-14=x32=14.0.0-2=1664557744=0

CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 
(message):

  The imported target "mlir-tblgen" references the file

 "/usr/lib/llvm-14/bin/mlir-tblgen"

  but this file does not exist.  Possible reasons include:

A new build is pending ...


Andreas

Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes

[Lyndon Brown]

ping.

Bug#1021152: audacity: FTBFS on armel, s390x

[Scott Talbert]

Source: audacity
Version: 3.2.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

audacity 3.2.0+dfsg-1 FTBFS on armel and s390x.

Tail of log for audacity on armel:
/usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for 
argument of type ‘__gnu_cxx::__normal_iterator >’ changed in GCC 7.1
 1287 |   _M_realloc_insert(end(), __x);
  |   ~^~~~
In member function ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) 
[with _Tp = LabelStruct; _Alloc = std::allocator]’,
inlined from ‘void LabelTrack::Import(wxTextFile&)’ at 
/<>/src/LabelTrack.cpp:592:27:
/usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for 
argument of type ‘__gnu_cxx::__normal_iterator >’ changed in GCC 7.1
 1287 |   _M_realloc_insert(end(), __x);
  |   ~^~~~
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[2]: *** [CMakeFiles/Makefile2:1922: src/CMakeFiles/Audacity.dir/all] Error 
2
make[2]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[1]: *** [Makefile:159: all] Error 2
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi'
dh_auto_build: error: cd obj-arm-linux-gnueabi && make -j8 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:47: binary-arch] Error 25

Tail of log for audacity on s390x:
[ 65%] Building CXX object src/CMakeFiles/Audacity.dir/SseMathFuncs.cpp.o
cd /<>/obj-s390x-linux-gnu/src && /usr/bin/c++ 
-DAUDACITY_DLL_API="" -DAUDIO_DEVICES_API="" -DAUDIO_GRAPH_API="" 
-DAudacity_EXPORTS -DBASIC_UI_API="" -DBUILDING_AUDACITY -DCMAKE 
-DCOMPONENTS_API="" -DEXCEPTIONS_API="" -DEXPERIMENTAL_CRASH_REPORT 
-DEXPERIMENTAL_DRAGGABLE_PLAY_HEAD -DEXPERIMENTAL_FULL_WASAPI 
-DEXPERIMENTAL_HALF_WAVE -DEXPERIMENTAL_KEY_VIEW -DEXPERIMENTAL_MIDI_OUT 
-DEXPERIMENTAL_MODULE_PREFS -DEXPERIMENTAL_NOISE_REDUCTION 
-DEXPERIMENTAL_NOTETRACK_OVERLAY -DEXPERIMENTAL_NYQUIST_SPLIT_CONTROL 
-DEXPERIMENTAL_PUNCH_AND_ROLL -DEXPERIMENTAL_SCIENCE_FILTERS 
-DEXPERIMENTAL_SCROLLING_LIMITS -DEXPERIMENTAL_SCRUBBING_SCROLL_WHEEL 
-DEXPERIMENTAL_SCRUBBING_SUPPORT -DEXPERIMENTAL_SPECTRAL_EDITING 
-DEXPERIMENTAL_SYNC_LOCK -DEXPERIMENTAL_THEMING 
-DEXPERIMENTAL_TWO_TONE_TIME_RULER -DEXPERIMENTAL_ZOOM_TOGGLE_BUTTON 
-DFFMPEG_SUPPORT_API="" -DFILES_API="" -DGRAPHICS_API="" -DHAVE_LRINT 
-DHAVE_LRINTF -DHAVE_MLOCK -DIPC_API="" -DMATH_API="" -DMODULE_MANAGER_API="" 
-DPREFERENCES_API="" -DPROJECT_API="" -DPROJECT_HISTORY_API="" 
-DPROJECT_RATE_API="" -DREGISTRIES_API="" -DSAMPLE_TRACK_API="" 
-DSCREEN_GEOMETRY_API="" -DSTRINGS_API="" -DSTRING_UTILS_API="" -DTHEME_API="" 
-DTHEME_RESOURCES_API="" -DTRACK_API="" -DTRANSACTIONS_API="" -DUSE_FFMPEG 
-DUSE_NYQUIST=1 -DUSE_PORTMIXER=1 -DUTILITY_API="" -DUUID_API="" -DWXUSINGDLL 
-DXML_API="" -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/<>/obj-s390x-linux-gnu/src/private -I/<>/include 
-I/<>/src -I/<>/libraries/lib-string-utils 
-I/<>/libraries/lib-uuid 
-I/<>/libraries/lib-project-rate 
-I/<>/libraries/lib-project 
-I/<>/libraries/lib-registries 
-I/<>/libraries/lib-preferences 
-I/<>/libraries/lib-utility 
-I/<>/libraries/lib-basic-ui 
-I/<>/libraries/lib-strings 
-I/<>/libraries/lib-components 
-I/<>/libraries/lib-exceptions 
-I/<>/libraries/lib-xml -I/<>/libraries/lib-files 
-I/<>/libraries/lib-audio-devices 
-I/<>/lib-src/portmixer/include 
-I/<>/libraries/lib-math 
-I/<>/libraries/lib-theme-resources 
-I/<>/libraries/lib-theme 
-I/<>/libraries/lib-sample-track 
-I/<>/libraries/lib-audio-graph 
-I/<>/libraries/lib-track 
-I/<>/libraries/lib-module-manager 
-I/<>/libraries/lib-ipc 
-I/<>/libraries/lib-project-history 
-I/<>/libraries/lib-screen-geometry 
-I/<>/libraries/lib-transactions 
-I/<>/libraries/lib-graphics 
-I/<>/libraries/lib-ffmpeg-support 
-I/<>/libraries/lib-sentry-reporting 
-I/<>/lib-src/libnyquist -isystem 
/usr/lib/s390x-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem 
/usr/include/wx-3.2 -isystem /usr/include/lame -isystem /usr/include/lilv-0 
-isystem /usr/include/sratom-0 -isystem /usr/include/sord-0 -isystem 
/usr/include/serd-0 -isystem /usr/include/suil-0 -isystem /usr/include/portSMF 
-isystem /usr/include/soundtouch -isystem /usr/include/glib-2.0 -isystem 
/usr/lib/s390x-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0 
-isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem 
/usr/include/dbus-1.0 -isystem /usr/lib/s390x-linux-gnu/dbus-1.0/include 
-isystem /usr/include/gio-unix-2.0 -isystem /usr/include/cairo -isystem 
/usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem 
/usr/include/fribidi -isystem /usr/include/atk-1.0 -isystem 
/usr/include/pixman-1 -isystem /usr/include/uuid -isystem 
/usr/include/freetype2 -isystem /usr/include/gdk-pixbuf-2.0 -isystem 
/usr/include/libpng16 -isystem /usr/include/libmount -isystem 
/usr/include/blkid -g -O2 -ffile-prefix-map=/<>=. 

Bug#1020869: geg: Generates different graphs from equivalent formulas

[Sven Geuer]

Here's a simpler formular showing the same erroneous behaviour of geg:

1/x and 1/(x) return the expected graph

while

1/(x/1) returns the horizontal line f(x)=1.


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

Bug#1019425: See also 939392

[Nye Liu]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939392

Bug#939392: See also 1019425

[Nye Liu]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019425

Bug#964654:

[Jeremy White]

Bug#939392: please provide kmodsign like Ubuntu does

[Nye Liu]

Same here

Building module:
Cleaning build area...
'make' KVER=5.19.0-2-amd64 
src=/usr/src/rtl88x2bu-5.8.7.1...

Signing module /var/lib/dkms/rtl88x2bu/5.8.7.1/build/88x2bu.ko
/usr/sbin/dkms: line 1055: kmodsign: command not found
Cleaning build area...

88x2bu.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.19.0-2-amd64/updates/dkms/
depmod...

I see this

$ dpkg -S sign-file
linux-kbuild-5.19: /usr/lib/linux-kbuild-5.19/scripts/sign-file

but that's not terribly useful since you can't even symlink it to 
kmodsign if you change kbuild versions.

Bug#834724:

[Jeremy White]

Bug#951805: Help with glbinding

[Andrea Pappacoda]

Il giorno dom 2 ott 2022 alle 20:54:01 +02:00:00, Ghislain Vaillant 
 ha scritto:
Feel free to assist with maintenance of any of my packages under the 
Debian science team umbrella.


You don't need to ask for permission 


Thanks for the fast reply, Ghislain! I'll start working on this in a 
few days. Would you be able to sponsor my first upload and/or grant me 
DM rights to the package? If you prefer, I can publish my changes in a 
Salsa fork so that you can take a look at them before trusting me too 
much :)


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1021151: ITP: setuptools-rust -- Plugin for setuptools to build Rust Python extensions

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: setuptools-rust
  Version : 1.5.2
  Upstream Author : Nikolay Kim 
* URL : https://github.com/PyO3/setuptools-rust
* License : MIT
  Programming Lang: Python
  Description : Plugin for setuptools to build Rust Python extensions

  Compile and distribute Python extensions written in Rust as easily as if
  they were written in C.
 
  Extensions can be implemented with PyO3 or rust-cpython.
 
I plan to maintain this package as part of the Python team.

Bug#1021150: cryptsetup: please upload to bullseye-backports

[Luca Boccassi]

Source: cryptsetup
Severity: wishlist
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Maintainer(s),

Could you please consider an upload of the latest cryptsetup to
bullseye-backports?

We are enabling the tokens plugins in systemd [0], which require at
least 2.4.0. We often upload systemd to backports, so it would be
useful to have a newer cryptsetup there too, so that we don't have to
disable it again.

I am happy to do an NMU to backports if you lack the time to take care
of it.

Thanks!

[0] https://salsa.debian.org/systemd-team/systemd/-/merge_requests/175

-- 
Kind regards,
Luca Boccassi


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

Bug#1021149: https://wiki.debian.org/ProgrammingLanguage: missing introduction

[Thure Duehrsen]

Package: wiki.debian.org
Severity: minor
Tags: a11y
X-Debbugs-Cc: t.duehr...@gmx.net

Dear Maintainer,

The Wiki page on programming languages,
https://wiki.debian.org/ProgrammingLanguage, is missing a few introductory
sentences describing what can be found on the page.
As it currently stands, it is a collection of snippets and links, in some
cases without a clear purpose. This applies to the BASIC and C sections in
particular.

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Niels Thykier]

On Mon, 14 Dec 2020 15:01:52 -0700 Sean Whitton 
 wrote:

Hello Ansgar,

On Tue 24 Nov 2020 at 01:37PM +01, Ansgar wrote:

> Package: debian-policy
> Version: 4.5.1.0
> Severity: normal
>
> After a discussion in #-devel today I reviewed packages using other
> choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
> query [1] found two uses:
>
> [...]
>
> The complexity to support arbitrary additional keywords as choices of
> R³ seems overkill given there is just one real user (libcap2) and the
> current R³ specification doesn't handle that usecase fully either.
>
> Therefore I suggest to deprecate using R³ values other than "no" and
> "binary-targets" within Debian.
>
> (Unrelated: R³: no should probably be recommended.)

We would definitely need input from the designers of the R³ system
before removing anything (to my knowledge, the design was led by Niels
and Guillem).  They were designing for the very long term, so I don't
think we can safely infer much from the present contents of the archive.

I'm also not really convinced by your arguments that having these other
possible values adds much of a burden.  This is not about code which has
to be updated, just text.  We do not expect newcomers to imbibe
everything in Policy.

--
Sean Whitton


Hi,

Here is my view in short: As I see it, only the values `no` and 
`binary-targets` for `Rules-Requires-Root` makes sense for the *policy 
defined targets*[1] at the moment.  Accordingly, Debian policy can 
probably reduce the field to only cover `binary-targets` and `no` (and 
describe the remaining values as "[they] will mostly behave like `no`, 
but read more in the dpkg documentation for concrete the non-policy 
relevant use-case")


In theory, you could use `Rules-Requires-Root` to cover the static 
ownership cases (where you need to chown files and store that ownership 
in the deb).  However, that would require people to consistently use 
fakeroot with -l + -s (which, to my knowledge, no one does) - failure to 
do so would just silently loose the ownership and the files would end up 
with the wrong owner.


On a related note, both Guillem and I agreed a while back that ownership 
(among other) should ideally be specifiably without using chown.  While 
a concrete method has not yet materialized, I am not working on 
supporting static ownership via chown in debhelper (nor do I plan to do 
so), so in practice `binary-targets` is the only reliable way to setup 
static ownership for any package built via debhelper[2].


So in summary, with the current tooling, only `no` and `binary-targets` 
make sense for *policy defined targets* and I am not aware of anything 
that would change that.


Thanks,
~Niels

PS: As for the adding a recommendation to use `Rules-Requires-Root: no` 
where possible. I would second such as change. Over half of all Debian 
source packages in testing have the value, and adoption has been quite 
fast despite very little push from Guillem and I on it.  For me, the 
recommendation would be documenting public sentiment on this topic.


Source: https://trends.debian.net/rulesreqroot_testing-percent.png

[1]: There is a set of values for asking dpkg-buildpackage to provide 
(fake)root for custom targets, which might make sense for users/packages 
- but since those would be custom targets, Debian Policy should not care 
about these targets.  But it probably has to mention the field can have 
other values than specified and that is okay for very rare cases.


[2]: When `Rules-Requires-Root` is not (effectively) `binary-targets`, 
debhelper will pass `--root-owner-group` to `dpkg-deb`, which neuters 
any filesystem specified ownership.

Bug#918925: i3: Status and title bar text do not appear with default config file

[Jakob Haufe]

Does this issue persist? If so, is this on RaspiOS or Debian?

-- 
ceterum censeo microsoftem esse delendam.


pgpeiViOH38hD.pgp
Description: OpenPGP digital signature

Bug#1021148: https://wiki.debian.org/Crosstool: missing introduction

[Thure Duehrsen]

Package: wiki.debian.org
Severity: minor
Tags: a11y
X-Debbugs-Cc: t.duehr...@gmx.net

Dear Maintainer,

while browsing the page https://wiki.debian.org/ProgrammingLanguage, in the "C"
section I came across the Crosstool page, https://wiki.debian.org/Crosstool.
While I am an experienced C programmer, I had never heard of Crosstool, so
clicked the link, to find there is no introduction saying what the tool is for
and why I would want to use it.

I did notice that the page has not been updated in over a decade.

Bug#792894: Why are 826011 and 826012 considered blockers?

[Luca Boccassi]

On Sun, 10 May 2020 15:07:06 +0200 Dirk Heinrichs
 wrote:
> Hi,
> 
> I wonder why these two bugs are considered blockers for this one?
From
> the 3 scenarios below
> 
>   * DHCPv4 only
>   * DHCPv6 only
>   * DHCPv4 and DHCPv6
> 
> only the last one would need to have both started, so only this
_might_
> have a use for compound target units. But even if they are not
> available, one can still enable/start each service separately via its
> own service file. This means that 826011 and 826012 are, at most,
nice
> to have, but in no way are they blocking systemd service files for
> isc-dhcp-server, right?
> 
> In addition, the current init script based mechanism for running both
is
> also buggy: When one service got killed, its PID file is still
around,
> which results in the init script refusing to start ANY of them unless
> that PID file is removed.
> 
> So, please, replace the current init script with proper, independent
> systemd service files for both dhcpdv4 and dhcpdv6 for bullseye. A
> compound target unit can still be added later.
> 
> Bye...
> 
>     Dirk

Ping - any update on this? It would be good to get this sorted as
mentioned above. isc-dhcp is one of the few popular packages left
without native units.

-- 
Kind regards,
Luca Boccassi


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

Bug#951805: Help with glbinding

[Ghislain Vaillant]

Hi Andrea,

Feel free to assist with maintenance of any of my packages under the Debian
science team umbrella.

You don't need to ask for permission 

Ghis

Le dim. 2 oct. 2022, 18:22, Andrea Pappacoda  a écrit :

> Hi Ghislain, glbinding hasn't been updated in four years. Would you
> like some help with the package? I've used glbinding in the past, and
> I'd be happy to help with maintenance under the Science team.
>
> --
> OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49
>
>
>

Bug#1021147: RM: uim-mozc [armel armhf] -- RoQA; depends on uim which FTBFS

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal
Control: block 1021102 by -1

Dear FTP masters,

In https://bugs.debian.org/1021102 I requested removing uim on armel and
armhf.

uim-mozc is a reverse dependency of uim, so it has to be removed too.

--
Dmitry Shachnev

Bug#1021146: RM: uim-chewing [armel armhf] -- RoQA; depends on uim which FTBFS

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal
Control: block 1021102 by -1

Dear FTP masters,

In https://bugs.debian.org/1021102 I requested removing uim on armel and
armhf.

uim-chewing is a reverse dependency of uim, so it has to be removed too.

--
Dmitry Shachnev

Bug#1021145: RM: mlterm-im-uim [armel armhf] -- RoQA; depends on uim which FTBFS

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal
Control: block 1021102 by -1

Dear FTP masters,

In https://bugs.debian.org/1021102 I requested removing uim on armel and
armhf.

mlterm-im-uim is a reverse dependency of uim, so it has to be removed too.

--
Dmitry Shachnev

Bug#1021144: RM: gkrelluim [armel armhf] -- RoQA; depends on uim which FTBFS

[Dmitry Shachnev]

Package: ftp.debian.org
Severity: normal
Control: block 1021102 by -1

Dear FTP masters,

In https://bugs.debian.org/1021102 I requested removing uim on armel and
armhf.

gkrelluim is a reverse dependency of uim, so it has to be removed too.

--
Dmitry Shachnev

Bug#941998: UsrMerge breaks cruft

[Luca Boccassi]

On Sun, 2022-10-02 at 16:16 +0200, Alexandre Detiste wrote:
> Version: 0.9.44
> 
> cruft is now a transitional package that pulls
> cruft-ng which is Usrmerge aware.
> 
> Matching merge-request has been submitted
> to UsrMerge repository on Salsa:
> 
> https://salsa.debian.org/md/usrmerge/-/merge_requests/11

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#1021143: rust-cargo: CVE-2022-36113 CVE-2022-36114

[Moritz Mühlenhoff]

Source: rust-cargo
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for rust-cargo.

CVE-2022-36113[0]:
| Cargo is a package manager for the rust programming language. After a
| package is downloaded, Cargo extracts its source code in the ~/.cargo
| folder on disk, making it available to the Rust projects it builds. To
| record when an extraction is successful, Cargo writes "ok" to the
| .cargo-ok file at the root of the extracted source code once it
| extracted all the files. It was discovered that Cargo allowed packages
| to contain a .cargo-ok symbolic link, which Cargo would extract. Then,
| when Cargo attempted to write "ok" into .cargo-ok, it would actually
| replace the first two bytes of the file the symlink pointed to with
| ok. This would allow an attacker to corrupt one file on the machine
| using Cargo to extract the package. Note that by design Cargo allows
| code execution at build time, due to build scripts and procedural
| macros. The vulnerabilities in this advisory allow performing a subset
| of the possible damage in a harder to track down way. Your
| dependencies must still be trusted if you want to be protected from
| attacks, as it's possible to perform the same attacks with build
| scripts and procedural macros. The vulnerability is present in all
| versions of Cargo. Rust 1.64, to be released on September 22nd, will
| include a fix for it. Since the vulnerability is just a more limited
| way to accomplish what a malicious build scripts or procedural macros
| can do, we decided not to publish Rust point releases backporting the
| security fix. Patch files are available for Rust 1.63.0 are available
| in the wg-security-response repository for people building their own
| toolchain. Mitigations We recommend users of alternate registries to
| exercise care in which package they download, by only including
| trusted dependencies in their projects. Please note that even with
| these vulnerabilities fixed, by design Cargo allows arbitrary code
| execution at build time thanks to build scripts and procedural macros:
| a malicious dependency will be able to cause damage regardless of
| these vulnerabilities. crates.io implemented server-side checks to
| reject these kinds of packages years ago, and there are no packages on
| crates.io exploiting these vulnerabilities. crates.io users still need
| to exercise care in choosing their dependencies though, as remote code
| execution is allowed by design there as well.

https://github.com/rust-lang/cargo/security/advisories/GHSA-rfj2-q3h3-hm5j
https://github.com/rust-lang/cargo/commit/97b80919e404b0768ea31ae329c3b4da54bed05a

CVE-2022-36114[1]:
| Cargo is a package manager for the rust programming language. It was
| discovered that Cargo did not limit the amount of data extracted from
| compressed archives. An attacker could upload to an alternate registry
| a specially crafted package that extracts way more data than its size
| (also known as a "zip bomb"), exhausting the disk space on the machine
| using Cargo to download the package. Note that by design Cargo allows
| code execution at build time, due to build scripts and procedural
| macros. The vulnerabilities in this advisory allow performing a subset
| of the possible damage in a harder to track down way. Your
| dependencies must still be trusted if you want to be protected from
| attacks, as it's possible to perform the same attacks with build
| scripts and procedural macros. The vulnerability is present in all
| versions of Cargo. Rust 1.64, to be released on September 22nd, will
| include a fix for it. Since the vulnerability is just a more limited
| way to accomplish what a malicious build scripts or procedural macros
| can do, we decided not to publish Rust point releases backporting the
| security fix. Patch files are available for Rust 1.63.0 are available
| in the wg-security-response repository for people building their own
| toolchain. We recommend users of alternate registries to excercise
| care in which package they download, by only including trusted
| dependencies in their projects. Please note that even with these
| vulnerabilities fixed, by design Cargo allows arbitrary code execution
| at build time thanks to build scripts and procedural macros: a
| malicious dependency will be able to cause damage regardless of these
| vulnerabilities. crates.io implemented server-side checks to reject
| these kinds of packages years ago, and there are no packages on
| crates.io exploiting these vulnerabilities. crates.io users still need
| to excercise care in choosing their dependencies though, as the same
| concerns about build scripts and procedural macros apply here.

https://github.com/rust-lang/cargo/security/advisories/GHSA-2hvr-h6gw-qrxp
https://github.com/rust-lang/cargo/commit/d1f9553c825f6d7481453be8d58d0e7f117988a7

If you fix the vulnerabilities please also make sure to include the
CVE (Common 

Bug#1021140: vlc: No video when "Integrate video in interface" is enabled

[KeyofBlueS]

Package: vlc
Version: 3.0.17.4-4+b2
Severity: important
X-Debbugs-Cc: keyofbl...@gmail.com

Dear Maintainer,

vlc can't display any video when "Integrate video in interface" is enabled.

I've tried several video files, reset vlc config, disabled "Input/Codecs >
Hardware-accelerated decoding" and no matter what i set in "Video > Output",
nothing changes.
I've followed the "Debugging and bug reporting advices", also.

This happened, i guess, after the recent upgrade of some qt stuff in sid.

vlc -vvv log is attached.

Thanks and best regards.


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

Kernel: Linux 5.18.5-custom (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 vlc depends on:
ii  vlc-bin  3.0.17.4-4+b2
ii  vlc-plugin-base  3.0.17.4-4+b2
ii  vlc-plugin-qt3.0.17.4-4+b2
ii  vlc-plugin-video-output  3.0.17.4-4+b2

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.17.4-4
ii  vlc-plugin-access-extra3.0.17.4-4+b2
ii  vlc-plugin-notify  3.0.17.4-4+b2
ii  vlc-plugin-samba   3.0.17.4-4+b2
ii  vlc-plugin-skins2  3.0.17.4-4+b2
ii  vlc-plugin-video-splitter  3.0.17.4-4+b2
ii  vlc-plugin-visualization   3.0.17.4-4+b2

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
ii  vlc-plugin-pipewire3-2
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.35-1
ii  libvlc5  3.0.17.4-4+b2

Versions of packages libvlc5 depends on:
ii  libc62.35-1
ii  libvlccore9  3.0.17.4-4+b2

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.17.4-4+b2

Versions of packages vlc-bin depends on:
ii  libc6   2.35-1
ii  libvlc-bin  3.0.17.4-4+b2
ii  libvlc5 3.0.17.4-4+b2

Versions of packages vlc-plugin-access-extra depends on:
ii  libc62.35-1
ii  libsrt1.5-gnutls 1.5.1-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.17.4-4+b2
ii  libvncclient10.9.13+dfsg-4
ii  libxcb-composite01.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.0-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.7.2-1
ii  libass9  1:0.16.0-1
ii  libavahi-client3 0.8-6
ii  libavahi-common3 0.8-6
ii  libavc1394-0 0.5.4-5
ii  libavcodec59 7:5.1.2-1
ii  libavformat597:5.1.2-1
ii  libavutil57  7:5.1.2-1
ii  libbluray2   1:1.3.3-1
ii  libc62.35-1
ii  libcairo21.16.0-6
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2+b1
ii  libdav1d61.0.0-2
ii  libdbus-1-3  1.14.2-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.2-2+b1
ii  libfaad2 2.10.0-2+b1
ii  libflac8 1.3.4-2
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112.2.0-3
ii  libgcrypt20  1.10.1-2
ii  libglib2.0-0 2.74.0-2
ii  libgnutls30  3.7.7-2
ii  libgpg-error01.45-2
ii  libharfbuzz0b5.2.0-2
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7
ii  liblua5.2-0  5.2.4-2
ii  libmad0  0.15.1b-10.1+b1
ii  libmatroska7 1.6.3-2
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.30.2-1
ii  libmtp9  1.1.20-1
ii  libncursesw6 6.3+20220423-2
ii  

Bug#1021142: cargo: CVE-2022-36113 CVE-2022-36114

[Moritz Mühlenhoff]

Source: cargo
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for cargo.

CVE-2022-36113[0]:
| Cargo is a package manager for the rust programming language. After a
| package is downloaded, Cargo extracts its source code in the ~/.cargo
| folder on disk, making it available to the Rust projects it builds. To
| record when an extraction is successful, Cargo writes "ok" to the
| .cargo-ok file at the root of the extracted source code once it
| extracted all the files. It was discovered that Cargo allowed packages
| to contain a .cargo-ok symbolic link, which Cargo would extract. Then,
| when Cargo attempted to write "ok" into .cargo-ok, it would actually
| replace the first two bytes of the file the symlink pointed to with
| ok. This would allow an attacker to corrupt one file on the machine
| using Cargo to extract the package. Note that by design Cargo allows
| code execution at build time, due to build scripts and procedural
| macros. The vulnerabilities in this advisory allow performing a subset
| of the possible damage in a harder to track down way. Your
| dependencies must still be trusted if you want to be protected from
| attacks, as it's possible to perform the same attacks with build
| scripts and procedural macros. The vulnerability is present in all
| versions of Cargo. Rust 1.64, to be released on September 22nd, will
| include a fix for it. Since the vulnerability is just a more limited
| way to accomplish what a malicious build scripts or procedural macros
| can do, we decided not to publish Rust point releases backporting the
| security fix. Patch files are available for Rust 1.63.0 are available
| in the wg-security-response repository for people building their own
| toolchain. Mitigations We recommend users of alternate registries to
| exercise care in which package they download, by only including
| trusted dependencies in their projects. Please note that even with
| these vulnerabilities fixed, by design Cargo allows arbitrary code
| execution at build time thanks to build scripts and procedural macros:
| a malicious dependency will be able to cause damage regardless of
| these vulnerabilities. crates.io implemented server-side checks to
| reject these kinds of packages years ago, and there are no packages on
| crates.io exploiting these vulnerabilities. crates.io users still need
| to exercise care in choosing their dependencies though, as remote code
| execution is allowed by design there as well.

https://github.com/rust-lang/cargo/security/advisories/GHSA-rfj2-q3h3-hm5j
https://github.com/rust-lang/cargo/commit/97b80919e404b0768ea31ae329c3b4da54bed05a

CVE-2022-36114[1]:
| Cargo is a package manager for the rust programming language. It was
| discovered that Cargo did not limit the amount of data extracted from
| compressed archives. An attacker could upload to an alternate registry
| a specially crafted package that extracts way more data than its size
| (also known as a "zip bomb"), exhausting the disk space on the machine
| using Cargo to download the package. Note that by design Cargo allows
| code execution at build time, due to build scripts and procedural
| macros. The vulnerabilities in this advisory allow performing a subset
| of the possible damage in a harder to track down way. Your
| dependencies must still be trusted if you want to be protected from
| attacks, as it's possible to perform the same attacks with build
| scripts and procedural macros. The vulnerability is present in all
| versions of Cargo. Rust 1.64, to be released on September 22nd, will
| include a fix for it. Since the vulnerability is just a more limited
| way to accomplish what a malicious build scripts or procedural macros
| can do, we decided not to publish Rust point releases backporting the
| security fix. Patch files are available for Rust 1.63.0 are available
| in the wg-security-response repository for people building their own
| toolchain. We recommend users of alternate registries to excercise
| care in which package they download, by only including trusted
| dependencies in their projects. Please note that even with these
| vulnerabilities fixed, by design Cargo allows arbitrary code execution
| at build time thanks to build scripts and procedural macros: a
| malicious dependency will be able to cause damage regardless of these
| vulnerabilities. crates.io implemented server-side checks to reject
| these kinds of packages years ago, and there are no packages on
| crates.io exploiting these vulnerabilities. crates.io users still need
| to excercise care in choosing their dependencies though, as the same
| concerns about build scripts and procedural macros apply here.

https://github.com/rust-lang/cargo/security/advisories/GHSA-2hvr-h6gw-qrxp
https://github.com/rust-lang/cargo/commit/d1f9553c825f6d7481453be8d58d0e7f117988a7

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities 

Bug#1021141: imagemagick: CVE-2022-3213

[Moritz Mühlenhoff]

Source: imagemagick
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for imagemagick.

CVE-2022-3213[0]:
| A heap buffer overflow issue was found in ImageMagick. When an
| application processes a malformed TIFF file, it could lead to
| undefined behavior or a crash causing a denial of service.

https://bugzilla.redhat.com/show_bug.cgi?id=2126824
https://github.com/ImageMagick/ImageMagick/commit/30ccf9a0da1f47161b5935a95be854fe84e6c2a2
https://github.com/ImageMagick/ImageMagick6/commit/1aea203eb36409ce6903b9e41fe7cb70030e8750

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021139: barbican: CVE-2022-3100

[Moritz Mühlenhoff]

Source: barbican
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for barbican.

CVE-2022-3100[0]:
access policy bypass via query string injection

Only reference so far is Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2125404

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021138: php8.1: CVE-2022-31628 CVE-2022-31629

[Moritz Mühlenhoff]

Source: php8.1
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for php8.1.

CVE-2022-31628[0]:
| In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar
| uncompressor code would recursively uncompress "quines" gzip files,
| resulting in an infinite loop.

PHP Bug: https://bugs.php.net/bug.php?id=81726
https://github.com/php/php-src/commit/404e8bdb68350931176a5bdc86fc417b34fb583d
https://github.com/php/php-src/commit/432bf196d59bcb661fcf9cb7029cea9b43f490af

CVE-2022-31629[1]:
| In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability
| enables network and same-site attackers to set a standard insecure
| cookie in the victim's browser which is treated as a `__Host-` or
| `__Secure-` cookie by PHP applications.

PHP Bug: https://bugs.php.net/bug.php?id=81727
https://github.com/php/php-src/commit/0611be4e82887cee0de6c4cbae320d34eec946ca

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-31628
https://www.cve.org/CVERecord?id=CVE-2022-31628
[1] https://security-tracker.debian.org/tracker/CVE-2022-31629
https://www.cve.org/CVERecord?id=CVE-2022-31629

Please adjust the affected versions in the BTS as needed.

Bug#1021137: modsecurity-crs: CVE-2022-39955 CVE-2022-39956 CVE-2022-39957 CVE-2022-39958

[Moritz Mühlenhoff]

Source: modsecurity-crs
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for modsecurity-crs.

CVE-2022-39955[0]:
| The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial
| rule set bypass by submitting a specially crafted HTTP Content-Type
| header field that indicates multiple character encoding schemes. A
| vulnerable back-end can potentially be exploited by declaring multiple
| Content-Type "charset" names and therefore bypassing the configurable
| CRS Content-Type header "charset" allow list. An encoded payload can
| bypass CRS detection this way and may then be decoded by the backend.
| The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the
| currently supported versions 3.2.1 and 3.3.2. Integrators and users
| are advised to upgrade to 3.2.2 and 3.3.3 respectively.

https://coreruleset.org/20220919/crs-version-3-3-3-and-3-2-2-covering-several-cves/

CVE-2022-39956[1]:
| The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial
| rule set bypass for HTTP multipart requests by submitting a payload
| that uses a character encoding scheme via the Content-Type or the
| deprecated Content-Transfer-Encoding multipart MIME header fields that
| will not be decoded and inspected by the web application firewall
| engine and the rule set. The multipart payload will therefore bypass
| detection. A vulnerable backend that supports these encoding schemes
| can potentially be exploited. The legacy CRS versions 3.0.x and 3.1.x
| are affected, as well as the currently supported versions 3.2.1 and
| 3.3.2. Integrators and users are advised upgrade to 3.2.2 and 3.3.3
| respectively. The mitigation against these vulnerabilities depends on
| the installation of the latest ModSecurity version (v2.9.6 / v3.0.8).

https://coreruleset.org/20220919/crs-version-3-3-3-and-3-2-2-covering-several-cves/

CVE-2022-39957[2]:
| The OWASP ModSecurity Core Rule Set (CRS) is affected by a response
| body bypass. A client can issue an HTTP Accept header field containing
| an optional "charset" parameter in order to receive the response in an
| encoded form. Depending on the "charset", this response can not be
| decoded by the web application firewall. A restricted resource, access
| to which would ordinarily be detected, may therefore bypass detection.
| The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the
| currently supported versions 3.2.1 and 3.3.2. Integrators and users
| are advised to upgrade to 3.2.2 and 3.3.3 respectively.

https://coreruleset.org/20220919/crs-version-3-3-3-and-3-2-2-covering-several-cves/

CVE-2022-39958[3]:
| The OWASP ModSecurity Core Rule Set (CRS) is affected by a response
| body bypass to sequentially exfiltrate small and undetectable sections
| of data by repeatedly submitting an HTTP Range header field with a
| small byte range. A restricted resource, access to which would
| ordinarily be detected, may be exfiltrated from the backend, despite
| being protected by a web application firewall that uses CRS. Short
| subsections of a restricted resource may bypass pattern matching
| techniques and allow undetected access. The legacy CRS versions 3.0.x
| and 3.1.x are affected, as well as the currently supported versions
| 3.2.1 and 3.3.2. Integrators and users are advised to upgrade to 3.2.2
| and 3.3.3 respectively and to configure a CRS paranoia level of 3 or
| higher.

https://coreruleset.org/20220919/crs-version-3-3-3-and-3-2-2-covering-several-cves/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-39955
https://www.cve.org/CVERecord?id=CVE-2022-39955
[1] https://security-tracker.debian.org/tracker/CVE-2022-39956
https://www.cve.org/CVERecord?id=CVE-2022-39956
[2] https://security-tracker.debian.org/tracker/CVE-2022-39957
https://www.cve.org/CVERecord?id=CVE-2022-39957
[3] https://security-tracker.debian.org/tracker/CVE-2022-39958
https://www.cve.org/CVERecord?id=CVE-2022-39958

Please adjust the affected versions in the BTS as needed.

Bug#1021136: sox: CVE-2022-39236 CVE-2022-39249 CVE-2022-39251

[Moritz Mühlenhoff]

Source: sox
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for sox.

CVE-2022-39236[0]:
| Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript.
| Starting with version 17.1.0-rc.1, improperly formed beacon events can
| disrupt or impede the matrix-js-sdk from functioning properly,
| potentially impacting the consumer's ability to process data safely.
| Note that the matrix-js-sdk can appear to be operating normally but be
| excluding or corrupting runtime data presented to the consumer. This
| is patched in matrix-js-sdk v19.7.0. Redacting applicable events,
| waiting for the sync processor to store data, and restarting the
| client are possible workarounds. Alternatively, redacting the
| applicable events and clearing all storage will fix the further
| perceived issues. Downgrading to an unaffected version, noting that
| such a version may be subject to other vulnerabilities, will
| additionally resolve the issue.

https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-hvv8-5v86-r45x
https://github.com/matrix-org/matrix-js-sdk/commit/a587d7c36026fe1fcf93dfff63588abee359be76
https://github.com/matrix-org/matrix-spec-proposals/pull/3488

CVE-2022-39249[1]:
| Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript.
| Prior to version 19.7.0, an attacker cooperating with a malicious
| homeserver can construct messages appearing to have come from another
| person. Such messages will be marked with a grey shield on some
| platforms, but this may be missing in others. This attack is possible
| due to the matrix-js-sdk implementing a too permissive key forwarding
| strategy on the receiving end. Starting with version 19.7.0, the
| default policy for accepting key forwards has been made more strict in
| the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys
| in response to previously issued requests and only from own, verified
| devices. The SDK now sets a `trusted` flag on the decrypted message
| upon decryption, based on whether the key used to decrypt the message
| was received from a trusted source. Clients need to ensure that
| messages decrypted with a key with `trusted = false` are decorated
| appropriately, for example, by showing a warning for such messages.
| This attack requires coordination between a malicious homeserver and
| an attacker, and those who trust your homeservers do not need a
| workaround.

https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-6263-x97c-c4gg
https://github.com/matrix-org/matrix-js-sdk/commit/a587d7c36026fe1fcf93dfff63588abee359be76
https://github.com/matrix-org/matrix-spec-proposals/pull/3061
https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients

CVE-2022-39251[2]:
| Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript.
| Prior to version 19.7.0, an attacker cooperating with a malicious
| homeserver can construct messages that legitimately appear to have
| come from another person, without any indication such as a grey
| shield. Additionally, a sophisticated attacker cooperating with a
| malicious homeserver could employ this vulnerability to perform a
| targeted attack in order to send fake to-device messages appearing to
| originate from another user. This can allow, for example, to inject
| the key backup secret during a self-verification, to make a targeted
| device start using a malicious key backup spoofed by the homeserver.
| These attacks are possible due to a protocol confusion vulnerability
| that accepts to-device messages encrypted with Megolm instead of Olm.
| Starting with version 19.7.0, matrix-js-sdk has been modified to only
| accept Olm-encrypted to-device messages. Out of caution, several other
| checks have been audited or added. This attack requires coordination
| between a malicious home server and an attacker, so those who trust
| their home servers do not need a workaround.

https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-r48r-j8fx-mq2c
https://github.com/matrix-org/matrix-js-sdk/commit/a587d7c36026fe1fcf93dfff63588abee359be76
https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-39236
https://www.cve.org/CVERecord?id=CVE-2022-39236
[1] https://security-tracker.debian.org/tracker/CVE-2022-39249
https://www.cve.org/CVERecord?id=CVE-2022-39249
[2] https://security-tracker.debian.org/tracker/CVE-2022-39251
https://www.cve.org/CVERecord?id=CVE-2022-39251

Please adjust the affected versions in the BTS as needed.

Bug#1012196: buglist

[André]

Control: tags -1 -moreinfo

> d/copyright
> ===
>
> Some GPL-2+ licensed files have the following additional exception:
> # The developers of the Exaile media player hereby grant permission
> # for non-GPL compatible GStreamer and Exaile plugins to be used and
> # distributed together with GStreamer and Exaile. This permission is
> # above and beyond the permissions granted by the GPL license by which
> # Exaile is covered. If you modify this code, you may extend this
> # exception to your version of the code, but you are not obligated to
> # do so. If you do not wish to do so, delete this exception statement
> # from your version.

I reworked the copyright file based on 
https://sources.debian.org/src/exaile/3.4.0.2-1/debian/copyright/

Is the extension represented correct?


> d/rules
> ===
>
> Please remove or explain the lines:
>
> dh_auto_clean
> make manpage
> make completion
> ...
> #override_dh_installdocs:
> # dh_installdocs readme
> override_dh_usrlocal:
>
> Please think of a different method instead of calling dh_auto_clean 
during install time to get rid of __pycache__ if
> that is the reason for it. Maybe just copy the Makefile line '-find . 
-name "__pycache__" -exec rm -rf {} \;' ?


The point was to remove __pychache__.
Now I prevent dh_auto_build to do `make compile`

Bug#1021135: sox: CVE-2021-33844

[Moritz Mühlenhoff]

Source: sox
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for sox.

CVE-2021-33844[0]:
| A floating point exception (divide-by-zero) issue was discovered in
| SoX in functon startread() of wav.c file. An attacker with a crafted
| wav file, could cause an application to crash.

https://sourceforge.net/p/sox/bugs/349/
https://bugzilla.redhat.com/show_bug.cgi?id=1975664

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021134: sox: CVE-2021-23172

[Moritz Mühlenhoff]

Source: sox
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for sox.

CVE-2021-23172[0]:
| A vulnerability was found in SoX, where a heap-buffer-overflow occurs
| in function startread() in hcom.c file. The vulnerability is
| exploitable with a crafted hcomn file, that could cause an application
| to crash.

https://sourceforge.net/p/sox/bugs/350/
https://bugzilla.redhat.com/show_bug.cgi?id=1975666

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021133: sox: CVE-2021-23159

[Moritz Mühlenhoff]

Source: sox
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for sox.

CVE-2021-23159[0]:
| A vulnerability was found in SoX, where a heap-buffer-overflow occurs
| in function lsx_read_w_buf() in formats_i.c file. The vulnerability is
| exploitable with a crafted file, that could cause an application to
| crash.

https://sourceforge.net/p/sox/bugs/352/
https://bugzilla.redhat.com/show_bug.cgi?id=1975671

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1021132: pyqt5-dev-tools: pylupdate5 will not work in a cowbuilder shell

[Georges Khaznadar]

Package: pyqt5-dev-tools
Version: 5.15.7+dfsg-1
Severity: important

Dear Maintainer,

When I run `gbp buildpackage --git-pbuilder` to check debian packages,
it fails when pylupdate5 is invoked:

---8<--
  File "/usr/lib/python3/dist-packages/PyQt5/pylupdate_main.py", line 73, in
_encoded_path
return path.encode(locale.getdefaultlocale()[1])
TypeError: encode() argument 'encoding' must be str, not None
---8<--

This happens since Python3 became Python3.10: in a cowbuilder shell,
locale.getdefaultlocale() returns now (None, None), which may be legitimate.
However it should not prevent pylupdate to make its work. In this case,
the rigth thing to do might be: `encoding="C"; return path.encode(encoding)`

I pushed such a change into our Salsa repository, and I shall make an upload to
DELAYED+15; please feel free to tell me to cancel this upload.

Thank you in advance for any comment.

Best regards, Georges.

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


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages pyqt5-dev-tools depends on:
ii  libc6  2.35-1
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5xml5 5.15.4+dfsg-5
ii  libstdc++6 12.2.0-3
ii  python33.10.6-1
ii  python3-pyqt5  5.15.7+dfsg-1

pyqt5-dev-tools recommends no packages.

pyqt5-dev-tools suggests no packages.

-- no debconf information

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Sebastian Ramacher]

On 2022-10-02 10:51:50 -0700, eeickme...@ubuntu.com wrote:
> On Sun, 2022-10-02 at 18:44 +0200, Sebastian Ramacher wrote:
> > On 2022-10-02 08:55:34 -0700, eeickme...@ubuntu.com wrote:
> > > Hi Sebastian,
> > > 
> > > On Sun, 2022-10-02 at 17:35 +0200, Sebastian Ramacher wrote:
> > > > Control: tags -1 upstream fixed-upstream
> > > > 
> > > > On 2022-10-02 17:12:57 +0200, Sebastian Ramacher wrote:
> > > > > Control: tags -1 confirmed
> > > > > 
> > > > > On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> > > > > > Package: vlc
> > > > > > Version: 3.0.17.4-4+b2
> > > > > > Severity: important
> > > > > > X-Debbugs-Cc: arraybo...@gmail.com
> > > > > > 
> > > > > > Dear Maintainer,
> > > > > > 
> > > > > > When attempting to play back MP4 videos using VLC, only a
> > > > > > black
> > > > > > screen is
> > > > > > displayed, sometimes with the VLC logo still slightly visible
> > > > > > in
> > > > > > the
> > > > > > background. This problem appears to have been caused by the
> > > > > > introduction of
> > > > > > ffmpeg5 into Debian.
> > > > > 
> > > > > No, I don't think so. This issue is more recent.
> > > > > 
> > > > > > 
> > > > > > Steps to reproduce:
> > > > > > 
> > > > > >   1. Download a .mp4 video. Any video should work, I
> > > > > > personally
> > > > > > use drone
> > > > > >  footage from Pexels.
> > > > > >   2. Open the video using VLC. Using Media -> Open File...
> > > > > > from
> > > > > > within the
> > > > > >  GUI works, as well as using the command line (vlc
> > > > > > ./video.mp4).
> > > > > > 
> > > > > > Expected result:
> > > > > > 
> > > > > > The video should play back properly, allowing audio to be
> > > > > > heard
> > > > > > and video to
> > > > > > be seen.
> > > > > > 
> > > > > > Actual result:
> > > > > > 
> > > > > > The screen remains black (or, if you open the video from the
> > > > > > command line, the
> > > > > > VLC logo can be seen dimly in the area where the video should
> > > > > > be). The
> > > > > > playback slider moves normally, as if the video was playing
> > > > > > back
> > > > > > properly.
> > > > > 
> > > > > Indeed, I have no idea why though.
> > > > 
> > > > The issue seems to be fixed in 3.0.18-rc2.
> > > > 
> > > > Cheers
> > > 
> > > This is excellent news. FYI, we're tracking this bug in Launchpad
> > > as
> > > well at https://launchpad.net/bugs/1991457 . Not sure if you feel
> > > like
> > > packaging an rc soon for this (even in experimental), but it would
> > > definitely help us as we have multiple flavors with this seeded
> > > (Ubuntu
> > > Studio, Kubuntu, Lubuntu, and Ubuntu Unity have chimed-in so far).
> > 
> > There are no tarballs yet. Whenever they (or the 3.0.18 release)
> > becomes
> > available, I'll upload new version.
> > 
> > Cheers
> 
> Thanks. We're about 1.5 weeks away from Final Freeze, so we don't have
> time to wait for a 3.0.18 release. Is there a link to the upstream
> commit so that we can patch what we have to fix this bug downstream?

I'm afraid you'll have to bisect to find that commit.

Cheers
-- 
Sebastian Ramacher

Bug#1021032: vlc: playing mp4 videos results in a black screen

[eeickmeyer]

On Sun, 2022-10-02 at 18:44 +0200, Sebastian Ramacher wrote:
> On 2022-10-02 08:55:34 -0700, eeickme...@ubuntu.com wrote:
> > Hi Sebastian,
> > 
> > On Sun, 2022-10-02 at 17:35 +0200, Sebastian Ramacher wrote:
> > > Control: tags -1 upstream fixed-upstream
> > > 
> > > On 2022-10-02 17:12:57 +0200, Sebastian Ramacher wrote:
> > > > Control: tags -1 confirmed
> > > > 
> > > > On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> > > > > Package: vlc
> > > > > Version: 3.0.17.4-4+b2
> > > > > Severity: important
> > > > > X-Debbugs-Cc: arraybo...@gmail.com
> > > > > 
> > > > > Dear Maintainer,
> > > > > 
> > > > > When attempting to play back MP4 videos using VLC, only a
> > > > > black
> > > > > screen is
> > > > > displayed, sometimes with the VLC logo still slightly visible
> > > > > in
> > > > > the
> > > > > background. This problem appears to have been caused by the
> > > > > introduction of
> > > > > ffmpeg5 into Debian.
> > > > 
> > > > No, I don't think so. This issue is more recent.
> > > > 
> > > > > 
> > > > > Steps to reproduce:
> > > > > 
> > > > >   1. Download a .mp4 video. Any video should work, I
> > > > > personally
> > > > > use drone
> > > > >  footage from Pexels.
> > > > >   2. Open the video using VLC. Using Media -> Open File...
> > > > > from
> > > > > within the
> > > > >  GUI works, as well as using the command line (vlc
> > > > > ./video.mp4).
> > > > > 
> > > > > Expected result:
> > > > > 
> > > > > The video should play back properly, allowing audio to be
> > > > > heard
> > > > > and video to
> > > > > be seen.
> > > > > 
> > > > > Actual result:
> > > > > 
> > > > > The screen remains black (or, if you open the video from the
> > > > > command line, the
> > > > > VLC logo can be seen dimly in the area where the video should
> > > > > be). The
> > > > > playback slider moves normally, as if the video was playing
> > > > > back
> > > > > properly.
> > > > 
> > > > Indeed, I have no idea why though.
> > > 
> > > The issue seems to be fixed in 3.0.18-rc2.
> > > 
> > > Cheers
> > 
> > This is excellent news. FYI, we're tracking this bug in Launchpad
> > as
> > well at https://launchpad.net/bugs/1991457 . Not sure if you feel
> > like
> > packaging an rc soon for this (even in experimental), but it would
> > definitely help us as we have multiple flavors with this seeded
> > (Ubuntu
> > Studio, Kubuntu, Lubuntu, and Ubuntu Unity have chimed-in so far).
> 
> There are no tarballs yet. Whenever they (or the 3.0.18 release)
> becomes
> available, I'll upload new version.
> 
> Cheers

Thanks. We're about 1.5 weeks away from Final Freeze, so we don't have
time to wait for a 3.0.18 release. Is there a link to the upstream
commit so that we can patch what we have to fix this bug downstream?

Thanks in advance,
Erich

Bug#1021131: Fix national-encoding tag

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.132
Severity: wishlist

Yadd writes in https://salsa.debian.org/jelmer/janitor/-/issues/153:

> could Janitor fix this lintian tag? Here is a little script I use for this:
> 
> ```bash
> #!/bin/bash
> TO="UTF-8"; FILE=$1
> FROM=$(file -i $FILE | cut -d'=' -f2)
> if [[ $FROM = "binary" ]]; then
>  echo "Skipping binary $FILE..."
>  exit 0
> fi
> iconv -f $FROM -t $TO -o $FILE.tmp $FILE; ERROR=$?
> if [[ $ERROR -eq 0 ]]; then
>   echo "Converting $FILE..."
>   mv -f $FILE.tmp $FILE
> else
>   echo "Error on $FILE"
> fi
> ```

Running "select information from lintian where tag = 'national-encoding' and 
package_type = 'source';" in UDD I see 731 issues for this tag.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.22.2
ii  python3  3.10.6-1
ii  python3-breezy   3.2.2-2+b1
ii  python3-debian   0.1.47
ii  python3-debmutate0.57
ii  python3-distro-info  1.1
ii  python3-dulwich  0.20.46-1
ii  python3-iniparse 0.5-1
ii  python3-iso8601  1.0.2-1
ii  python3-ruamel.yaml  0.17.16-1
ii  python3-tqdm 4.64.0-2
ii  python3-upstream-ontologist  0.1.25-2

Versions of packages lintian-brush recommends:
ii  debhelper13.9.1
ii  decopy   0.2.4.7-0.2
ii  dos2unix 7.4.3-1
ii  gpg  2.2.39-1
ii  lintian  2.115.3
ii  ognibuild0.0.13-1
ii  python3-asyncpg  0.26.0-1
ii  python3-bs4  4.11.1-1
ii  python3-docutils 0.17.1+dfsg-2
ii  python3-levenshtein  0.12.2-2+b2
ii  python3-lxml 4.9.1-1+b1
ii  python3-markdown 3.4.1-1
ii  python3-pyinotify0.9.6-2
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.9.2-1

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.70
ii  git-buildpackage   0.9.28
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  243

-- debconf-show failed

Bug#1021130: bullseye-pu: package tinyexr/1.0.1+dfsg-1+deb11u1

[Timo Röhling]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,
I'd like to update tinyexr in bullseye

[ Reason ]
The update fixes two vulnerabilities with low priority, i.e.
the security team has decided not to issue a DSA.

[ Impact ]
CVE-2022-34300: Heap overflow in DecodePixelData
CVE-2022-38529: Heap overflow in rleUncompress

[ Tests ]
I have verified that the changes fix the aforementioned vulnerabilities
and do not cause regressions in the package test suite.

[ Risks ]
tinyexr is a low popcon package with two reverse dependencies
(both of which I maintain).
Both code fixes are localized and unlikely to cause further issues.

[ 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 ]
The update patches two statements in two functions


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmM5zIAACgkQ+C8H+466
LVnfmAv7BCTx2RPhA8gGGRGpHjQGY9o8gwWoTfKocWmPfJgEz3KLt3HntP7jo3fn
x6QooHIYCJ8iveUPD1J0zK5wgr//22Z9iER1Uuk/48SVAVKXDbuvak3wJer5ssDl
pAwluYXdMNREfOcu49sJ0cs5WmaPFsv7Kt1LLWfsTBRru3ekLwYI4AkHrCFpSfy0
SVEm4zF/99athm4Pd/teV1znvXcmhAW64UxoypsSJpdJm46kyZ2fHZPxMOVkaQGe
Vz4mROOoAMA60stDL0ot/iFjiUCen/dUlR/K8VP3h3l3NI6/hgLiGW7QvrVom07j
J0knQxnnMn+RVJGQRxaWFm/Qculk9xvY8H/uekvgZglWMxoW2FmJCvTnlizETCB6
MxIf0aHQRDgY+0g1VbAGsOZ12xjkTV5BhsKADN+eOHI0hfwiNJEkjMLVOnUNdnhC
qHYZILTfH4sTXs/xNlGJ49KJlFYmizsNwEIL0CTi6eVf062whzUFiRmDN/JYMvax
+/SrWuWb
=WbEi
-END PGP SIGNATURE-
diff -Nru tinyexr-1.0.1+dfsg/debian/changelog 
tinyexr-1.0.1+dfsg/debian/changelog
--- tinyexr-1.0.1+dfsg/debian/changelog 2021-08-29 20:43:34.0 +0200
+++ tinyexr-1.0.1+dfsg/debian/changelog 2022-10-01 23:13:34.0 +0200
@@ -1,3 +1,11 @@
+tinyexr (1.0.1+dfsg-1+deb11u1) bullseye; urgency=medium
+
+  * Fix low-priority vulnerabilities
+- CVE-2022-34300: Heap overflow in DecodePixelData
+- CVE-2022-38529: Heap overflow in rleUncompress
+
+ -- Timo Röhling   Sat, 01 Oct 2022 23:13:34 +0200
+
 tinyexr (1.0.1+dfsg-1) unstable; urgency=medium
 
   * New upstream version 1.0.1+dfsg
diff -Nru tinyexr-1.0.1+dfsg/debian/patches/0005-CVE-2022-38529.patch 
tinyexr-1.0.1+dfsg/debian/patches/0005-CVE-2022-38529.patch
--- tinyexr-1.0.1+dfsg/debian/patches/0005-CVE-2022-38529.patch 1970-01-01 
01:00:00.0 +0100
+++ tinyexr-1.0.1+dfsg/debian/patches/0005-CVE-2022-38529.patch 2022-10-01 
23:13:34.0 +0200
@@ -0,0 +1,25 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?= 
+Date: Thu, 8 Sep 2022 19:31:26 +0200
+Subject: CVE-2022-38529
+
+Fix heap buffer overflow in rleUncompress.
+Backported from upstream commit cc1b199dd17b700c3130a53866ea462ab88e7f82
+
+Forwarded: not-needed
+---
+ tinyexr.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tinyexr.h b/tinyexr.h
+index eb5e5c0..ba05fdf 100644
+--- a/tinyexr.h
 b/tinyexr.h
+@@ -1480,7 +1480,7 @@ static int rleUncompress(int inLength, int maxLength, 
const signed char in[],
+   int count = *in++;
+   inLength -= 2;
+ 
+-  if (0 > (maxLength -= count + 1)) return 0;
++  if (0 > (maxLength -= count + 1) || inLength < 0) return 0;
+ 
+   memset(out, *reinterpret_cast(in), count + 1);
+   out += count + 1;
diff -Nru tinyexr-1.0.1+dfsg/debian/patches/0006-CVE-2022-34300.patch 
tinyexr-1.0.1+dfsg/debian/patches/0006-CVE-2022-34300.patch
--- tinyexr-1.0.1+dfsg/debian/patches/0006-CVE-2022-34300.patch 1970-01-01 
01:00:00.0 +0100
+++ tinyexr-1.0.1+dfsg/debian/patches/0006-CVE-2022-34300.patch 2022-10-01 
23:13:34.0 +0200
@@ -0,0 +1,26 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?= 
+Date: Thu, 8 Sep 2022 20:38:54 +0200
+Subject: CVE-2022-34300
+
+Fix heap buffer overflow in DecodePixelData.
+
+Forwarded: https://github.com/syoyo/tinyexr/pull/175
+---
+ tinyexr.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tinyexr.h b/tinyexr.h
+index ba05fdf..c36e6ec 100644
+--- a/tinyexr.h
 b/tinyexr.h
+@@ -3568,8 +3568,8 @@ static bool DecodePixelData(/* out */ unsigned char 
**out_images,
+ assert(requested_pixel_types[c] == TINYEXR_PIXELTYPE_FLOAT);
+ for (size_t v = 0; v < static_cast(num_lines); v++) {
+   const float *line_ptr = reinterpret_cast((
+-  v * pixel_data_size * static_cast(x_stride) +
+-  channel_offset_list[c] * static_cast(x_stride)));
++  v * pixel_data_size * static_cast(width) +
++  channel_offset_list[c] * static_cast(width)));
+   for (size_t u = 0; u < static_cast(width); u++) {
+ float val;
+ // val = line_ptr[u];
diff -Nru tinyexr-1.0.1+dfsg/debian/patches/series 
tinyexr-1.0.1+dfsg/debian/patches/series
--- tinyexr-1.0.1+dfsg/debian/patches/series2021-08-29 

Bug#1021047: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Tommi,

there is a reverse dependency that needs to be taken care of:


Checking reverse dependencies...
# Broken Depends:
gwave: gwave

# Broken Build-Depends:
gwave: guile-gnome2-dev


In case it matters, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1021102: RM: uim [armel armhf] -- RoQA; FTBFS, blocks Qt transition

[Thorsten Alteholz]

Hi Dmitry,

On 02.10.22 10:07, Dmitry Shachnev wrote:

Unfortunately these reverse dependencies will need to be removed too:
gkrelluim, mlterm-im-uim, uim-chewing, uim-mozc.


please file separate RM bugs for each of them.

Thanks!
 Thorsten

Bug#1021129: deal with fuzz in debian/patches

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.132
Severity: wishlist

lintian-brush should deal better with patch application:

* 
https://janitor.debian.net/cupboard/pkg/ros-robot-model/96756a8d-9272-40d6-ad26-30eb25a43326/
* 
https://janitor.debian.net/cupboard/pkg/doomsday/8c0583cf-609a-47dc-8273-2be8e441e03f/
* 
https://janitor.debian.net/cupboard/pkg/jnoisemeter/cd7ef123-502c-4274-9bb4-0b6aaf54a41f/
* 
https://janitor.debian.net/cupboard/pkg/giada/bbf98d6d-744e-4814-83c7-3e30d23041b4/


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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.22.2
ii  python3  3.10.6-1
ii  python3-breezy   3.2.2-2+b1
ii  python3-debian   0.1.47
ii  python3-debmutate0.57
ii  python3-distro-info  1.1
ii  python3-dulwich  0.20.46-1
ii  python3-iniparse 0.5-1
ii  python3-iso8601  1.0.2-1
ii  python3-ruamel.yaml  0.17.16-1
ii  python3-tqdm 4.64.0-2
ii  python3-upstream-ontologist  0.1.25-2

Versions of packages lintian-brush recommends:
ii  debhelper13.9.1
ii  decopy   0.2.4.7-0.2
ii  dos2unix 7.4.3-1
ii  gpg  2.2.39-1
ii  lintian  2.115.3
ii  ognibuild0.0.13-1
ii  python3-asyncpg  0.26.0-1
ii  python3-bs4  4.11.1-1
ii  python3-docutils 0.17.1+dfsg-2
ii  python3-levenshtein  0.12.2-2+b2
ii  python3-lxml 4.9.1-1+b1
ii  python3-markdown 3.4.1-1
ii  python3-pyinotify0.9.6-2
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.9.2-1

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.70
ii  git-buildpackage   0.9.28
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  243

-- debconf-show failed

Bug#1021128: nmu: grpc_1.44.0-3

[Pirate Praveen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 1021113 by -1

nmu grpc_1.44.0-3 . ANY . experimental . -m "Rebuild with 
libabsl20220623"

Bug#1021115: unifrac-tools: Baseline violation on x86 and FTBFS everywhere else

[Étienne Mollier]

Adrian Bunk, on 2022-10-02:
> I was talking about a different change that would have been wrong:
> 
> -ifeq ($(PERFORMING_CONDA_BUILD),True)
>  CPPFLAGS += -mtune=generic
> -else
> -CPPFLAGS += -mfma -march=native
> -endif
> 
> 
> This would have fixed the baseline violation,
> but broken the build on non-x86 in a different way.

Right, I see your point.  True the -mtune= options are not valid
on several architectures.  Thanks for the clarification!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Colin Watson]

On Sun, Oct 02, 2022 at 05:50:07PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Colin Watson (2022-10-02 17:00:58)
> > As well as more localized testing, I built a .deb with this and used
> > josch's instructions from the start of this bug to build mmdebstrap
> > tarballs via disorderfs, using
> > "--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
> > --include=./man-db_2.10.3~20221002-1_amd64.deb" to inject the new .deb.
> > The two resulting tarballs had somewhat differing file lists (timestamps
> > etc.), but all the actual files in the tarballs were bitwise-identical.
> 
> Did you maybe forget the "export SOURCE_DATE_EPOCH=XXX" step? Just replace XXX
> with the output of `date +%s` but make sure that both mmdebstrap invocations
> see the same value for SOURCE_DATE_EPOCH and then there should be zero
> differences and a "cmp" should be sufficient to make sure that it works.

I thought I'd set SOURCE_DATE_EPOCH, but I'd failed to pass it through
sudo.  After fixing that, I indeed get cmp-identical tarballs.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Sebastian Ramacher]

On 2022-10-02 08:55:34 -0700, eeickme...@ubuntu.com wrote:
> Hi Sebastian,
> 
> On Sun, 2022-10-02 at 17:35 +0200, Sebastian Ramacher wrote:
> > Control: tags -1 upstream fixed-upstream
> > 
> > On 2022-10-02 17:12:57 +0200, Sebastian Ramacher wrote:
> > > Control: tags -1 confirmed
> > > 
> > > On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> > > > Package: vlc
> > > > Version: 3.0.17.4-4+b2
> > > > Severity: important
> > > > X-Debbugs-Cc: arraybo...@gmail.com
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > When attempting to play back MP4 videos using VLC, only a black
> > > > screen is
> > > > displayed, sometimes with the VLC logo still slightly visible in
> > > > the
> > > > background. This problem appears to have been caused by the
> > > > introduction of
> > > > ffmpeg5 into Debian.
> > > 
> > > No, I don't think so. This issue is more recent.
> > > 
> > > > 
> > > > Steps to reproduce:
> > > > 
> > > >   1. Download a .mp4 video. Any video should work, I personally
> > > > use drone
> > > >  footage from Pexels.
> > > >   2. Open the video using VLC. Using Media -> Open File... from
> > > > within the
> > > >  GUI works, as well as using the command line (vlc
> > > > ./video.mp4).
> > > > 
> > > > Expected result:
> > > > 
> > > > The video should play back properly, allowing audio to be heard
> > > > and video to
> > > > be seen.
> > > > 
> > > > Actual result:
> > > > 
> > > > The screen remains black (or, if you open the video from the
> > > > command line, the
> > > > VLC logo can be seen dimly in the area where the video should
> > > > be). The
> > > > playback slider moves normally, as if the video was playing back
> > > > properly.
> > > 
> > > Indeed, I have no idea why though.
> > 
> > The issue seems to be fixed in 3.0.18-rc2.
> > 
> > Cheers
> 
> This is excellent news. FYI, we're tracking this bug in Launchpad as
> well at https://launchpad.net/bugs/1991457 . Not sure if you feel like
> packaging an rc soon for this (even in experimental), but it would
> definitely help us as we have multiple flavors with this seeded (Ubuntu
> Studio, Kubuntu, Lubuntu, and Ubuntu Unity have chimed-in so far).

There are no tarballs yet. Whenever they (or the 3.0.18 release) becomes
available, I'll upload new version.

Cheers
-- 
Sebastian Ramacher

Bug#1021127: geany-plugins FTBFS with libgit2 1.5.0

[Adrian Bunk]

Source: geany-plugins
Version: 1.38+dfsg-1
Severity: serious
Tags: ftbfs
Forwarded: https://github.com/geany/geany-plugins/issues/1164

https://buildd.debian.org/status/logs.php?pkg=geany-plugins=1.38%2Bdfsg-1%2Bb2

...
gcb-plugin.c: In function ‘gcb_git_buf_grow’:
gcb-plugin.c:219:12: error: ‘git_buf’ has no member named ‘asize’; did you mean 
‘size’?
  219 |   if (buf->asize == 0) {
  |^
  |size
gcb-plugin.c: In function ‘buf_zero’:
gcb-plugin.c:237:10: error: ‘git_buf’ has no member named ‘asize’; did you mean 
‘size’?
  237 | buf->asize = 0;
  |  ^
  |  size
...

Bug#951805: Help with glbinding

[Andrea Pappacoda]

Hi Ghislain, glbinding hasn't been updated in four years. Would you 
like some help with the package? I've used glbinding in the past, and 
I'd be happy to help with maintenance under the Science team.


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1021115: unifrac-tools: Baseline violation on x86 and FTBFS everywhere else

[Adrian Bunk]

On Sun, Oct 02, 2022 at 05:13:33PM +0200, Étienne Mollier wrote:
> Hi Adrian,
> 
> Adrian Bunk, on 2022-10-02:
> > src/Makefile:
> > ...
> > ifeq ($(PERFORMING_CONDA_BUILD),True)
> > CPPFLAGS += -mtune=generic
> > else
> > CPPFLAGS += -mfma -march=native
> > endif
> > ...
> > 
> > 
> > 
> > Please remove this block, it is a baseline violation on x86
> > and causes FTBFS everywhere else.
> > 
> > Please don't use the PERFORMING_CONDA_BUILD case instead:
> > -mtune=generic is already the Debian default on x86,
> > but it is not supported on some/all(?) other architectures.
> 
> Done, the PERFORMING_CONDA_BUILD variable is specific to conda
> distribution and normally not related to enabling SIMD support.
> Touching it on the debian package end would also enable a lot of
> other bits which we probably don't need or want.

I was talking about a different change that would have been wrong:

-ifeq ($(PERFORMING_CONDA_BUILD),True)
 CPPFLAGS += -mtune=generic
-else
-CPPFLAGS += -mfma -march=native
-endif


This would have fixed the baseline violation,
but broken the build on non-x86 in a different way.


> Thanks for your report!
> 
> Have a nice day,  :)

cu
Adrian

Bug#1021126: RFS: libunistring/1.0-2 -- Unicode string library for C

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : libunistring
   Version  : 1.0-2
   Upstream contact : Bruno Haible 
   URL  : https://www.gnu.org/software/libunistring/
   License  : FreeSoftware, GPL-3+, GPL-3+ or GFDL-1.2+, MIT, 
  GPL-2+, LGPL-3+ or GPL-2+,
  GPL-2+ with distribution exception
   Vcs  : https://jff.email/cgit/libunistring.git
   Section  : libs

The source builds the following binary packages:

  libunistring-dev - Unicode string library for C - development files
  libunistring2 - Unicode string library for C

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.0-2.dsc

or from 

 git https://jff.email/cgit/libunistring.git?h=release%2Fdebian%2F1.0-2



Changes since the last upload:

 libunistring (1.0-2) unstable; urgency=medium
 .
   * debian/libunistring2.symbols.hurd-i386:
 - Refresh symbols (Closes: #1018232).
   * debian/libunistring2.symbols:
 - Refresh symbols.
   * Replace upstream signing key.
   * Declare compliance with Debian Policy 4.6.1.0 (No changes needed).


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1021032: vlc: playing mp4 videos results in a black screen

[eeickmeyer]

Hi Sebastian,

On Sun, 2022-10-02 at 17:35 +0200, Sebastian Ramacher wrote:
> Control: tags -1 upstream fixed-upstream
> 
> On 2022-10-02 17:12:57 +0200, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > 
> > On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> > > Package: vlc
> > > Version: 3.0.17.4-4+b2
> > > Severity: important
> > > X-Debbugs-Cc: arraybo...@gmail.com
> > > 
> > > Dear Maintainer,
> > > 
> > > When attempting to play back MP4 videos using VLC, only a black
> > > screen is
> > > displayed, sometimes with the VLC logo still slightly visible in
> > > the
> > > background. This problem appears to have been caused by the
> > > introduction of
> > > ffmpeg5 into Debian.
> > 
> > No, I don't think so. This issue is more recent.
> > 
> > > 
> > > Steps to reproduce:
> > > 
> > >   1. Download a .mp4 video. Any video should work, I personally
> > > use drone
> > >  footage from Pexels.
> > >   2. Open the video using VLC. Using Media -> Open File... from
> > > within the
> > >  GUI works, as well as using the command line (vlc
> > > ./video.mp4).
> > > 
> > > Expected result:
> > > 
> > > The video should play back properly, allowing audio to be heard
> > > and video to
> > > be seen.
> > > 
> > > Actual result:
> > > 
> > > The screen remains black (or, if you open the video from the
> > > command line, the
> > > VLC logo can be seen dimly in the area where the video should
> > > be). The
> > > playback slider moves normally, as if the video was playing back
> > > properly.
> > 
> > Indeed, I have no idea why though.
> 
> The issue seems to be fixed in 3.0.18-rc2.
> 
> Cheers

This is excellent news. FYI, we're tracking this bug in Launchpad as
well at https://launchpad.net/bugs/1991457 . Not sure if you feel like
packaging an rc soon for this (even in experimental), but it would
definitely help us as we have multiple flavors with this seeded (Ubuntu
Studio, Kubuntu, Lubuntu, and Ubuntu Unity have chimed-in so far).

Thanks,
Erich

> 
> > 
> > Cheers
> > 
> > > 
> > > Additional notes:
> > > 
> > > This bug was first discovered in Ubuntu 22.10 Kinetic Kudu,
> > > however it is also
> > > easily reproducible using Debian Sid. The bug exists both on
> > > physical and
> > > virtual hardware on Ubuntu, and I have been able to replicate it
> > > in a virtual
> > > machine on Debian.
> > > 
> > > -- System Information:
> > > Debian Release: bookworm/sid
> > >   APT prefers unstable
> > >   APT policy: (500, 'unstable')
> > > Architecture: amd64 (x86_64)
> > > 
> > > Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > > LANGUAGE not set
> > > Shell: /bin/sh linked to /usr/bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > > 
> > > Versions of packages vlc depends on:
> > > ii  vlc-bin  3.0.17.4-4+b2
> > > ii  vlc-plugin-base  3.0.17.4-4+b2
> > > ii  vlc-plugin-qt    3.0.17.4-4+b2
> > > ii  vlc-plugin-video-output  3.0.17.4-4+b2
> > > 
> > > Versions of packages vlc recommends:
> > > ii  vlc-l10n   3.0.17.4-4
> > > ii  vlc-plugin-access-extra    3.0.17.4-4+b2
> > > ii  vlc-plugin-notify  3.0.17.4-4+b2
> > > ii  vlc-plugin-samba   3.0.17.4-4+b2
> > > ii  vlc-plugin-skins2  3.0.17.4-4+b2
> > > ii  vlc-plugin-video-splitter  3.0.17.4-4+b2
> > > ii  vlc-plugin-visualization   3.0.17.4-4+b2
> > > 
> > > Versions of packages vlc suggests:
> > > pn  vlc-plugin-fluidsynth  
> > > pn  vlc-plugin-jack    
> > > pn  vlc-plugin-pipewire    
> > > pn  vlc-plugin-svg 
> > > 
> > > Versions of packages libvlc-bin depends on:
> > > ii  libc6    2.35-1
> > > ii  libvlc5  3.0.17.4-4+b2
> > > 
> > > Versions of packages libvlc5 depends on:
> > > ii  libc6    2.35-1
> > > ii  libvlccore9  3.0.17.4-4+b2
> > > 
> > > Versions of packages libvlc5 recommends:
> > > ii  libvlc-bin  3.0.17.4-4+b2
> > > 
> > > Versions of packages vlc-bin depends on:
> > > ii  libc6   2.35-1
> > > ii  libvlc-bin  3.0.17.4-4+b2
> > > ii  libvlc5 3.0.17.4-4+b2
> > > 
> > > Versions of packages vlc-plugin-access-extra depends on:
> > > ii  libc6    2.35-1
> > > ii  libsrt1.5-gnutls 1.5.1-1
> > > ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.17.4-4+b2
> > > ii  libvncclient1    0.9.13+dfsg-4
> > > ii  libxcb-composite0    1.15-1
> > > ii  libxcb-shm0  1.15-1
> > > ii  libxcb1  1.15-1
> > > 
> > > Versions of packages vlc-plugin-base depends on:
> > > ii  liba52-0.7.4 0.7.4-20
> > > ii  libarchive13 3.6.0-1
> > > ii  libaribb24-0 1.0.3-2
> > > ii  libasound2   1.2.7.2-1
> > > ii  libass9  1:0.16.0-1
> > > ii  libavahi-client3 0.8-6
> > > ii  

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Dominique Dumont]

On Wed, 28 Sep 2022 12:17:48 +0200 Dominique Dumont  wrote:
> I'll have to reach out to upstream to investigate.

I've a fix from upstream for rakudo package. The fix is added in rakudo 
2020.07-2

I need to re-upload the affected module packages to depend on that version of 
rakudo (so the package is rebuilt without the conflicting file).

I will not upload a new version of perl6-readline. This package is replaced by 
raku-readline and has a RM bug filed.

All the best

Dod

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Johannes Schauer Marin Rodrigues]

Quoting Colin Watson (2022-10-02 17:00:58)
> Success!
> 
>   https://gitlab.com/cjwatson/man-db/-/compare/5d2594d0a0...866c3571d3

Thank you!! :D

> 
> As well as more localized testing, I built a .deb with this and used
> josch's instructions from the start of this bug to build mmdebstrap
> tarballs via disorderfs, using
> "--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
> --include=./man-db_2.10.3~20221002-1_amd64.deb" to inject the new .deb.
> The two resulting tarballs had somewhat differing file lists (timestamps
> etc.), but all the actual files in the tarballs were bitwise-identical.

Did you maybe forget the "export SOURCE_DATE_EPOCH=XXX" step? Just replace XXX
with the output of `date +%s` but make sure that both mmdebstrap invocations
see the same value for SOURCE_DATE_EPOCH and then there should be zero
differences and a "cmp" should be sufficient to make sure that it works.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Sebastian Ramacher]

Control: tags -1 upstream fixed-upstream

On 2022-10-02 17:12:57 +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> > Package: vlc
> > Version: 3.0.17.4-4+b2
> > Severity: important
> > X-Debbugs-Cc: arraybo...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > When attempting to play back MP4 videos using VLC, only a black screen is
> > displayed, sometimes with the VLC logo still slightly visible in the
> > background. This problem appears to have been caused by the introduction of
> > ffmpeg5 into Debian.
> 
> No, I don't think so. This issue is more recent.
> 
> > 
> > Steps to reproduce:
> > 
> >   1. Download a .mp4 video. Any video should work, I personally use drone
> >  footage from Pexels.
> >   2. Open the video using VLC. Using Media -> Open File... from within the
> >  GUI works, as well as using the command line (vlc ./video.mp4).
> > 
> > Expected result:
> > 
> > The video should play back properly, allowing audio to be heard and video to
> > be seen.
> > 
> > Actual result:
> > 
> > The screen remains black (or, if you open the video from the command line, 
> > the
> > VLC logo can be seen dimly in the area where the video should be). The
> > playback slider moves normally, as if the video was playing back properly.
> 
> Indeed, I have no idea why though.

The issue seems to be fixed in 3.0.18-rc2.

Cheers

> 
> Cheers
> 
> > 
> > Additional notes:
> > 
> > This bug was first discovered in Ubuntu 22.10 Kinetic Kudu, however it is 
> > also
> > easily reproducible using Debian Sid. The bug exists both on physical and
> > virtual hardware on Ubuntu, and I have been able to replicate it in a 
> > virtual
> > machine on Debian.
> > 
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages vlc depends on:
> > ii  vlc-bin  3.0.17.4-4+b2
> > ii  vlc-plugin-base  3.0.17.4-4+b2
> > ii  vlc-plugin-qt3.0.17.4-4+b2
> > ii  vlc-plugin-video-output  3.0.17.4-4+b2
> > 
> > Versions of packages vlc recommends:
> > ii  vlc-l10n   3.0.17.4-4
> > ii  vlc-plugin-access-extra3.0.17.4-4+b2
> > ii  vlc-plugin-notify  3.0.17.4-4+b2
> > ii  vlc-plugin-samba   3.0.17.4-4+b2
> > ii  vlc-plugin-skins2  3.0.17.4-4+b2
> > ii  vlc-plugin-video-splitter  3.0.17.4-4+b2
> > ii  vlc-plugin-visualization   3.0.17.4-4+b2
> > 
> > Versions of packages vlc suggests:
> > pn  vlc-plugin-fluidsynth  
> > pn  vlc-plugin-jack
> > pn  vlc-plugin-pipewire
> > pn  vlc-plugin-svg 
> > 
> > Versions of packages libvlc-bin depends on:
> > ii  libc62.35-1
> > ii  libvlc5  3.0.17.4-4+b2
> > 
> > Versions of packages libvlc5 depends on:
> > ii  libc62.35-1
> > ii  libvlccore9  3.0.17.4-4+b2
> > 
> > Versions of packages libvlc5 recommends:
> > ii  libvlc-bin  3.0.17.4-4+b2
> > 
> > Versions of packages vlc-bin depends on:
> > ii  libc6   2.35-1
> > ii  libvlc-bin  3.0.17.4-4+b2
> > ii  libvlc5 3.0.17.4-4+b2
> > 
> > Versions of packages vlc-plugin-access-extra depends on:
> > ii  libc62.35-1
> > ii  libsrt1.5-gnutls 1.5.1-1
> > ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.17.4-4+b2
> > ii  libvncclient10.9.13+dfsg-4
> > ii  libxcb-composite01.15-1
> > ii  libxcb-shm0  1.15-1
> > ii  libxcb1  1.15-1
> > 
> > Versions of packages vlc-plugin-base depends on:
> > ii  liba52-0.7.4 0.7.4-20
> > ii  libarchive13 3.6.0-1
> > ii  libaribb24-0 1.0.3-2
> > ii  libasound2   1.2.7.2-1
> > ii  libass9  1:0.16.0-1
> > ii  libavahi-client3 0.8-6
> > ii  libavahi-common3 0.8-6
> > ii  libavc1394-0 0.5.4-5
> > ii  libavcodec59 7:5.1.1-2+b1
> > ii  libavformat597:5.1.1-2+b1
> > ii  libavutil57  7:5.1.1-2+b1
> > ii  libbluray2   1:1.3.3-1
> > ii  libc62.35-1
> > ii  libcairo21.16.0-6
> > ii  libcddb2 1.3.2-7
> > ii  libchromaprint1  1.5.1-2+b1
> > ii  libdav1d61.0.0-2
> > ii  libdbus-1-3  1.14.2-1
> > ii  libdc1394-25 2.2.6-4
> > ii  libdca0  

Bug#1003677: reproduced

[Benda Xu]

Thanks Vasilis, I could reproduce this error.  The fix will come
together with the new version.

Yours,
Benda

Bug#1021115: unifrac-tools: Baseline violation on x86 and FTBFS everywhere else

[Étienne Mollier]

Hi Adrian,

Adrian Bunk, on 2022-10-02:
> src/Makefile:
> ...
> ifeq ($(PERFORMING_CONDA_BUILD),True)
> CPPFLAGS += -mtune=generic
> else
> CPPFLAGS += -mfma -march=native
> endif
> ...
> 
> 
> 
> Please remove this block, it is a baseline violation on x86
> and causes FTBFS everywhere else.
> 
> Please don't use the PERFORMING_CONDA_BUILD case instead:
> -mtune=generic is already the Debian default on x86,
> but it is not supported on some/all(?) other architectures.

Done, the PERFORMING_CONDA_BUILD variable is specific to conda
distribution and normally not related to enabling SIMD support.
Touching it on the debian package end would also enable a lot of
other bits which we probably don't need or want.

Thanks for your report!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Life Line Project - The King - Doom


signature.asc
Description: PGP signature

Bug#1021032: vlc: playing mp4 videos results in a black screen

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-09-30 13:23:02 -0500, Aaron Rainbolt wrote:
> Package: vlc
> Version: 3.0.17.4-4+b2
> Severity: important
> X-Debbugs-Cc: arraybo...@gmail.com
> 
> Dear Maintainer,
> 
> When attempting to play back MP4 videos using VLC, only a black screen is
> displayed, sometimes with the VLC logo still slightly visible in the
> background. This problem appears to have been caused by the introduction of
> ffmpeg5 into Debian.

No, I don't think so. This issue is more recent.

> 
> Steps to reproduce:
> 
>   1. Download a .mp4 video. Any video should work, I personally use drone
>  footage from Pexels.
>   2. Open the video using VLC. Using Media -> Open File... from within the
>  GUI works, as well as using the command line (vlc ./video.mp4).
> 
> Expected result:
> 
> The video should play back properly, allowing audio to be heard and video to
> be seen.
> 
> Actual result:
> 
> The screen remains black (or, if you open the video from the command line, the
> VLC logo can be seen dimly in the area where the video should be). The
> playback slider moves normally, as if the video was playing back properly.

Indeed, I have no idea why though.

Cheers

> 
> Additional notes:
> 
> This bug was first discovered in Ubuntu 22.10 Kinetic Kudu, however it is also
> easily reproducible using Debian Sid. The bug exists both on physical and
> virtual hardware on Ubuntu, and I have been able to replicate it in a virtual
> machine on Debian.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.17.4-4+b2
> ii  vlc-plugin-base  3.0.17.4-4+b2
> ii  vlc-plugin-qt3.0.17.4-4+b2
> ii  vlc-plugin-video-output  3.0.17.4-4+b2
> 
> Versions of packages vlc recommends:
> ii  vlc-l10n   3.0.17.4-4
> ii  vlc-plugin-access-extra3.0.17.4-4+b2
> ii  vlc-plugin-notify  3.0.17.4-4+b2
> ii  vlc-plugin-samba   3.0.17.4-4+b2
> ii  vlc-plugin-skins2  3.0.17.4-4+b2
> ii  vlc-plugin-video-splitter  3.0.17.4-4+b2
> ii  vlc-plugin-visualization   3.0.17.4-4+b2
> 
> Versions of packages vlc suggests:
> pn  vlc-plugin-fluidsynth  
> pn  vlc-plugin-jack
> pn  vlc-plugin-pipewire
> pn  vlc-plugin-svg 
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.35-1
> ii  libvlc5  3.0.17.4-4+b2
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.35-1
> ii  libvlccore9  3.0.17.4-4+b2
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.17.4-4+b2
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.35-1
> ii  libvlc-bin  3.0.17.4-4+b2
> ii  libvlc5 3.0.17.4-4+b2
> 
> Versions of packages vlc-plugin-access-extra depends on:
> ii  libc62.35-1
> ii  libsrt1.5-gnutls 1.5.1-1
> ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.17.4-4+b2
> ii  libvncclient10.9.13+dfsg-4
> ii  libxcb-composite01.15-1
> ii  libxcb-shm0  1.15-1
> ii  libxcb1  1.15-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-20
> ii  libarchive13 3.6.0-1
> ii  libaribb24-0 1.0.3-2
> ii  libasound2   1.2.7.2-1
> ii  libass9  1:0.16.0-1
> ii  libavahi-client3 0.8-6
> ii  libavahi-common3 0.8-6
> ii  libavc1394-0 0.5.4-5
> ii  libavcodec59 7:5.1.1-2+b1
> ii  libavformat597:5.1.1-2+b1
> ii  libavutil57  7:5.1.1-2+b1
> ii  libbluray2   1:1.3.3-1
> ii  libc62.35-1
> ii  libcairo21.16.0-6
> ii  libcddb2 1.3.2-7
> ii  libchromaprint1  1.5.1-2+b1
> ii  libdav1d61.0.0-2
> ii  libdbus-1-3  1.14.2-1
> ii  libdc1394-25 2.2.6-4
> ii  libdca0  0.0.7-2
> ii  libdvbpsi10  1.3.3-1
> ii  libdvdnav4   6.1.1-1
> ii  libdvdread8  6.1.3-1
> ii  libebml5 1.4.2-2+b1
> ii  libfaad2 2.10.0-2+b1
> ii  libflac8 1.3.4-2
> ii  libfontconfig1   2.13.1-4.5
> ii  libfreetype6 

Bug#913905: i3-wm: focus sometimes stucks on the previous window

[Jakob Haufe]

Control: tags -1 + moreinfo

Does this still apply to current versions of i3?


-- 
ceterum censeo microsoftem esse delendam.


pgpo9Oah4xWkb.pgp
Description: OpenPGP digital signature

Bug#1021123: libgdbm-compat-dev: missing dependency on libgdbm-dev

[Colin Watson]

Package: libgdbm-compat-dev
Version: 1.23-2
Severity: serious
Justification: Policy 3.5

The header files in libgdbm-compat-dev (dbm.h, gdbm-ndbm.h, and ndbm.h)
all have "#include ".  libgdbm-compat-dev therefore needs to
depend on libgdbm-dev so that this #include can be resolved.

(Noticed while improving man-db's upstream CI jobs.)

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Colin Watson]

Control: tag -1 fixed-upstream

Success!

  https://gitlab.com/cjwatson/man-db/-/compare/5d2594d0a0...866c3571d3

As well as more localized testing, I built a .deb with this and used
josch's instructions from the start of this bug to build mmdebstrap
tarballs via disorderfs, using
"--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
--include=./man-db_2.10.3~20221002-1_amd64.deb" to inject the new .deb.
The two resulting tarballs had somewhat differing file lists (timestamps
etc.), but all the actual files in the tarballs were bitwise-identical.

Feel free to do any other testing you think might be useful.  There's a
bootstrapped source tarball attached as an artifact to the
"build-distcheck" CI job in GitLab that you can easily use to build a
snapshot .deb if you need one.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1021122: ssh: Please increase unix_listener socket path limit (path ... too long for Unix domain socket)

[Petter Reinholdtsen]

Package: openssh-client
Version: 1:8.4p1-5

When using ssh with torsocks to log into a machine with ssh available
via Tor, and ~/.ssh/config set up to use a control socket, I get this
error when I try to log in (note, the onion address has been replaced
with a different one without SSH available, as I do not want to share
the name of my internal servers and picked one of the Debian APT source
addresses as a replacement):

  unix_listener: path

"/home/user/.ssh/sock/user@2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion:22.XRUZqmyfV6BqfB0H"
too long for Unix domain socket

My ~/.ssh/config have setup like this:

  Host *
ControlPath ~/.ssh/sock/%r@%h:%p
ControlMaster auto

I log in using a commend like this:

  torsocks ssh 2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion

According to
https://stackoverflow.com/questions/35970686/ansible-ssh-error-unix-listener-too-long-for-unix-domain-socket
 >
there is a 104 or 108 character count limit on the socket path length.
The path aboev is 109 characters.

Can this limit please be raised to a higher number, perhaps 256, to
ensure such union address can be used as hostnames?

A workaround is to use '-S none' to disable the control socket, but it
is quite a a blunt hammer, and I thought it might be worth a try to ask
if you could raise the size limit instead.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1021121: not installable due to new python3-matrix-nio

[Jochen Sprickerhof]

Package: python3-pantalaimon
Version: 0.10.4-2
Severity: grave
Tags: fixed-upstream

Hi,

I've uploaded python3-matrix-nio 0.20.0 to unstable to close a security
issue. Sadly python3-pantalaimon has a versioned dependency making it
now uninstallable: python3-matrix-nio (<< 0.20). There is a new upstream
version (0.10.5) bumping just this dependency so I would propose to
rather drop the version locking.

I'm filling this bug instead as the package is already in the group.

Cheers Jochen

Bug#877805: simple-scan: Cannot re-save after rotating

[Jörg Frings-Fürst]

Hello,


I have tested it again with the latest available versions. The error is
no longer present.

Therefore I close this bug.

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1020211: version in bookworm is not affected

[Paul Gevers]

Grmml

On 02-10-2022 16:31, Paul Gevers wrote:

# this should prevent autoremoval for now
notfound 1020211 53.0+dfsg-1


Of course that didn't work. Because now the BTS treats all previous 
versions as affected. It doesn't matter, let's keep this on our radar 
and ping the bug as long as the solution is unclear but testing is 
unaffected.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021119: Acknowledgement (openshot-qt: openshot fails to open color picker in chroma key effect filter [patch available])

[Sebastian Späth]

MR to release a version with the upstream patch applied at
https://salsa.debian.org/multimedia-team/openshot-qt/-/merge_requests/2

Bug#1020211: emacspeak: FTBFS: make[4]: *** [Makefile:322: emacspeak-loaddefs.el] Error 255

[Paul Gevers]

Control: fixed -1 53.0+dfsg-2

Hi,

On Sun, 18 Sep 2022 08:52:28 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on amd64.


While this is worked around in the version in unstable, the underlying 
problem isn't. The problem is that emacs 28 has a new feature called 
native compilation. It's currently being investigated by the emacs 
toolchain maintainers how to work around properties of native 
compilation in the context of a distribution (e.g. on IRC in #d-emacs). 
Until that's done, emacs 28 will not migrate to testing, hence this 
issue (and the failure to install emacspeak in unstable, which is 
currently blocking migration of emacspeak itself) is not affecting 
testing (yet).


As emacspeak isn't using the default tool (dh-elpa) yet, we may have to 
fix the code that runs during installation ourselves, but until the 
emacs maintainers have figured out what's best in general, I propose to 
wait with fixing it in emacspeak.


Migrating to use dh-elpa will probably mean we don't need to do anything 
in emacspeak to fix the native compilation problem ourselves, but last 
time I looked into that, it didn't look trivial for emacspeak. If 
anybody wants to invest their time into the dh-elpa migration, I would 
applaud that.


For now, keep an eye on it, prevent removal of emacspeak from testing, 
and how we don't have to do too much to fix the situation once emacs is 
ready to migrate.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021119: openshot-qt: openshot fails to open color picker in chroma key effect filter [patch available]

[Sebastian Spaeth]

Package: openshot-qt
Version: 2.6.1+dfsg1-2
Severity: important
Tags: patch upstream

When adding the chroma key effect filter in openshot and trying to change the
key color from black, by double-clicking on the color, the color picker fails
to open, rendering the whole effect useless.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-
packages/openshot_qt/windows/views/properties_tableview.py", line 346, in
doubleClickedCB
currentColor = QColor(red, green, blue)
TypeError: arguments did not match any overloaded call:
  QColor(Qt.GlobalColor): argument 1 has unexpected type 'float'
  QColor(int): argument 1 has unexpected type 'float'
  QColor(QRgba64): argument 1 has unexpected type 'float'
  QColor(Any): too many arguments
  QColor(): too many arguments
  QColor(int, int, int, alpha: int = 255): argument 1 has unexpected type
'float'
  QColor(str): argument 1 has unexpected type 'float'
  QColor(Union[QColor, Qt.GlobalColor, QGradient]): argument 1 has unexpected
type 'float'
INFO main_window: Prompt user to save project

Upstream has indeed patched the line in question in March 2022 in a still
unreleased version in commit:
https://github.com/OpenShot/openshot-
qt/commit/be9a9b9faa62c66678cec4da89d00cbcc28748d8

I have verified that the patch applies cleanly to the released version of
openshot and fixes the issue at hand (the color picker opens and works).

I propose to cherry pick above upstream patch into the version that is
currently in bookworm as the chroma key effect is effectively broken in
bookworm and I don't think a new release is imminent.

I will propose a MR into the Debian packaging repo that includes this patch
soon.


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

Kernel: Linux 5.19.0-1-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 openshot-qt depends on:
ii  fonts-cantarell 0.303.1-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  python3 3.10.6-1
ii  python3-openshot0.2.7+dfsg1-4
ii  python3-pkg-resources   65.3.0-1.1
ii  python3-pyqt5   5.15.7+dfsg-1+b1
ii  python3-pyqt5.qtsvg 5.15.7+dfsg-1+b1
ii  python3-pyqt5.qtwebkit  5.15.7+dfsg-1+b1
ii  python3-requests2.27.1+dfsg-1
ii  python3-zmq 22.3.0-1+b2

Versions of packages openshot-qt recommends:
pn  blender   
ii  inkscape  1.2.1+ds-1+b1

Versions of packages openshot-qt suggests:
pn  openshot-qt-doc  

-- no debconf information
>From be9a9b9faa62c66678cec4da89d00cbcc28748d8 Mon Sep 17 00:00:00 2001
From: Richard Newsham 
Date: Tue, 22 Mar 2022 07:34:02 +
Subject: [PATCH] Properties: Ensure QColor() is passed int args

---
 src/windows/views/properties_tableview.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/windows/views/properties_tableview.py 
b/src/windows/views/properties_tableview.py
index fdaa7ee2..6d05b7dd 100644
--- a/src/windows/views/properties_tableview.py
+++ b/src/windows/views/properties_tableview.py
@@ -343,7 +343,7 @@ class PropertiesTableView(QTableView):
 blue = cur_property[1]["blue"]["value"]
 
 # Show color dialog
-currentColor = QColor(red, green, blue)
+currentColor = QColor(int(red), int(green), int(blue))
 log.debug("Launching ColorPicker for %s", currentColor.name())
 ColorPicker(
 currentColor, parent=self, title=_("Select a Color"),
-- 
2.37.2

Bug#1021120: xft: Please package new upstream version 2.3.6

[Tong Sun]

Package: xft
Version: 2.3.6
Severity: normal
Tags: sid
X-Debbugs-CC: debia...@lists.debian.org

Dear Debian xft package maintainer,

As shown in https://gitlab.freedesktop.org/xorg/lib/libxft/-/tags, the
xft upstream has released a new version 2.3.6, which is critical for
any packages based on it to handle color emoji properly, like for st.

Please consider packaging it in Debian. Thanks!

Best,

Bug#1020639: pdfarranger: libqpdf 11 require pdfarranger 1.9.1

[Jeremy Bicha]

On Sun, Oct 2, 2022 at 8:15 AM Jérémy Lal  wrote:
> i've prepared and pushed an update to salsa.
>
> I can upload it, if no one is planning to do it.

Go ahead.

Thank you,
Jeremy Bicha

Bug#1021118: ITP: golang-github-dennwc-btrfs -- btrfs library for Go

[Daniel Swarbrick]

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

* Package name: golang-github-dennwc-btrfs
  Version : 0.0~git20220403.b3db0b2
  Upstream Author : Denys Smirnov 
* URL : https://github.com/dennwc/btrfs
* License : Apache-2.0
  Programming Lang: Go
  Description : btrfs library for Go

btrfs library for Go, providing access to low-level management functions
of btrfs filesystems.

This package is a new build-dep for the btrfs collector in Prometheus
node_exporter >= v1.4.0. I will co-maintain this package as part of the
Debian Go packaging team.

Bug#1021117: llvm-15-dev: cmake fails on missing /usr/lib/llvm-15/bin/mlir-tblgen

[Andreas Beckmann]

Package: llvm-15-dev
Version: 1:15.0.1-1~exp2
Severity: serious

Hi,

while trying to package spirv-llvm-translator-15, I encountred the
following cmake error:

dh_auto_configure -- \
-DCMAKE_SKIP_RPATH=ON \
-DLLVM_EXTERNAL_SPIRV_HEADERS_SOURCE_DIR=/usr/include \
-DBUILD_SHARED_LIBS=ON \
-DLLVM_SPIRV_INCLUDE_TESTS=ON \
-DLLVM_EXTERNAL_LIT=/usr/lib/llvm-15/build/utils/lit/lit.py \
-Wno-dev
cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_SKIP_RPATH=ON -DLLVM_EXTERNAL_SPIRV_HEADERS_SOURCE_DIR=/usr/include 
-DBUILD_SHARED_LIBS=ON -DLLVM_SPIRV_INCLUDE_TESTS=ON 
-DLLVM_EXTERNAL_LIT=/usr/lib/llvm-15/build/utils/lit/lit.py -Wno-dev ..
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.0") 
-- Using SPIR-V Headers from
  /usr/include
-- The CXX compiler identification is GNU 12.2.0
-- The C compiler identification is GNU 12.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib/x86_64-linux-gnu/libffi.so  
-- Performing Test Terminfo_LINKABLE
-- Performing Test Terminfo_LINKABLE - Success
-- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so  
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) 
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14") 
CMake Error at /usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake:1634 (message):
  The imported target "mlir-tblgen" references the file

 "/usr/lib/llvm-15/bin/mlir-tblgen"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-15/cmake/LLVMConfig.cmake:329 (include)
  CMakeLists.txt:82 (find_package)


-- Configuring incomplete, errors occurred!


The corresponding find_package() call is

...
if(NOT DEFINED BASE_LLVM_VERSION)
  set (BASE_LLVM_VERSION 15.0.0)
endif(NOT DEFINED BASE_LLVM_VERSION)
...
  if(LLVM_SPIRV_INCLUDE_TESTS)
set(LLVM_TEST_COMPONENTS
  llvm-as
  llvm-dis
)
  endif(LLVM_SPIRV_INCLUDE_TESTS)

  find_package(LLVM ${BASE_LLVM_VERSION} REQUIRED
COMPONENTS
  Analysis
  BitReader
  BitWriter
  CodeGen
  Core
  Passes
  Support
  TransformUtils
  ${LLVM_TEST_COMPONENTS}
  )
...

This works fine with llvm-14 and spirv-llvm-translator-14.


If I work around this by adding a B-D: mlir-15-tools, the next problem is

CMake Error at /usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake:1634 (message):
  The imported target "MLIRSupportIndentedOstream" references the file

 "/usr/lib/llvm-15/lib/libMLIRSupportIndentedOstream.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-15/cmake/LLVMConfig.cmake:329 (include)
  CMakeLists.txt:82 (find_package)


-- Configuring incomplete, errors occurred!


Next one is 

CMake Error at /usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake:1634 (message):
  The imported target "sancov" references the file

 "/usr/lib/llvm-15/bin/sancov"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-15/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/llvm-15/cmake/LLVMConfig.cmake:329 (include)
  CMakeLists.txt:82 (find_package)


-- Configuring incomplete, errors occurred!


and now I'm stopping chasing missing 

Bug#1021093: transition: ros2-rcutils

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-10-02 00:30:41 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I'd like to transition ros2-rcutils after a SONAME bump.
> I could rebuild all reverse dependencies on amd64 successfully.
> 
> The Ben tracker at
> https://release.debian.org/transitions/html/auto-ros2-rcutils.html
> looks mostly fine, even though I would have expected ros-ros-comm in
> dependency level 2.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1021092: transition: libgit2

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libgit2.html

On 2022-10-02 00:23:25 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I'd like to transition libgit2 after a SONAME bump.

Please go ahead.

> I've rebuilt most of the reverse dependencies successfully, some
> dependencies need special attention though:
> 
> python3-pygit2 needs to be updated to be compatible with libgit2 1.5;
> as I am the maintainer I got this covered.
> 
> ruby-rugged also needs to be updated; I have filed bug #1020632 for
> this.
> 
> The Rust toolchain looks a bit weird in the Ben tracker at
> https://release.debian.org/transitions/html/auto-libgit2.html
> and I've had some issues rebuilding stuff following the dependency
> levels.

As far as I am aware, a new cargo version with all the necessary updates
for those rust packages is currently being prepared in experimental.
Those packages will need source uploads anyway.

Cheers
-- 
Sebastian Ramacher

Bug#1021090: transition: coq-hierarchy-builder

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-10-01 22:10:46 +0200, julien.pu...@gmail.com wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: jpu...@debian.org
> X-Debbugs-Cc: Debian OCaml Maintainers
> 
> 
> Hi,
> 
> there is a new version of coq-hierarchy-builder ; it requires
> rebuilding another package:
> 
>  nmu mathcomp-analysis_0.5.4-1+b2 . ANY . -m 'Rebuild because of upload
> of coq-hierarchy-builder=1.4.0-1'
>  dw mathcomp-analysis_0.5.4-1+b2 . ANY . -m 'coq-hierarchy-builder >=
> 1.4.0-1'
> 
> 
> I'm waiting for your approval to upload coq-hierarchy-builder 1.4.0-1.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1021104: RFS: simple-scan/42.5-1 -- Simple Scanning Utility

[Jörg Frings-Fürst]

Hello Adam,

many thanks for your review.

Am Sonntag, dem 02.10.2022 um 12:57 +0200 schrieb Adam Borowski:
> On Sun, Oct 02, 2022 at 10:23:31AM +0200, Jörg Frings-Fürst wrote:
> >    Package name : simple-scan
> >    Version  : 42.5-1
> 
> >  simple-scan (42.5-1) unstable; urgency=medium
> >  .
> >    * New upstream release.
> >    * Adoption of most of the points from the bug "minor cleanup"
> >  (Closes #904168).
> 
> Lintian sez:
> E: simple-scan: possible-missing-colon-in-closes Closes #904168
> [usr/share/doc/simple-scan/changelog.Debian.gz:1]
> 
> ... which is indeed too insidious to be spotted by humans. :p
> Please add the colon so the "Closes" works.
> 
☹️ Fixed and uploaded into git and mentors.


> 
> Meow!

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1021116: ITP: golang-github-dennwc-ioctl -- ioctl library for Go

[Daniel Swarbrick]

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

* Package name: golang-github-dennwc-ioctl
  Version : 1.0.0
  Upstream Author : Denys Smirnov 
* URL : https://github.com/dennwc/ioctl
* License : MIT
  Programming Lang: Go
  Description : ioctl library for Go

Lightweight ioctl library for Go, providing functions for performing
read/write ioctl operations.

This package is dependency of github.com/dennwc/btrfs, and thus an
indirect dependency of Prometheus node_exporter 1.4.0+. It appears
fairly inactive, as it is functionally complete and mature. I don't
expect it to require much maintenance going forward, however I will
co-maintain it as part of the Debian Go packaging team.

Bug#1021115: unifrac-tools: Baseline violation on x86 and FTBFS everywhere else

[Adrian Bunk]

Source: unifrac-tools
Version: 1.1.1-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian Med Packaging Team 
, Étienne Mollier 


https://buildd.debian.org/status/fetch.php?pkg=unifrac-tools=armel=1.1.1-1=1664713094=0

...
h5c++ -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -mfma -march=native -Wextra 
-Wno-unused-parameter -Wall  -std=c++11 -pedantic -I. -O4 -fPIC 
-L/<>/debian/tmp/usr/lib -c tree.cpp -o tree.o
arm-linux-gnueabi-g++: error: unrecognized command-line option ‘-mfma’
...


https://buildd.debian.org/status/fetch.php?pkg=unifrac-tools=amd64=1.1.1-2=1664716667=0

...
h5c++ -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -mfma -march=native -Wextra 
-Wno-unused-parameter -Wall  -std=c++11 -pedantic -I. -O4 -fPIC 
-L/<>/debian/tmp/usr/lib -c tree.cpp -o tree.o
...


src/Makefile:
...
ifeq ($(PERFORMING_CONDA_BUILD),True)
CPPFLAGS += -mtune=generic
else
CPPFLAGS += -mfma -march=native
endif
...



Please remove this block, it is a baseline violation on x86
and causes FTBFS everywhere else.

Please don't use the PERFORMING_CONDA_BUILD case instead:
-mtune=generic is already the Debian default on x86,
but it is not supported on some/all(?) other architectures.

Bug#1021114: FS: ipmiutil/3.1.8-2 -- IPMI management utilities

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : ipmiutil
   Version  : 3.1.8-2
   Upstream contact : [fill in name and email of upstream]
   URL  : https://sourceforge.net/projects/ipmiutil/
   License  : GPL-2+ with OpenSSL exception, BSD-2-clause,
  GPL-2+, Artistic-2.0, Zlib, BSD-3-clause
   Vcs  : https://jff.email/cgit/ipmiutil.git
   Section  : utils

The source builds the following binary packages:

  ipmiutil - IPMI management utilities

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmiutil/ipmiutil_3.1.8-2.dsc

or from 

 git https://jff.email/cgit/ipmiutil.git?h=release%2Fdebian%2F3.1.8-2


Changes since the last upload:

 ipmiutil (3.1.8-2) unstable; urgency=medium
 .
   * debian/patches/0700-init.patch (Closes: #1020558):
 - Fix insert of /lib/lsb/init-functions.
   * Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
   * debian/copyright:
 - Add year 2022 to myself.
   * debian/source/lintian-overrides:
 - Fix typo.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1020942: debian-live: Reconsideration of Calamares installer on the next stable of Bookworm

[Jonathan Carter (highvoltage)]

Hi

On 2022/09/29 08:52, Green wrote:

Calamares installer should act properly to NOT install unneeded large amounts 
of locales by default; on the contrary other distribution's installer like in 
Fedora or MX Linux behave quite properly.


I agree, this is among a few other issues, my #1 issue with Calamares on 
our live media right now. For what it's worth, debian-installer exhibits 
the same behaviour on our live media.



If this problem is not easily solved, I would like to propose to replace the 
present calamares with Gazelle-installer developed by MX dev, instead. It seems 
that Gazelle-installer is quite a nice installer without such a problem.


I took a look at it again, it solves /some/ of Calamares's problems, but 
it also brings in new ones. I think it's fine (and even great) if 
someone packages gazelle-installer for Debian, but since we're edging 
closer and closer to freeze date, I don't think we're likely to switch 
to it for Bookworm. By Trixie, I hope to have a much better long-term 
solution in place.


-Jonathan

Bug#1021113: libgrpc22 in experimental needs a rebuild with newer libabsl

[Pirate Praveen]

Package: libgrpc22
Severity: serious
Version: 1.44.0-3

Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 69949
(I)Dose_applications: Cudf Universe: 69949 packages
(I)Dose_applications: --checkonly specified, consider all packages as 
background packages

(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 status: broken
 reasons:
  -
   missing:
pkg:
 package: libgrpc22
 version: 1.44.0-3
 architecture: amd64
 unsat-dependency: libabsl20210324:amd64 (>= 0~20210324.2-1)
depchains:
 -
  depchain:
   -
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
depends: ruby-grpc:amd64 (>= 1.42~)
   -
package: ruby-grpc
version: 1.44.0-3
architecture: amd64
depends: libgrpc22:amd64 (>= 1.44.0)

background-packages: 69948
foreground-packages: 1
total-packages: 69949